敏捷研发！还要绩效？

推荐一套 Agilean 原创的研发绩效度量指标体系，以及配套的工具实现推荐。

随着敏捷思想渐入人心，践行者们积极开展诸多尝试，往往忽视了建立与之相匹配的绩效体系，甚至认为既然敏捷了，还搞绩效何用。在过往十余年为大企业进行敏捷落地咨询的过程中，我们强烈感受到敏捷组织不仅要有绩效体系，还应投入更多思考来设计合理的考核指标，并根据实施中获取的真实数据反馈不断迭代优化。这里，就以 Agilean 自创的研发绩效体系( DEF , Development Efficacy Framework)为例，来谈谈我们的观点与实践。

这套绩效体系以「多快好赞」4组指标为核心：

多：需求吞吐量和吞吐率，衡量现实产能；

快：想法澄清、需求研发、故障修复的耗费时长，衡量研发部门对市场要求的响应能力；

好：生产缺陷需求比，衡量交付质量；

赞：需求方对交付的评价，衡量业务满意度。

研发绩效的「多快好赞」指标体系

知微系统已将这套指标体系纳入统计功能，从而进行可视化展现和快速统计。下面将结合知微研发同学的真实数据，对重要指标进行详细解释。

需求耗费时长

需求耗费时长（即需求前置时间，Leadtime）衡量研发团队需求交付速度，它反映了研发的快速响应能力，受到很多研发团队关注。

计算单一「需求耗费时长」的公式如下：

需求耗费时长计算公式

如果一个需求11月5日提出，11月20日上线，则该需求耗费时长为15天。

基于过往经验，我们建议研发部门以85%分位数来衡量整体需求耗费时长指标。随机取10个需求为例，耗费时长分别是15、25、40、45、45、45、48、52、65、80天，85%分位数为第9个数字（10*85%并四舍五入），由此可知85%的需求在65天内交付。

知微的统计视图即以85%分位数对需求耗费时长进行可视化展示。下图为2017年7月至今年11月13日的真实数据，即知微研发近3年的需求耗费时长统计。图里方框内的数字，表示如果以2017年11月28日之前的90天为采样周期，知微85%的需求在27天内完成。

知微对 leadtime 的统计展示

为什么选用85%分位数而不是使用更广的平均数？统计的意义在于以真实有效的数据进行预测，从而支持更优决策，避免由于主观或经验判断布下的雷区，而均值和50%分位数无法具备支持预测的作用。通常情况下，均值和85%分位数的统计结果会出现两倍的差距，85%分位数和99%分位数也往往是约两倍关系（考虑此文主题，背后原理不再展开）。因此，85%分位数是一个很好的预测平衡点。

研发需求耗费时长真实数据统计通常符合韦伯分布

上面这张柱形分布图，真实展现了知微三年来的需求耗费时长。可以看到，数据较好地符合了韦伯分布（Weibull Distribution），即存在一个众数尖峰以及一条长尾。排除掉异常时间影响后，我们就可以自信地进行整体交付时效和响应指标的预测。

需求耗费时长是一项非常重要的协作指标。研发部门任何环节掉队，都会导致该指标发生敏感变化，因此，所有相关角色都应对该指标负责。基于以上考虑，知微支持对需求耗费时长进行分段计算。不仅能实时展示需求端到端耗费时长，也可以分成需求分析、设计、研发、测试、验收等各段分别展示，并以不同颜色的线条表现其变化趋势。

需求交付慢不一定是开发的锅

举一个典型例子。开发同学经常为整体交付慢背锅，很多人认为需求交付慢的根源在于开发耗时太久。但通过知微研发团队累积的真实数据可以看到，开发环节耗费时长（9天）远远少于需求分析（14天）和验收（14天）。事实上，我们用了两倍于开发阶段的时间，来想清楚需求。通过自身经历，我们深深感受到对创新产品来说，想清楚需求要花很多时间，过程中需要不同角色参与，需要头脑风暴和反复讨论。在这个过程中，研发并不是瓶颈，「想好」是「做好」的前提。

通过上述的分段计算方式，需求完成链条中不同阶段的具体耗时一目了然。团队可以快速发现影响整体交付速度的环节，找到真正的痛点，并采取有针对性的改善措施，而不是仅凭主观做出判断。

现实中，不同企业不同研发部门对「需求耗费时长」的理解并不一致，主要差异在于该从哪个步骤开始计算：用需求提出时间？需求澄清时间？还是需求确认选择时间？我们认为最好采用适合组织流程现状的统计方式，这并不会影响该指标蕴含的价值。因此，知微上所有的统计指标和计算公式，都能根据企业需要进行灵活定义和实时调整，人们可以自行编辑诸如需求耗费时长一类的计算公式，只要该统计结果能在现实中引领改善，对企业就是有意义的。

需求吞吐量和吞吐率

需求吞吐量（单位时间或版本内完成的需求个数），是最直观粗暴的研发产能度量指标，表述通常为「上个版本完成了XX个需求」。需求吞吐率在吞吐量基础上增加了平均计算，以衡量单位时间或版本完成的平均需求规模，表述通常为「今年以来，每个版本平均完成XX个需求」。

这两个指标容易理解且应用广泛。以知微为例，下图是研发团队近两年需求吞吐量的按月统计结果（也可按需选择日、周、双周等不同统计周期），从图中数据可以计算出研发团队的吞吐率。比如，今年6-10月这段时间，需求吞吐率为52个需求/月。

需求吞吐量统计

除了按时间统计产能，知微也支持按版本进行吞吐量和吞吐率统计。下图可以看出知微的迭代速度（差不多每两周一个版本），以及每个版本完成了多少个需求，以及产能的变化。

每个版本需求吞吐率

采用吞吐量和吞吐率作为产能指标，往往被问到一个问题：如何衡量需求规模？目前，需求规模衡量通常有两种选择：需求个数、需求估算点数。如果尚未建起一套成熟有效的估算机制，我们强烈建议使用需求个数而非需求估算点数来衡量需求规模。产品经理与研发共同协作，将需求拆分成粒度相对均匀的条目，再用需求个数来代表需求规模。

除度量产能这个作用以外，需求吞吐量/率还能够与需求耗费时长形成制衡，二者共同使用，可以避免只改善交付速度但降低交付数量，或者只考虑数量增加而忽视了速度。在二者基础之上，研发还应关注交付质量和交付成效，助力业务指标的达成。

那么，好的质量指标该是什么样？请继续往下看。

生产缺陷需求比

生产缺陷需求比是一项质量指标，用于衡量研发交付质量，计算公式如下：

生产缺陷需求比计算公式

直接以知微研发团队的实际数据进行介绍：

生产缺陷需求比

知微上一个版本V1.1.1，上线需求59个，生产缺陷7个，生产缺陷需求比为0.11个缺陷每需求。这是对该指标的基础统计，我们建议研发团队建立一套生产缺陷分级机制，按照致命缺陷、严重缺陷、普通缺陷等严重级别对生产缺陷数量进行加权计算。

依然采用知微V1.1.1版本的数据。过滤后发现7个缺陷均为普通缺陷，如果致命、严重、普通缺陷权重分别为3、1、0.5，加权后的生产缺陷个数为0*3+0*1+7*0.5=3.5，即加权后的生产缺陷需求比为0.06个缺陷每需求。

不同业务类型、不同规模的研发组织对质量的要求不尽相同。生产缺陷需求比与需求耗费时长可以形成制衡，既要交付快，也要兼顾质量水平。很多角色可能对质量造成影响，比如产品经理、开发工程师、测试工程师、架构师等。

满意度指标

与需求耗费时长、吞吐量等指标相比，满意度是一个外部指标，它反映需求方（外部客户、业务部门等）对研发交付质量、时效、可用度、体验等的综合评价。满意度有时会带上主观因素，但我们仍应尽可能客观地度量它。

一个需求上线后，其耗费时长、吞吐量、生产缺陷需求比等指标已经可以得出。到此阶段时，对需求的评价已暂时脱离研发体系，转而由业务部门处理，通过适合的评价体系，在客户处获得对该需求的满意度评价。

目前流行的满意度指标体系中，常见的是CSAT「非常满意」-「非常不满意」5重评价，NPS（净推荐值）的0分（完全不可能）- 1分（完全可能）推荐倾向。对于服务型产品，有CES（用户费力度）的评价体系。这些指标无好坏之分，企业按需采用即可。

知微对满意度指标的统计

针对满意度指标统计，知微能够配置出不同的满意度评价指标，将该指标作为一项属性，由具体的需求卡片承载（见上图）。也具备指定打分人、需求完成后打分提醒等功能。

总结部分

我们总结出以下表格，来直观展现哪些角色应该关注哪些指标：

DEF 指标体系的推荐指标

除了文中谈到的几个指标，还有很多相关概念和内容值得展开阐述，包括上表里的流动效率、分布K值等等。本文为DEF「研发绩效体系」系列文章的首篇，在后续文章中，我们将继续以真实数据为例，详细解读其它指标和背后的逻辑，敬请期待。