怎么在百度首页做网站,南沙网站建设哪家好,网络公司经营范围能写建材吗,jsp网站开发源码简介
阿里云数据中台是一个包含落地实施方法论、平台产品和技术服务的企业级解决方案。阿里云数据中台以Maxcompute等大数据计算平台为载体#xff0c;以三个One为理论基础构成数据中台方法论#xff0c;实现在一个平台里完成数据全生命周期的管理工作。
本文总结了企业级数…简介
阿里云数据中台是一个包含落地实施方法论、平台产品和技术服务的企业级解决方案。阿里云数据中台以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的角色。可尝试由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营销模型是把人群资产定量化运营的模型如下详解
AAwareness品牌认知人群。包括被品牌广告触达和品类词搜索的人
IInterest品牌兴趣人群。包括广告点击、浏览品牌/店铺主页、参与品牌互动、浏览产品详情页、品牌词搜索、领取试用、订阅/关注/入会、加购收藏的人
PPurchase品牌购买人群指购买过品牌商品的人
LLoyalty品牌忠诚人群包括复购、评论、分享的人。
在AIPL模型里可以对每一个顾客的特性进行精准营销有效提高顾客的忠诚度。
以上这就是指标和标签驱动业务价值运营的过程。在这个阶段有2个风险值得提前做好应对
1. 成熟标准行业的龙头拥有自己完善的运营方式。
曾服务过某客户是亚洲最大的行业龙头其所在的行业流程化程度极高作为交付方我们很难拿出什么颠覆性的指标/标签体系。
2. 新的运营方式出成绩的周期大于项目建设周期。
数据中台一个场景的建设周期都需要6-12个月。即使能够在运营方式上给客户带来指导也很难让客户在项目周期内实践这一运营方式因为变革增加了客户的不适应性和不确定性经常需要适合的契机。
PRD设计
在调研环节项目的目标是输出大而全的指标/标签体系以帮助或者启发客户运营端的创新。所以MRD环节梳理的指标体系不一定要全部开发落地。某些指标/标签可能在当下没有数据基础但是可以作为未来企业数据采集规划的方向。
但在PRD环节就不一样了PRD考虑的是根据指标的价值确定指标的可落地性并设计以可视化的方式展示这些指标。
在PRD设计环节完成后理论上项目的需求范围就比较清晰了此时建议产出一份完整的需求总表Product Backlog。在此表示的是与客户达成一致作为最终验收前完成的需求范围那饱含需求的优先级。需求总表涵盖了在上一阶段完成的MRDPRD本项目内的上云清单公共层维度与事实表建设清单指标/标签清单等。唯有需求范围明确优先级定义清晰后面的开发才能有章可循避免需求扩散。
数据线
数据线大概分为几个步骤
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进行可视化流程化管理。 最后质量保障一定不能等到最后一刻才去进行这样加大了复工风险。质量保障应该有一个完整的机制持续进行。
数据中台 - 项目收尾
项目收尾阶段归集交付物自行存档并发给客户为完结的项目进程和结果制作总结文件用于汇报。设计一些仪式纪念里程碑时间点。同时复盘本期项目的亮点和缺点细节以帮助下一个项目。
作者吴剑弘吉鉧
原文链接
本文为阿里云原创内容未经允许不得转载。
