效能指标「研发浓度」在项目度量中的应用

文｜费解on效能改进

一、背景

在研发管理领域，业界一直在试图寻找可以衡量研发交付效率的指标。常见的指标有：吞吐率（多）、研发周期（快）、资源利用率（省）。然而，在实践中，我们发现，上述三项无法直接作为指导改进的北极星指标：

1）吞吐率，在一段时间内交付项目的个数，是产品需求方关注的指标。若项目未交付，则不落入统计，也就无法发现问题和采取行动。而一旦交付，就错过了采取行动的时机。该指标是个滞后指标，它只关注项目的终点，犹如刻舟求剑，可参考性较差。见图1中，4月份吞吐率为0，但并不意味着生产是停滞的，5月份吞吐率为1，也不意味着持续了5个月的项目D是健康的。

图1. 多个项目上线后，被统计在不同月份的吞吐率中

2）研发周期，基于单个项目计划的起止时间，是由关键路径决定的，项目经理尤为关心。然而，在关键路径上的人员，除了计划内的研发工作之外，又受到项目外的精力牵扯（比如：处理临时突发的线上 bug）和因为他人牵扯而等待（比如：等待联调、等待测试）的影响。单看研发周期，无法评价项目中资源被有效利用的情况。见图2中，甲中途离开处理外部事务，在完成任务后等待乙来接棒。

图2. 项目受计划外工作牵扯

3）资源利用率，员工工作投入的饱和度，技术经理在做团队管理时常考虑的指标。这个饱和度特指从工作负荷视角出发，看员工是不是在忙，但容易忽略工作的聚焦程度。见图2中，甲和乙的工作饱和度都很高，但因为参与者的精力分散在多处，并不会对项目B尽快交付有任何帮助。

那么，是否存在一项北极星指标，可以实时反馈研发过程的效率，从而有效采取改进措施呢？

二、指标介绍

有赞效能改进团队经过不断探索，定义了「研发浓度」指标，作为研发效率的度量。该指标融合前文介绍的吞吐率、研发周期和资源利用率，反映了「为缩短项目周期而投入资源」的决策收益。计算公式如下：

研发浓度 = 项目工作量人日 ÷ ( 研发周期 × 参与人数 ) × 100%

场景a：单人满负荷完成全部工作。这个场景比较简单，聚焦并独立完成一件事，此时的研发浓度是：100%（ = 10人日 ÷ ( 10个工作日 × 1人 ) × 100%）。

图3. 单人满负荷完成全部工作

场景b：单人拖沓完成全部工作。和图2中出现的问题一样，甲中途离开，去处理项目以外的工作，导致研发周期发生变动（工作量并未发生变化），此时的研发浓度是：66.7%（ = 10人日 ÷ ( 15个工作日 × 1人 ) × 100%），且精力越分散，该项目的浓度越低。

图4. 单人拖沓完成全部工作

场景c：两人分工紧密衔接。由于职能或既定工序等原因（比如：甲先负责开发，然后乙负责测试），需要由不同的角色，分别负责先后两道工序，来协同完成工作。从项目的视角来看，甲和乙分别存在等待（尽管人员不会闲置，比如处理一些日常事务性工作，但终究无助于该项目的尽快交付）。此时的研发浓度是：50%（ = 10人日 ÷ ( 10个工作日 × 2人 ) × 100%）。在这种流水线工作模式下，同一时刻始终只有 1 人处于工作状态，故随着参与人数上升，研发浓度下降。

图5. 两人分工紧密衔接

场景d：紧后工作部分前置。乙的 4 人日工作，是甲的紧后工作。如果乙想办法将一部分准备工作前置（比如：提前写测试用例），就能使研发周期缩短。此时的研发浓度是：62.5%（ = 10人日 ÷ ( 8个工作日 × 2人 ) × 100%）

图6. 紧后工作部分前置

场景e：两人并行工作。乙的工作完全不依赖甲（工作节奏完美匹配），甲是唯一的关键路径，乙可以在6个工作日内弹性完成自己的任务，但依然存在等待。该场景在规模较大的项目中经常出现（比如：多名研发人员并行开发）。此时的研发浓度是：83.3%（ = 10人日 ÷ ( 6个工作日 × 2人 ) × 100%）。

图7. 两人并行工作

场景f：两人各担一半工作。甲和乙能自由地均分任务，尽量不出现某个人成为关键路径的情况，这样能最大程度上缩短研发周期（这在任务层面是一种理想状态，但如果甲和乙是两个跨职能的平行团队则完全是可能的）。此时的研发浓度是：100%（ = 10人日 ÷ ( 5个工作日 × 2人 ) × 100%）。

图8. 两人各担一半工作

在上述各场景中，我们可以看到，在项目中采取不同的资源利用率策略，会形成不同的研发周期效果，进而影响吞吐率，这就是「研发浓度」所要表达的信息。即：资源的利用率越高（包括：掌握的功能模块和技能越全面、越少被外界打扰、越简洁无依赖的工作流），单个项目的研发周期就越短，研发效率就越高。

三、实践运用

下图是有赞某业务线在某段时期内的研发浓度统计，其中高亮的红色柱子，体现出浓度最集中（超过该业务线的一半项目）的区间是在 12% ~ 28% 的范围里。

图9. 研发浓度直方图

我们从这些项目中找几个案例：

【正面案例】A项目（图10），3人参与（前端×1，后端×1，测试×1），项目周期 20 个工作日，总工作量是 45 人日，计算研发浓度 = 75%（45 人日 ÷ (20 工作日 × 3 人) × 100%）。

图10. A项目甘特图

【反面案例】B项目（图11），8人参与（前端×3，后端×2，测试×3），项目周期 43 个工作日，总工作量是 26 人日，计算研发浓度 = 8%（26 人日 ÷ (43 工作日 × 8 人) × 100%）。

图11. B项目甘特图

目测相较于A项目，B项目的复杂度略高一些，跨了3条业务线的协作。分析甘特图，体现出来的可改进点非常有意思，笔者罗列一二，期待读者朋友能留言，参与互动：

a）两位核心开发人员的投入时间相差较大（图中两根最长的蓝色柱子），导致形成关键路径，拉长开发周期。我们的疑问是：后进入者是否被上一个项目所牵绊？本项目是否有必要匆忙启动呢？

b）个别参与开发的成员，工作量只有半天（图中最短的两个蓝色颗粒）。我们的疑问是：他们是否有必要参与项目，其工作能否交接给其他人完成呢？

c）开发和测试在工序上形成明显的交接（图中空心蓝色柱子）。我们的疑问是：是否可以把用例设计工作进行左移，以及在测试阶段提升自动化水平来提升测试效率呢？

四、小结

「研发浓度」的优势在于，它是一项领先指标，能直接体现任意项目的研发效率，并在过程中进行度量，发现问题可以随时介入并进行改进。希望能借助本文，得到读者朋友的垂青，并将其运用到更广泛的度量场景之中。