數(shù)據(jù)中臺實戰(zhàn)入門篇:數(shù)據(jù)中臺對內(nèi)、對外合作機制
上一篇文章講了《數(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é)議。
干貨
這個可以可以666
板凳
贊