飞猪项目管理数字化实践

6月29日，阿里巴巴研发效能部与PMI、Teambition联合举办的阿里巴巴研发效能实践日将在杭州西溪园区举行，活动聚焦敏捷精益项目管理。活动详情及报名可点我前往。

项目管理的目的是什么？面对工做中的各类不肯定性，如何利用数据帮助项目管理？又有哪些数据是项目经理须要关注的？这里分享一篇飞猪技术部高级项目管理专家姚澍的文章，但愿给你带来一些启发。

前言

项目管理是起源于20世纪中期美国的航空项目，通过大量专业的项目管理从业人士总结出来的一门学科，而且随着时间发展在不断演进、更新，好比，在2018最新的PMBOK第六版中就提出了敏捷适应型的项目管理方法、拉动式的进度规划、新型项目经理价值等等。当下，全球IT公司中都在普遍使用LeSS、SaFe、精益、DevOps，这些新颖的方法论都集中关注在高效的产品开发或生产阶段，依然没法彻底取代更系统化的项目管理。

项目管理的目的

常常听到周边的同窗说，项目经理一没权威、二没前途，谁都不肯意作项目经理，由于干很差就要背锅。现实中，看到的不少项目经理项目计划拍脑壳，执行过程拍胸脯，项目战报拍马屁，最后草草收尾、拍拍手走人。彷佛由于带着“管理”两个字，让你们误觉得这是一个务虚的官僚主义行为，丝绝不考虑当中的科学性、知识体系、方法论，最后学敏捷只学会了站会、学精益只学会了画看板、学DevOps只学会了刷脸好办事。

为何要有项目？为何要项目管理？咱们在管理什么？难道只是为了运动式的完成一项任务？难道只是为了每一年绩效好考核？咱们常常被身在其中的身份制约了视野，老是想着用多快好省的方法达到目的，结果在不知不觉当中，就走入了小巷之中。在那个窄巷当中行走，不是进，就是退，甚至没法转身。只有跳出本身的小巷思惟、凌空跃起再去审视局面时，才能看到还有不少其余的选择和出路。这时，才会天然的去追问：为何要立项？项目里为何要有这些需求？哪些产品特性须要改变？研发团队的开发活动如何分解？谁在关键路径上？要花费多少工时？如何保证全部研发活动最后能按时按质量交付？如何保证产品上线后实现业务目标？如何监控过程当中的风险、问题？最后项目的投资回报好比何？是否完成了企业的财年目标？财报中我们今年将是亏仍是盈？

这样一系列追问下来，是否是慢慢感受自带CEO视角了？ 对，没错。项目就是企业的平常活动的组织方式，在质疑要不要立项时就分辨了哪些是临时任务哪些是每日例行，就能识别出企业最核心的关键任务，采用合适的方法管理项目和平常。

初创企业里，团队很小，七、8我的一间房、通信靠喊的时代，沟通、管理成本是相对较小的，肯定优先级就能够直接执行了，甚至也没什么好失去的。然而团队体量上去以后，稍有疏忽，沉没成本太大，会直接影响企业存亡。

项目管理铁三角里的几个因素：范围、成本、工期、质量，都和企业的关注高度吻合，企业管理核心也就天然落到了关键项目的管理上。

为什么要数字化管理项目

互联网公司要面对不少不肯定的用户、对手、市场，面对未知，咱们怎么办？只有两个方法：

• 试验，在小范围快速实现产品原型，灰度测试或者A/B测试收取反馈，结合运营效果快速反馈，在下一个迭代优化、改进。
• 度量，准肯定义度量维度，精确、及时收集数据，运用数据分析暴露问题、验证试验结果，从而持续优化。

度量离不开数据，我见过不少项目经理，在描述本身带过的项目规模时，说不出准确的数字：多少团队成员、多大项目范围（代码行、特性数量、开发工时），多长的项目周期，多少项目成本，怎样的业务目标？不少人甚至分不清楚OPEX和CAPEX，更不用说ROI。由于缺乏谈数字的环境，缺乏对数字的敏感，没有鼓励和培养人人习惯用数字分析来系统性思考的内部环境，致使大部分的技术甚至PD只会埋头干活，鲜少追问为何，沟通时也用大量的篇幅主观、模糊的描述项目进展，形成理解误差、沟通低效。

为何要习惯在工做中谈数字呢？

• 数字是量化的目标。企业运做是有详细细节规划的，好比，财年的业务目标、成本预算，应该层层分解，落实到各个项目、各个节点当中去，甚至要能反向推导，这样才能预测月度、季度的运营结果。同时，在过程中能做为组织行为的基准线，让你们自觉针对目标及时调整行为。
• 数字更客观，能更准确描述细节。数字比感受更可靠，人每每容易被本身的情绪、偏见、误解欺骗，会对事实做出错误的判断。论据越客观、越细致，才越能经得起推敲，无论是用来决策仍是沟通，都远胜于简单的拍脑壳。
• 数字是驱动力。项目经理的核心价值应该在数据分析上，能从大量的、有效的数据当中发现趋势，识别风险或者机会，及时调整项目策略，保障项目目标达成。遗憾的是，现实中大多数项目经理都干的是初级的信息、事实收集工做。不是说信息收集不重要，而是应该创建起通用的、自动化的、可视化的数据大盘，把精力投入到收集完以后如何整合，如何解读，如何决策。

哪些数据是项目经理必须关注的

以下表所示，项目的不一样阶段的关注重点不同，相应的要有高效的手段挖掘出有用的信息。

注：文中提到的Aone是阿里一站式研发协做平台，对外叫云效，下同

事实上，AONE已经能基本提供收集以上全部信息的功能。不少大型的IT企业一直竭尽全力的在寻找合适的工具管理各种信息，由于历史遗留问题，不得不花费大量的时间、精力打通全部的信息通道，迁移、整合数据，而AONE已经帮助咱们弯道超车，实现了完整的需求产生、生产、集成、发布、部署。在飞猪，咱们更进一步，针对特定的应用场景，基于AONE的数据，二次开发，用魔法石生成了重点项目的定制化项目数据大盘。

飞猪项目数据大盘实践

那么数据大盘包含了哪些内容呢？

首先，从19财年业务策略开始梳理重点战役结构，用一张图画出各战役之间的关联（如下为示意图），并明确负责的项目经理和产品经理，造成第一级的项目目录。重点在：

• 分清楚项目发起人和项目集经理。咱们常常容易把这两个角色弄混，一个项目会出现好几个管理者，在不一样场合项目经理的名字不同。项目经理是第一责任人，必须是直接指挥、跟踪、汇报项目的执行人，明确其惟一性和权威性并广而告之很重要，能加速问题解决和减小沟通误解。
• 整合项目结构，合并相关联的，并普遍沟通。
• 目标明确再立项。

设定统一的项目里程碑规范。之前项目的里程碑计划很随意，无关紧要，大小不一。容易形成：颗粒度过小，外部干系人看不懂；颗粒度太大，缺乏对项目组内的指导。如今采用统一的M系列里程碑定义，明确项目考核的时间点和标准，严格执行重要里程碑（M1&M4）的评审制度，有效的管理干系人指望，并随时度量下一个里程碑的可实现性。这样的好处是：

• 用统一的术语规范的项目执行的质量标准。
• 里程碑评审增长项目执行的严肃性和完整性，作到善始善终，防止有始无终，帮助持续改进。
• 增长沟通有效性，项目的评审结果和跟踪直观、易读、统一。

整理AONE项目空间，明确产品线、项目组合、项目集、项目的结构关系。需求、测试、缺陷、发布所有落入AONE，在魔法石生成对应的报表结构，层层钻取细节信息。

• 在飞猪产品线下设置子产品线，全部需求都直接在对应的子产品线下建立，遵循统一的规范模版，这样才能保证全部需求属性一致，方便魔法石度量。
• 全部重要项目在PMO注册、建立，不容许私建项目。简化项目结构，只容许两层项目归属关系，避免过深的项目结构带来的责任不明确。
• 由PMO组织重点项目例会，项目集经理向项目发起人汇报项目状态，方便及时调整策略、暴露问题，解决冲突，同步信息。

建设项目经理的责任制，要求项目经理必须对项目总体表现给出信心判断，依据AONE里的项目健康度信息造成项目晴雨表，红绿灯直观表现出项目的健康状态。要注意的是：

• 项目状态是项目经理的主观判断，是报告里为数很少的非客观评价，但不能省略，总体判断项目健康状态，同时也给出责任人的承诺
• 项目的趋势比单点状态更重要。对持续告警的项目，要开始专项治理。

针对需求管理，首先明确不一样角色的责任和合做方式。清晰的项目边界是成功的关键。项目启动初期，应该花大量的时间和精力明确需求范围、优先级、技术方案，而不是盲目开工，毫无纪律的边讨论边干活，不断返工，最后越作越困惑。好比，下面的两个实例，

• 项目A，对各种需求范围的管理都很严格，需求总量只出不进，每个月评审上线效果，在后期果断丢弃低优先级的需求保证项目按时完结。
• 而项目B，各种需求都在缓慢增加，实际表现就是项目作的像平常，将来没有规划，想到什么就作什么，目标不明确。

使用按优先级分类的需求累积流图，识别项目核心交付内容，经过平常监管防止项目边界蔓延，作到善始善终，清空桌面再结项。

测试计划可使用甘特图，测试过程当中要有按期（每日/每周）进展推动图。项目后半段的时候，每每是测试的白热化阶段，有些项目可能须要用日会结合缺陷报告重点推动，识别出阻塞测试的缺陷，是否须要组织特殊小分队集中解决难题，是否须要不断升级警告直到团队的高层领导桌面上，要能结合进展明确指出问题以及解决办法，而不要罗列繁琐的细节。

缺陷分析，在宏观上，要能指出质量问题是否收敛，解决速度是否够快，识别重点问题集中区；微观上要就重点问题清单，点对点分析缘由、找出解决方案、给出实施计划。缺陷不只仅是质量风险，也是工做量，无论是修复问题，仍是提出新需求，都是整个项目的新增工做量。实际上，缺陷也是能够预测的，根据千行缺陷率、改动代码行数、修复工时、合适的数据预估模型，就能更合理的估计产品上线时间，而不是总倒排工期。作到符合必定质量标准的产品才容许上线，杜绝只开发不测试、只测试不修复、无纪律上线等一系列严重影响用户体验的行为。

风险管理一直是项目管理的难点。首先，咱们只能管理看获得的风险，有些风险也不可避免的会实现，更不用说那些彻底没法预测的风险。其次，风险管理更考验项目经理我的的经验和敏锐。AONE提供了风险管理的功能，但“重风险识别，轻用风险应对分析”的现象仍是比较广泛。AONE中提供的风险汇总视图（下图左）只能单维度的展示风险严重性，缺乏可能性指标，因而咱们在数据大盘里加上了风险矩阵（下图右），按严重性、可能性划分出9宫格，把注意力集中在矩阵右上角，一目了然。

人力资源投入是你们都很感兴趣的一个话题。AONE暂时不提供相关统计，咱们只能另外开发小工具，由团队TL每个月填写各项目参与人员的数量。资源分配能够宏观上帮助研发团队规划项目投入，不只仅对过去的资源投入分析总结，更重要是能够总体上预计将来的资源分配是否能支持业务需求。

理论上，你们填好AONE里的需求工时估计，计算出来的工做总量应该是最准确的资源耗费成本，也能够生成项目的工做量燃尽图，以此能准确的预测项目实际上线、验收的日期。但实际执行中面临挑战太大，需求拆分不明确致使工时估计落实困难，而不得不折中由TL来汇总人力资源分配信息。

通过半年的项目规范、数据运营落地实践，从S1半年的项目需求交付周期回顾，咱们发现:

• 强管控的需求交付周期明显短于平均值。
• 交付周期中占比较大的是需求分析阶段，表征就是项目前期需求、目标不明确，致使后期开发赶工，测试压缩，最后的结果天然就不够好。
• AONE的使用规范统一化很是重要，对需求的跟踪、更新不及时就会形成数据误差。在使用好项目例会同步信息的同时，经过关联代码和需求自动汇总状态变化信息，让数据更准确。

项目管理体系的将来

我常常被问到PMO是干什么的？不少人直接把PMO和过程改进、提升研发效能相等，我以为PMO应该承担的责任是：首先，协助分解战略，合理部署资源，把关项目立项，整合项目结构。其次，创建系统的适配的管理规范，拉通上下游，让研发团队如同工厂生产线通常有质量、有效率的交付产品；最后，赋能项目经理，提升管理水平。优化、提效应该是一以贯之的持续改进。

通过半年的数据建设，飞猪技术部运行的项目已经逐渐规范，完成了两个重点战役的M4验收，明确了项目边界，逐步培养项目经理们的数据意识，倡导你们追问业务目标，量化过程指标，每一个迭代都及时收集业务反馈，保证用户价值在运营、产品、技术、客满团队之间的顺利传递，并造成闭环。固然，咱们依然面临巨大的挑战：

• 用户价值的追问、传递必须锲而不舍的坚持下去。
• 平常需求和弱管控的项目开发支持不够。
• AONE中沉淀了大量的数据，须要人性化的自动收集和分析焦点问题。
• 项目的迭代规划、按期演示还没有制度化。
• 项目经理赋能不够，只有愈来愈多的优秀项目经理成长起来，才能更普遍的保证系统健康运行。

这半年，有成功交付上线的项目，也有目标不明确业务效果不明显而被叫停的项目，咱们为成功喝彩，也为挫败反思，至少咱们已经迈出了第一步。但愿有一天能真正实现项目的可视化、可度量、可预测，但愿有更多的人有热情投身项目管理。将来的路还很长，咱们还需努力。

在此文结尾，不得不提到龙幽、欧旋两位数据挖掘专家过去5个月中对PMO工做的倾力支持，老是容忍并及时知足需求方提出的各类琐碎、奇葩、紧急的要求，衷心感谢！！

本文做者：云效鼓励师

原文连接

本文为云栖社区原创内容，未经容许不得转载。