對于企業來說，要建設自己的大數據平臺，需要的不只是技術解決方案，更重要的是組建一支優秀的數據團隊。那么，數據團隊有哪些成員組成？他們的工作方式是什么？采用怎樣的組織架構來開展工作？

　　1. 數據團隊成員

　　這里只討論數據團隊中核心成員的角色和他們的工作職責。

　　1）基礎平臺團隊

　　主要負責搭建穩定、可靠的大數據存儲和計算平臺。

　　核心成員包括：

　　數據開發工程師

　　負責Hadoop、Spark、Hbase和Storm等系統的搭建、調優、維護和升級等工作，保證平臺的穩定。

　　數據平臺架構師

　　負責大數據底層平臺整體架構設計、技術路線規劃等工作，確保系統能支持業務不斷發展過程中對數據存儲和計算的高要求。

　　運維工程師

　　負責大數據平臺的日常運維工作

　　2）數據平臺團隊

　　主要負責數據的清洗、加工、分類和管理等工作，構建企業的數據中心，為上層數據應用提供可靠的數據。

　　數據開發工程師

　　負責數據清洗、加工、分類等開發工作，并能響應數據分析師對數據提取的需求。

　　數據挖掘工程師

　　負責從數據中挖掘出有價值的數據，把這些數據錄入到數據中心，為各類應用提供高質量、有深度的數據。

　　數據倉庫架構師

　　負責數據倉庫整體架構設計和數據業務規劃工作。

　　3）數據分析團隊

　　主要負責為改善產品體驗設計和商業決策提供數據支持。

　　業務分析師

　　主要負責深入業務線，制定業務指標，反饋業務問題，為業務發展提供決策支持。

　　建模分析師

　　主要負責數據建模，基于業務規律和數據探索構建數據模型，提升數據利用效率和價值。

　　2. 數據團隊的工作方式

　　數據團隊的工作可以分成兩大部分，一部分是建設數據存儲和計算平臺，另一部分是基于數據平臺提供數據產品和數據服務。

　　平臺的建設者包括三種人群：基礎平臺團隊對hadoop、spark、storm等各類大數據技術都非常熟悉，負責搭建穩定、可靠的大數據存儲和計算平臺。數據平臺團隊主要負責各類業務數據進行清洗、加工、分類以及挖掘分析，然后把數據有組織地存儲到數據平臺當中，形成公司的數據中心，需要團隊具有強大的數據建模和數據管理能力。數據產品經理團隊主要是分析挖掘用戶需求，構建數據產品為開發者、分析師和業務人員提供數據可視化展示。

　　平臺的使用者也可以包括三種人群：數據分析團隊通過分析挖掘數據，為改善產品體驗設計和商業決策提供數據支持。運營、市場和管理層可以通過數據分析師獲得有建設性的分析報告或結論，也可以直接訪問數據產品獲得他們感興趣的數據，方便利用數據做決策。數據應用團隊利用數據平臺團隊提供的數據開展推薦、個性化廣告等工作。

　　3. 數據分析團隊的組織架構

　　在整個大數據平臺體系中的團隊：基礎平臺、數據平臺、數據應用和數據產品經理團隊都可以保持獨立的運作，只有數據分析團隊的組織架構爭議比較大。數據分析團隊一方面要對業務比較敏感，另一方面又需要與數據平臺技術團隊有深度融合，以便能獲得他們感興趣的數據以及在數據平臺上嘗試實驗復雜建模的可能。

　　從他們的工作方式可以看出，數據分析團隊是銜接技術和業務的中間團隊，這樣的團隊組織架構比較靈活多變：

　　1）外包

　　公司自身不設立數據分析部門，將數據分析業務外包給第三方公司，當前電信行業，金融行業中很多數據分析類業務都是交給外包公司完成的。

　　優勢： 很多情況下，可以降低公司的資金成本和時間成本；許多公司內部缺乏相關的知識與管理經驗，外包給專業的團隊有助于公司數據價值的體現 。

　　劣勢：一方面外包人員的流動和合作變數，對數據的保密性沒有保證；另外一方面，外包團隊對需求的響應會比較慢，處理的問題相對通用傳統，對公司業務認知不如內部員工深入，創新較低。

　　2）分散式

　　每個產品部門獨立成立數據分析團隊，負責響應自己產品的數據需求，為業務發展提供決策支持。

　　優勢：數據分析團隊與開發團隊、設計團隊以及策劃團隊具有共同的目標，團隊整體歸屬感強，績效考核與產品發展直接掛鉤，有利于業務的發展。

　　劣勢：在業務規模比較小的情況下，數據分析師比較少，交流的空間也比較小。因為身邊的同事都不是該領域的人才，無法進行學習交流，所以成長空間會比較小，分析師的流失也會比較嚴重，最終陷入招募新人——成長受限——離職——招募新人的惡性循環。另一方面，每個產品團隊都零星地招募幾個分析師，整體來看給員工的感覺是公司并不是特別重視數據化運營的文化，對數據的認同感會被削弱，不利于公司建立數據分析平臺體系。

　　3）集中式

　　數據分析團隊與產品團隊、運營團隊各自獨立，團隊的負責人具有直接向分管數據的副總裁或CEO直接匯報的權限，團隊負責響應各業務部門的數據需求。

　　優勢：分析團隊具有充分的自主權，可以專心建設好公司級別的數據平臺體系，研究數據最具有價值的那些問題，有權平衡業務短期需求和平臺長期需求直接的關系。另一方面，這種自上而下建立起來組織架構，可以向全體員工傳達數據在公司的重要位置，有利于建立數據化運營的文化。

　　劣勢：產品業務團隊會覺得他們對數據的掌控權比較弱，一些業務數據需求得不到快速響應，認為分析團隊的反應太慢無法滿足業務發展的需要。隨著業務發展越來越大，產品團隊會自己招募分析師來響應數據需求，逐漸替代分析團隊的工作，這樣勢必會導致分析團隊的工作被邊緣化。

　　4）嵌入式

　　數據分析團隊同樣獨立于產品團隊存在，但只保留部分資深數據專家，負責招聘、培訓數據分析師，然后把這些人派遣到各產品團隊內部，來響應各類業務數據需求。

　　優勢：團隊的靈活性比較好，可以根據公司各業務線的發展情況合理調配人力資源，重點發展的項目投入優秀的人才，一些需要關閉的項目人才可以轉移到其他項目中去。

　　劣勢：分析師被嵌入到產品團隊內部，受產品團隊主管的領導，從而失去了自主權，導致淪落為二等公民。人事關系在公司數據分析團隊中，卻要被業務團隊主管考核，但業務團隊主管并不關心他們的職業發展，導致分析師的職業發展受到限制。

　　那么，到底采取哪一種組織架構比較合適呢？

　　可以根據公司數據化運營進展的深度靈活采取一種或幾種方式。除了外包模式，其他組織架構我都經歷過，簡單來說，早期采用分散式、中期采用集中式、后期采用分散式或嵌入式以及兩則并存。

　　早期：公司對數據體系的投入一般是比較謹慎的，因為要全面建設數據體系需要投入大量的人力和財力，公司不太可能還沒有看清楚局勢的情況下投入那么多資源。所以，往往都是讓每個產品團隊自己配置分析師，能解決日常的業務問題就行。杭研院早期的網易云閱讀、印像派等項目中就是采用的這種分散的模式。

　　中期：隨著業務的發展、公司對數據的認識有所提高并且重視程度不斷加大，就開始愿意投入資源來構建公司級別的數據體系。這個階段采用集中式有利于快速構建數據分析平臺，為公司各個產品團隊提供最基礎的數據分析體系，能在未來應對業務的快速發展。杭研院花了兩年時間完成了這個階段的主要工作，并在網易云音樂和易信產品發展階段起到了至關重要的作用。

　　后期：一旦公司級別的數據分析平臺構建完成，消除了早期分散模式中分析師缺少底層平臺支持的窘境，他們能夠在分析平臺上自助完成大量的數據分析工作。而且經歷過集中式階段的洗禮，公司上上下下對數據的認識都有了很大的提高。此時，在回到分散模式時，原先的很多弊端已基本消除，此外，采用嵌入模式也是可以的。目前杭研院在網易云音樂、網易云課堂、考拉海購等幾個產品中就是分散式和嵌入式并存的架構。

　　總之，沒有最好的組織架構，只有適合自己的組織架構。

　　【作者介紹　沈琦：網易杭州研究院商業智能部門總監、大數據技術專家　自2007年畢業以來，一直在網易杭研院從事大數據技術的相關工作，現擔任商業智能部門總監，負責管理杭研院和考拉兩個商業智能團隊，在大數據技術和部門管理方面都具有豐富的經驗。商業智能部門負責網易數個億級用戶產品的數據分析工作，覆蓋考拉海淘、云音樂、云課堂、云閱讀和易信等眾多網易明星級產品。】