神策 FM | 数据驱动时代，你的岗位如何转变？
作者簡介：桑文鋒，神策數據創始人兼 CEO。
在 19 世紀下葉，有種崗位非常吃香，就是電報員。
年輕的愛迪生就做過電報員的工作，敲動按鍵收發電報，仿佛今天的程序員。可遺憾的是，這種職業持續了幾十年，隨著電話的出現，逐步被淘汰了。
在 10 年之前，春節回家買票是很困難的，黃牛很吃香，可后來有了 12306 和實名制，斷了黃牛們的財路，“職業黃牛”逐漸下崗。
我最早參加工作時，覺得做程序員挺悲劇的，需要天天對著電腦，可是現在放眼望過去，又有多少白領的工作是不用整天對著電腦的呢？
圖 1 圖片來源于網絡
崗位在變，崗位要求也在變，沒有東西是恒定不變的。
隨著數據驅動時代的到來，對各種崗位的要求，也在悄然變化。我這里探討的是互聯網領域中，崗位在數據能力要求上的轉變，包括產品經理、研發工程師、運營經理、市場經理、數據分析師、管理者等。
一、產品經理
2010 年，一本《人人都是產品經理》在互聯網圈子吹了個遍，一下子給許多人帶來了希望，原來還有產品經理這么一個崗位，看起來很不錯啊，紛紛決定當產品經理。
在這之前，產品經理這個崗位在幾家大的互聯網公司存在已久，但也不過是 2000 年之后的事情，之前更是沒有這個崗位。如何成為一名優秀的產品經理，相關的培訓和書籍也已經比較多了，網上更是很多類似的文章。
圖 2《人人都是產品經理》
可在數據驅動時代，對產品經理又有什么要求呢？那就是用數據說話的能力。
我在 2007 年入職百度知道做研發工程師，入職第一天，就發現郵箱里收到了幾十封報表郵件，包括百度知道的提問量、回答量、Session 數、檢索量等。我心想：這樣的核心數據怎么連我這種剛入職的新人就能看到？后來才知道，原來“用數據說話”就是百度的文化。
一個產品功能要不要做，一個軟件模塊性能如何，都要用數據說話。
曾經有幾個月時間，我只為了將百度知道用戶提交失敗的次數從 100 降低到個位數費盡周折。
產品經理在進行需求評審時，都會有專門的一塊內容，就是“統計需求”。在評審會上，產品經理和研發工程師會討論需要用什么數據做支撐，以及統計的口徑是什么。
等項目上線之后，就開始分析實際數據是否和預期相符，如果不相符，就要尋找問題出在哪里，并且通過分析出的問題進行改進，然后再進行數據驗證。
可以說，不只是要有數據意識，還要在工作中形成數據驅動的流程。
我這兩年接觸的產品經理中，許多都向我反饋——數據采集需求推不動研發工程師，我一問詳情，才知道往往是產品上線以后，產品經理才提出了數據采集和分析的需求，而這個時候工程師早就把要做的工作做完了。
在這種時間點提出需求，感覺是在打補丁，配合的不好。
這其實反映一個問題，就是產品經理在提出產品需求時，并沒有做足夠的數據需求梳理。相當一部分同學是把這件事放在業務上線之后，可偏偏這個工作要提前做，不能懶惰。
當然，肯定有許多數據需求是事先想不清楚的，這種不可避免，但如果前期數據需求在產品需求解決中溝通得比較好，兩邊配合也要好很多。
有本書叫《精益創業》，我推薦每個產品經理都讀一讀，它里面核心講解了兩個概念，一個是 MVP，做最小可用產品，另一個就是把數據分析引入到產品迭代中，形成點子 - 產品研發 - 數據分析 - 點子的循環。
二、研發工程師
產品經理和研發工程師是一對共同體，不可割舍但又矛盾重重。前面說了產品經理的問題，這里反過來看工程師的問題。
許多時候，產品經理提出數據需求時，工程師反饋的內容是——很忙，比如正忙著迭代功能，產品經理的需求要晚一點再做。可是如果開發的功能不能夠用數據做驗證，那開發本身又有多少意義呢？
我曾經看過一篇文章對比硅谷和北京，里面提到北京的創業氛圍要比硅谷拼得多。但是也提到一個問題，很多同學只忙著開發功能了，卻沒有做必要的數據收集。這同樣也是個基本的問題，就是數據驅動時代，對工程師的要求變了。
我剛入職百度時，會有一項培訓，就是教你如何打日志。所謂日志，就是用戶做的每一個請求，后臺都要記錄下來，比如什么時間來自什么 IP 地址的用戶訪問了什么頁面，類似這樣的記錄。
這些日志有兩個作用，一是當服務出現故障時，可以通過日志分析請求參數是什么，導致了后來出現了什么異常，二是用于用戶使用情況統計。
我在學校時總覺得類似這樣的處理會極大的降低服務器的性能，可實際工作中發現完全不是這樣，并且發現日志真是一個偉大的存在。我自己在百度的工作也是一直圍繞日志處理的，最開始主要用于開發調 Bug，后來變成了分析業務情況。
在信息化建設時期，我們開發一個軟件模塊，主要為了解決業務流程的一個需求，通過人和軟件模塊結合，形成整個業務流程。可在數據化建設時代，我們可以理解為軟件模塊都是為了服務數據流，所有的開發工作都是在建設溝渠，為了讓數據之流能夠順暢流通。
這是一種巨大的思維轉變。
許多公司的軟件系統也會產生數據，但更多的是為了支撐業務運轉。所謂的數據打通不過是在長江黃河之間，加了一條直徑 10 厘米的管子，以此就說長江黃河已經打通，這是不對的。
一名優秀的軟件工程師，要把數據收集和模塊開發看做同等重要的事，要鍛煉自己的數據思維。
三、運營經理 & 市場經理
廣義的運營是無所不包的，拉新、留存、變現等都是運營要做的事情，COO 的職責更是大管家，讓一切有序運行。許多公司是把拉新放在第一位的，所以都會有專門的市場部門，服務于品牌和拉新。而運營經理側重于盤活已有用戶。
我當時所在的百度新產品部，像知道、百科這樣的產品，直到 2009 年左右才有專門的運營崗位，之前都是產品經理兼任的。
市場投放效果如何？不是看著是否花哨，還是要看實際帶來的效果如何，需要計算 ROI（投入產出比）。在 To B 領域，往往市場團隊和銷售團隊容易有矛盾，市場抱怨銷售浪費了線索，而銷售抱怨市場拿來的線索質量不行。
圖 3 圖片來源于網絡
這里核心的問題在于沒有將兩者的工作都數據化，并且形成反饋機制。
市場效果的考核不是以下載量或留下聯系方式這樣的基礎觸達指標，而是要以銷售團隊的確認為標準。銷售團隊最終轉化的情況，要及時反饋到市場團隊，這樣市場團隊及時對活動、渠道做出調整，這樣形成有效的聯動。
用戶的盤活，核心在于對不同人群采用不同策略，極端情況是針對每個用戶都能夠個性化策略。
這個過程，運營經理就要對用戶根據一些維度進行劃分，采用不同策略，并且在采用動作后，還要收集數據反饋，確認之前的劃分標準和策略是否有效，及時做出調整。這里面都是需要數據做支撐的，需要善于利用數據。
四、數據分析師
作為數據分析師，在這個時代是幸運的，以后沒有公司不需要數據分析師。
但與此同時，對數據分析師的要求也在提升。過去的定位往往是“取數”，就是業務人員有了數據需求，提交給分析師，然后分析師把結果返回過來。這樣的事情，應該用工具來替代。
數據分析師的工作決不能停留于此，而是要更進一步，每次收到一個數據需求時，多問一句，背后的“業務需求”是什么？
因為每個數據需求都是一個點，就像產品經理出了一次拳，背后是為了達到某個目的。如何獲取到這背后的目的信息，數據分析師就會發揮自己對數據理解和敏感的優勢，不只是局限在業務人員的單一取數需求，可以提供更多維度的數據，來幫助業務人員做出判斷。
并且了解了業務需求，可以做出預判，在工作中提前做好準備，而不是經常加班來滿足一些意想不到的需求。
五、管理者
要形成數據驅動的文化和氛圍，老板具有決定性的影響。
可以設想，一線員工廢了很大功夫做出一份數據報告，可老板看了之后還是憑個人感覺做出了決策，員工還會再好好準備數據嗎？相反，如果每次開會討論，都是先問數據情況怎么樣、基于數據我們能做出什么樣的判斷，整個公司上下都會很容易形成數據驅動的氛圍。
這里說來就一句話，但做起來卻是最難的。
通過以上的探討，希望能夠激發你重新思考自己的崗位需求，到底是否能符合日益變化的職位要求。如果現在的你就是 19 世紀下葉電報員，那么你是不是要開始做出什么變化了。
號外！更多精彩聲音，可關注
神策 FM
?『點擊圖片，解鎖更多精彩』
▼▼▼
內容不錯，記得戳好看哦?↓↓↓
總結
以上是生活随笔為你收集整理的神策 FM | 数据驱动时代，你的岗位如何转变？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 你的 A/B 测试数据期骗你了吗？
- 下一篇： 他们的背后，是我们！