6000字干货分享（数据中台项目管理实践分享）后端

简介：本文总结了企业级数据中台项目的实践经验，希望能够为正在规划或者已在实施数据中台类项目的企业和个人提供经验。
作者：吴剑弘（吉鉧）
简介
阿里云数据中台是一个包含落地实施方法论、平台产品和技术服务的企业级解决方案。阿里云数据中台以Maxcompute等大数据计算平台为载体，以三个One为理论基础构成数据中台方法论，实现在一个平台里完成数据全生命周期的管理工作。
本文总结了企业级数据中台项目的实践经验，希望能够为正在规划或者已在实施数据中台类项目的企业和个人提供经验。
阿里云数据中台类项目的管理全貌和实施过程可以总结为以下大图：
image.png
数据中台项目管理实践分享（一）项目启动
数据中台项目是一个企业级的项目，在每个数据中台项目的建设之初，需要进行全盘且较为全面的规划，避免‘单烟囱’式的方式去建设中台。
启动阶段是极为重要的，大部分的计划和规划都在这个阶段产出，建议这个阶段应该占到整个项目计划时间的15%。若项目计划规划不充分，项目实施就可能是一个填坑的过程。在项目起始阶段，可按4步走：

定目标
定团队
定计划
定章法

定目标
在数据中台项目开始之前，需要考虑企业建设中台的初衷与目标。了解企业目前的战略，调研每个数据中台场景涉及的部门、部门目标，以及部门之间、场景之间的联通性。这样有助于实现数据中台的一体化建设，明确数据中台建设的目标，避免后续工作的返工。
基于企业目标和战略，拆解各个部门的目标和KPI。在规划数据中台时，考虑如何通过数据化进行分析、评价和考核，并通过可视化展示目标与进展。在调研项目目标时，项目组需要着重考量：

企业中不同角色都需要什么样的数据支持，这些数据的分布在哪里？数据流向何处？管理层建设数据中台的初衷是什么，他们都在关注哪些数据？

例如有些企业建设数据中台的初衷是进行数据治理，是想统一当前口径不一致的指标。如果我们能知道哪几个指标是管理层最大的痛点，就可以优先治理，提前满足管理层的部分需求。企业级数据中台的建设必须得到企业级管理层的支持，而数据类的项目常常是一个长期价值大，但过程枯燥的项目。所以，持续性向领导层体现项目的建设亮点就显得特别重要。

企业客户的数据将会如何被使用，从技术实施上考虑如何搭建相对应的架构？

例如实时和非实时场景，这也决定或影响了后续上云的架构。

这些数据所涉及到的业务流程有哪些？

除了要明确项目的目标之外，在实施过程中还需要考虑合同的约束条件，例如有无时间约束，投入工作量，是否对员工进行培训等。一些细节因素也会对项目产生影响。例如如果员工考核是在年底的12月31日，那项目最好在12月初就能有较好的产出，以便满足项目参与人员的绩效考核。
通过以上综合的考量，才能定下数据中台项目的目标，和每一个场景的子项目目标。
定团队
大型企业客户特别关心项目组织阵型和分工。数据中台项目是企业级项目，一个成功的数据中台项目团队，是必须有甲方的核心管理层、业务方、和技术方密切参与的。在很多的项目中，由于甲方团队不能深度参与或者角色缺失，导致协调力度不够，引起进度和质量的不可控。特别是政府和大型企业的项目，最难处理的就是组织内部的关系。组织架构图的绘制需要思考如何做到一碗水端平，又能满足推动项目的目的。
企业级项目建议设置一个项目管理委员会（Project Control Borad,以下简称PCB），由甲方的核心管理层和乙方的核心管理层参与。PCB的角色在于确定项目的目标，解决内部分歧，在项目需要决策时提供决策支持。如果PCB缺失，甲方多部门参与项目的时候，很容易因为部门间利益冲突，使得问题难以调停。
在大企业经常有的组织结构是，IT类项目的合同方是IT部门，但主导部门却是数据部门。IT部门与数据部门对项目的诉求，甚至可能是冲突的。项目组的结构设计必须充分考虑各个团队的诉求点，在求同存异的大方向下，确保大目标一致，让各个团队都处在适合的位置。为此，在传统角色的基础上，建议加设Product Owner的角色。可尝试由IT部门担任PM，数据类项目涉及较多IT部门内部流程，由IT部门的PM来协调流程更为顺畅，例如数据权限开通，产品权限开通等。 Product Owner可以来管控需求和需求的优先级。
image.png
项目角色定位
客户侧角色
项目交付过程中，客户方的配合尤为重要，因此客户的角色显得尤为重要。
客户需求决策者Project Owner

产品需求负责人
统一需求间存在的分歧
迭代式定义产品及需求优先级

客户项目经历Project Manager

解决团队每日存在的Blocker，重点解决客户侧的所有问题。
保证最大限度完成每一次迭代，为总体进度负责。
告知客户所需的流程需要，要做到可量化，可测试，可执行。
组织每日站会，周会等例会。

客户业务方负责人

统筹每个场景客户业务需求。
定义业务需求的Definition of Done (例如指标业务逻辑)。
验证和验收上云结果。（注：上云数据的质量结果，从一开始就需要业务方去验证。项目推进过程中，经常出现由于源头数据缺失或质量不达标的情况引起指标不准确的情况）
验证与验收指标。

客户业务配合人

客户业务需求的制造者。
定义业务需求的Definition of Done (例如指标业务逻辑)。
验证和验收上云结果。
验证与验收指标。

客户技术负责人（客户TM）

对整体的交付质量负责，对每一次迭代的质量负责。
告知并协助客户的质量和管理流程。
统筹数据盘点和数据上云等工作。

客户技术实施人

数据盘点和数据上云等工作。

阿里云侧角色
与之配合，阿里也需要提供五位一体的团队提供支持：
image.png
项目经理 Project Manager

解决团队每日存在的Blocker，重点解决阿里侧的所有问题。
保证最大限度完成每一次迭代，为总体进度负责。
组织每日站会，周会等例会。

架构经理Architect Manager

参与业务和数据资产调研，整理数据资产报告
数据的模型设计
面向产品开发部门，反馈产品需求和建议。

技术经理Technical Manager

管理并进行相关的开发工作，对整体的交付质量负责，对每一次迭代的质量负责。
指导技术人员使用阿里产品，遵守开发规范等技术要求。
评估工作量，并合理分配技术工作。

业务分析师 Business Analyst

对整体的咨询质量负责，为项目的亮点提炼负责。
总结，赋能和实践数据阿里的最佳实践和方法论。

产品PD

负责可视化展示的设计。
保证所设计的指标能落地。
负责内部自测。

定计划
唯有项目目标和项目团队明确了以后，才能开始计划的定制。项目计划的制定必须是一个严谨详细，群策群力的过程。一个好的计划想要达到的效果是，让项目组的每个人，能够把这个项目即将经历的事情，都在脑海里面过一遍。这就例如史蒂芬·柯维在《高效能人士的七个习惯》书中所说的第一次创造的过程。
在这个过程中，经常能够预见到很多风险。在很多公司很多人对于“创建详细计划”有抵触心理，喜欢直接开干。这其实是不应该的，在交付ToB、ToG项目时，如果前期计划规划做得不够，很可能面临客户的挑战，例如客户可能会有如下的问题：

你们定的计划怎么和实际操作不太一样？我怎么通过计划监督你们的进度？
你们计划里面的一个任务就持续了两个月的时间，这个任务都包含了什么？
从原始计划上看不到我们甲方需要配合什么，为何经常需要甲方紧急的协助？
为何项目预知风险的能力？
每个项目之间的关系是什么？

定章法
有人的地方便有江湖，特别是新组建的项目团队，大家都来自不同的团队，代表着不同的利益。在项目实施的开始之初，如果能够组织项目组共同制定项目章程，将会对项目的顺利实施起到非常大的帮助。创建项目章程的目的是，约定多方共事的游戏规则，以达到在满足各自利益的前提下，共同完成项目的目标。
项目章程包含了项目目标、团队和计划，同时也包含验收方式，先决条件和协作方式等。同时提醒一点，要和客户定章程，需要有良好的客户关系为基础，有了一定的默契才能真正遵守。缺少了人的支持，项目章程就变得没有价值。甲方也需要重视项目章程的落地，这也是对甲乙双方合作关系的保护。
数据中台项目管理实践分享（二）需求调研与设计
需求调研和设计阶段，目的是承接的是项目起始阶段的产物，并给下一阶段“技术实施”输出详细的开发实施需求。
为了加速项目的实施进度，在做需求调研的同时，还可以同步进行数据的上云工作，和数据中台数据架构的设计（公共层设计）。以下3条线是可以并行进行：
l 业务线负责业务调研
l 上云线负责数据上云
l 架构线负责公共层数据架构设计
业务线
业务调研及结合行业最佳实践
阿里云数据中台类项目的实施，有一个比较大的不同点在于，阿里云数据中台是基于业务场景驱动的技术交付。每一个业务场景都是围绕着建立针对该业务场景的指标/标签体系（以下简称指标体系），并通过指标体系指导业务运营，驱动和实现价值创造的过程。
指标体系的建设过程，是对现有指标或指标体系的梳理，并结合行业或者跨行业（例如互联网行业，新零售行业）的理解和最佳实践，形成一套新的，能够高效指导业务运营的指标体系。对于现有指标体系的收集，阿里云提供一系列的模板，可让甲方根据日常的经验来收集填写。
对于没有实施过数据中台项目的人，可能对指标/标签体系和运营的关系理解不深，不明白指标/标签是如何对运营能够起到作用。举一个相关的例子，新零售常用的AIPL营销模型，是把人群资产定量化运营的模型，如下详解：
A（Awareness），品牌认知人群。包括被品牌广告触达和品类词搜索的人；
I（Interest），品牌兴趣人群。包括广告点击、浏览品牌/店铺主页、参与品牌互动、浏览产品详情页、品牌词搜索、领取试用、订阅/关注/入会、加购收藏的人；
P（Purchase），品牌购买人群，指购买过品牌商品的人；
L（Loyalty），品牌忠诚人群，包括复购、评论、分享的人。
在AIPL模型里，可以对每一个顾客的特性，进行精准营销，有效提高顾客的忠诚度。
以上这就是指标和标签驱动业务价值运营的过程。在这个阶段有2个风险值得提前做好应对：

成熟标准行业的龙头拥有自己完善的运营方式。

曾服务过某客户，是亚洲最大的行业龙头，其所在的行业流程化程度极高，作为交付方我们很难拿出什么颠覆性的指标/标签体系。

新的运营方式出成绩的周期大于项目建设周期。

数据中台一个场景的建设周期，都需要6-12个月。即使能够在运营方式上给客户带来指导，也很难让客户在项目周期内实践这一运营方式，因为变革增加了客户的不适应性和不确定性，经常需要适合的契机。
PRD设计
在调研环节，项目的目标是输出大而全的指标/标签体系，以帮助或者启发客户运营端的创新。所以MRD环节梳理的指标体系，不一定要全部开发落地。某些指标/标签，可能在当下没有数据基础，但是可以作为未来企业数据采集规划的方向。
但在PRD环节就不一样了，PRD考虑的是根据指标的价值，确定指标的可落地性，并设计以可视化的方式，展示这些指标。
在PRD设计环节完成后，理论上项目的需求范围就比较清晰了，此时建议产出一份完整的需求总表（Product Backlog）。在此表示的是，与客户达成一致，作为最终验收前完成的需求范围，那饱含需求的优先级。需求总表涵盖了在上一阶段完成的MRD，PRD，本项目内的上云清单，公共层维度与事实表建设清单，指标/标签清单等。唯有需求范围明确，优先级定义清晰，后面的开发才能有章可循，避免需求扩散。
数据线
数据线，大概分为几个步骤

确定数据盘点和上云的范围和优先级
数据盘点
上云架构设计和数据上云

确定数据盘点和上云的范围和优先级
该阶段的目标是，探查每个场景所需的数据，了解这些数据分布的系统，产出数据盘点和上云系统清单。需要注意的是，这个清单不仅要包含上云的系统和表，还需要包含上云的历史数据回刷范围。历史数据回刷范围是根据客户想要看到多久的数据而定。例如客户想看近2年的销售额对比，那回刷的范围就必须是2年以上。
数据盘点
根据上云系统清单去盘点所需用到的数据，盘点的内容包括
系统流程映射表：基于业务过程，罗列各个业务系统间的关系。系统间数据互相访问的时限要求。
数据源基本信息：基于系统级别，罗列各个业务系统的基础信息，例如系统类型，数据库类型，数据量，负责人等系统级别的信息。
数据资源目录：基于表级别，罗列各个表的内容描述，属性信息，上云优先级等。
数据字典：基于字段级别，罗列各个字段的属性和元数据信息。
注：数据盘点的工作，不只是为了数据上云，可以同时考虑数据治理的一些工作，例如在数据盘点访谈的同时，也可以同时调研技术元数据和业务元数据的范围。
上云架构设计和数据上云
该阶段是根据盘点的数据信息和数据使用要求，设计上云架构，并依照架构开始上云操作。
架构线
架构线有两个动作：
1.梳理企业的业务大图
2.基于业务大图，指导数据中台的公共层建设，也就是设计事实表和维度表的设计。
数据中台业务大图，关注基于业务对象的业务动作，和业务动作过程中涉及的业务对象。业务动作在中台里面体现就是事实表，业务对象对应的是维度表。
例如一个航空公司的客户，他会购买机票，会付款，可能会退票退款，这些就是业务过程，有相关数据的对事实流水的记录，即事实表。关于维度，可以简单的理解为从哪个维度/角度/对象去分析这张事实表，例如从客户的维度，机票的维度、付款的维度等。
在设计维度表和事实表（公共层）的时候，需同时考虑数据治理的相关事宜。在此前经历的某项目中，曾被客户质疑公共层的数据有些偏颇。复盘后发现由两大原因导致：
问题一：客户源数据质量问题
问题二：缺失数据治理的环节
【6000字干货分享（数据中台项目管理实践分享）】针对问题一的建议是，业务方在数据上云后，便开始检查数据的质量，而不是在开发后再去排错。上云的数据质量得不到保证，再准确的计算口径也不能得到一个准确的指标/标签。
针对问题二的流程建议是，在数据中台实施过程中，加入数据治理的过程。建议流程如下：

基于业务大图设计公共层的数据架构（维度表和事实表）。
组织客户对维度表和事实表进行评审。
客户信息中心基于维度表和事实表，完成技术元数据的数据治理。
客户业务方基于维度表和事实表，完成业务元数据的数据治理。
客户汇总技术元数据和业务元数据，阿里云再基于客户提供的内容，进行开发。

数据中台项目管理实践分享（三）技术实施
传统流水线开发
以往在做数据中台项目的时候，沿用的是流水线型的开发方式，都是在上一个阶段有较清晰完整的交付物时，才进入到下一个阶段。例如需求明确了才设计。设计明确了，才开始开发。开发完成了，才开始验收。这样的好处是：1）便于需求的管理，可以通过设置里程碑，让客户确定需求，以降低需求的扩散；2）方便规划资源的投入，在一段时间只要一类资源的投入。例如咨询环节只投入BA，设计环节只投入PD。
但是这样的问题是：

经常出现上下游不衔接，上游的需求不能被实现。
重复工作，例如BA向客户调研指标口径，但当PD/TM接手指标清单以后，PD/TM又需要重新和客户梳理一回。
由于所有的指标/标签都是同时上线，客户需要等待的时间较长。客户不能较好控制指标的优先级。
对于乙方也是很不利的，等所有指标都开发完成以后，才让客户验收。验收的风险很大，周期长，返工风险大。
数据中台持续的周期可能是半年以上，很难保证在这么长的周期内，需求是一层不变的。哪怕是确认了，也有更改可能。

敏捷式开发
为了解决以上的问题，阿里云在项目实施中引入了迭代式的开发。以双周作为迭代计划，每个双周都是一个完整的开发单元。
每一次迭代，都需要进行迭代规划会，从需求总表中（Product Backlog）由客户选出价值最高，优先级最高的指标作为本次迭代开发的目标，该目标称之为迭代清单（Sprint Backlog）。
每一个迭代，都只与客户共同完成本次迭代指标口径确认，再进行指标开发，指标测试，指标验收上线。在每一个双周结束，和客户进行一次总验收和复盘会。
image.png
这样可以保证开发都是根据客户价值的优先级来进行的。每一次迭代都能有指标验收和上线。对于甲方来说能提前分批预知风险，客户也可以提早使用高价值的指标。
为了方便协同和实现项目可视化，推荐使用Teambition(TB)作为管理工具。首先预设项目模板，让项目组的成员能够方便的在TB上找到所需的项目内容，对需求范围的管理也很有帮助，例如上文提到的数据上云清单，维度表清单，事实表清单，指标/标签清单，迭代清单等，每一类清单都有开发步骤和流程，很适合通过TB进行可视化，流程化管理。
image.png
image.png
最后，质量保障一定不能等到最后一刻才去进行，这样加大了复工风险。质量保障应该有一个完整的机制，持续进行。
数据中台 - 项目收尾
项目收尾阶段归集交付物自行存档并发给客户，为完结的项目进程和结果制作总结文件用于汇报。设计一些仪式，纪念里程碑时间点。同时复盘本期项目的亮点和缺点细节，以帮助下一个项目。
原文链接：http://click.aliyun.com/m/100...
本文为阿里云原创内容，未经允许不得转载。