简介
阿里云中间平台是一个企业级解决方案，包括实现方法论、平台产品和技术服务。阿里云数据中心以Maxcompute等大数据计算平台为载体，以三个一为理论基础，形成数据中心的方法论，在一个平台实现数据全生命周期的管理。
本文总结了企业级数据平台项目的实践经验，希望能为正在规划或已经实施数据平台项目的企业和个人提供经验。
阿里云数据中平台项目的整体管理图景和实施过程可以概括为以下大图景:
数据平台项目管理实践分享项目启动。
数据平台项目是一个企业级项目。在每个数据平台项目建设之初，就要进行全面综合的规划，避免数据平台建设的‘单烟囱’方式。
创业阶段极其重要，大部分计划和方案都是在这个阶段产生的。建议这个阶段占整个项目策划时间的15%。如果项目策划不充分，项目实施可能就是一个填坑的过程。在项目的初始阶段，您可以遵循四个步骤:
设定目标
2.组建一个团队
制定计划
4.制定规则。
确立目标
在数据中心项目开始之前，需要考虑建设数据中心的初衷和目标。了解企业当前的战略，调查每个数据场景涉及的部门和目标，以及部门和场景之间的连接性。这将有助于实现数据中心的一体化建设，明确数据中心建设的目标，避免后续工作的返工。
根据企业目标和战略，分解各部门的目标和KPI。在规划数据中心时，考虑如何通过数据进行分析、评估和检查，并通过可视化展示目标和进度。调查项目目标时，项目团队应关注:
1.企业中不同的角色需要什么样的数据支持，这些数据分布在哪里？数据流向哪里？管理层建设数据中心的初衷是什么，关注的是哪些数据？
比如有些企业建数据中心的初衷是为了管理数据，目前统一不同口径的指标。如果能知道哪些指标是管理层最大的痛点，就可以优先治理，提前满足管理层的一些需求。企业级数据中心的建设必须要有企业级管理的支撑，而数据项目往往是一个长期的项目，价值巨大但过程枯燥。因此，不断向领导反映项目的亮点就显得尤为重要。
2.企业客户的数据会如何使用，如何从技术实现上构建相应的架构？
比如实时和非实时场景，这也决定或影响了后续云的架构。
3.这些数据涉及哪些业务流程？
除了明确项目的目标之外，还需要考虑合同在实施过程中的约束条件，比如是否有时间约束、工作量、是否培训员工等。一些细节也会影响项目。比如年底员工考核是12月31日，那么项目在12月初就应该有比较好的产出，这样才能满足项目参与者的绩效考核。
通过以上综合考虑，我们可以设定数据中的中间项目的目标和每个场景的子项目目标。
丁堆
大型企业客户特别关注项目的组织形式和分工。数据中心项目是企业级项目。一个成功的数据中心项目团队必须有甲方核心管理层、业务方和技术方的密切参与。很多项目中，甲方团队不能深度参与或者角色缺失，导致协调不够，进度和质量不可控。尤其是政府和大企业的项目，最难处理的就是组织内部的关系。组织机构图的绘制需要考虑如何做到一碗水端平，达到推进项目的目的。
对于企业级项目，建议成立有甲乙双方核心管理层参与的项目管理委员会，PCB的作用是确定项目目标，解决内部分歧，在项目需要决策时提供决策支持。如果PCB缺失，甲方多部门参与项目时，容易出现部门间利益冲突，导致问题难以调解。
在大型企业的组织架构中，IT部门是IT项目的承建方，但主导部门是数据部门。IT部门和数据部门对项目的需求甚至可能冲突。项目团队的结构设计一定要充分考虑各个团队的诉求点，求同存异，保证大的目标一致，让各个团队都处于合适的位置。因此，在传统角色的基础上，建议增加产品负责人的角色。尝试使用IT部门作为PM。数据项目更多涉及IT部门内部流程，IT部门的PM可以更顺畅地协调流程，比如开放数据权限、产品权限等。产品所有者可以控制需求和需求的优先级。
项目角色定位
次要角色
在项目交付过程中，客户的配合尤为重要，因此客户的作用尤为重要。
客户决策者项目负责人
1.负责产品需求的人
2.统一要求之间的分歧
3.反复定义产品和需求优先级
客户体验项目经理
1.解决团队中Blocker的日常存在，重点解决客户端的所有问题。
2.保证每一次迭代最大限度的完成，对整体进度负责。
3.告知客户所需的过程需求，这些需求应该是可量化的、可测试的和可执行的。
4.组织每日例会、周会和其他例会。
商务聚会负责人
1.协调每个场景中客户的业务需求。
2.定义业务需求完成的定义。
3.验证并接受云结果。
4.验证和验收指标。
商业伙伴
1.客户业务需求的制造者。
2.定义业务需求完成的定义。
3.验证并接受云结果。
4.验证和验收指标。
客户的技术负责人
1.对整体交付质量和每次迭代的质量负责。
2.在质量和管理过程中通知和协助客户。
3.协调数据库存和数据云。
技术实施者
1.数据库存和数据云等。
阿里云侧面角色
与此合作，阿里还需要五位一体团队提供支持:
项目经理
1.解决团队中Blocker的日常存在，重点解决阿里端的所有问题。
2.保证每一次迭代最大限度的完成，对整体进度负责。
3.组织每日例会、周会和其他例会。
建筑经理
1.参与业务和数据资产研究，整理数据资产报告。
2.数据的模型设计。
3.面向产品开发部门，反馈产品需求和建议。
技术经理技术经理
1.管理和执行相关开发工作，对整体交付质量和每次迭代的质量负责。
2.指导技术人员使用阿里产品，遵守开发规范等技术要求。
3.评估工作量，合理分配技术工作。
商业分析师
1.负责整体咨询质量，提炼项目亮点。
2.总结、授权和实践data Ali的最佳实践和方法。
产品PD
1.负责视觉展示的设计。
2.确保设计的指标能落地。
3.负责内部自测。
制定计划
只有明确了项目目标和项目团队，才能开始方案的定制。项目的制定必须是一个严格、详细和协调的过程。一个好的计划想要达到的效果是，项目组的每个人都能在脑海中经历项目将要经历的事情。这就是比如斯蒂芬·柯维在《高效能人士的七个习惯》一书中提到的第一次创造的过程。
在这个过程中，往往可以预见到很多风险。在很多公司，很多人对“创建详细计划”有抵触情绪，喜欢直接开始。其实这是不应该的。在交付ToB和ToG项目时，如果前期规划做得不够，很可能会面临来自客户的挑战。例如，客户可能有以下问题:
1.你的计划和实际操作有什么不同？我如何通过计划监控你的进度？
2.你计划中的一项任务持续了两个月。这项任务包括什么？
3.从原计划中，我们看不出甲方需要配合什么。为什么我们经常需要甲方的紧急援助？
4.为什么说项目的风险预测能力？
5.各个项目之间有什么关系？
制定规则
有地利人和的江湖，尤其是新组建的项目组。大家来自不同的团队，代表不同的利益。在项目实施初期，如果能组织项目团队共同制定项目章程，对项目的顺利实施有很大的帮助。制定项目章程的目的是规定多方共同努力的游戏规则，以达到在满足各自利益的前提下共同完成项目的目的。
项目章程包含项目目标、团队和计划，以及验收方式、前提条件和合作方式。同时要提醒你，你需要有一个良好的客户关系作为基础来和客户制定章程，有一定默契才能真正遵守。没有人们的支持，项目章程就变得毫无价值。甲方也需要重视项目章程的执行，这也保护了甲乙双方的合作关系。
数据台中项目管理实践共享需求的研究与设计
研究和设计阶段旨在承担项目初始阶段的产品，并为下一阶段的“技术实施”输出详细的开发和实施需求。
为了加快项目的实施进度，在做需求调研的同时，可以同步进行数据的云端工作，设计数据中心的数据架构。以下三行可以并行执行:
l业务线负责业务调研。
l云线负责数据云。
l架构线负责公共层数据架构的设计。
插入干线
业务研究和行业最佳实践的整合
阿里云数据平台项目实施的一个很大的区别是，阿里云数据平台是基于业务场景驱动的技术交付。每一个业务场景都围绕着为业务场景建立指标/标签体系，并通过指标体系指导业务运营、驱动和实现价值创造的过程。
指标体系构建的过程是对现有的指标或指标体系进行梳理，结合行业或跨行业的理解和最佳实践，形成一套新的能够高效指导企业经营的指标体系。对于现有指标体系的采集，阿里云提供了一系列模板，供甲方根据日常经验进行采集和填写。
对于没有实施过数据中心项目的人来说，可能对指标/标签体系与运营之间的关系，以及指标/标签如何在运营中发挥作用并没有深刻的理解。举一个相关的例子，新零售常用的AIPL营销模型是一个量化人的资产运作的模型，如下:
a、品牌认知人群。包括被品牌广告感动，被类目词搜索的人群；
p，品牌购买者，指购买过品牌商品的人；
l、品牌忠诚的人，包括复购、评论、分享的人。
在AIPL模型中，我们可以准确地营销每个客户的特征，并有效地提高客户忠诚度。
这就是指标和标签驱动商业价值运营的过程。在这个阶段，有两个风险值得提前处理:
1.成熟标准行业的龙头有自己完善的运营模式。
曾经服务过一个客户，是亚洲最大的行业龙头，行业高度精简。作为投放方，我们很难拿出什么颠覆性的指标/标签体系。
2.新运营模式的成果期比项目建设期要长。
在数据站构建一个场景需要6-12个月。即使能在运营模式上给予客户指导，客户也很难在项目周期中实践这种运营模式，因为变更增加了客户的不适应性和不确定性，他们往往需要合适的机会。
珠三角设计
在研究阶段，项目的目标是输出一个庞大而全面的指标/标签体系，帮助或启发客户运营端的创新。因此，没有必要完全开发MRD链接梳理的指标体系。有些指标/标签目前可能没有数据基础，但可以作为未来企业数据收集规划的方向。
但是，在珠三角就不一样了。PRD考虑到指标可以根据其值落地，设计了可视化的方式来显示这些指标。
在PRD设计完成后，项目的需求范围在理论上将会明确。这时候建议制作一份完整的需求汇总表。这里是指与客户达成协议，作为最终验收前完成的需求范围，充满了需求的优先级。总需求表包括前一阶段完成的MRD和PRD、本项目中的云访问列表、公共维度和事实表构建列表、指标/标签列表等。只有需求范围清晰，优先级明确，后面的开发才有章可循，避免需求扩散。
数据线；数据同步传输电缆
数据线，大概分几个步骤。
1.确定数据清点和云访问的范围和优先级。
2.数据清单
3.云架构设计和数据云
确定数据清点和云访问的范围和优先级。
此阶段的目标是探索每个场景所需的数据，了解这些数据的分发系统，清点输出数据和云系统列表。需要注意的是，这个列表不仅要包括云上的系统和表，还要包括云上的历史数据刷取范围。历史数据刷新的范围取决于客户希望查看数据的时间。比如一个客户想看近两年的销售对比，刷回来的范围必须是两年以上。
数据清单
根据云系统列表，查看需要的数据。检查的内容包括
系统映射表:根据业务流程，列出各个业务系统之间的关系。系统间数据访问的时间限制要求。
基础数据源信息:基于系统层面，列出各业务系统的基本信息，如系统类型、数据库类型、数据量、负责人等系统层面信息。
数据目录:基于表格级别，列出内容描述、属性信息、云优先级等。每张桌子。
字典:基于字段级别，列出每个字段的属性和元数据信息。
注意:数据清单不仅是针对云的，也是针对数据治理的。例如，在数据清单访谈期间，还可以调查技术元数据和业务元数据的范围。
云架构设计和数据云
在这个阶段，根据库存的数据信息和数据使用需求，设计上云架构，根据架构启动上云运营。
建筑线条
该架构有两个动作:
1.梳理企业的商业图景。
2.基于大业务图景，指导数据中心公共层建设，即设计事实表和维度表。
data desk的大业务地图重点关注基于业务对象的业务动作，以及业务动作过程中涉及的业务对象。业务操作反映在中间桌面的事实表中，业务对象对应于维度表。
比如一个航空空公司的客户会买一张飞机票，付款，可能会退票。这些是业务流程，以及带有相关数据的事实记录，即事实表。至于维度，可以简单理解为从哪个维度/角度/对象来分析这个事实表，比如从客户维度，飞机票维度，支付维度等等。
在设计维度表和事实表时，需要同时考虑数据治理的相关问题。在之前的一个项目中，客户质疑公共层的数据有偏差。复盘后发现是两大原因造成的:
问题1:客户源数据的质量。
问题2:数据治理缺乏环节
第一个问题的建议是，数据上云后，业务端开始检查数据的质量，而不是开发后再调试。云数据的质量无法保证，再精确的计算口径也无法得到准确的指标/标签。
第二个问题的流程建议是在数据中心的实施中添加数据治理流程。建议的流程如下:
1.基于大业务图设计公共层的数据架构。
2.组织客户查看维度表和事实数据表。
3.客户信息中心基于维度表和事实表完成技术元数据的数据管理。
4.客户业务端基于维度表和事实表完成业务元数据的数据管理。
5.客户汇总技术元数据和业务元数据，阿里云基于客户提供的内容进行开发。
项目管理实践共享技术在数据平台中的实现
传统管道开发
以前做数据中期项目，遵循的是流水线开发方式，只有前一阶段有了清晰完整的可交付成果，才进入下一阶段。例如，只有在需求明确时才进行设计。只有设计清楚了，才能开始开发。开发完成后，开始验收。这样做有以下优点:1)便于需求管理，客户可以通过设置里程碑来确定自己的需求，减少需求的扩散；2)便于规划资源的投入，一段时间内只需要一种资源。比如咨询只投BA，设计只投PD。
但问题是:
1.上下游往往脱节，上游需求无法实现。
2.重复的工作，比如BA调查客户的指标口径，但是PD/TM接手指标清单后，PD/TM需要再次与客户进行梳理。
3.由于所有指示器/标签同时在线，客户需要等待很长时间。客户无法更好的控制指标的优先级。
4.对乙方也很不利，而且所有指标都制定好了，客户才能接受。验收风险大，周期长，返工风险高。
5.数据中心的持续周期可能在半年以上，很难保证在这么长的周期内需求是恒定的。即使确认了，也有可能改变。
敏捷开发
为了解决上述问题，阿里云在项目实施中引入了迭代开发。以双周为迭代计划，每个双周为一个完整的开发单元。
每一次迭代都需要召开一次迭代规划会议，客户从需求汇总表中选择价值和优先级最高的指标作为本次迭代开发的目标，称为迭代列表。
在每次迭代中，我们只和客户一起确认本次迭代的指标口径，然后进行指标开发、指标测试和指标验收。每两周结束时，与客户举行一次全面验收和重新报价会议。
这样可以保证开发按照客户价值的优先级进行。每次迭代都可以有指标验收和上线。对于甲方来说，可以提前批量预测风险，客户也可以提前使用高价值指标。
为了便于协作和实现项目可视化，建议使用Teambition作为管理工具。首先预置项目模板，让项目组成员在TB上轻松找到需要的项目内容，对于需求范围的管理也很有帮助，比如上面提到的数据云列表、维度表列表、事实表列表、指标/标签列表、迭代列表等。每种列表都有开发步骤和流程，非常适合通过TB进行可视化和流程管理。
最后，质量保证一定不能等到最后一刻，这增加了复工的风险。质量保证应该有一个完整的机制，并持续进行。
数据表-项目结束
在项目的收尾阶段，收集到的可交付成果将自行归档并发送给客户，并为已完成的项目进度和结果准备一份总结文件进行汇报。设计一些纪念里程碑的仪式。同时回顾这个项目的亮点和不足的细节，为下一个项目提供帮助。
作者:吴
原文链接:http://click.aliyun.com/m/1000348660/
本文为阿里云原创内容，未经允许不得转载。
