［导读］项目各项数据，是项目经理判断项目和团队健康程度的重要依据。通常项目经理用来度量项目状态的指标有两类：一类是过程数据；一类为事后数据。那么如何通过这些数据来看出项目和团队的健康程度呢？
项目各项数据，是项目经理判断项目和团队健康程度的重要依据。通常项目经理用来度量项目状态的指标有两类：一类是过程数据，主要为项目进展，通常用燃尽图展示；一类为事后数据，如：项目规模，团队负荷，需求完成率，需求蔓延率，及时交付率等。那么如何通过这些数据来看出项目和团队的健康程度呢？
1. 项目进展
项目进展是首要的过程数据，那么如何衡量项目进展？一般我们用燃尽图来衡量项目进展。燃尽图的横轴为日期（或者项目已进行的天数），纵轴为剩余的工作量，根据团队估算单位的不同，纵轴的单位也会有所不同。常见的有人天，人时，故事点等，由于笔者所在团队通常以人天为估算单位，本节的例子将以人天为单位讲述。理想情况下，燃尽图为一条斜率一定的直线，我们称之为标准线。
项目进行中，项目经理根据当天实际剩余的工作量画点，然后将点连成线，我们称这条线为实际线。当实际线在标准线上方时则预示项目进展存在风险，需要引起项目经理的注意，偏离越大风险越大。当实际线在标准线下方时则说明项目进展好于预期，当前风险较低。但实际情况往往没有标准线这么理想，实际情况下，燃尽图一般如下图所示。前期的燃尽图一般在标准线上方，但到后半程燃尽图会迅速下降。不过不同的团队可能“正常”的实际线也会不同，这跟整个团队的特性有关。例如有一些团队比较乐观，他们会对当前的进展有更高的预期，所以他们前半程的燃尽线会更靠近标准线，甚至低于标准线；而保守的团队则会相反。
实际情况下，项目经理会在项目过程中收集剩余的工作量并且绘制燃尽图，当剩余工作量高于 团队“正常的”实际线的时候，项目经理就需要挖掘是什么原因导致现在的情况，例如测试资源的瓶颈，导致大量测试工作被积压，这个事情就可以跟团队商量是否能有开发分担部分测试工作；例如某个开发在某个需求上需要技术难题，导致他的工作量无法“燃尽”，项目经理就需要协调团队内或者团队外的技术专家帮忙尽快解决问题。燃尽图就是通过这种方式发挥它的作用的。
2. 项目规模
项目规模是指项目的大小。一般会在固定周期的迭代模式中做纵向比较。理论上我们应该像敏捷里面用故事点来表示需求的大小，也有一些团队会用复杂度，难度等来衡量需求的大小。但是目前我们只能做到用所有任务团队估算的人天数之和来表示项目的规模，我们认为在团队稳定的情况下，大家的估算标准在一定时期内的稳定的，从而可以作为项目规模的依据。几个迭代下来，一个团队会总结出属于自己的合适的规模大小，即安排如此大小的规模，团队能够完成。例如通常情况下安排50人天的工作量，团队基本能够完成。
那么后面的版本就可以以50人天作为一个参考。当安排的工作量远远超出这个值，那么项目经理就需要提醒团队，这里面的风险有多大，从而跟团队商量调整的策略。反之亦然。
3. 团队负荷
团队负荷=计划安排的总工作量/团队总的可用时间
团队总的可用时间在计划阶段，需要刨去大家的请假安排、常规会议时间，再乘上人员的投入比例。由于大家对需求估算的标准不一样，例如有的团队会自然把沟通和讨论的时间都算到需求的工作量里面，但有的团队评估的则是纯写代码的工作量。所以根据团队的不同，正常的负荷也会不同。笔者所在的一个团队，他们正常的负荷大约在90%左右，这个负荷情况下，可能团队不需要加班就能达到较高的需求完成率（下节展开讲述），如果超出这个值，那么团队可能会需要加班才能完成所有需求；如果大家不加班，需求的完成率就会较低。这个数值也是在计划阶段有较大的参考意义。
4. 需求完成率
需求完成率=完成了的需求大小/总的需求大小*100%
这个指标一般是出现在周期固定的迭代模式中，周期不固定的版本中通常用另外一个指标（及时交付率）来衡量，由于笔者参与的团队大部分都用需求完成率，所以本节主要描述该数值。
那么如何衡量需求的大小呢？根据团队估算单位的不同，需求大小的单位也会不同。常见的有人天，人时，故事点等，由于笔者所在团队通常以人天为估算单位，本节的例子将以人天为单位讲述。一个需求的大小等于完成这个需求所需各任务的人天数之和。例如：注册这个需求，后台开发1人天，前端开发1人天，测试1人天，这样这个需求的大小就为3人天。需求完成率=完成的需求大小/总的需求大小。如果某个版本的需求完成率较低，那么就需要团队反思什么原因导致这个问题。 例如：版本工作量安排的超出寻常，团队努力之后还是达不到很高的完成率，那么下个版本，我们可能要考虑不要塞太多需求进来；抑或是开发提测质量有问题，冒烟几次都未通过，导致团队花费较多精力一起解决该问题，那么我们需要讨论如何改进能够提高我们的冒烟测试通过率。总之，如果这个数字有异常，项目经理应该与团队一起找到原因并且在下个版本去改进。
5. 需求蔓延率
需求蔓延率=增加的需求大小/原计划的需求大小*100%
与需求完成率一样，这个数值一般出现在周期固定的迭代模式中，它表示的是需求变更的大小。 需求蔓延率高说明需求变更多，原因可能是需求阶段比较“草率”，导致在开发过程中出现频繁的需求调整。需求蔓延率低说明需求变更少，需求变更太少也不是好事，说明我们可能在需求阶段花费了较多时间，在版本截止日期固定的情况下，可能会压缩开发时间，导致开发加班。与需求完成率一样，每个团队都应该有一个“正常”的需求蔓延率。例如笔者所在团队正常的需求变更率在20%以内，如果超出20%那么就可能导致该版本的需求完成率较低，团队的协作也会随之出现问题。
6. 单位工作量bug产出率
单位工作量bug产出率=bug数/总工作量
这里的bug数是指提测后发布前的测试bug数。这个值较高的时候，说明版本的提测质量可能存在问题。反之则说明质量还不错。当然团队的成员结构不同，这个值也会有较大的差距，成熟团队的这个值可能较低，但是新成员较多的团队，这个值往往会高些。所以这个数据也只能用于纵向比较。例如：前3个版本的这个值是在1.1，但是突然有一个版本这个值飙升到了1.4，这个时候就需要引起项目经理和团队的注意，反思是什么原因造成的，并且在后续版本改进。笔者目前收集到的某个团队的这个值一般在1.1-1.2，差的版本会到1.4。
以上这些数据看起来很美好，似乎能很直观的衡量团队的情况。然而“理想很丰满，现实却容易骨感”。这些数据在一定条件下才能发挥其较大的作用，其他时候反应的情况会跟实际情况有较大偏差。
下一篇文章《数据专题研究｜项目度量中常见的7种陷阱》，我们一起聊聊影响这些数据发挥更大作用的一些因素。
本文来自微信公众号“网易杭研项目管理”（ID：NeteasePM），作者 何燕华。
管理圈经授权发布，如需转载请联系原作者。
粤公网安备 44010602010970