互聯網數據崗位定位與分工

最近面試了幾個BI數據分析師的求職者，能力上自是各有長短，甚至有那麼兩三位感覺在專業上也是把我碾壓了一番，簡短不足一小時的溝通，也是讓自己收益頗豐，更是感慨於自己決不可懈怠；

但是隱隱約約也覺察出一個共通的問題——當下大多數互聯網數據人才對自己的職業發展似乎並沒有一個比較明確的方向和界限，這一點在數據分析師和數據PM身上尤為突出；

我們的簡歷上明確寫著之後的工作範疇是「構建業務指標體系，進行業務數據分析」；對職位需求也是重業務理解和分析思路，數據技術要求有但是並不嚴苛。

但最後我們收到的簡歷，五花八門，數據分析師、數據PM不一而足，其中數據開發類的求職也不乏少數（BI工程師、架構師、ETL工程師）。

其中一名面試者，來自於筆者上一家公司，起初溝通過後感覺資質不錯，且也有不少過人之處。但明確問了希望做的工作之後，均是報表開發、ETL需求設計偏數據PM之類的內容，對於做業務數據分析反而鮮有提及。最後只能遺憾告之需求崗位與候選人想做的事情還是有一些偏差。

想起自己二流本科統計學畢業，有幸從畢業後一直做的與專業相關的工作，title換了好幾次，但是都是圍著數據打轉，常常自嘲做了X年的婊。之前只是秉著對專業的熱愛，覺得能一直做自己的專業用自己的專業就很好，也並沒有深入思考過幾份工作刨掉數據內核之後的外在區分和方向。直到去年從前公司跳槽，花了不少時間沉澱了下這幾年的收穫，加上網上資料和前輩諮詢，隱約明白大數據雖然興起才幾年，但當前已經逐漸出現了崗位界限，尤其是在已經成熟的大廠，一張線上報表的呈現，早不是一個開發包辦的時代。而基於界限在單點上的方法論總結，也早已零零總總，雖然談不上統一標準，但是確實已經在逐漸形成完善的專業體系。躊躇一番之後，也終於為自己明確了近三年要深挖的點——數據PM；於是當時拒了某大廠的業務分析，接受了現公司的數據運營offer，究其原因，無非現公司的崗位描述里，確實是比較偏數據PM的。

在新公司本身也是配合技術、支援業務的做數據體系搭建，整個過程本身就包含了對數據體系中各個人定位和分工的確認。因此將近一年以來，除了惡補各種數據架構、產品方面的知識，也並沒有停止對數據崗位定位和分工的思考；

要說關於互聯網的數據崗位介紹，網上資料不少，或者光看拉鉤和BOSS直聘上的JD也大概能總結出個一二，比如之前的這篇文章（http://6bfd759b.fromwiz.com/share/s/1H_nmr0YeA322Mqbn504wTNh3CNLJK09Ekn129sanl1awzer）《大數據知識體系大全》，簡單的羅列了大數據涉及到的工作模塊，並按照模塊給出了一些崗位描述。但筆者總感覺分工不夠具象，對於大廠的數據人來說，很多level不算太高的初級分析師並不能也不需要一下子接觸到大數據的全貌，而對於小廠的數據人來說，很有可能並沒有見過也無法想像諸如SPARK、數據平台、數據倉庫等大數據相關應用。那麼自然而然，關於架構師、工程師、數據PM、可視化等等一系列稱謂，也只能存在於概念中，並不能給數據人很好的指明方向和界限；

基於以上，筆者嘗試分享一下自己關於這方面的思考，如有不妥，歡迎指正；

一、梳理數據工作邏輯

要理解互聯網數據崗位的分工，我建議我們首先為自己梳理一下數據支撐業務的基本邏輯，在這裡我將其分為業務流和架構模型：

1.業務流：

所謂業務流，就是我們在工作中數據支持具體業務的基本工作流程，相信絕大部分公司數據對業務的支撐主要都是提供數據（包括分析數據和業務系統接入數據）和提供業務分析報告；

我們常常看到的場景是這樣的（業務分析報告的產出）：

業務方：分析師，我們計劃搞一次促銷活動，你可否看一下靠不靠譜，預期怎麼樣？

分析師（拿出業務需求文檔）：工程師，麻煩幫我跑個數，巴拉巴拉。。。。

工程師：噠噠噠噠（寫代碼中）；

分析師（拿出PPT）：數據顯示，我們之前做的促銷活動轉化率基本在X到Y之間波動，相比非促銷期間平均提升Z個百分點。同時如果我們按人群特性分組，會發現A人群的轉化率巴拉巴拉。。。。

我們也常常遇到這樣的場景（數據提供）：

業務方：分析師，我們可能有一個長期的策略要搞一搞，你這裡記得幫我們定期做好數據監控；

分析師（拿出業務需求文檔）：數據PM，我們最近有個長期的策略要搞，所以要上一個報表和一些儀錶盤，大概想看這些數據；

數據PM（數據PRD）：工程師，我們最近要上一個報表和一些儀錶盤，基本的交互和數據邏輯是這樣的；底層數據我們可能要做一些運算和存儲，方便業務方快速回溯和查詢，數據來源和加工邏輯是這樣的；

工程師：噠噠噠噠（寫代碼中）；

我們可以把以上業務流簡單的抽象一下，就是下面這個流程：

2.架構模型：

所謂架構模型，就是在企業中，數據從採集到呈現所要經過的基本流程以及流程涉及的相關技術；這方面涉及比較深的技術內容，筆者本身屬於非技術出身，對於大數據相關技術，目前也僅停留在了解甚至聽說階段，在此不便做過多解釋；

我們可以看下當下主流企業的架構模型：

這樣的：

或者這樣的：

實際上，各個公司根據自身的特點或者規模，具體採用的技術千差萬別。大廠一般基於Spark+hadoop進行計算，但在實際的ETL加工中，有些直接使用的第三方成熟ETL套件如Congos、Kettle等，有些則是直接將sql建表語句定時化充當ETL使用；而很多創業公司則是乾脆沒有數據倉庫，直接每天從業務庫把數據100%copy到本地，然後再利用定製化腳本輸出為表格呈現；亦或者自己即不做數據本地存儲也不寫定製腳本，直接利用第三方工具如growingIO、神策等系統採集並分析數據；

但我們對這些看似形態各異、技術選型不一的數據架構剝絲去繭，實際發現，整個數據從採集到應用的過程，無非就是下面幾個環節：

二、明確具體分工

梳理了數據工作邏輯，我們便可以從業務流和架構模型上明確各個崗位的分工：

1.業務流

業務需求——數據分析師：一般在業務序列下，為業務服務，負責根據業務方的業務邏輯，確定業務指標，產出業務需求文檔，給到數據PM；拿到數據後，還要負責根據數據輸出數據分析報告；

數據（產品）需求—— 數據PM：一般在企業的數據部門下，是數據部門的需求和項目介面，拿到分析師給的業務需求文檔後，會將業務需求轉換為數據或者產品需求文檔（相比分析師產出的業務需求，數據PM一般還需要考慮數據的底層邏輯、報表的前端交互等偏邏輯細節上的東西），給到數據開發；

技術實現—— 數據開發：拿到數據PM的數據需求文檔或數據PRD後，用代碼提取數據或將數據產品實現；

2.架構模型

數據採集層，一般涉及三類崗位：

數據產品經理：負責提出數據採集的需求，比如數據採集中最基本的埋點需求；

前/後端工程師：負責實施數據產品經理提出的埋點需求；

大數據架構師：幾乎貫穿了整個數據架構的角色，埋點發送機制、數據接收機制、數據接收後的運算存儲機制，都在架構師的掌控之內；

數據存儲和加工層，一般涉及四類崗位：

數據產品經理：負責設計和提出支撐業務及產品的數據加工需求（可以理解為ETL）；

大數據架構師：數據的加工本質是數據在大數據架構中的計算過程，架構師需要保證架構性能能夠支撐這種需求；

ETL工程師：負責用代碼實現數據產品經理輸出的數據加工需求；

數據挖掘：有一些數據加工需求本身就是數據挖掘，或者需要調用部分數據挖掘的演算法，這些需求現在有一部分從資料庫管理員轉型過來的ETL工程師是暫時無法實現的；同時有相當一部分的數據挖掘工程師本身技能樹可能是R和python比較強勢而資料庫語言偏弱；所以出現了一些公司數據挖掘和ETL工程師搭檔工作的情況；

數據應用層，一般涉及三類崗位：

數據產品經理：負責前端數據產品的需求梳理，比如報表平台、儀錶盤的PRD輸出；

數據分析師：負責業務方的常規數據支持，業務數據梳理和數據分析；

數據可視化工程師：負責前端數據產品的開發；

三、特別說明

需要說明的是，雖然我們在前文按照業務流和架構模型將數據崗位的職責和界限做了貌似比較明確的界限，但在實際工作的過程中，這些界限更多的是內容的劃分，而不是崗位的劃分；

實際在大部分的公司，哪怕是有明確不同title的大廠，崗位之間有界限，但是界限也不一定是按照筆者所述的方式劃分，以下列舉幾種常見的情況：

1.數據分析師在業務流上一人解決所有問題的情況：

在很多初創企業，數據基礎設施偏弱，但是老闆和業務方的數據意識都還不錯，這個時候往往會有數據分析師一個人把業務流上所有事情都負責的情況，有些企業不一定叫數據分析師，比如筆者現在的數據運營其實就有點這種味道；這樣的企業，數據分析師也不需要梳理什麼業務需求文檔，牛逼的分析師自己就能撰寫數據提取腳本（sql、python）從本地或線上業務庫提取數據，然後輸出數據分析報告； 一般的分析師則會直接與數據開發溝通，由開發代為提取數據，最後根據數據輸出分析報告；

2.業務人員充當分析師的情況：

不管大廠還是小廠，都有業務人員直接充當分析師的情況；筆者之前的一家公司，數據基礎極為完善，業務發展迅猛，很多時候業務組自己的分析師並不能滿足快速發展的業務需求，迫使業務組運營及產品人員人人自帶sql技能。於是在開展項目過程中，也就時常會出現業務人員自行撰寫業務需求文檔與數據PM對接、業務人員自行撰寫數據提取腳本完成數據分析工作的情況；

3.業務流上，數據開發充當數據分析師的情況：

這種情況一般出現在初創企業（筆者沒見過哪個大廠有這種情況）。這類企業的業務人員通常不會將業務需求轉化為數據需求再與開發對接，通常直接向數據開發提出業務需求，然後開發根據自己對業務的理解，將業務數據化之後，進行數據提取。部分企業的數據開發在這個流中可能還是只做數據提取工作，但也有少部分企業會要求數據開發輸出數據分析報告，承擔數據監控的責任；

4.架構模型上，數據開發充當數據產品經理的情況：

數據產品經理（數據PM）實質是近一兩年才大規模出現的title，通常現在是大廠才會明確定義該職位的界限。多數企業的報表開發、儀錶盤開發、ETL需求設計等現在偏數據產品類的工作，早先一般根據公司不同會被劃分到數據分析師或者數據開發的職責範疇；目前了解到初創企業一般是歸在數據開發名下。

5.架構模型上，分析師充當數據挖掘的情況：

事實上，高階的數據分析師一般都具備數據挖掘的能力，低配工具一般是SPSS，標配得會R，高配的會pythonsas。很多數據分析師在進行分析和撰寫報告時，會直接應用挖掘演算法輸出結論。

綜上各種特別情況，筆者只是將數據工作的內容進行了比較粗糙的模塊化，並做了一定職位上的關聯，便於我們去定位自己更喜歡和傾向於哪個模塊，重點在於通過事去明確自己的定位，然後在某個點上去做更深的專研，而不是讓大家根據自己現在的title去給自己設限。

四、能力模型要求

1.分析師：

事實上，就算從具體研究方向上，分析師也可以基本分成兩類：數據分析師、商業分析師；

數據分析師：最常見的分析師，主要服務於業務部門，分析方向以業務和項目研究為主；能力上要求有很強的業務sense，能夠快速理解業務，找到業務中的關鍵指標，明確分析思路；技能上一般是微軟套件、sql；

商業分析師：業務分析師高階版，企業內一般服務於戰略層，分析方向以企業戰略和市場為主；能力上除了數據分析師的必要能力外，還需要有足夠的行業視野和商業敏感度；技能上一般是微軟套件、tableau、R；舉個和數據分析師的區別——一般商業分析師都會看統計年鑒，數據分析師可能不需要；

2.數據PM：

一般由一定階段的數據分析師成長而來，筆者目前沒有見過沒做過數據分析的數據PM，基本上根據架構模型分三個方向：可視化、數據倉庫、大數據；

可視化：與傳統產品經理最接近的數據產品經理，做過基本的數據分析工作，掌握基本的產品方法論，了解數據從存儲層到應用層的運算邏輯；技能上一般是微軟套件、sql、流程圖、Axure等原型工具；

數據倉庫：做過基本的數據分析工作，對於數據生產的整個流程足夠了解，資料庫語言肯定要比一般的分析師要強，了解大數據和數據挖掘，懂主流的商業智能和數據倉庫相關理論；技能上一般是微軟套件、sql、流程圖、R、sas；

大數據產品經理：筆者見過的大數據產品經理一般都是數據開發出身，所以理解該崗位可能還是偏技術向。因為筆者技術功底較弱，不便評價；

3.數據開發：

基本可以歸結為三大類：數據挖掘、可視化工程師、架構師（在很多企業同時擔當ETL工程師的角色）；

本身因為專業原因，對數據挖掘還知曉一二，明確sql、R、python等皆屬於剛需技能，同時還需要一定的業務理解能力，行業上對於主流的資源庫要有了解。

至於其他開發崗位，礙於當前專業素養和能力限制，了解不夠，不便評價；

關於邏輯能力。。。如果邏輯思維能力差的話，真的不適合做數據，隨便數據啥都不適合。

四、總結

數據類崗位隨著互聯網的興起而興起，伴著互聯網下半場的到來，精細化運營對數據的依賴，加速了崗位的專業化進程；筆者尤記得2012年畢業時在大街網上搜索數據崗位，數據分析師都不算多，作為國家統計局直屬院校統計專業畢業生，筆者的同學大部分不是進了銀行就是考了各級統計局。筆者一人悻悻然從西安跑到北京，入職的第一個title是商品專員（依賴數據對商品進行管理）；那時數據更多的還是屬於運營人員的某項加分技能而存在；等到2013年，數據分析師已經基本成了互聯網企業的一個獨立崗位。之後莫名的一堆技術向的數據崗位映入眼帘，再之後突然又冒出了商業分析師、數據產品經理等一系列概念，昭示著數據工作確實在越來越精細化和專業化，從統計走向分析，分析又衍生出產品；

產品、運營、技術在中國的互聯網史上也並不是一開始就分工明確的。我們知道OICQ最早就是小馬哥自己即做產品又寫代碼還要負責陪聊做運營；後來三者分離，而內部也在分工，比如產品就分前端產品、供應鏈產品；運營又分用戶運營和產品運營；技術更是根據支撐環節不同早已界限明確。數據最早是作為產品和運營的支撐角色出現的，而如今但凡有點規模的企業中早已是個獨立的崗位，那麼之後數據內部的專業化和精細化具體會怎麼分化呢？以上，是我的總結和思考，歡迎大家共同討論和指正；

推薦閱讀：