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

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

前言

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

项目管理的目的

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

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

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

初创企业里，团队很小，7、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工作的倾力支持，总是容忍并及时满足需求方提出的各种琐碎、奇葩、紧急的要求，衷心感谢！！