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

文 | 费解 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%)。

图7. 两人并行工作

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

图8. 两人各担一半工作

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

3. 实践运用

下图是有赞某业务线在某段时期内的研发浓度统计,其中高亮的红色柱子,体现出浓度最集中(超过该业务线的一半项目)的区间是在 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)开发和测试在工序上形成明显的交接(图中空心蓝色柱子)。我们的疑问是:是否可以把用例设计工作进行左移,以及在测试阶段提升自动化水平来提升测试效率呢?

4. 小结

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

延伸阅读

如果读者对效能改进也有兴趣,欢迎加入有赞效能改进团队,请将简历投递至:feijie@youzan.com,我们共同探讨和实践。

欢迎关注我们的公众号