项目度量中常见的7种陷阱-项目管理文章库

1、 项目度量中常见的7种陷阱-项目管理文章库 对项目做度量，只有在满足一定前提下才能发挥较大作用，下面就来简单聊聊影响这些数据发挥更大作用的一些因素。项目度量中常用的6种数据类型的项目数据指标，虽然看起来很美好，似乎能很直观的衡量团队的情况。但是，这些数据只有在一定的前提下才能发挥较大作用，其他时候反应的情况会跟实际情况有较大偏差，下面就来简单聊聊影响这些数据发挥更大作用的一些因素。数据的陷阱1. 团队数量和人员不稳定因为前面的很多数据都是针对某个团队做纵向比较的，当团队的人数变化较大，或者人数虽然没变，但是正式员工全换成了实习生。这些情况会造成同一个数值前后对比产生的意义不是特别大。例如某个团

2、队前几个版本能完成的需求规模一般在50人天左右，但是某个版本有2个资深人员离职，同时补充进来2个实习生。接下来一个版本的完成的规模只有40人天 。50人天-40人天，并不是因为流程或者其他什么原因，而是因为人员的变化。如果频繁的人员调整就会导致每个版本的数值都不一样，而且看不出什么规律。数据的陷阱2. 估算经验不足因为大部分数据都是基于大家的估算，如果是没有经验的同学，可能由于估算本身的关系就会导致迭代间数据的不同，并不能真实的反应团队和项目的情况。例如某个团队中几个都是没有经验的同学，第一个版本基于他们的估算安排了50人天的工作量，计划负荷是90%，结果完成率是95%。第二个版本这个时候项目

3、经理会认为再安排50人天的工作量也是比较合理的，但是结果第二个迭代的完成率可能只有70%，原因不是别的，而是因为他们把第二个迭代的工作量估少了。数据的陷阱3. 成员非全职投入非全职的人员其实很难判断他在当前项目的投入是多少。继续拿上一节的例子，一个团队，其中两人非全职，第一个版本基于他们的估算安排了50人天的工作量，计划负荷是90%，结果完成率是95%。第二个版本，项目经理天然认为在投入程度一样的情况下再安排50人天的工作量应该ok，但是实际完成率只有70%。原因其实是这两个人在这个版本期间，参与的另外一个项目时间更紧张，所以他们天然花费了更多精力在那个项目。从而导致第二个版本的完成率低。估算

4、没有经验，很难把握版本间的估算标准，那么数据的变化完全取决于估算的情况，会看不出项目中其他的问题。数据的陷阱4. 需求的量不稳定需求量不稳定， 有的时候需求多，有时候又没有需求，那么关于团队负荷，需求完成率等的统计就完全没意义了。需求少的时候团队负荷自然就少，需求完成率就高。这意味着这些数据统计在运维型的项目中就不一定适用，因为需求都是来自线上，需求出现的时候团队就要加班加点，需求没有的时候就没什么事做。所以在这种类型的项目中，本文的这些数据可能已经不适用，需要用另外一套数据。数据的陷阱5. 版本任务间依赖严重因为我们是基于迭代安排的工作量和计划负荷来衡量计划是否合理，这有点借鉴scrum的做

5、法。但是scrum中每个团队成员都是多面手，哪里需要去哪里。但是在我们实际的项目中还是会存在角色壁垒，如果版本中的任务间依赖非常严重，就可能产生较多等待时间，导致产出较低。例如之前版本团队一般能完成50人天的需求规模，但是某一个版本任务a依赖任务b导致负责任务b的同学前期要等待任务b，自然他就无法在前期对需求的消灭有所贡献。因此最终这个版本完成的需求规模可能只有40人天。这种情况下，我们应该尽量避免在一个版本安排太多有依赖关系的工作，前置工作最好能在上一个版本完成。数据的陷阱6. 需求切分不够细承接上一节的内容，其实需求的切分也是为了避免策划和开发之间，但是这是很重要的一环，两周的迭代最好能有

6、3，4次的提测，这样测试基本不存在等待开发的状态。数据的陷阱7. 人员配比不合理这里的人员配比指，策划，交互，视觉，开发，测试等的角色的配比 。这个配比如何不合理，某个角色是瓶颈，那么其他角色就会处于等待状态，造成整体的资源浪费。这个时候其实项目经理只要关注瓶颈的部分就行，整体的数据意义不大。结语这些数据要发挥最大的作用还在于强执行和正向循环。所谓强执行就是需要项目经理坚持这些数据的收集，但是同时需要为数据的收集选取好工具和流程，让团队能以较小的成本产出这些数据(这部分有兴趣的同学可以单独联系交流)。同时要让这些数据能在我们做决策的时候提供相应的价值，让大家看到这些数据的意义，这样团队就会更加乐于配合项目经理提供这些数据，正向循环也就此建立了。另外， 对于项目经理来说，数据能提供给项目经理的 最直观也是最有价值的点是能帮助项目经理判断项目或者团队的健康程度。项目经理日常的工作内容较杂，当项目出现很多问题的时候项目经理可能会去埋头解决问题，从而忽视了跳出来看整体的情况，从更早的时候去杜绝问题的产生 。恰巧，数据统计能帮上忙，通过数据项目经理能在更早期的时候发现一些问题同时加以干预。