上一篇文章講了《數(shù)據(jù)中臺實戰(zhàn)入門篇：雙中臺戰(zhàn)略》，主要解決了什么是中臺、什么是數(shù)據(jù)中臺、業(yè)務(wù)中臺、什么公司適合搭建雙中臺體系這幾個問題。本篇文章講一下數(shù)據(jù)中臺的人員構(gòu)成、內(nèi)部如何合作、數(shù)據(jù)中臺的項目管理、數(shù)據(jù)中臺如何與運營部門合作這幾個問題。

數(shù)據(jù)中臺人員構(gòu)成

架構(gòu)師：架構(gòu)師是整個數(shù)據(jù)中臺團隊的技術(shù)負(fù)責(zé)人。涉及到大的模塊比如標(biāo)簽平臺、推薦，要拿到業(yè)界比較成熟的架構(gòu)設(shè)計，這樣有個參考，能避免我們踩很多坑。另外包括技術(shù)選型比如大數(shù)據(jù)常用的計算框架spark、handoop等用那個比較合適，還有一些需要攻關(guān)的技術(shù)難題都需要協(xié)調(diào)他來解決。

項目經(jīng)理：項目經(jīng)理要和架構(gòu)師一起排團隊的開發(fā)計劃。保證讓每個任務(wù)在時間節(jié)點完成，他要更加了解團隊的每個成員的特點，最大的發(fā)揮團隊成員的優(yōu)勢。另外關(guān)于項目的質(zhì)量、風(fēng)險都需要項目經(jīng)理制定合理的流程來保證。

產(chǎn)品經(jīng)理：數(shù)據(jù)中臺的產(chǎn)品經(jīng)理對外要和運營的同事混熟，了解整個產(chǎn)品現(xiàn)在的策略，節(jié)奏是什么，這個時期關(guān)注的最核心的指標(biāo)有那些。對內(nèi)要將產(chǎn)品的方向、功能用偏技術(shù)的語言和開發(fā)溝通清楚，保證產(chǎn)品價值的最大化。

模型設(shè)計師：模型設(shè)計是數(shù)據(jù)中臺比較重要的一環(huán)，底層模型的好壞直接決定數(shù)據(jù)中臺數(shù)據(jù)指標(biāo)的質(zhì)量和可擴展性。一個好的模型設(shè)計師需要對產(chǎn)品業(yè)務(wù)流程比較熟悉，對每條產(chǎn)品線的數(shù)據(jù)存儲比較熟悉，需要和產(chǎn)品配合，一起摸清每個指標(biāo)的開龍去脈，并將模型的思路，計算的方式清晰的告訴數(shù)據(jù)開發(fā)。全方面、多維度的建模是數(shù)據(jù)中臺的基礎(chǔ)，數(shù)據(jù)模型設(shè)計師是相對來說數(shù)據(jù)中臺中比較核心的職位。

數(shù)據(jù)開發(fā)工程師：他們主要和模型設(shè)計師打交道，模型設(shè)計師把業(yè)務(wù)口徑轉(zhuǎn)化為技術(shù)口徑，告訴他們每個指標(biāo)應(yīng)該從那里提取數(shù)據(jù)，怎么計算。他們將計算的結(jié)果一層一層匯總，最終要和后端工程師定義數(shù)據(jù)顯示的接口。另外需要配置計算任務(wù)，每天每個指標(biāo)應(yīng)該什么時候計算，那些需要實時計算，那些需要離線計算，都是他們來處理。

后端開發(fā)工程師：數(shù)據(jù)中臺的后端開發(fā)工程師和傳統(tǒng)項目的后端開發(fā)工程師有點不同，他做的更多的是數(shù)據(jù)指標(biāo)接口，與他打交道的是數(shù)據(jù)開發(fā)和產(chǎn)品經(jīng)理、測試。他要對內(nèi)的分析產(chǎn)品提供接口，還要將一部分?jǐn)?shù)據(jù)以接口的形式輸出給其他業(yè)務(wù)線。

前端開發(fā)工程師：前端開發(fā)工程師主要和’后端工程師、測試打交道、UI打交道，他需要特別熟悉前端的一些技術(shù)比如js、h5等。一些可視化的圖表組件也需要比較熟悉如echart等，他需要做的是如何把我們的數(shù)據(jù)指標(biāo)，以更合適的圖表顯示給我們數(shù)據(jù)中臺的用戶去用。

UI會根據(jù)產(chǎn)品經(jīng)理的原型設(shè)計效果圖，一旦效果圖通過，UI設(shè)計師會出切圖（功能的標(biāo)注），然后前端開發(fā)工程師基于切圖完成前端界面的開發(fā)。前端工程師和UI對審美還是有一定的要求，因為視覺和交互直接決定了產(chǎn)品的用戶體驗。

測試工程師：數(shù)據(jù)中臺的測試工程師和普通項目的測試有點不同，他更多的是測試數(shù)據(jù)的準(zhǔn)確性，數(shù)據(jù)中臺數(shù)據(jù)的準(zhǔn)確性決定產(chǎn)品價值的80%。

測試工程師需要理解指標(biāo)的計算邏輯，數(shù)據(jù)開發(fā)會進行自測，是保證數(shù)據(jù)準(zhǔn)確性的第一道門檻，測試工程師是保證數(shù)據(jù)準(zhǔn)確性的第二道門檻，產(chǎn)品功能上線初期會讓運營的同事先試用，他們的是保證數(shù)據(jù)準(zhǔn)確性的第三道門檻。當(dāng)功能運營了一段時間比如二個月或者三個月，測試工程師會組織功能的回測，就形成了第四道門檻。

數(shù)據(jù)中臺內(nèi)部如何合作

可以看到要完成一個指標(biāo)的開發(fā)還是需要很多角色的配合的，怎么保證這些角色高效的溝通、配合完成項目呢？

我們總結(jié)了一套比較規(guī)范的流程：

第一步要確定指標(biāo)的業(yè)務(wù)口徑。

業(yè)務(wù)口徑應(yīng)該由數(shù)據(jù)中臺的產(chǎn)品經(jīng)理來主導(dǎo)，找到提出該指標(biāo)的運營負(fù)責(zé)人溝通。接下來要問清楚這個指標(biāo)有什么用，給誰用。

不是所有的指標(biāo)都有開發(fā)的意義，因為數(shù)據(jù)中臺前期每做一個指標(biāo)都會花費大量的人力資源，所以一定要考慮這個指標(biāo)的性價比，我們投入這么多資源，能夠給公司帶來什么，要么直接和交易額相關(guān)，要么就是能節(jié)省運營同事大量的工作時間，節(jié)省人力成本也是為公司省錢嘛。

第二步要確定指標(biāo)的技術(shù)口徑。

技術(shù)口徑是由建模工程師主導(dǎo)，此時模型設(shè)計師要和產(chǎn)品經(jīng)理溝通整個指標(biāo)的業(yè)務(wù)邏輯，另外就是產(chǎn)品經(jīng)理需要要協(xié)調(diào)業(yè)務(wù)方的技術(shù)開發(fā)人員和建模工程師一起梳理數(shù)據(jù)庫層面需要用到表結(jié)構(gòu)和字段。一定要精確到字段級別。

這些字段都確定好后，就能初步定下來這個指標(biāo)能不能統(tǒng)計，如果不能統(tǒng)計產(chǎn)品經(jīng)理應(yīng)該主動告知運營并且還要告訴運營同事做了哪些功能才能統(tǒng)計這些指標(biāo)，接下來就是協(xié)調(diào)業(yè)務(wù)方產(chǎn)品經(jīng)理討論是不是要做這些功能。

第三步是原型設(shè)計和評審。

這部分還是產(chǎn)品經(jīng)理來主導(dǎo)，基于需求設(shè)計原型。原型設(shè)計完后要進行內(nèi)部評審和外部評審。內(nèi)部評審要拉上我們的架構(gòu)師、建模工程師、數(shù)據(jù)開發(fā)工程師、后端開發(fā)工程師、前端開發(fā)工程師、UI、測試工程師，一起說明整個功能的價值和詳細的操作流程，確保大家理解的一致。

接下來產(chǎn)品經(jīng)理要和運營基于原型做一個外部評審，把有歧義的地方一并解決。比較重要的功能產(chǎn)品經(jīng)理需要發(fā)郵件讓我們的運營進一步確認(rèn)，并同步給所有的運營同事保證大家的口徑一致。

第四步是模型設(shè)計。

此時主導(dǎo)的是我們的模型設(shè)計工程師，模型設(shè)計會采用三層建模的方式把數(shù)據(jù)更加科學(xué)的組織存儲。分為 ODS（操作數(shù)據(jù)層），DWD(明細數(shù)據(jù)層)、DWS（匯總數(shù)據(jù)層）、ADS （應(yīng)用數(shù)據(jù)層），這是業(yè)界對數(shù)據(jù)分層常用的模型。模型設(shè)計工程師要清楚的知道數(shù)據(jù)來源自那里，要怎么存放。

第五步是數(shù)據(jù)開發(fā)。

此時主導(dǎo)的是大數(shù)據(jù)開發(fā)工程師。首先要和數(shù)據(jù)建模工程師溝通好技術(shù)口徑明確好我們計算的指標(biāo)都來自于那些業(yè)務(wù)系統(tǒng)，他們通過數(shù)據(jù)同步的工具將數(shù)據(jù)同步到ODS層，然后就是一層一層的通過SQL計算到DW*層，一層一層的匯總，最后形成可為應(yīng)用直接服務(wù)的數(shù)據(jù)填充到ADS層。

另外大數(shù)據(jù)開發(fā)工程另外一個比較重要的工作就是設(shè)置調(diào)度任務(wù)，簡單來講就是什么時候計算提前寫好的計算腳本如T-1每天凌晨處理上一天的數(shù)據(jù)。隨著業(yè)務(wù)的增長，運營會對實時數(shù)據(jù)的需求越來越大，還有一些實時計算任務(wù)的配置也是由大數(shù)據(jù)開發(fā)工程師完成。

第六步是后端開發(fā)。

此時由后端開發(fā)工程師主導(dǎo)，后端開發(fā)工程師基于產(chǎn)品經(jīng)理的功能定義輸出相應(yīng)的接口給前端開發(fā)工程師調(diào)用，由于ADS層是由數(shù)據(jù)開發(fā)工程師已經(jīng)將數(shù)據(jù)注入常規(guī)的關(guān)系型數(shù)據(jù)庫（如MYSQL等），此時后端開發(fā)工程師更多的是和產(chǎn)品經(jīng)理溝通產(chǎn)品的功能、性能方面的問題，以便給使用者更好的用戶體驗。

第七步是前端開發(fā)。

此時主導(dǎo)的是前端開發(fā)工程師。原型出來后產(chǎn)品經(jīng)理會讓UI設(shè)計師基于產(chǎn)品功能的重點設(shè)計UI，UI設(shè)計師經(jīng)過反復(fù)的設(shè)計，UI最終定型后，會給我們的前端開發(fā)工程師提供切圖，前端開發(fā)工程師基于UI的切圖做前端頁面的開發(fā)。

第八步是聯(lián)調(diào)。

此時數(shù)據(jù)開發(fā)工程師、前端開發(fā)工程師、后端開發(fā)工程師都要參與進來。一般來說需要大數(shù)據(jù)開發(fā)工程師基于歷史的數(shù)據(jù)執(zhí)行計算任務(wù)，數(shù)據(jù)開發(fā)工程師承擔(dān)數(shù)據(jù)準(zhǔn)確性的校驗，前后端解決用戶操作的相關(guān)BUG保證不出現(xiàn)低級的問題。

第九步是測試。

此時由測試工程師來主導(dǎo)。測試工程師在完成原型評審后就要開始寫測試用例，那些是開發(fā)人員自己要自測通過才能交上來測試的，那些是自己要再次驗證的都在測試用例寫清楚。此時有經(jīng)驗的產(chǎn)品經(jīng)理會向運營人員要歷史的統(tǒng)計數(shù)據(jù)來核對數(shù)據(jù)，不過運營人員的數(shù)據(jù)不一定準(zhǔn)確，只是拿來參考。

最終測試沒問題后，產(chǎn)品經(jīng)理可以協(xié)調(diào)運營人員試用，試用中發(fā)現(xiàn)的一些問題再回爐重新修改，此時整個研發(fā)過程就結(jié)束了。

第十步是上線。

運維工程師會配合我們的前后端開發(fā)工程師更新最新的版本到服務(wù)器，此時產(chǎn)品經(jīng)理要找到該指標(biāo)的負(fù)責(zé)人長期跟進指標(biāo)的準(zhǔn)確性。重要的指標(biāo)還要每過一個周期內(nèi)部再次驗證，從而保證數(shù)據(jù)的準(zhǔn)確性。

數(shù)據(jù)中臺內(nèi)部迭代計劃

每月制定月度計劃，設(shè)定月度目標(biāo)

每個月我們會組織和每條產(chǎn)品線的運營、產(chǎn)品同事做一個常規(guī)溝通，主要溝通他們目前使用數(shù)據(jù)中臺遇到的一些問題，他們下個月的計劃是什么。

基于運營的反饋，我們會制定下個月的迭代計劃。產(chǎn)品經(jīng)理基于運營的反饋定義下個月要做的內(nèi)容和優(yōu)先級，架構(gòu)師和項目經(jīng)理基于需求的工作量排開發(fā)計劃，這個開發(fā)計劃是精確到每兩周一個迭代完成月度目標(biāo)。

一個月的迭代時間太長，一個功能要很久才能看見效果，互聯(lián)網(wǎng)產(chǎn)品的開發(fā)要求短平快，我們也采用短平快的模式將一個月的任務(wù)分為2個迭代完成。

第一個迭代主要做一些優(yōu)化的功能和一些需求已經(jīng)十分明確的功能，在第一個迭代產(chǎn)品經(jīng)理需要完成第二個迭代的需求調(diào)研，當(dāng)完成了需求調(diào)研會在第二個迭代的第一周進行需求評審。評審?fù)瓿珊蠹夹g(shù)的同事就可以進行第二個迭代的開發(fā)。

到了第三周因為和運營開了一次月度會議，那下個月的需求也基本確定下來。產(chǎn)品經(jīng)理就可以繼續(xù)去調(diào)研下個月第一個迭代的內(nèi)容，產(chǎn)品經(jīng)理的需求會比技術(shù)同事的工作提前兩周，這樣就形成了一個良性的循環(huán)。

數(shù)據(jù)中臺如何與其他部門合作

先看下和其他部門的依賴關(guān)系。數(shù)據(jù)中臺作為一個獨立的部門要支撐起N條產(chǎn)品線的數(shù)據(jù)化運營，一般和我們打交道的有每條產(chǎn)品線的運營和產(chǎn)品經(jīng)理。運營人員會有一些數(shù)據(jù)指標(biāo)的需求，各個產(chǎn)品線的產(chǎn)品經(jīng)理需要協(xié)助我們完成數(shù)據(jù)指標(biāo)的技術(shù)口徑，因為產(chǎn)品的功能都是業(yè)務(wù)線的產(chǎn)品經(jīng)理開發(fā)的，所以他們是最清楚產(chǎn)品線的業(yè)務(wù)流程是數(shù)據(jù)流。

業(yè)務(wù)口徑和原型確認(rèn)

當(dāng)有運營的同事有一個新的數(shù)據(jù)指指標(biāo)需求，怎么告訴我們呢？

需要有一個規(guī)范的流程。我們制定可一個表格來讓運營的同事去填，這個表格主要解決是誰，那條產(chǎn)品線，指標(biāo)的名稱是什么，指標(biāo)的業(yè)務(wù)口徑是什么、統(tǒng)計周期是什么。

這個表格首先要提交到數(shù)據(jù)中臺的產(chǎn)品經(jīng)理，產(chǎn)品經(jīng)理需要和需求方再次溝通確定指標(biāo)的定義和價值。當(dāng)產(chǎn)品經(jīng)理覺得沒問題就可以提交給喬峰，讓喬峰協(xié)調(diào)數(shù)據(jù)開發(fā)來看指標(biāo)的技術(shù)口徑。當(dāng)技術(shù)口徑都沒問題，就會進入產(chǎn)品設(shè)計階段。

當(dāng)產(chǎn)品經(jīng)理把原型輸出后，首先要和運營去再次確認(rèn)，保證功能沒有問題，此時最好是讓運營回復(fù)下郵件確認(rèn)。

接下來就進入開發(fā)階段，當(dāng)開發(fā)完成后有個技巧，可以問運營的同事要一些歷史手工統(tǒng)計的數(shù)據(jù)，這個數(shù)據(jù)會對我們有一定的參考意義。當(dāng)功能上線后運營人員需要對這個指標(biāo)負(fù)責(zé)，有一個試用期比如一周內(nèi)，他們需要在這個周期內(nèi)反饋數(shù)據(jù)的問題。接下來就是數(shù)據(jù)指標(biāo)的迭代。

與各條產(chǎn)品線建立月度溝通機制

剛才提到月度溝通的會議十分重要，這是數(shù)據(jù)中臺比較強大的反饋閉環(huán)之一。這個會議一方面知道運營那邊的節(jié)奏，保證數(shù)據(jù)中臺和運營部門的節(jié)奏是一致的。

另外一方面我們能收集到大量的用戶反饋，因為數(shù)據(jù)中臺的用戶主要就是運營人員，解決他們的數(shù)據(jù)化運營問題?；谶@些反饋數(shù)據(jù)中臺可以更加有針對性的優(yōu)化現(xiàn)有的功能。

建立日常溝通微信群

需要與每條線的運營同事、產(chǎn)品同事建立微信群，日常的數(shù)據(jù)難免會有一些問題，當(dāng)有問題時運營要有十分便捷的反饋渠道。運營群里的反饋數(shù)據(jù)中臺要第一時間去處理，因為正是由于這些反饋，數(shù)據(jù)中臺的功能才會變得更加有價值。

規(guī)范的取數(shù)流程

我們制定了一套規(guī)范的取數(shù)流程，業(yè)務(wù)人員要寫清楚自己取數(shù)的目的，指標(biāo)的業(yè)務(wù)口徑、統(tǒng)計周期等

。這個需要經(jīng)過運營負(fù)責(zé)人的審核，數(shù)據(jù)中臺產(chǎn)品經(jīng)理的審核。產(chǎn)品經(jīng)理審核主要確定這個數(shù)據(jù)的意義和目前的系統(tǒng)是否有這樣的數(shù)據(jù)，如果真的需要幫他們?nèi)?shù)，要進一步確認(rèn)業(yè)務(wù)口徑。盡量做到，讓開發(fā)看到業(yè)務(wù)口徑就知道該怎么計算那些指標(biāo)，不浪費開發(fā)的時間。

推薦閱讀：

《數(shù)據(jù)中臺實戰(zhàn)入門篇：雙中臺戰(zhàn)略》

數(shù)據(jù)中臺實戰(zhàn)（四）：商品分析（產(chǎn)品設(shè)計篇）

數(shù)據(jù)中臺實戰(zhàn)（三）：用戶分析（產(chǎn)品設(shè)計篇）

數(shù)據(jù)中臺實戰(zhàn)（二）：基于阿里OneData的數(shù)據(jù)指標(biāo)管理體系

數(shù)據(jù)中臺實戰(zhàn)（一）：以B2B點電商為例談?wù)劗a(chǎn)品經(jīng)理下的數(shù)據(jù)埋點

作者：Wilton（董超華），曾任職科大訊飛，現(xiàn)任富力環(huán)球商品貿(mào)易港大數(shù)據(jù)產(chǎn)品經(jīng)理。微信公眾號：改變世界的產(chǎn)品經(jīng)理。

本文由@華仔 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash, 基于CC0協(xié)議。