起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識數據中臺實戰入門篇：數據中臺對內、對外合作機制
上一篇文章講了《數據中臺實戰入門篇：雙中臺戰略》，主要解決了什么是中臺、什么是數據中臺、業務中臺、什么公司適合搭建雙中臺體系這幾個問題。本篇文章講一下數據中臺的人員構成、內部如何合作、數據中臺的項目管理、數據中臺如何與運營部門合作這幾個問題。
數據中臺人員構成
架構師：架構師是整個數據中臺團隊的技術負責人。涉及到大的模塊比如標簽平臺、推薦，要拿到業界比較成熟的架構設計，這樣有個參考，能避免我們踩很多坑。另外包括技術選型比如大數據常用的計算框架spark、handoop等用那個比較合適，還有一些需要攻關的技術難題都需要協調他來解決。
項目經理：項目經理要和架構師一起排團隊的開發計劃。保證讓每個任務在時間節點完成，他要更加了解團隊的每個成員的特點，最大的發揮團隊成員的優勢。另外關于項目的質量、風險都需要項目經理制定合理的流程來保證。
產品經理：數據中臺的產品經理對外要和運營的同事混熟，了解整個產品現在的策略，節奏是什么，這個時期關注的最核心的指標有那些。對內要將產品的方向、功能用偏技術的語言和開發溝通清楚，保證產品價值的最大化。
模型設計師：模型設計是數據中臺比較重要的一環，底層模型的好壞直接決定數據中臺數據指標的質量和可擴展性。一個好的模型設計師需要對產品業務流程比較熟悉，對每條產品線的數據存儲比較熟悉，需要和產品配合，一起摸清每個指標的開龍去脈，并將模型的思路，計算的方式清晰的告訴數據開發。全方面、多維度的建模是數據中臺的基礎，數據模型設計師是相對來說數據中臺中比較核心的職位。
數據開發工程師：他們主要和模型設計師打交道，模型設計師把業務口徑轉化為技術口徑，告訴他們每個指標應該從那里提取數據，怎么計算。他們將計算的結果一層一層匯總，最終要和后端工程師定義數據顯示的接口。另外需要配置計算任務，每天每個指標應該什么時候計算，那些需要實時計算，那些需要離線計算，都是他們來處理。
后端開發工程師：數據中臺的后端開發工程師和傳統項目的后端開發工程師有點不同，他做的更多的是數據指標接口，與他打交道的是數據開發和產品經理、測試。他要對內的分析產品提供接口，還要將一部分數據以接口的形式輸出給其他業務線。
前端開發工程師：前端開發工程師主要和’后端工程師、測試打交道、UI打交道，他需要特別熟悉前端的一些技術比如js、h5等。一些可視化的圖表組件也需要比較熟悉如echart等，他需要做的是如何把我們的數據指標，以更合適的圖表顯示給我們數據中臺的用戶去用。
UI會根據產品經理的原型設計效果圖，一旦效果圖通過，UI設計師會出切圖（功能的標注），然后前端開發工程師基于切圖完成前端界面的開發。前端工程師和UI對審美還是有一定的要求，因為視覺和交互直接決定了產品的用戶體驗。
測試工程師：數據中臺的測試工程師和普通項目的測試有點不同，他更多的是測試數據的準確性，數據中臺數據的準確性決定產品價值的80%。
測試工程師需要理解指標的計算邏輯，數據開發會進行自測，是保證數據準確性的第一道門檻，測試工程師是保證數據準確性的第二道門檻，產品功能上線初期會讓運營的同事先試用，他們的是保證數據準確性的第三道門檻。當功能運營了一段時間比如二個月或者三個月，測試工程師會組織功能的回測，就形成了第四道門檻。
數據中臺內部如何合作
可以看到要完成一個指標的開發還是需要很多角色的配合的，怎么保證這些角色高效的溝通、配合完成項目呢？
我們總結了一套比較規范的流程：
第一步要確定指標的業務口徑。
業務口徑應該由數據中臺的產品經理來主導，找到提出該指標的運營負責人溝通。接下來要問清楚這個指標有什么用，給誰用。
不是所有的指標都有開發的意義，因為數據中臺前期每做一個指標都會花費大量的人力資源，所以一定要考慮這個指標的性價比，我們投入這么多資源，能夠給公司帶來什么，要么直接和交易額相關，要么就是能節省運營同事大量的工作時間，節省人力成本也是為公司省錢嘛。
第二步要確定指標的技術口徑。
技術口徑是由建模工程師主導，此時模型設計師要和產品經理溝通整個指標的業務邏輯，另外就是產品經理需要要協調業務方的技術開發人員和建模工程師一起梳理數據庫層面需要用到表結構和字段。一定要精確到字段級別。
這些字段都確定好后，就能初步定下來這個指標能不能統計，如果不能統計產品經理應該主動告知運營并且還要告訴運營同事做了哪些功能才能統計這些指標，接下來就是協調業務方產品經理討論是不是要做這些功能。
第三步是原型設計和評審。
這部分還是產品經理來主導，基于需求設計原型。原型設計完后要進行內部評審和外部評審。內部評審要拉上我們的架構師、建模工程師、數據開發工程師、后端開發工程師、前端開發工程師、UI、測試工程師，一起說明整個功能的價值和詳細的操作流程，確保大家理解的一致。
接下來產品經理要和運營基于原型做一個外部評審，把有歧義的地方一并解決。比較重要的功能產品經理需要發郵件讓我們的運營進一步確認，并同步給所有的運營同事保證大家的口徑一致。
第四步是模型設計。
此時主導的是我們的模型設計工程師，模型設計會采用三層建模的方式把數據更加科學的組織存儲。分為 ODS（操作數據層），DWD(明細數據層)、DWS（匯總數據層）、ADS （應用數據層），這是業界對數據分層常用的模型。模型設計工程師要清楚的知道數據來源自那里，要怎么存放。
第五步是數據開發。
此時主導的是大數據開發工程師。首先要和數據建模工程師溝通好技術口徑明確好我們計算的指標都來自于那些業務系統，他們通過數據同步的工具將數據同步到ODS層，然后就是一層一層的通過SQL計算到DW*層，一層一層的匯總，最后形成可為應用直接服務的數據填充到ADS層。
另外大數據開發工程另外一個比較重要的工作就是設置調度任務，簡單來講就是什么時候計算提前寫好的計算腳本如T-1每天凌晨處理上一天的數據。隨著業務的增長，運營會對實時數據的需求越來越大，還有一些實時計算任務的配置也是由大數據開發工程師完成。
第六步是后端開發。
此時由后端開發工程師主導，后端開發工程師基于產品經理的功能定義輸出相應的接口給前端開發工程師調用，由于ADS層是由數據開發工程師已經將數據注入常規的關系型數據庫（如MYSQL等），此時后端開發工程師更多的是和產品經理溝通產品的功能、性能方面的問題，以便給使用者更好的用戶體驗。
第七步是前端開發。
此時主導的是前端開發工程師。原型出來后產品經理會讓UI設計師基于產品功能的重點設計UI，UI設計師經過反復的設計，UI最終定型后，會給我們的前端開發工程師提供切圖，前端開發工程師基于UI的切圖做前端頁面的開發。
第八步是聯調。
此時數據開發工程師、前端開發工程師、后端開發工程師都要參與進來。一般來說需要大數據開發工程師基于歷史的數據執行計算任務，數據開發工程師承擔數據準確性的校驗，前后端解決用戶操作的相關BUG保證不出現低級的問題。
第九步是測試。
此時由測試工程師來主導。測試工程師在完成原型評審后就要開始寫測試用例，那些是開發人員自己要自測通過才能交上來測試的，那些是自己要再次驗證的都在測試用例寫清楚。此時有經驗的產品經理會向運營人員要歷史的統計數據來核對數據，不過運營人員的數據不一定準確，只是拿來參考。
最終測試沒問題后，產品經理可以協調運營人員試用，試用中發現的一些問題再回爐重新修改，此時整個研發過程就結束了。
第十步是上線。
運維工程師會配合我們的前后端開發工程師更新最新的版本到服務器，此時產品經理要找到該指標的負責人長期跟進指標的準確性。重要的指標還要每過一個周期內部再次驗證，從而保證數據的準確性。
數據中臺內部迭代計劃
每月制定月度計劃，設定月度目標
每個月我們會組織和每條產品線的運營、產品同事做一個常規溝通，主要溝通他們目前使用數據中臺遇到的一些問題，他們下個月的計劃是什么。
基于運營的反饋，我們會制定下個月的迭代計劃。產品經理基于運營的反饋定義下個月要做的內容和優先級，架構師和項目經理基于需求的工作量排開發計劃，這個開發計劃是精確到每兩周一個迭代完成月度目標。
一個月的迭代時間太長，一個功能要很久才能看見效果，互聯網產品的開發要求短平快，我們也采用短平快的模式將一個月的任務分為2個迭代完成。
第一個迭代主要做一些優化的功能和一些需求已經十分明確的功能，在第一個迭代產品經理需要完成第二個迭代的需求調研，當完成了需求調研會在第二個迭代的第一周進行需求評審。評審完成后技術的同事就可以進行第二個迭代的開發。
到了第三周因為和運營開了一次月度會議，那下個月的需求也基本確定下來。產品經理就可以繼續去調研下個月第一個迭代的內容，產品經理的需求會比技術同事的工作提前兩周，這樣就形成了一個良性的循環。
數據中臺如何與其他部門合作
先看下和其他部門的依賴關系。數據中臺作為一個獨立的部門要支撐起N條產品線的數據化運營，一般和我們打交道的有每條產品線的運營和產品經理。運營人員會有一些數據指標的需求，各個產品線的產品經理需要協助我們完成數據指標的技術口徑，因為產品的功能都是業務線的產品經理開發的，所以他們是最清楚產品線的業務流程是數據流。
業務口徑和原型確認
當有運營的同事有一個新的數據指指標需求，怎么告訴我們呢？
需要有一個規范的流程。我們制定可一個表格來讓運營的同事去填，這個表格主要解決是誰，那條產品線，指標的名稱是什么，指標的業務口徑是什么、統計周期是什么。
這個表格首先要提交到數據中臺的產品經理，產品經理需要和需求方再次溝通確定指標的定義和價值。當產品經理覺得沒問題就可以提交給喬峰，讓喬峰協調數據開發來看指標的技術口徑。當技術口徑都沒問題，就會進入產品設計階段。
當產品經理把原型輸出后，首先要和運營去再次確認，保證功能沒有問題，此時最好是讓運營回復下郵件確認。
接下來就進入開發階段，當開發完成后有個技巧，可以問運營的同事要一些歷史手工統計的數據，這個數據會對我們有一定的參考意義。當功能上線后運營人員需要對這個指標負責，有一個試用期比如一周內，他們需要在這個周期內反饋數據的問題。接下來就是數據指標的迭代。
與各條產品線建立月度溝通機制
剛才提到月度溝通的會議十分重要，這是數據中臺比較強大的反饋閉環之一。這個會議一方面知道運營那邊的節奏，保證數據中臺和運營部門的節奏是一致的。
另外一方面我們能收集到大量的用戶反饋，因為數據中臺的用戶主要就是運營人員，解決他們的數據化運營問題?；谶@些反饋數據中臺可以更加有針對性的優化現有的功能。
建立日常溝通微信群
需要與每條線的運營同事、產品同事建立微信群，日常的數據難免會有一些問題，當有問題時運營要有十分便捷的反饋渠道。運營群里的反饋數據中臺要第一時間去處理，因為正是由于這些反饋，數據中臺的功能才會變得更加有價值。
規范的取數流程
我們制定了一套規范的取數流程，業務人員要寫清楚自己取數的目的，指標的業務口徑、統計周期等
。這個需要經過運營負責人的審核，數據中臺產品經理的審核。產品經理審核主要確定這個數據的意義和目前的系統是否有這樣的數據，如果真的需要幫他們取數，要進一步確認業務口徑。盡量做到，讓開發看到業務口徑就知道該怎么計算那些指標，不浪費開發的時間。
推薦閱讀：
數據中臺實戰（二）：基于阿里OneData的數據指標管理體系
數據中臺實戰（一）：以B2B點電商為例談談產品經理下的數據埋點
作者：Wilton（董超華），曾任職科大訊飛，現任富力環球商品貿易港大數據產品經理。微信公眾號：改變世界的產品經理。
本文由@華仔 原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash, 基于CC0協議。
干貨
這個可以可以666
板凳
贊