神策 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 测试数据期骗你了吗?
- 下一篇: 他们的背后,是我们!