簡介

阿里云數(shù)據(jù)中臺是一個包含落地實施方法論、平臺產(chǎn)品和技術(shù)服務(wù)的企業(yè)級解決方案。阿里云數(shù)據(jù)中臺以Maxcompute等大數(shù)據(jù)計算平臺為載體，以三個One為理論基礎(chǔ)構(gòu)成數(shù)據(jù)中臺方法論，實現(xiàn)在一個平臺里完成數(shù)據(jù)全生命周期的管理工作。

本文總結(jié)了企業(yè)級數(shù)據(jù)中臺項目的實踐經(jīng)驗，希望能夠為正在規(guī)劃或者已在實施數(shù)據(jù)中臺類項目的企業(yè)和個人提供經(jīng)驗。

阿里云數(shù)據(jù)中臺類項目的管理全貌和實施過程可以總結(jié)為以下大圖：

數(shù)據(jù)中臺項目管理實踐分享（一）項目啟動

數(shù)據(jù)中臺項目是一個企業(yè)級的項目，在每個數(shù)據(jù)中臺項目的建設(shè)之初，需要進(jìn)行全盤且較為全面的規(guī)劃，避免‘單煙囪’式的方式去建設(shè)中臺。

啟動階段是極為重要的，大部分的計劃和規(guī)劃都在這個階段產(chǎn)出，建議這個階段應(yīng)該占到整個項目計劃時間的15%。若項目計劃規(guī)劃不充分，項目實施就可能是一個填坑的過程。在項目起始階段，可按4步走：

1. 定目標(biāo)

2. 定團(tuán)隊

3. 定計劃

4. 定章法

定目標(biāo)

在數(shù)據(jù)中臺項目開始之前，需要考慮企業(yè)建設(shè)中臺的初衷與目標(biāo)。了解企業(yè)目前的戰(zhàn)略，調(diào)研每個數(shù)據(jù)中臺場景涉及的部門、部門目標(biāo)，以及部門之間、場景之間的聯(lián)通性。這樣有助于實現(xiàn)數(shù)據(jù)中臺的一體化建設(shè)，明確數(shù)據(jù)中臺建設(shè)的目標(biāo)，避免后續(xù)工作的返工。

基于企業(yè)目標(biāo)和戰(zhàn)略，拆解各個部門的目標(biāo)和KPI。 在規(guī)劃數(shù)據(jù)中臺時，考慮如何通過數(shù)據(jù)化進(jìn)行分析、評價和考核，并通過可視化展示目標(biāo)與進(jìn)展。在調(diào)研項目目標(biāo)時，項目組需要著重考量：

1. 企業(yè)中不同角色都需要什么樣的數(shù)據(jù)支持，這些數(shù)據(jù)的分布在哪里？數(shù)據(jù)流向何處？管理層建設(shè)數(shù)據(jù)中臺的初衷是什么，他們都在關(guān)注哪些數(shù)據(jù)？

例如有些企業(yè)建設(shè)數(shù)據(jù)中臺的初衷是進(jìn)行數(shù)據(jù)治理，是想統(tǒng)一當(dāng)前口徑不一致的指標(biāo)。如果我們能知道哪幾個指標(biāo)是管理層最大的痛點，就可以優(yōu)先治理，提前滿足管理層的部分需求。企業(yè)級數(shù)據(jù)中臺的建設(shè)必須得到企業(yè)級管理層的支持，而數(shù)據(jù)類的項目常常是一個長期價值大，但過程枯燥的項目。所以，持續(xù)性向領(lǐng)導(dǎo)層體現(xiàn)項目的建設(shè)亮點就顯得特別重要。

2. 企業(yè)客戶的數(shù)據(jù)將會如何被使用，從技術(shù)實施上考慮如何搭建相對應(yīng)的架構(gòu)？

例如實時和非實時場景，這也決定或影響了后續(xù)上云的架構(gòu)。

3. 這些數(shù)據(jù)所涉及到的業(yè)務(wù)流程有哪些？

除了要明確項目的目標(biāo)之外，在實施過程中還需要考慮合同的約束條件，例如有無時間約束，投入工作量，是否對員工進(jìn)行培訓(xùn)等。一些細(xì)節(jié)因素也會對項目產(chǎn)生影響。例如如果員工考核是在年底的12月31日，那項目最好在12月初就能有較好的產(chǎn)出，以便滿足項目參與人員的績效考核。

通過以上綜合的考量，才能定下數(shù)據(jù)中臺項目的目標(biāo)，和每一個場景的子項目目標(biāo)。

定團(tuán)隊

大型企業(yè)客戶特別關(guān)心項目組織陣型和分工。數(shù)據(jù)中臺項目是企業(yè)級項目，一個成功的數(shù)據(jù)中臺項目團(tuán)隊，是必須有甲方的核心管理層、業(yè)務(wù)方、和技術(shù)方密切參與的。在很多的項目中，由于甲方團(tuán)隊不能深度參與或者角色缺失，導(dǎo)致協(xié)調(diào)力度不夠，引起進(jìn)度和質(zhì)量的不可控。特別是政府和大型企業(yè)的項目，最難處理的就是組織內(nèi)部的關(guān)系。組織架構(gòu)圖的繪制需要思考如何做到一碗水端平，又能滿足推動項目的目的。

企業(yè)級項目建議設(shè)置一個項目管理委員會（Project Control Borad,以下簡稱PCB），由甲方的核心管理層和乙方的核心管理層參與。PCB的角色在于確定項目的目標(biāo)，解決內(nèi)部分歧，在項目需要決策時提供決策支持。如果PCB缺失，甲方多部門參與項目的時候，很容易因為部門間利益沖突，使得問題難以調(diào)停。

在大企業(yè)經(jīng)常有的組織結(jié)構(gòu)是，IT類項目的合同方是IT部門，但主導(dǎo)部門卻是數(shù)據(jù)部門。IT部門與數(shù)據(jù)部門對項目的訴求，甚至可能是沖突的。項目組的結(jié)構(gòu)設(shè)計必須充分考慮各個團(tuán)隊的訴求點，在求同存異的大方向下，確保大目標(biāo)一致，讓各個團(tuán)隊都處在適合的位置。為此，在傳統(tǒng)角色的基礎(chǔ)上，建議加設(shè)Product Owner的角色。可嘗試由IT部門擔(dān)任PM，數(shù)據(jù)類項目涉及較多IT部門內(nèi)部流程，由IT部門的PM來協(xié)調(diào)流程更為順暢，例如數(shù)據(jù)權(quán)限開通，產(chǎn)品權(quán)限開通等。 Product Owner可以來管控需求和需求的優(yōu)先級。

項目角色定位

客戶側(cè)角色

項目交付過程中，客戶方的配合尤為重要，因此客戶的角色顯得尤為重要。

客戶需求決策者Project Owner

1. 產(chǎn)品需求負(fù)責(zé)人

2. 統(tǒng)一需求間存在的分歧

3. 迭代式定義產(chǎn)品及需求優(yōu)先級

客戶項目經(jīng)歷Project Manager

1. 解決團(tuán)隊每日存在的Blocker，重點解決客戶側(cè)的所有問題。

2. 保證最大限度完成每一次迭代，為總體進(jìn)度負(fù)責(zé)。

3. 告知客戶所需的流程需要，要做到可量化，可測試，可執(zhí)行。

4. 組織每日站會，周會等例會。

客戶業(yè)務(wù)方負(fù)責(zé)人

1. 統(tǒng)籌每個場景客戶業(yè)務(wù)需求。

2. 定義業(yè)務(wù)需求的Definition of Done (例如指標(biāo)業(yè)務(wù)邏輯)。

3. 驗證和驗收上云結(jié)果。（注：上云數(shù)據(jù)的質(zhì)量結(jié)果，從一開始就需要業(yè)務(wù)方去驗證。項目推進(jìn)過程中，經(jīng)常出現(xiàn)由于源頭數(shù)據(jù)缺失或質(zhì)量不達(dá)標(biāo)的情況引起指標(biāo)不準(zhǔn)確的情況）

4. 驗證與驗收指標(biāo)。

客戶業(yè)務(wù)配合人

1. 客戶業(yè)務(wù)需求的制造者。

2. 定義業(yè)務(wù)需求的Definition of Done (例如指標(biāo)業(yè)務(wù)邏輯)。

3. 驗證和驗收上云結(jié)果。

4. 驗證與驗收指標(biāo)。

客戶技術(shù)負(fù)責(zé)人（客戶TM）

1. 對整體的交付質(zhì)量負(fù)責(zé)，對每一次迭代的質(zhì)量負(fù)責(zé)。

2. 告知并協(xié)助客戶的質(zhì)量和管理流程。

3. 統(tǒng)籌數(shù)據(jù)盤點和數(shù)據(jù)上云等工作。

客戶技術(shù)實施人

1. 數(shù)據(jù)盤點和數(shù)據(jù)上云等工作。

阿里云側(cè)角色

與之配合，阿里也需要提供五位一體的團(tuán)隊提供支持：

項目經(jīng)理 Project Manager

1. 解決團(tuán)隊每日存在的Blocker，重點解決阿里側(cè)的所有問題。

2. 保證最大限度完成每一次迭代，為總體進(jìn)度負(fù)責(zé)。

3. 組織每日站會，周會等例會。

架構(gòu)經(jīng)理Architect Manager

1. 參與業(yè)務(wù)和數(shù)據(jù)資產(chǎn)調(diào)研，整理數(shù)據(jù)資產(chǎn)報告

2. 數(shù)據(jù)的模型設(shè)計

3. 面向產(chǎn)品開發(fā)部門，反饋產(chǎn)品需求和建議。

技術(shù)經(jīng)理Technical Manager

1. 管理并進(jìn)行相關(guān)的開發(fā)工作，對整體的交付質(zhì)量負(fù)責(zé)，對每一次迭代的質(zhì)量負(fù)責(zé)。

2. 指導(dǎo)技術(shù)人員使用阿里產(chǎn)品，遵守開發(fā)規(guī)范等技術(shù)要求。

3. 評估工作量，并合理分配技術(shù)工作。

業(yè)務(wù)分析師 Business Analyst

1. 對整體的咨詢質(zhì)量負(fù)責(zé)，為項目的亮點提煉負(fù)責(zé)。

2. 總結(jié)，賦能和實踐數(shù)據(jù)阿里的最佳實踐和方法論。

產(chǎn)品PD

1. 負(fù)責(zé)可視化展示的設(shè)計。

2. 保證所設(shè)計的指標(biāo)能落地。

3. 負(fù)責(zé)內(nèi)部自測。

定計劃

唯有項目目標(biāo)和項目團(tuán)隊明確了以后，才能開始計劃的定制。項目計劃的制定必須是一個嚴(yán)謹(jǐn)詳細(xì)，群策群力的過程。一個好的計劃想要達(dá)到的效果是，讓項目組的每個人，能夠把這個項目即將經(jīng)歷的事情，都在腦海里面過一遍。這就例如史蒂芬·柯維在《高效能人士的七個習(xí)慣》書中所說的第一次創(chuàng)造的過程。

在這個過程中，經(jīng)常能夠預(yù)見到很多風(fēng)險。在很多公司很多人對于“創(chuàng)建詳細(xì)計劃”有抵觸心理，喜歡直接開干。這其實是不應(yīng)該的，在交付ToB、ToG項目時，如果前期計劃規(guī)劃做得不夠，很可能面臨客戶的挑戰(zhàn)，例如客戶可能會有如下的問題：

1. 你們定的計劃怎么和實際操作不太一樣？我怎么通過計劃監(jiān)督你們的進(jìn)度？

2. 你們計劃里面的一個任務(wù)就持續(xù)了兩個月的時間，這個任務(wù)都包含了什么？

3. 從原始計劃上看不到我們甲方需要配合什么，為何經(jīng)常需要甲方緊急的協(xié)助？

4. 為何項目預(yù)知風(fēng)險的能力？

5. 每個項目之間的關(guān)系是什么？

定章法

有人的地方便有江湖，特別是新組建的項目團(tuán)隊，大家都來自不同的團(tuán)隊，代表著不同的利益。在項目實施的開始之初，如果能夠組織項目組共同制定項目章程，將會對項目的順利實施起到非常大的幫助。創(chuàng)建項目章程的目的是，約定多方共事的游戲規(guī)則，以達(dá)到在滿足各自利益的前提下，共同完成項目的目標(biāo)。

項目章程包含了項目目標(biāo)、團(tuán)隊和計劃，同時也包含驗收方式，先決條件和協(xié)作方式等。同時提醒一點，要和客戶定章程，需要有良好的客戶關(guān)系為基礎(chǔ)，有了一定的默契才能真正遵守。缺少了人的支持，項目章程就變得沒有價值。甲方也需要重視項目章程的落地，這也是對甲乙雙方合作關(guān)系的保護(hù)。

數(shù)據(jù)中臺項目管理實踐分享（二）需求調(diào)研與設(shè)計

需求調(diào)研和設(shè)計階段，目的是承接的是項目起始階段的產(chǎn)物，并給下一階段“技術(shù)實施”輸出詳細(xì)的開發(fā)實施需求。

為了加速項目的實施進(jìn)度，在做需求調(diào)研的同時，還可以同步進(jìn)行數(shù)據(jù)的上云工作，和數(shù)據(jù)中臺數(shù)據(jù)架構(gòu)的設(shè)計（公共層設(shè)計）。以下3條線是可以并行進(jìn)行：

l 業(yè)務(wù)線負(fù)責(zé)業(yè)務(wù)調(diào)研

l 上云線負(fù)責(zé)數(shù)據(jù)上云

l 架構(gòu)線負(fù)責(zé)公共層數(shù)據(jù)架構(gòu)設(shè)計

業(yè)務(wù)線

業(yè)務(wù)調(diào)研及結(jié)合行業(yè)最佳實踐

阿里云數(shù)據(jù)中臺類項目的實施，有一個比較大的不同點在于，阿里云數(shù)據(jù)中臺是基于業(yè)務(wù)場景驅(qū)動的技術(shù)交付。 每一個業(yè)務(wù)場景都是圍繞著建立針對該業(yè)務(wù)場景的指標(biāo)/標(biāo)簽體系（以下簡稱指標(biāo)體系），并通過指標(biāo)體系指導(dǎo)業(yè)務(wù)運營，驅(qū)動和實現(xiàn)價值創(chuàng)造的過程。

指標(biāo)體系的建設(shè)過程，是對現(xiàn)有指標(biāo)或指標(biāo)體系的梳理，并結(jié)合行業(yè)或者跨行業(yè)（例如互聯(lián)網(wǎng)行業(yè)，新零售行業(yè)）的理解和最佳實踐，形成一套新的，能夠高效指導(dǎo)業(yè)務(wù)運營的指標(biāo)體系。對于現(xiàn)有指標(biāo)體系的收集，阿里云提供一系列的模板，可讓甲方根據(jù)日常的經(jīng)驗來收集填寫。

對于沒有實施過數(shù)據(jù)中臺項目的人，可能對指標(biāo)/標(biāo)簽體系和運營的關(guān)系理解不深，不明白指標(biāo)/標(biāo)簽是如何對運營能夠起到作用。舉一個相關(guān)的例子，新零售常用的AIPL營銷模型，是把人群資產(chǎn)定量化運營的模型，如下詳解：

A（Awareness），品牌認(rèn)知人群。包括被品牌廣告觸達(dá)和品類詞搜索的人；

I（Interest），品牌興趣人群。包括廣告點擊、瀏覽品牌/店鋪主頁、參與品牌互動、瀏覽產(chǎn)品詳情頁、品牌詞搜索、領(lǐng)取試用、訂閱/關(guān)注/入會、加購收藏的人；

P（Purchase），品牌購買人群，指購買過品牌商品的人；

L（Loyalty），品牌忠誠人群，包括復(fù)購、評論、分享的人。

在AIPL模型里，可以對每一個顧客的特性，進(jìn)行精準(zhǔn)營銷，有效提高顧客的忠誠度。

以上這就是指標(biāo)和標(biāo)簽驅(qū)動業(yè)務(wù)價值運營的過程。在這個階段有2個風(fēng)險值得提前做好應(yīng)對：

1. 成熟標(biāo)準(zhǔn)行業(yè)的龍頭擁有自己完善的運營方式。

曾服務(wù)過某客戶，是亞洲最大的行業(yè)龍頭，其所在的行業(yè)流程化程度極高，作為交付方我們很難拿出什么顛覆性的指標(biāo)/標(biāo)簽體系。

2. 新的運營方式出成績的周期大于項目建設(shè)周期。

數(shù)據(jù)中臺一個場景的建設(shè)周期，都需要6-12個月。即使能夠在運營方式上給客戶帶來指導(dǎo)，也很難讓客戶在項目周期內(nèi)實踐這一運營方式，因為變革增加了客戶的不適應(yīng)性和不確定性，經(jīng)常需要適合的契機。

PRD設(shè)計

在調(diào)研環(huán)節(jié)，項目的目標(biāo)是輸出大而全的指標(biāo)/標(biāo)簽體系，以幫助或者啟發(fā)客戶運營端的創(chuàng)新。所以MRD環(huán)節(jié)梳理的指標(biāo)體系，不一定要全部開發(fā)落地。某些指標(biāo)/標(biāo)簽，可能在當(dāng)下沒有數(shù)據(jù)基礎(chǔ)，但是可以作為未來企業(yè)數(shù)據(jù)采集規(guī)劃的方向。

但在PRD環(huán)節(jié)就不一樣了，PRD考慮的是根據(jù)指標(biāo)的價值，確定指標(biāo)的可落地性，并設(shè)計以可視化的方式，展示這些指標(biāo)。

在PRD設(shè)計環(huán)節(jié)完成后，理論上項目的需求范圍就比較清晰了，此時建議產(chǎn)出一份完整的需求總表（Product Backlog）。在此表示的是，與客戶達(dá)成一致，作為最終驗收前完成的需求范圍，那飽含需求的優(yōu)先級。需求總表涵蓋了在上一階段完成的MRD，PRD，本項目內(nèi)的上云清單，公共層維度與事實表建設(shè)清單，指標(biāo)/標(biāo)簽清單等。唯有需求范圍明確，優(yōu)先級定義清晰，后面的開發(fā)才能有章可循，避免需求擴散。

數(shù)據(jù)線

數(shù)據(jù)線，大概分為幾個步驟

1. 確定數(shù)據(jù)盤點和上云的范圍和優(yōu)先級

2. 數(shù)據(jù)盤點

3. 上云架構(gòu)設(shè)計和數(shù)據(jù)上云

確定數(shù)據(jù)盤點和上云的范圍和優(yōu)先級

該階段的目標(biāo)是，探查每個場景所需的數(shù)據(jù)，了解這些數(shù)據(jù)分布的系統(tǒng)，產(chǎn)出數(shù)據(jù)盤點和上云系統(tǒng)清單。需要注意的是，這個清單不僅要包含上云的系統(tǒng)和表，還需要包含上云的歷史數(shù)據(jù)回刷范圍。歷史數(shù)據(jù)回刷范圍是根據(jù)客戶想要看到多久的數(shù)據(jù)而定。例如客戶想看近2年的銷售額對比，那回刷的范圍就必須是2年以上。

數(shù)據(jù)盤點

根據(jù)上云系統(tǒng)清單去盤點所需用到的數(shù)據(jù)，盤點的內(nèi)容包括

系統(tǒng)流程映射表：基于業(yè)務(wù)過程，羅列各個業(yè)務(wù)系統(tǒng)間的關(guān)系。系統(tǒng)間數(shù)據(jù)互相訪問的時限要求。

數(shù)據(jù)源基本信息：基于系統(tǒng)級別，羅列各個業(yè)務(wù)系統(tǒng)的基礎(chǔ)信息，例如系統(tǒng)類型，數(shù)據(jù)庫類型，數(shù)據(jù)量，負(fù)責(zé)人等系統(tǒng)級別的信息。

數(shù)據(jù)資源目錄：基于表級別，羅列各個表的內(nèi)容描述，屬性信息，上云優(yōu)先級等。

數(shù)據(jù)字典：基于字段級別，羅列各個字段的屬性和元數(shù)據(jù)信息。

注：數(shù)據(jù)盤點的工作，不只是為了數(shù)據(jù)上云，可以同時考慮數(shù)據(jù)治理的一些工作，例如在數(shù)據(jù)盤點訪談的同時，也可以同時調(diào)研技術(shù)元數(shù)據(jù)和業(yè)務(wù)元數(shù)據(jù)的范圍。

上云架構(gòu)設(shè)計和數(shù)據(jù)上云

該階段是根據(jù)盤點的數(shù)據(jù)信息和數(shù)據(jù)使用要求，設(shè)計上云架構(gòu)，并依照架構(gòu)開始上云操作。

架構(gòu)線

架構(gòu)線有兩個動作：

1.梳理企業(yè)的業(yè)務(wù)大圖

2.基于業(yè)務(wù)大圖，指導(dǎo)數(shù)據(jù)中臺的公共層建設(shè)，也就是設(shè)計事實表和維度表的設(shè)計。

數(shù)據(jù)中臺業(yè)務(wù)大圖，關(guān)注基于業(yè)務(wù)對象的業(yè)務(wù)動作，和業(yè)務(wù)動作過程中涉及的業(yè)務(wù)對象。業(yè)務(wù)動作在中臺里面體現(xiàn)就是事實表，業(yè)務(wù)對象對應(yīng)的是維度表。

例如一個航空公司的客戶，他會購買機票，會付款，可能會退票退款，這些就是業(yè)務(wù)過程，有相關(guān)數(shù)據(jù)的對事實流水的記錄，即事實表。關(guān)于維度，可以簡單的理解為從哪個維度/角度/對象去分析這張事實表，例如從客戶的維度，機票的維度、付款的維度等。

在設(shè)計維度表和事實表（公共層）的時候，需同時考慮數(shù)據(jù)治理的相關(guān)事宜。在此前經(jīng)歷的某項目中，曾被客戶質(zhì)疑公共層的數(shù)據(jù)有些偏頗。復(fù)盤后發(fā)現(xiàn)由兩大原因?qū)е拢?/span>

問題一：客戶源數(shù)據(jù)質(zhì)量問題

問題二：缺失數(shù)據(jù)治理的環(huán)節(jié)

針對問題一的建議是，業(yè)務(wù)方在數(shù)據(jù)上云后，便開始檢查數(shù)據(jù)的質(zhì)量，而不是在開發(fā)后再去排錯。上云的數(shù)據(jù)質(zhì)量得不到保證，再準(zhǔn)確的計算口徑也不能得到一個準(zhǔn)確的指標(biāo)/標(biāo)簽。

針對問題二的流程建議是，在數(shù)據(jù)中臺實施過程中，加入數(shù)據(jù)治理的過程。 建議流程如下：

1. 基于業(yè)務(wù)大圖設(shè)計公共層的數(shù)據(jù)架構(gòu)（維度表和事實表）。

2. 組織客戶對維度表和事實表進(jìn)行評審。

3. 客戶信息中心基于維度表和事實表，完成技術(shù)元數(shù)據(jù)的數(shù)據(jù)治理。

4. 客戶業(yè)務(wù)方基于維度表和事實表，完成業(yè)務(wù)元數(shù)據(jù)的數(shù)據(jù)治理。

5. 客戶匯總技術(shù)元數(shù)據(jù)和業(yè)務(wù)元數(shù)據(jù)，阿里云再基于客戶提供的內(nèi)容，進(jìn)行開發(fā)。

數(shù)據(jù)中臺項目管理實踐分享（三）技術(shù)實施

傳統(tǒng)流水線開發(fā)

以往在做數(shù)據(jù)中臺項目的時候，沿用的是流水線型的開發(fā)方式，都是在上一個階段有較清晰完整的交付物時，才進(jìn)入到下一個階段。 例如需求明確了才設(shè)計。設(shè)計明確了，才開始開發(fā)。開發(fā)完成了，才開始驗收。這樣的好處是：1）便于需求的管理，可以通過設(shè)置里程碑，讓客戶確定需求，以降低需求的擴散；2）方便規(guī)劃資源的投入，在一段時間只要一類資源的投入。例如咨詢環(huán)節(jié)只投入BA，設(shè)計環(huán)節(jié)只投入PD。

但是這樣的問題是：

1. 經(jīng)常出現(xiàn)上下游不銜接，上游的需求不能被實現(xiàn)。

2. 重復(fù)工作，例如BA向客戶調(diào)研指標(biāo)口徑，但當(dāng)PD/TM接手指標(biāo)清單以后，PD/TM又需要重新和客戶梳理一回。

3. 由于所有的指標(biāo)/標(biāo)簽都是同時上線，客戶需要等待的時間較長?？蛻舨荒茌^好控制指標(biāo)的優(yōu)先級。

4. 對于乙方也是很不利的，等所有指標(biāo)都開發(fā)完成以后，才讓客戶驗收。驗收的風(fēng)險很大，周期長，返工風(fēng)險大。

5. 數(shù)據(jù)中臺持續(xù)的周期可能是半年以上，很難保證在這么長的周期內(nèi)，需求是一層不變的。哪怕是確認(rèn)了，也有更改可能。

敏捷式開發(fā)

為了解決以上的問題，阿里云在項目實施中引入了迭代式的開發(fā)。以雙周作為迭代計劃，每個雙周都是一個完整的開發(fā)單元。

每一次迭代，都需要進(jìn)行迭代規(guī)劃會，從需求總表中（Product Backlog）由客戶選出價值最高，優(yōu)先級最高的指標(biāo)作為本次迭代開發(fā)的目標(biāo)，該目標(biāo)稱之為迭代清單（Sprint Backlog）。

每一個迭代，都只與客戶共同完成本次迭代指標(biāo)口徑確認(rèn)，再進(jìn)行指標(biāo)開發(fā)，指標(biāo)測試，指標(biāo)驗收上線。在每一個雙周結(jié)束，和客戶進(jìn)行一次總驗收和復(fù)盤會。

這樣可以保證開發(fā)都是根據(jù)客戶價值的優(yōu)先級來進(jìn)行的。每一次迭代都能有指標(biāo)驗收和上線。對于甲方來說能提前分批預(yù)知風(fēng)險，客戶也可以提早使用高價值的指標(biāo)。

為了方便協(xié)同和實現(xiàn)項目可視化，推薦使用Teambition(TB)作為管理工具。首先預(yù)設(shè)項目模板，讓項目組的成員能夠方便的在TB上找到所需的項目內(nèi)容，對需求范圍的管理也很有幫助，例如上文提到的數(shù)據(jù)上云清單，維度表清單，事實表清單，指標(biāo)/標(biāo)簽清單，迭代清單等，每一類清單都有開發(fā)步驟和流程，很適合通過TB進(jìn)行可視化，流程化管理。

最后，質(zhì)量保障一定不能等到最后一刻才去進(jìn)行，這樣加大了復(fù)工風(fēng)險。質(zhì)量保障應(yīng)該有一個完整的機制，持續(xù)進(jìn)行。

數(shù)據(jù)中臺 - 項目收尾

項目收尾階段歸集交付物自行存檔并發(fā)給客戶，為完結(jié)的項目進(jìn)程和結(jié)果制作總結(jié)文件用于匯報。設(shè)計一些儀式，紀(jì)念里程碑時間點。同時復(fù)盤本期項目的亮點和缺點細(xì)節(jié)，以幫助下一個項目。