文章目录

• 1趋势分析
• 2钻井分析
• 3相关性分析
• 4累积流量图分析
• 5流动效率分析
• 6流量负载分析
• 总结

虽然R&D效率度量的出发点是很好的，但是如何正确有效地度量它是一个相当困难的技术任务。最近关于如何测量有效性的讨论层出不穷，但很少有文章具体描述如何构建系统的测量框架，如何选择测量指标，如何进行测量分析，以及如何实地操作。在此背景下，张乐先生撰写了一系列关于R&D有效性测量的核心方法和实践的文章，总结和提炼了以往的经验，包括以下内容:

1.效率测量的难点与反模式

2.行业案例和效率衡量的关键原则

3.效率测度的实践框架和指标体系设计。

4.效率测量的常用分析方法

5.对实施有效性测量的建议。

以上内容将以连载五篇的形式发表，共计三万余字。本文为第四篇。

在文章的最后，我们详细介绍了R&D效率测度的指标体系设计，并给出了测度指标的全貌。度量标准很多，但如何利用好才是关键。

正如道格拉斯·w·哈伯德(Douglas W. Hubbard)在他的畅销书《如何衡量任何事情》(How to Measure things)中指出的，“如果一个衡量标准真的很重要，那是因为它必须对决策和行为产生一些可以想象的影响。”如果我们不能确定一个指标是否能影响决策，以及如何改变这些决策，那么这个指标就是没有价值的。

对于指标的分析，这里有一些常用的方法:

1趋势分析

趋势比绝对值更能说明问题。

在衡量R&D效率的指标时，一段时间内的改善趋势将比绝对值更有意义。每一个组织、每一个部门、每一个团队、每一个人的出发点和语境都不一样，所以横向比较衡量指标的绝对值很可能会有偏差。对于每个个体来说，测量其随时间的变化趋势可以获得更有效的信息。

例如，下图是在某部门推广R&D效率分析时绘制的趋势图。可以看出，在2019年7月之前，随着时间的推移，交付周期持续呈上升趋势，即交付需求越来越慢。复盘期间，当时的管理者就认识到了这个问题。虽然每个人似乎都在忙于自己的工作(资源利用率高)，但从业务或客户的角度来看，R&D效率的体验持续下降(流动效率降低)。因此，当时管理者决定任命专人负责R&D效率的诊断、分析和提升，直接干预提前期，通过一系列改进措施扭转这一趋势。图中红圈位置为转折点，2019年8月后分娩周期明显下降，说明采取的干预措施是有效的。在度量的指导下，发现问题，处理问题，最终提高部门的效率。

下图是趋势分析的另一个案例。这个部门的核心是在线质量，用缺陷逃逸率指标来衡量。可以看出，从2019年的Q2到2020年的Q3，缺陷逃逸率一直处于下降趋势。但更重要的是，为实现这一目标采取了哪些措施和做法？图中代码评审覆盖率、单元测试数量、通过率的趋势图就是这个问题的答案。可以看出，减少在线缺陷逃逸的目标已经达到，这是因为幕后有很多优质内置活动的努力。通过趋势分析，我们可以看到几个指标之间的相关性。这个相关性分析方法很有用，我们后面会解释。

2钻井分析

钻取式分析可以帮助我们从宏观到微观，从表象到根本原因逐层排查问题，找到影响效率的瓶颈。常见的钻取分析包括按阶段钻取(针对交付周期指标)、按聚集维度钻取、按在制品钻取等。让我们看一些例子。

按阶段下钻

我们经常看到的是，如果生产研究部门被业务部门抱怨交付速度太慢，那么生产研究部门的管理者脑子里的第一反应很可能是:多招几个开发人员！从约束理论的角度来看，输送管道中至少会有一个约束因素，限制了全局流动效率的潜力。但是这个约束的具体阶段很可能和我们预期的完全不一样。

在下面的例子中，该部门遇到的问题是准备时间长。这样，在逐阶段向下钻取交付周期后，就形成了柱形图。从图中可以看出，需求的平均开发周期在5天左右，其实并不是很长，但是开发前有一个接近5天的等待周期，其他阶段的平均时间消耗接近甚至高于开发周期。例如，测试阶段需要9天以上，方案和PRD阶段需要近6天。在精益理论中，我们可以将活动分为三类:增值活动(如写代码等。)，非增值但必要的活动(如测试等)。)，以及浪费(如等待和缺陷导致的返工)。我们应该最大化增值活动，优化非增值但必要的活动，消除不必要的浪费。那么在这种情况下，我们找到了改进的大方向，再用其他指标进一步考察问题，应该可以得出有针对性的优化策略。

按聚合维度下钻

R&D效能测评平台收集各种R&D工具的效能数据后，一般会自下而上进行汇总，比如按照产品、部门、团队、项目、应用等不同维度进行汇总。，以便为显示和分析提供更高层次的视图。当我们分析效率问题时，我们是从上到下进行的。比如我们先看到整个公司的效率，看到各个部门的横向对比，然后一层一层的往下钻，一直到子部门、团队层面，甚至下钻到数据细节，从宏观到微观分析问题的根源。

在下面的案例中，您首先可以看到左上角的汇总数据报告，该报告显示了所选部门在所选时间范围(周/月/季度)内与其同行的交付周期的横向比较，并且可以将上一个周期与当前周期进行比较。从这个宏观数据出发，我们可以进一步下钻进行分析，比如下钻至所选部门的下一级部门、下二级部门、下三级部门的数据图表，最后下钻至具体的明细数据。然后，你可以将选定范围内的需求按照交付周期的长短进行排序，查看这些需求的交付过程和状态流的细节，分析影响效率的问题，寻找改进的切入点。

对在制品进行下钻

我们在做绩效衡量分析时，往往会按照固定的周期(如每月或每季度)统计绩效数据，出具绩效报告。但是每次看到业绩报告里的统计数据，这个周期就已经过去了。当我们基于上一个周期的数据分析决定采取一些改进措施时，需要在下一个周期结束时验证效果，这就带来了一种延迟反馈。

其实我们也可以采取一些更加积极及时的分析和干预方法。例如，前一篇文章中提到的流负载(或在制品)指数就是一个领先指数。流量负荷过高，后续投放效率下降，投放周期变长。所以要及时介入，识别这类问题。那么如何干预呢？可以使用一种称为时效报告的深入分析方法。

交付管道中的工作停滞会浪费交付过程中的宝贵时间。停留时间报告显示了未完成的工作在交付管道中处于当前状态的时间。在下面的案例中，我们首先可以看到左下角的流水负荷报表，该报表显示了所选部门在所选时间范围(周/月/季度)内的人均在制品数量，可以对上一个周期和本周期进行对比。从这个宏观数据出发，我们可以进一步下钻进行分析，比如下钻至所选部门的下一级部门、下二级部门、下三级部门的数据图表，最后下钻至具体的明细数据。这样就可以看到这些在制品的详细情况，目前处于什么阶段，在当前阶段停留了多长时间。如果做的比较好，可以计算出每个阶段工作项的平均停留时间作为参考值。如果您发现一些工作项停留的时间超过了平均时间，那么您需要付出特别的努力来进一步分析导致拥塞的原因，然后迅速采取行动，找到恢复工作项流动的方法。

3相关性分析

软件R&D效率的提高是复杂的，受多种因素的影响。这些因素和结果之间是有关联的，不是因果关系。即使我们发现两组数据之间存在相关性，也并不意味着其中一组数据一定会导致另一组数据。举个例子，如果一个团队的“代码技术负债率”指标很高，一般意味着代码中存在的很多问题被暂时搁置，未来持续维护的成本和技术风险很高，那么从一个较长时期的趋势来看，“交付周期”这个指标很有可能会持续增长，也就是两组指标之间存在相关性。但是，这并不是必然的因果关系。虽然技术欠账多，但很可能是人员能力、突击加班等其他因素暂时掩盖了这个问题，这种趋势在表面上被抵消了。

但是，从R&D效率分析的角度来看，我们仍然可以从历史数据中分析这种相关性，然后通过实验探索，找到能够有效驱动效率提升的因素，进行持续干预。比如，为了提高在线质量，降低缺陷密度，经验告诉我们，要加强单元测试的覆盖率，完善代码审查机制，补充自动化测试用例。但是，这真的管用吗？根据我们的数据，很可能没有任何作用！不是说这些做法不应该做，而是可能做得不对。可能只是为了指标好看，写缺乏断言的单元测试，找熟人分分钟过一遍代码评审，覆盖一些不热门的代码做硬性测试覆盖目标，等等。所以我们需要实验性思维，不断审视、反思、检讨所采取的做法，哪些做法是真正有效的，哪些是收效甚微的，哪些是方向正确的，但由于执行不到位，结果不如预期。如果我们想通过实验找到那些真正有用的改进活动以及它们与结果的相关性，那么采取有针对性的行动会更有效率和效果。

在下面的例子中，我们的目标是减少需求提前期。根据R&D效率领域专家的经验和理论投入，我们认为时间消耗、流量负载、需求规模、紧急需求插入率、需求变更率、变更提前期、代码技术负债率、缺陷解决时间、代码复杂度/重复率等指标与需求交付周期正相关，而流量效率、需求评审通过率、代码评审通过率、发布成功率等指标与需求交付周期负相关。

然后，我们分析过去六个月的历史数据，得到一个相关系数的热图。在图中，正/负相关性由从亮到暗的颜色来标记。我们可以看到，大部分关联数据的计算结果与我们的经验和理论相匹配，但也有一些数据与经验不同。然后，我们的行动思路很明确，就是对已经被数据证明相关的活动和流程指标进行干预，比如降低流量负荷，提高需求的稳定性，从而加快需求的交付。然后对数据与经验不符的指标进行审视和反思，分析实践是否无效或数据是否失真，进一步增加实验，为下一个周期的继续探索做准备。

上述分析过程体现了数据驱动和实验的思维方式，这是R&D效率测度有效引导和促进效率提升的必由之路。

此外，在这种情况下，我们还使用了北极星指数、恒星指数和栅栏指数的表达式。如上所述，北极星指数，也被称为一个重要的指标，可以用来指导我们改进的方向。为了进一步分解分析北极星指标，我们还需要一些辅助参考指标。这些指示器可能有几个，分布在北极星指示器周围。我称之为星星指示器。栅栏指数的设置是为了避免过度追求北极星指数所带来的潜在负面影响，避免在实现目标的方案选择上的短视行为。我们在分析一个具体场景的时候，可以利用北极星指数、星星指数、栅栏指数组成的指数集，进行综合的度量分析。

4累积流量图分析

在上面的钻取分析一节中，我介绍了分阶段钻取的方法，可以根据交付管道中的不同节点，将交付周期分解为每个阶段的耗时情况。但这种方法实际上是统计一个时期内的平均值，平均值并不能反映时间变化的趋势。只能用于事后分析，不能介入过程。接下来，我们来提炼解决这个问题。

CFD: Cumulative Flow Diagram)是一种有效的度量和分析方法，可以很好地反映工作项在各个流程节点的流动情况，观察交付过程中不同角色的配合情况，轻松分析R&D流程各阶段在制品、交付周期和交付效率随时间的变化趋势。

累积流程图的x轴是日期，通常以天数作为刻度，y轴是工作项目数。那么Y轴从R&D过程的第一个状态(如“分析”)到最后一个状态(如“完成”)的高度就代表了WIP的数量。高度越高，积累的WIP越多。在R&D过程中，从第一个状态(如“分析”)到最后一个状态(如“完成”)的X轴长度代表从开发开始到完成的周期时间。这个长度越长，周期时间就越长，这往往是在制品堆积造成的。根据利特尔定律，生产能力=在制品/平均提前期。在累积流量图中，“完成”线的斜率是吞吐量。通过观察“完成”线斜率的变化，可以直观地看到团队交付效率的变化。

了解以上分析方法后，就可以按照时间维度绘制工作项各阶段的累积流程图，来识别当前的交付进度、瓶颈、问题以及需要进一步探索的内容。

下图显示了R&D有效性测量平台绘制的四个典型累积流程图。让我们逐一分析:

在左上角的累积流图中，我们发现代表”测试中”的红色区域随着时间推移，面积持续扩大，而且这个区域的高度和长度都在快速增长。这说明”测试中”这个状态的在制品堆积变得越来越严重，并且交付周期也在变得越来越长。我们初步可以判定”测试中”阶段可能是当前交付管道中的瓶颈所在。但这个时候还不能武断地认为就一定是测试资源或者测试产能的问题，还可能有各种其他情况。比如，开发提测质量很差导致大量缺陷产生，工作项虽然处于测试中状态但实际是在等待开发修复缺陷。或者是由于不同系统之间的依赖，已完成的部分不具备可独立测试性，需要等待其他系统就绪后才能开展测试等。但无论如何，我们已经找到了瓶颈点所在及其发展趋势，接下来的问题就是如何干预、优化和提升了。在右上角的累积流图中，我们发现代表了开发、测试、上线的多个阶段、不同颜色的区域都发生了”塌陷”，而工作项总量却保持稳定。这说明可能是多个阶段的状态发生了回退，比如某些需求虽然开发、测试完成，并且最终上线了，但是业务在线上验收的时候发现存在重大问题，或与原始需求目标存在较大差异，要求需求下线并重新进行设计和开发。这是一种严重的返工行为，我们知道这代表着巨大的研发资源浪费。这就是我们为什么要从源头把控好需求的质量，加强对需求的理解，明确需求验收条件的原因。如果是需求存在质量或歧义的问题，可能导致数倍于需求分析工作量的研发和测试工作量产生，这种杠杆作用会让本来就很稀缺的研发资源的有效产出进一步降低。研发效能不仅与效率有关，还关乎到有效性。在左下角的累积流图中，我们发现代表”开发中”的黄色区域随着时间推移，其高度保持水平，这说明”开发中”这个状态已经陷入了停滞。但代表”测试中”的绿色区域还在持续增长，说明并不是所有工作都停滞了。我们需要进一步探查发生这种情况的原因，由于并不是所有工作都停滞了，我们可以排除放长假的影响。所以，很有可能是开发过程中遇到了重大的技术架构问题，导致开发工作无法继续开展，或者由于出现了突发的紧急状况，需要调拨大量开发人员去进行救火，导致当前开发工作停滞。停滞作为流动的对立面，我们应当及时识别出这种情况，尽快处理。在右下角的累积流图中，我们看到除了“测试中”阶段出现在制品堆积问题以外，还发现在迭代后期有大量新增需求的情况发生，这有可能是为了响应业务的变化而进行紧急需求插入，也有可能是为了”搭车上线”，赶在发布窗口之前追加一些新的需求。敏捷思维让我们欣然接受需求的变更，但是我们也承认过度的变更会导致开发过程的摩擦。上线前出现大量需要搭车上线的需求也不一定都是合理的，很可能因开发和验证时间不充分导致线上问题，所以我们不能一味地接受，还有要进行合理的权衡。

5流动效率分析

效率是工作项处于活动工作状态(无阻塞工作)的时间与交付管道中总交付时间(活动工作时间的等待时间)的比率。经验表明，很多企业的流动效率不到10%，这意味着需求在交付管道中被卡住、被阻塞、等待了大量时间。

结合DevOps平台中的看板工具，我们将待评审、就绪(待开发)、待测试、待发布阶段的属性设置为“等待”，将需求沟通、需求评审、方案设计、开发、测试、发布阶段的属性设置为“活动”，这样就可以得到R&D流程的基础数据，并计算出流程效率指数。

下图是某部门落地流程效率测量分析的一些实施细节。通过统一配置指定范围内各团队的看板，明确各阶段的入场和退场，规范各团队的操作规范，就可以得到流程效率的度量数据。然后，通过控制在制品数量、促进小批量交付和引入一系列最佳实践，我们优化了R&D阶段的等待时间，并在一定程度上提高了流动效率。

这里有一个问题需要特别注意，就是数据的准确性。如果按照看板工具统计每个R&D阶段的时间消耗，那么就要考虑如何保持看板中工作项目的状态与实际工作状态一致。当然有办法。例如，我们可以依靠规范的宣传和监控来确保数据相对准确(例如，至少在每日会议上确保工作项的状态及时更新)。然而，更有效的方法是在工作项与代码关联之后，通过R&D人员的一系列后续动作，如提交、合并、测试和基于代码的上线，自动更新工作项的状态。我们将在下一章解释这一部分。

6流量负载分析

Load是交付管道中已经开始但尚未完成的工作项的数量，也就是我们常说的在制品数量。流量负荷是一个关键的先行指标。过高的流量负荷肯定会导致后续的投放效率下降，投放周期变长。因此，及时干预是必要的，以确定此类问题。

下图是我在一个团队中测量和分析落地流量负载时的一个案例。可以看到，产研团队的流量负荷比上一个统计周期增长了43%，而同一周期的产研交付周期增长了近20%。从实际统计数据来看，这两个指标之间存在相关性，流量负载的增加影响交付周期的上升。但是，这两个指标之间并没有像公式那样精确的数学关系。这是因为有许多因素会影响交付时间。我们不能像在实验室那样把其他因素都屏蔽掉，只能观察这两个指标之间的关系。此外，流量负荷的增加延迟了对交付周期上升的反馈，积压的需求在当前统计周期内可能无法完成，因此不进入交付周期的统计范围。但是，我们已经可以足够清楚地看到趋势，两个指标之间有很强的相关性。

看到问题后，我们可以使用上面提到的过程中的钻取方法来检查具体的工作项。我们也可以使用名为“个人R&D日历”的视图来查看它。下图可以看到，底层的开发人员在3月15日到3月21日这一周有大量的并行任务，而且都是贯穿整个一周安排的。这种并行的、频繁的中断和上下文切换也是R&D过程中典型的浪费——任务切换浪费。我们应该进一步优化R&D计划，控制并行WIP，使流程更加顺畅。

总结

如果一个衡量标准真的很重要，那是因为它必须对决策和行为产生一些可以想象的影响。度量标准有很多，但是如何利用好这些度量标准来识别、分析和诊断问题，做出有效的决策以提高效率，并引导正确的行动才是重点。本文提出了六种常用的效率测量和分析方法。虽然本文主要以管理域的度量和分析方法为例，但是对工程域(如代码、CI、测试等特殊项)的分析也是非常必要的。由于篇幅有限，暂时不展开，以后有机会再介绍。

R&D效率测算的难点不仅仅是测算指标的设计和测算分析方法的使用，在中大型企业落地还需要考虑很多因素。在下一篇文章中，我会根据自己最近的落地经验，介绍一些落地过程中的具体实施建议。

作者介绍:

腾讯DevOps、R&D效率资深专家张乐，长期在大型互联网公司(百度、JD.COM)工作，拥有数万R&D，专注于敏捷与DevOps实践体系、DevOps平台产品设计、R&D效率测评体系建设等方向。曾担任高级scrum master、DevOps平台产品总监、集团级R&D效率度量标准化联盟等职务。他长期活跃在技术领域。目前是DevOps起源国际组织中国DevOpsDays的核心组织者。他还是中国多个技术峰会的联席主席、DevOps/ R&D effectiveness的制作人和演讲嘉宾。EXIN DevOps全系列国际认证授权讲师，凤凰计划DevOps沙盘国际授权教练。曾担任埃森哲、惠普等世界500强企业的高级顾问和技术专家，拥有多年的敏捷和DevOps转型、工程效率提升和大型项目实践经验。畅销书《独角兽计划:数字时代的发展传奇》译者。

系列文章推荐阅读:R&D效率的启示