文 | 费解 on 效能改进

1. 背景

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

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

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

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

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

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

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

2. 指标介绍

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

研发浓度 = 项目工作量人日 ÷ ( 研发周期 × 参与人数 ) × 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%）。