简介: 本文总结了企业级数据中台项意图实践经验,希望能够为正在规划或许已在施行数据中台类项意图企业和个人供给经验。

作者:吴剑弘(吉鉧)

简介

阿里云数据中台是一个包含落地施行方法论、渠道产品和技能服务的企业级处理方案。阿里云数据中台以Maxcompute等大数据核算渠道为载体,以三个One为理论根底构成数据中台方法论,结束在一个渠道里结束数据全生命周期的办理作业。

本文总结了企业级数据中台项意图实践经验,希望能够为正在规划或许已在施行数据中台类项意图企业和个人供给经验。

阿里云数据中台类项意图办理全貌和施行进程能够总结为以下大图:

6000字干货分享:数据中台项目管理实践分享

数据中台项目办理实践共享(一)项目发动

数据中台项目是一个企业级的项目,在每个数据中台项意图建造之初,需求进行全盘且较为全面的规划,防止‘单烟囱’式的方法去建造中台。

发动阶段是极为重要的,大部分的方案和规划都在这个阶段产出,主张这个阶段应该占到整个项目方案时刻的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能够来管控需求和需求的优先级。

6000字干货分享:数据中台项目管理实践分享

项目人物定位

客户侧人物

项目交给进程中,客户方的合作尤为重要,因而客户的人物显得尤为重要。

客户需求决议方案者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. 数据盘点和数据上云等作业。

阿里云侧人物

与之合作,阿里也需求供给五位一体的团队供给支撑:

6000字干货分享:数据中台项目管理实践分享

项目司理 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营销模型,是把人群财物定量化运营的模型,如下详解:

A(Awareness),品牌认知人群。包含被品牌广告触达和品类词搜索的人;

I(Interest),品牌爱好人群。包含广告点击、浏览品牌/店铺主页、参加品牌互动、浏览产品详情页、品牌词搜索、收取试用、订阅/关注/入会、加购保藏的人;

P(Purchase),品牌购买人群,指购买过品牌商品的人;

L(Loyalty),品牌忠诚人群,包含复购、谈论、共享的人。

在AIPL模型里,能够对每一个顾客的特性,进行精准营销,有用提高顾客的忠诚度。

以上这便是方针和标签驱动事务价值运营的进程。在这个阶段有2个危险值得提前做好应对:

1. 成熟规范职业的龙头具有自己完善的运营方法。

曾服务过某客户,是亚洲最大的职业龙头,其地点的职业流程化程度极高,作为交给方咱们很难拿出什么颠覆性的方针/标签体系。

2. 新的运营方法出成绩的周期大于项目建造周期。

数据中台一个场景的建造周期,都需求6-12个月。即便能够在运营方法上给客户带来辅导,也很难让客户在项目周期内实践这一运营方法,因为革新增加了客户的不适应性和不确认性,常常需求合适的契机。

PRD规划

在调研环节,项意图方针是输出大而全的方针/标签体系,以协助或许启示客户运营端的立异。所以MRD环节梳理的方针体系,不一定要全部开发落地。某些方针/标签,或许在当下没有数据根底,可是能够作为未来企业数据采集规划的方向。

但在PRD环节就不相同了,PRD考虑的是依据方针的价值,确认方针的可落地性,并规划以可视化的方法,展现这些方针。

在PRD规划环节结束后,理论上项意图需求规模就比较明晰了,此刻主张产出一份完好的需求总表(Product Backlog)。在此表明的是,与客户达到一致,作为终究检验前结束的需求规模,那饱含需求的优先级。需求总表涵盖了在上一阶段结束的MRD,PRD,本项目内的上云清单,公共层维度与现实表建造清单,方针/标签清单等。唯有需求规模明晰,优先级界说明晰,后边的开发才干有章可循,防止需求扩散。

数据线

数据线,大概分为几个进程

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)。

每一个迭代,都只与客户共同结束本次迭代方针口径确认,再进行方针开发,方针测验,方针检验上线。在每一个双周完毕,和客户进行一次总检验和复盘会。

6000字干货分享:数据中台项目管理实践分享

这样能够确保开发都是依据客户价值的优先级来进行的。每一次迭代都能有方针检验和上线。关于甲方来说能提前分批预知危险,客户也能够提前使用高价值的方针。

为了便利协同和结束项目可视化,推荐使用Teambition(TB)作为办理工具。首先预设项目模板,让项目组的成员能够便利的在TB上找到所需的项目内容,对需求规模的办理也很有协助,例如上文提到的数据上云清单,维度表清单,现实表清单,方针/标签清单,迭代清单等,每一类清单都有开发进程和流程,很合适经过TB进行可视化,流程化办理。

6000字干货分享:数据中台项目管理实践分享

6000字干货分享:数据中台项目管理实践分享

最终,质量保证一定不能等到最终一刻才去进行,这样加大了复工危险。质量保证应该有一个完好的机制,继续进行。

数据中台 – 项目收尾

项目收尾阶段归集交给物自行存档并发给客户,为结束的项目进程和成果制作总结文件用于报告。规划一些典礼,留念里程碑时刻点。同时复盘本期项意图亮点和缺点细节,以协助下一个项目。

原文链接:click.aliyun.com/m/100034866…

本文为阿里云原创内容,未经允许不得转载。