共计 7022 个字符，预计需要花费 18 分钟才能阅读完成。
简介：本文总结了企业级数据中台我的项目的实践经验，心愿可能为正在布局或者已在施行数据中台类我的项目的企业和集体提供教训。
作者：吴剑弘（吉鉧）
简介
阿里云数据中台是一个蕴含落地施行方法论、平台产品和技术服务的企业级解决方案。阿里云数据中台以 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. 基于业务大图，领导数据中台的公共层建设，也就是设计事实表和维度表的设计。
数据中台业务大图，关注基于业务对象的业务动作，和业务动作过程中波及的业务对象。业务动作在中台外面体现就是事实表，业务对象对应的是维度表。
例如一个航空公司的客户，他会购买机票，会付款，可能会退票退款，这些就是业务过程，有相干数据的对事实流水的记录，即事实表。对于维度，能够简略的了解为从哪个维度 / 角度 / 对象去剖析这张事实表，例如从客户的维度，机票的维度、付款的维度等。
在设计维度表和事实表（公共层）的时候，需同时思考数据治理的相干事宜。在此前经验的某我的项目中，曾被客户质疑公共层的数据有些偏颇。复盘后发现由两大起因导致：
问题一：客户源数据品质问题
问题二：缺失数据治理的环节
针对问题一的倡议是，业务方在数据上云后，便开始检查数据的品质，而不是在开发后再去排错。上云的数据品质得不到保障，再精确的计算口径也不能失去一个精确的指标 / 标签。
针对问题二的流程倡议是，在数据中台施行过程中，退出数据治理的过程。倡议流程如下：
- 基于业务大图设计公共层的数据架构（维度表和事实表）。
- 组织客户对维度表和事实表进行评审。
- 客户信息中心基于维度表和事实表，实现技术元数据的数据治理。
- 客户业务方基于维度表和事实表，实现业务元数据的数据治理。
- 客户汇总技术元数据和业务元数据，阿里云再基于客户提供的内容，进行开发。
数据中台项目管理实际分享（三）技术施行
传统流水线开发
以往在做数据中台我的项目的时候，沿用的是流水线型的开发方式，都是在上一个阶段有较清晰残缺的交付物时，才进入到下一个阶段。例如需要明确了才设计。设计明确了，才开始开发。开发实现了，才开始验收。这样的益处是：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…
本文为阿里云原创内容，未经容许不得转载。