‍

阅读本文您将获取以下两点内容：

1、研发效能提升实践过程中有哪些痛点？

2、研发效能提升系统性方法论：MARI 方法论

‍

背景：由信通院云原生产业联盟、云计算标准和开源推进委员会、全球软件质量与效能大会组委会共同主办的『软件质量与效能度量』沙龙在线上举办。思码逸咨询专家陆春蕊 Carrie 作了『如何层层推进提升研发效能』主题分享，与行业大咖与从业者们分享了研发效能提升的实践方法。

‍

以下是演讲的干货内容，直接开整！

‍

研发效能实践的痛点    

‍

研发团队所面对的效能挑战反映在方方面面：

‍

1、交付速度慢质量差，业务方满意度低；

2、协作效率低下，等待和返工造成浪费，工程师满意度低；

3、研发人力资源难以调配，项目不断延期超出预算，管理层满意度低。

‍

因此，研发效能提升也成为越来越多团队关注的重点，但至今缺乏清晰明了的落地路径。基于思码逸与客户的持续沟通实践，我们发现研发效能的实践面临以下痛点：

‍

• 研发效能度量什么，如何选取指标？

• 研发效能提升从哪些维度做分析？

• 研发效能痛点的根因有哪些，怎么改进？

• 怎样验证、构建研发效能提升闭环？

• 缺乏研发效能度量工具，如何让研发效能提升实践落地？

‍

针对研发效能提升实践所面对的这些问题，思码逸提出了 MARI 方法论。

‍

研发效能提升方法论：MARI 方法论    

‍

MARI 是一套面向软件研发，应用于效能度量及实践落地的方法论，其目的是建立效能度量和改进的闭环。

‍

研发团队结合实际情况，将价值流中的关键阻碍问题定位为提升点后，可以应用 MARI 方法论，对问题进行量化评估、分析和拆解，获取效能瓶颈、改进机会等洞见，进而落地为软件工程实践的逐步优化，以及切实的效能提升。接下来我们将结合案例介绍 MARI 方法的应用。

‍

Measure 度量

研发效能的本质是更快更好更低成本地交付更优的业务价值——这短短的一句话中，包含了交付的效率、质量、成本、能力、业务价值等多个维度。

研发效能如此多维，要面面俱到做度量的成本是很高的，而大厂使用的指标也未必能适用于团队自身情况。因此，团队在开始改进活动前，需要牢记“以终为始”，结合团队实际痛点，确认改进目标，再根据目标选取度量指标。

例如，研发团队A最近主要头疼的是项目频繁延期，业务方怨声载道，但细究到研发的各个环节，产品、开发、测试、运维团队互相推诿，而且都声称人手不够。到底问题出在哪里呢？在这个情况下，需求交付周期这个反映价值流动效率、且能够下钻拆分到各个环节的指标，就是一个合适的北极星指标。

‍

Analyze 分析

在研发效能的相关讨论中，我们经常能看到著名的丰田生产方式创始人，大野耐一的这句话：那些不懂数据的人是糟糕的，而最最糟糕的人是那些只看数据的人。度量如果停留在数据，是一件非常危险的事情，重要的是从数据里洞察问题并指导改进。

图中我们列出了三种分析方法：

• 趋势分析能够展现度量指标随时间推移的变化趋势，根据走向做出是否需要继续分析的初步结论。

如果已经采取措施，可用来验证改善措施有效性；需要注意这里未必选择均值来观察趋势走向，80分位值可能能够更好地排除异常值，反映普遍情况。

• 下钻分析能够从宏观到微观，从表象到根因逐层排查问题，帮助团队找到关键瓶颈。由于北极星指标往往是一个顶层的聚合指标，可能有多种拆分下钻的路径。

下钻到研发环节时，建议避免使用提交次数、代码行数这样易受噪音影响的指标，思码逸设计的基于深度代码分析的『代码当量』可以解决这个问题，这一指标目前也已得到信通院开源生态监控平台采纳。

• 关联分析能够从历史数据中辨别相关性，进而寻找效能瓶颈的关键因素。此外，关联分析也有助于避免单一指标的负向牵引作用，洞察效能全局。

团队A通过分析发现，在近期需求交付周期的下钻中，仅有研发环节的交付时长显著高于历史水平；关联研发团队近期代码当量走势，发现研发团队的人均编码生产率呈明显的下降趋势。

‍

回顾 Review & 改进 Improve

基于以上分析，团队A的研发环节效率下降很可能是需求交付变慢的瓶颈。那么设定KPI，要求所有开发者的效率都提高，不就可以了吗？

‍

事情没有这么简单。找到了关键瓶颈，并不意味着找到了根因所在。在没有根因调研、解析的情况下，将任务直接下达一线，开发者缺乏明确改进方向的指导，只能盲目延长工作时间、增加工作负荷。即使投入了资源也很难协力提升，反而损害团队工作体验，懒政的管理者要为此负主要责任。

‍

以团队A的问题为例，研发环节效率下降可能是制度、过程、工具、人等多种因素造成的，也可能是受到上游需求环节的影响。从众多影响因素中不断排除，寻找根因，是非常复杂的工作。一方面可借助相关的度量指标和数据继续分析；另一方面，组织专项调研，倾听一线开发和leader声音，这部分工作是不能靠纯数据分析替代的。

团队A调研发现，研发团队近期存在显著的代码贡献不均现象，团队25%开发者贡献了83%工作量。由于任务拆分与排期不合理，大量工作堆积在少数几位开发者处，导致这几位开发者超负荷工作，而其他大部分开发者处于等待状态，整体效率下降。

针对这一问题，团队A一方面进行资源调配，补充人力缺口，降低了人均流负载，也减少开发者在任务间不断切换造成的浪费；另一方面调整了任务分配，减少任务间的耦合，避免了关键人力依赖和忙闲不均现象。

‍

持续改进的闭环

效能提升不能靠阶段性冲刺。要达到有效且可持续的效能提升，需要将度量和改进的实践融入日常研发流程，持续追踪，持续改进。

‍

MARI方法强调构建研发效能管理的闭环。在基于数据解读制定改进方案后，需要持续度量观察效能趋势，对改进后的指标数据进一步分析解读，对改进方案的有效性做出快速反馈。若改进推进一段时间后，继续提升效果不明显，边际效应降低，这一机制也有助于团队快速判断，及时将资源投入下一改进项。

‍

团队A在推行改进后，继续度量北极星指标，观察到需求交付周期相比三个月前未改进时缩短29%，需求吞吐量也有所上升，可推测先前的改进方案有效,调整研发资源与任务分配与效能的提升确实存在关联。

为了避免“面向指标改进”的情况，团队A关联了其他度量指标作为制衡。例如度量人均生产率，来验证需求交付变快确实与研发团队的产出效率提高相关，而不是因为需求拆分得更细了；度量测试缺陷率与线上缺陷率，来验证需求交付变快并不是以质量下降作为代价。制衡指标可以根据先前改进措施的影响范围来选择。

‍

以上就是 Carrie 分享的全部内容，团队A也终于突破重重迷雾，找到了阻碍快速交付的关键瓶颈，并进行了针对性的优化。最后用一张图来总结 MARI 方法的最佳实践：

‍