數據中臺項目管理實踐分享
簡介
阿里云數據中臺是一個包含落地實施方法論、平臺產品和技術服務的企業級解決方案。阿里云數據中臺以Maxcompute等大數據計算平臺為載體，以三個One為理論基礎構成數據中臺方法論，實現在一個平臺里完成數據全生命周期的管理工作。
本文總結了企業級數據中臺項目的實踐經驗，希望能夠為正在規劃或者已在實施數據中臺類項目的企業和個人提供經驗。
阿里云數據中臺類項目的管理全貌和實施過程可以總結為以下大圖：
數據中臺項目管理實踐分享（一）項目啟動
數據中臺項目是一個企業級的項目，在每個數據中臺項目的建設之初，需要進行全盤且較為全面的規劃，避免‘單煙囪’式的方式去建設中臺。
啟動階段是極為重要的，大部分的計劃和規劃都在這個階段產出，建議這個階段應該占到整個項目計劃時間的15%。若項目計劃規劃不充分，項目實施就可能是一個填坑的過程。在項目起始階段，可按4步走：
1. 定目標
2. 定團隊
3. 定計劃
4. 定章法
定目標
在數據中臺項目開始之前，需要考慮企業建設中臺的初衷與目標。了解企業目前的戰略，調研每個數據中臺場景涉及的部門、部門目標，以及部門之間、場景之間的聯通性。這樣有助于實現數據中臺的一體化建設，明確數據中臺建設的目標，避免后續工作的返工。
基于企業目標和戰略，拆解各個部門的目標和KPI。 在規劃數據中臺時，考慮如何通過數據化進行分析、評價和考核，并通過可視化展示目標與進展。在調研項目目標時，項目組需要著重考量：
1. 企業中不同角色都需要什么樣的數據支持，這些數據的分布在哪里？數據流向何處？管理層建設數據中臺的初衷是什么，他們都在關注哪些數據？
例如有些企業建設數據中臺的初衷是進行數據治理，是想統一當前口徑不一致的指標。如果我們能知道哪幾個指標是管理層最大的痛點，就可以優先治理，提前滿足管理層的部分需求。企業級數據中臺的建設必須得到企業級管理層的支持，而數據類的項目常常是一個長期價值大，但過程枯燥的項目。所以，持續性向領導層體現項目的建設亮點就顯得特別重要。
2. 企業客戶的數據將會如何被使用，從技術實施上考慮如何搭建相對應的架構？
例如實時和非實時場景，這也決定或影響了后續上云的架構。
3. 這些數據所涉及到的業務流程有哪些？
除了要明確項目的目標之外，在實施過程中還需要考慮合同的約束條件，例如有無時間約束，投入工作量，是否對員工進行培訓等。一些細節因素也會對項目產生影響。例如如果員工考核是在年底的12月31日，那項目最好在12月初就能有較好的產出，以便滿足項目參與人員的績效考核。
通過以上綜合的考量，才能定下數據中臺項目的目標，和每一個場景的子項目目標。
定團隊
大型企業客戶特別關心項目組織陣型和分工。數據中臺項目是企業級項目，一個成功的數據中臺項目團隊，是必須有甲方的核心管理層、業務方、和技術方密切參與的。在很多的項目中，由于甲方團隊不能深度參與或者角色缺失，導致協調力度不夠，引起進度和質量的不可控。特別是政府和大型企業的項目，最難處理的就是組織內部的關系。組織架構圖的繪制需要思考如何做到一碗水端平，又能滿足推動項目的目的。
企業級項目建議設置一個項目管理委員會（Project Control Borad,以下簡稱PCB），由甲方的核心管理層和乙方的核心管理層參與。PCB的角色在于確定項目的目標，解決內部分歧，在項目需要決策時提供決策支持。如果PCB缺失，甲方多部門參與項目的時候，很容易因為部門間利益沖突，使得問題難以調停。
在大企業經常有的組織結構是，IT類項目的合同方是IT部門，但主導部門卻是數據部門。IT部門與數據部門對項目的訴求，甚至可能是沖突的。項目組的結構設計必須充分考慮各個團隊的訴求點，在求同存異的大方向下，確保大目標一致，讓各個團隊都處在適合的位置。為此，在傳統角色的基礎上，建議加設Product Owner的角色?？蓢L試由IT部門擔任PM，數據類項目涉及較多IT部門內部流程，由IT部門的PM來協調流程更為順暢，例如數據權限開通，產品權限開通等。 Product Owner可以來管控需求和需求的優先級。
項目角色定位
客戶側角色
項目交付過程中，客戶方的配合尤為重要，因此客戶的角色顯得尤為重要。
客戶需求決策者Project Owner
1. 產品需求負責人
2. 統一需求間存在的分歧
3. 迭代式定義產品及需求優先級
客戶項目經歷Project Manager
1. 解決團隊每日存在的Blocker，重點解決客戶側的所有問題。
2. 保證最大限度完成每一次迭代，為總體進度負責。
3. 告知客戶所需的流程需要，要做到可量化，可測試，可執行。
4. 組織每日站會，周會等例會。
客戶業務方負責人
1. 統籌每個場景客戶業務需求。
2. 定義業務需求的Definition of Done (例如指標業務邏輯)。
3. 驗證和驗收上云結果。（注：上云數據的質量結果，從一開始就需要業務方去驗證。項目推進過程中，經常出現由于源頭數據缺失或質量不達標的情況引起指標不準確的情況）
4. 驗證與驗收指標。
客戶業務配合人
1. 客戶業務需求的制造者。
2. 定義業務需求的Definition of Done (例如指標業務邏輯)。
3. 驗證和驗收上云結果。
4. 驗證與驗收指標。
客戶技術負責人（客戶TM）
1. 對整體的交付質量負責，對每一次迭代的質量負責。
2. 告知并協助客戶的質量和管理流程。
3. 統籌數據盤點和數據上云等工作。
客戶技術實施人
1. 數據盤點和數據上云等工作。
阿里云側角色
與之配合，阿里也需要提供五位一體的團隊提供支持：
項目經理 Project Manager
1. 解決團隊每日存在的Blocker，重點解決阿里側的所有問題。
2. 保證最大限度完成每一次迭代，為總體進度負責。
3. 組織每日站會，周會等例會。
架構經理Architect Manager
1. 參與業務和數據資產調研，整理數據資產報告
2. 數據的模型設計
3. 面向產品開發部門，反饋產品需求和建議。
技術經理Technical Manager
1. 管理并進行相關的開發工作，對整體的交付質量負責，對每一次迭代的質量負責。
2. 指導技術人員使用阿里產品，遵守開發規范等技術要求。
3. 評估工作量，并合理分配技術工作。
業務分析師 Business Analyst
1. 對整體的咨詢質量負責，為項目的亮點提煉負責。
2. 總結，賦能和實踐數據阿里的最佳實踐和方法論。
產品PD
1. 負責可視化展示的設計。
2. 保證所設計的指標能落地。
3. 負責內部自測。
定計劃
唯有項目目標和項目團隊明確了以后，才能開始計劃的定制。項目計劃的制定必須是一個嚴謹詳細，群策群力的過程。一個好的計劃想要達到的效果是，讓項目組的每個人，能夠把這個項目即將經歷的事情，都在腦海里面過一遍。這就例如史蒂芬·柯維在《高效能人士的七個習慣》書中所說的第一次創造的過程。
在這個過程中，經常能夠預見到很多風險。在很多公司很多人對于“創建詳細計劃”有抵觸心理，喜歡直接開干。這其實是不應該的，在交付ToB、ToG項目時，如果前期計劃規劃做得不夠，很可能面臨客戶的挑戰，例如客戶可能會有如下的問題：
1. 你們定的計劃怎么和實際操作不太一樣？我怎么通過計劃監督你們的進度？
2. 你們計劃里面的一個任務就持續了兩個月的時間，這個任務都包含了什么？
3. 從原始計劃上看不到我們甲方需要配合什么，為何經常需要甲方緊急的協助？
4. 為何項目預知風險的能力？
5. 每個項目之間的關系是什么？
定章法
有人的地方便有江湖，特別是新組建的項目團隊，大家都來自不同的團隊，代表著不同的利益。在項目實施的開始之初，如果能夠組織項目組共同制定項目章程，將會對項目的順利實施起到非常大的幫助。創建項目章程的目的是，約定多方共事的游戲規則，以達到在滿足各自利益的前提下，共同完成項目的目標。
項目章程包含了項目目標、團隊和計劃，同時也包含驗收方式，先決條件和協作方式等。同時提醒一點，要和客戶定章程，需要有良好的客戶關系為基礎，有了一定的默契才能真正遵守。缺少了人的支持，項目章程就變得沒有價值。甲方也需要重視項目章程的落地，這也是對甲乙雙方合作關系的保護。
數據中臺項目管理實踐分享（二）需求調研與設計
需求調研和設計階段，目的是承接的是項目起始階段的產物，并給下一階段“技術實施”輸出詳細的開發實施需求。
為了加速項目的實施進度，在做需求調研的同時，還可以同步進行數據的上云工作，和數據中臺數據架構的設計（公共層設計）。以下3條線是可以并行進行：
l 業務線負責業務調研
l 上云線負責數據上云
l 架構線負責公共層數據架構設計
業務線
業務調研及結合行業最佳實踐
阿里云數據中臺類項目的實施，有一個比較大的不同點在于，阿里云數據中臺是基于業務場景驅動的技術交付。 每一個業務場景都是圍繞著建立針對該業務場景的指標/標簽體系（以下簡稱指標體系），并通過指標體系指導業務運營，驅動和實現價值創造的過程。
指標體系的建設過程，是對現有指標或指標體系的梳理，并結合行業或者跨行業（例如互聯網行業，新零售行業）的理解和最佳實踐，形成一套新的，能夠高效指導業務運營的指標體系。對于現有指標體系的收集，阿里云提供一系列的模板，可讓甲方根據日常的經驗來收集填寫。
對于沒有實施過數據中臺項目的人，可能對指標/標簽體系和運營的關系理解不深，不明白指標/標簽是如何對運營能夠起到作用。舉一個相關的例子，新零售常用的AIPL營銷模型，是把人群資產定量化運營的模型，如下詳解：
A（Awareness），品牌認知人群。包括被品牌廣告觸達和品類詞搜索的人；
I（Interest），品牌興趣人群。包括廣告點擊、瀏覽品牌/店鋪主頁、參與品牌互動、瀏覽產品詳情頁、品牌詞搜索、領取試用、訂閱/關注/入會、加購收藏的人；
P（Purchase），品牌購買人群，指購買過品牌商品的人；
L（Loyalty），品牌忠誠人群，包括復購、評論、分享的人。
在AIPL模型里，可以對每一個顧客的特性，進行精準營銷，有效提高顧客的忠誠度。
以上這就是指標和標簽驅動業務價值運營的過程。在這個階段有2個風險值得提前做好應對：
1. 成熟標準行業的龍頭擁有自己完善的運營方式。
曾服務過某客戶，是亞洲最大的行業龍頭，其所在的行業流程化程度極高，作為交付方我們很難拿出什么顛覆性的指標/標簽體系。
2. 新的運營方式出成績的周期大于項目建設周期。
數據中臺一個場景的建設周期，都需要6-12個月。即使能夠在運營方式上給客戶帶來指導，也很難讓客戶在項目周期內實踐這一運營方式，因為變革增加了客戶的不適應性和不確定性，經常需要適合的契機。
PRD設計
在調研環節，項目的目標是輸出大而全的指標/標簽體系，以幫助或者啟發客戶運營端的創新。所以MRD環節梳理的指標體系，不一定要全部開發落地。某些指標/標簽，可能在當下沒有數據基礎，但是可以作為未來企業數據采集規劃的方向。
但在PRD環節就不一樣了，PRD考慮的是根據指標的價值，確定指標的可落地性，并設計以可視化的方式，展示這些指標。
在PRD設計環節完成后，理論上項目的需求范圍就比較清晰了，此時建議產出一份完整的需求總表（Product Backlog）。在此表示的是，與客戶達成一致，作為最終驗收前完成的需求范圍，那飽含需求的優先級。需求總表涵蓋了在上一階段完成的MRD，PRD，本項目內的上云清單，公共層維度與事實表建設清單，指標/標簽清單等。唯有需求范圍明確，優先級定義清晰，后面的開發才能有章可循，避免需求擴散。
數據線
數據線，大概分為幾個步驟
1. 確定數據盤點和上云的范圍和優先級
2. 數據盤點
3. 上云架構設計和數據上云
確定數據盤點和上云的范圍和優先級
該階段的目標是，探查每個場景所需的數據，了解這些數據分布的系統，產出數據盤點和上云系統清單。需要注意的是，這個清單不僅要包含上云的系統和表，還需要包含上云的歷史數據回刷范圍。歷史數據回刷范圍是根據客戶想要看到多久的數據而定。例如客戶想看近2年的銷售額對比，那回刷的范圍就必須是2年以上。
數據盤點
根據上云系統清單去盤點所需用到的數據，盤點的內容包括
系統流程映射表：基于業務過程，羅列各個業務系統間的關系。系統間數據互相訪問的時限要求。
數據源基本信息：基于系統級別，羅列各個業務系統的基礎信息，例如系統類型，數據庫類型，數據量，負責人等系統級別的信息。
數據資源目錄：基于表級別，羅列各個表的內容描述，屬性信息，上云優先級等。
數據字典：基于字段級別，羅列各個字段的屬性和元數據信息。
注：數據盤點的工作，不只是為了數據上云，可以同時考慮數據治理的一些工作，例如在數據盤點訪談的同時，也可以同時調研技術元數據和業務元數據的范圍。
上云架構設計和數據上云
該階段是根據盤點的數據信息和數據使用要求，設計上云架構，并依照架構開始上云操作。
架構線
架構線有兩個動作：
1.梳理企業的業務大圖
2.基于業務大圖，指導數據中臺的公共層建設，也就是設計事實表和維度表的設計。
數據中臺業務大圖，關注基于業務對象的業務動作，和業務動作過程中涉及的業務對象。業務動作在中臺里面體現就是事實表，業務對象對應的是維度表。
例如一個航空公司的客戶，他會購買機票，會付款，可能會退票退款，這些就是業務過程，有相關數據的對事實流水的記錄，即事實表。關于維度，可以簡單的理解為從哪個維度/角度/對象去分析這張事實表，例如從客戶的維度，機票的維度、付款的維度等。
在設計維度表和事實表（公共層）的時候，需同時考慮數據治理的相關事宜。在此前經歷的某項目中，曾被客戶質疑公共層的數據有些偏頗。復盤后發現由兩大原因導致：
問題一：客戶源數據質量問題
問題二：缺失數據治理的環節
針對問題一的建議是，業務方在數據上云后，便開始檢查數據的質量，而不是在開發后再去排錯。上云的數據質量得不到保證，再準確的計算口徑也不能得到一個準確的指標/標簽。
針對問題二的流程建議是，在數據中臺實施過程中，加入數據治理的過程。 建議流程如下：
1. 基于業務大圖設計公共層的數據架構（維度表和事實表）。
2. 組織客戶對維度表和事實表進行評審。
3. 客戶信息中心基于維度表和事實表，完成技術元數據的數據治理。
4. 客戶業務方基于維度表和事實表，完成業務元數據的數據治理。
5. 客戶匯總技術元數據和業務元數據，阿里云再基于客戶提供的內容，進行開發。
數據中臺項目管理實踐分享（三）技術實施
傳統流水線開發
以往在做數據中臺項目的時候，沿用的是流水線型的開發方式，都是在上一個階段有較清晰完整的交付物時，才進入到下一個階段。 例如需求明確了才設計。設計明確了，才開始開發。開發完成了，才開始驗收。這樣的好處是：1）便于需求的管理，可以通過設置里程碑，讓客戶確定需求，以降低需求的擴散；2）方便規劃資源的投入，在一段時間只要一類資源的投入。例如咨詢環節只投入BA，設計環節只投入PD。
但是這樣的問題是：
1. 經常出現上下游不銜接，上游的需求不能被實現。
2. 重復工作，例如BA向客戶調研指標口徑，但當PD/TM接手指標清單以后，PD/TM又需要重新和客戶梳理一回。
3. 由于所有的指標/標簽都是同時上線，客戶需要等待的時間較長?？蛻舨荒茌^好控制指標的優先級。
4. 對于乙方也是很不利的，等所有指標都開發完成以后，才讓客戶驗收。驗收的風險很大，周期長，返工風險大。
5. 數據中臺持續的周期可能是半年以上，很難保證在這么長的周期內，需求是一層不變的。哪怕是確認了，也有更改可能。
敏捷式開發
為了解決以上的問題，阿里云在項目實施中引入了迭代式的開發。以雙周作為迭代計劃，每個雙周都是一個完整的開發單元。
每一次迭代，都需要進行迭代規劃會，從需求總表中（Product Backlog）由客戶選出價值最高，優先級最高的指標作為本次迭代開發的目標，該目標稱之為迭代清單（Sprint Backlog）。
每一個迭代，都只與客戶共同完成本次迭代指標口徑確認，再進行指標開發，指標測試，指標驗收上線。在每一個雙周結束，和客戶進行一次總驗收和復盤會。
這樣可以保證開發都是根據客戶價值的優先級來進行的。每一次迭代都能有指標驗收和上線。對于甲方來說能提前分批預知風險，客戶也可以提早使用高價值的指標。
為了方便協同和實現項目可視化，推薦使用Teambition(TB)作為管理工具。首先預設項目模板，讓項目組的成員能夠方便的在TB上找到所需的項目內容，對需求范圍的管理也很有幫助，例如上文提到的數據上云清單，維度表清單，事實表清單，指標/標簽清單，迭代清單等，每一類清單都有開發步驟和流程，很適合通過TB進行可視化，流程化管理。
最后，質量保障一定不能等到最后一刻才去進行，這樣加大了復工風險。質量保障應該有一個完整的機制，持續進行。
數據中臺 - 項目收尾
項目收尾階段歸集交付物自行存檔并發給客戶，為完結的項目進程和結果制作總結文件用于匯報。設計一些儀式，紀念里程碑時間點。同時復盤本期項目的亮點和缺點細節，以幫助下一個項目。
