读懂一个项目的研发效能 之 项目人效

思码逸企业版 4.0 的部分功能已进入内测阶段✨近期我们会用几篇文章，浅剧透一下 4.0 的新鲜功能。

最近几篇的主题将是 4.0 版本中的 GQM 看板——GQM 代表 Goal-Question-Metric（目标-问题-指标），是一套构建软件研发效能度量的系统方法。简单来说，GQM 方法强调面向清晰具体的目标，自上而下拆解，通过问题建立研发的度量模型 + 基于量化数据分析来回答问题，自下而上解读并达成目标。更多解读可以查看《GQM 概述：构建研发效能度量体系的根本方法》。

相比大多数所谓『数据看板』，GQM 看板的进化在于数据不再是简单罗列、看得人一头雾水；而是先将具体场景下的具体度量目标拆解成问题，再由问题引出指标图表，以递进的方式传递信息，并引导用户适时下钻探索。

我们认为，优秀的效能度量一定不会是难懂的。我们希望即使是不太了解研发效能领域知识的一线研发管理者，也能低成本理解每个指标的含义和指标给出的信息，实实在在将度量用起来，解决他们在研发管理中的遇到的各类“看不清”“说不明”。

上一篇文章中，我们介绍了我们将介绍 GQM 看板中的『项目交付效率看板』，这一篇将继续介绍『项目人效看板』。

0. 研发人效度量，为什么如此尴尬?

上一篇文章我们提到过，研发效率最终应当体现在交付效率（或者叫流动效率）上，让价值接收方感到交付物更多、响应更及时、研发目标更快速达成。

而与交付效率相对的人效，或者叫资源效率，虽然常备诟病，但依然是研发效效率中的绕不开的话题。

何勉《阿里如何定义团队的研发效能？》

一方面，人效的度量与改进确实有存在的必要。

仅在交付效率上下功夫的改进，例如加强跨部门沟通协调、减少等待，确实能使交付更快；例如调整研发投入重心与业务方向匹配，确实能使交付的软件功能更符合市场期望。但本质上，这些措施都是在产能不变情况下优化产能分配。如果产能本身处于偏低水平，不论如何优化分配，改进效果可能都是有限的。因此人效的提升是交付效率提升的重要手段之一。

另一方面，人效度量又因常常跑偏到强管理导向和“反人性”，而饱受争议。

对于管理者，尤其是没那么懂技术的管理者来说，工时、工作饱和度（执行任务的时长/总工时）、代码行数这样的指标更容易理解，因此常常被用来度量研发的人效。这些指标似乎给管理者提供了一种“监督员工们没摸鱼没划水，工资才算没白给”的安全感。

但软件研发毕竟是脑力劳动，开发者们不是生产代码的机器，不可能每天从早到晚精神抖擞全速运转。这就导致开发者和管理者之间痛苦且双输的博弈：开发者或想尽办法来绕过度量，或在高压下忙忙碌碌，变得疲惫、麻木和缺乏创造力，部分成员因此离开；管理者们可能如愿以偿看到人效指标上升，最后才发现这个数字和真正的效率提升并没有必然联系，可能还是负相关的。

再热爱工作，连轴转太久也只能交付 bullshit

研发人效度量如此尴尬，背后是常常跑偏的度量设计和使用。这也是思码逸希望提供更加可靠、有正向引导作用的人效看板的原因。

1. 人效度量，先选对指标

交付效率侧重于刻画端到端的交付表现，业务、产品、研发、测试各环节内部和它们之间的流转协调都会造成影响。而人效度量侧重于内部评估研发团队的交付能力，研发 Leader 们需要的是仅与研发环节相关的指标。

前面提到，常见的工时、工作饱和度指标多把开发者作为需要时时刻刻运转的资源，而非有创造力的人，因此广受诟病；而代码行数指标，则很可能错误地引导开发者们多敲空行、多写不必要的复杂函数来造数据，进而导致代码可读性和可维护性急剧下降，本质上使研发效率更加恶化。

思码逸选择人均代码当量和人均事务吞吐量作为北极星指标，来表示项目组的人效水平。

- 代码当量和代码行数一样是基于代码的工作量指标，但排除了代码风格、换行习惯等噪音干扰，且调整了移动、粘贴、数据修改等修改的权重，因此更鼓励重要且有创造性的工作。

- 事务吞吐量则是基于任务的工作量指标，能够更好地与项目交付进度相关联，但可能会受到事务颗粒度大小不一的影响。

因此，两个指标同时使用，能够可靠简洁地说明各项目的人均开发效率，及时挖掘内部最佳实践，或及时发现状态不佳的项目，再到其他图表进一步了解问题的原因。

项目人效四象限图

如果需要深入了解某一项目人效的具体信息，思码逸支持下钻分析，呈现项目人效趋势，并自动识别偏高或偏低的潜在异常点。如果贡献者人数频繁波动，则可能需要重点关注开发者专注度，我们会在第三部分介绍。

在此基础上，思码逸也将工时指标纳入分析。但工时不代表任何产出或工作量，而是研发团队和开发者的资源投入。将代码当量和事务吞吐量与工时交叉分析，则可以量化研发团队内部的投产比。这样的度量也有助于开发者们更专注于交付结果，而非磨洋工凑时长。需要留意的是，不同职能团队、不同类型项目的工时投产比可能相差很大，不经筛选的横向比较可能是欠妥的。

2. 参考行业基线，客观评估人效水平

代码当量和事务吞吐量两个指标量化了项目人效，但对于研发团队而言，数字的理解是有门槛的：这些数字代表了什么？四象限图表明，某个项目的人效在公司内处于上游，那么与行业对比如何？

根据项目语言和团队规模属性，思码逸能够自动匹配行业近似项目，为人效数据的解读提供参考基线，帮助团队客观认知当前人效水平，合理制定提效目标。

但这里也需要提醒一句：项目的发展阶段、业务属性等也会对人效造成影响。例如，成熟期的项目，其人效可能会低于起步期的项目，一方面是任务比后者少，另一方面是“历史包袱”也更重，改动需更小心谨慎。因此，在判断项目人效时，还是结合项目的实际需求进行分析。

3. 深入分析项目的贡献分布与专注度

接着前面的例子，项目到了成熟期，人效下降，Leader 们开始考虑：本项目是不是不需要那么多人参与了？是否可以把部分研发人力分到别的项目上？毕竟，研发人力成本如此昂贵，自然不希望空转导致浪费。

今日分工：90%项目成员等着 10%成员完成任务

这时候，就需要更精细的项目人效分析登场了。

首先，可以先通过项目贡献均衡度图表，判断有多少开发者是作为项目主力军工作。贡献均衡度的定义是贡献 80%工作量的开发者比例。如果均衡度较低，则项目大部分人力可能都是辅助角色，如果转移到新项目上，需要交接的工作也不会太多。

接着，我们可以下钻到某一项目内，继续验证均衡度是否走低，并通过产出分布帕累托图来判断工作是否逐渐集中在少数几位核心开发者，谁是核心开发者。

那么，非核心开发者们是还参与着其他项目，还是处于空转状态呢？人力专注度指标可以帮助我们直观了解。

如果许多非核心开发者仅专注于此项目，但代码产出和事务吞吐数又不高，则可能正处于空转状态。如果许多非核心开发者同时在开发其他项目，则需要结合新旧项目之间的关联，来判断开发者同时参与多个项目是否合理；若新旧项目之间关系不大，则可以考虑帮助开发者交接剩余工作，并完全转移到新项目上，减少上下文频繁切换造成的浪费。

另一种情形是，项目加班严重却频频延期，贡献高度集中于几位核心开发者。这种情况则可以结合产出分布的详情和专注度数据，辨别是项目人手确实不足，需要频繁抽调其他项目人员支持；或是任务太过耦合，核心开发者超负荷工作，而其他成员帮不上忙；亦或是项目人员结构不恰当，导致部分人员没有任务可做。

需要提醒的是，数据分析更多起到的是客观度量、提供建议、排除部分可能性、并引导层层下钻的作用，其本身往往难以直接得出行动项。排查项目人效问题的过程中，由开发者参与的复盘和讨论是必不可少的。

我们可以将贡献均衡度和人力专注度理解为人效的健康指标：持续超负荷工作、贡献过于集中、成员同时投入在多个不相关项目都是不健康的。不健康的情况下，人效可能依然很高，但大概率是不可持续（例如团队加班累垮）或风险巨大（例如核心成员离职）的。

总结

项目人效度量的是研发内部的研发产出，尽管这些产出不直接等同于业务侧和终端用户感受到的价值，但它代表了研发部门支持价值交付的带宽。在以提升交付效率为最终目的的改进中，提升研发人效是必不可少的路径之一。而人效度量的尴尬，则常常源于混淆了路径和目的。

在厘清概念的基础上，谨慎选用具有正向引导作用的度量指标，在合适的参考系下进行解读，在关注人效数字的同时重视健康度，并适时下钻到关键单点内，通过案例复盘来排查人效的影响因素。这样的度量和解读的方法，能够帮助研发团队避免掉进数字的陷阱，而是去发现和追问真正的问题。

聊完了交付效率和人效，下一篇我们会聊聊项目的质量控制。