逸 Talk | 如何建立研发效能管理的闭环？
本篇内容是9月7日『逸Talk』直播的干货总结。
欢迎持续关注『逸Talk』系列分享，参与直播，与嘉宾实时互动探讨。
点击文末『阅读全文』回看直播，公众号对话框发送『006』获取完整课件。
一个关键的基础认知
在讨论研发效能度量怎么做之前，需要先理解它是什么。
研发是相当复杂的系统工程，导致我们很难找到一两个指标来概括研发效能的全貌。因此，研发效能度量并不是指物理度量，不是在单项指标上追求绝对精准和正确。
效能度量更接近统计度量，需要科学地设计度量体系，在一定误差范围内发现数据的共性规律，辅以分析和调研，挖掘根本的原因。这个关键的基础认知能够帮助我们更准确地理解和管理研发效能。
既然是统计度量，设计度量体系时需要关注两个要素：
系统思维
在复杂体系的度量中，任何单一指标被过度宽泛地解读、被过度简化地归因、被过度粗暴地使用，甚至削足适履，都是危险的。比如用千行代码缺陷率指标来度量代码质量，就很可能使团队陷入教条主义，造成效能“血案”。关于度量体系中的系统思维，晶磊老师之前投稿给 InfoQ 的文章有更详细的阐述。
制衡机制
当某些指标被赋予过多意义，工程师往往很有动力进行一些“粉饰”。这种工程师与度量体系的博弈不仅浪费精力与成本，有时还会造成负面效果，比如为了代码行数指标好看，把一行代码拆成多行，把应当抽象成函数的代码复制粘贴，反而会使代码可读性和可维护性下降。
这种情况下，可能就需要代码开发当量这类挤掉水分的工作量指标，代码复用度这类反映软件工程质量的指标来做制衡。通过度量体系的整体设计，提高“粉饰”指标的门槛，来对冲单点指标的负向牵引效应。
近期完成立项的《软件研发效能度量规范》为研发团队定义并搭建度量体系提供了可参考的框架。以下对框架涉及到的概念进行解读：
度量
度量需要覆盖研发全生命周期，支持DevOps工具链上的不同数据源，打通需求-设计-开发-测试-交付-运营各环节，由价值流动效率串联各环节的资源效率。
认知
度量的直接目标是获得认知。认知被分为价值、速率、质量、成本、能力五个维度，从多个视角观察、理解软件研发流程及其成果，能够为后续的可落地、可持续的效能改进提供基础。
持续改进
度量不能停留在数字层面，需要层层深入挖掘根本原因，使度量带动思考和行动，建立持续改进的闭环。MARI实践方法论就是为这一环节设计，在第三部分会展开介绍。
研发效能
度量的最终目标是提升研发效能。研发效能包括三方面：效益，即研发效能应服务于业务交付的效果；效率，即高效高质完成任务，减少人力与资源的浪费；卓越能力，即团队工程能力需要同步提升。
MARI是一套应用于软件效能度量实践落地的方法论，其目的是建立效能度量和改进的闭环。Amy老师结合『需求交付时间过长』案例，对MARI的思路与实操方法进行了深入解读。
MARI由以下四个步骤组成：
M 度量 Measure
无论任何改进活动，首先需结合团队实际需求，面向改进目标通过量化数据对过程及目标进行刻画，并统一数据及指标的采集方法。
在梳理度量需求时，需要辨别不同角色在不同认知维度下需要什么信息，希望借助度量达到什么目的。提前进行全面梳理和优先级排序，能帮助研发团队识别关键度量需求。同时，需要关注度量的成本和收益，忌求多求全。
A 分析 Analyze
在量化指标的基础上，运用统计分析方法，对数据的趋势、分布、关联等信息进行分析，从项目、阶段、团队乃至个人不同角度下钻，得到对现状的量化理解。
R 回顾 Review
基于分析结果，对产生“果”（结果）的“因”（影响因子）进行回顾，挖掘对结果产生影响的根本原因，定位关键少数瓶颈。回顾阶段的要点在于团队达成共识：讨论和调查不是为了甩锅，而是为了找到根因。
在实操中，团队可以从流程设置、工具体系、制度设计、资源分配等角度来筛查问题的根因所在。如果团队认为问题起源某些不可控的因素（比如一个粗心的过失），那么可能还需要继续追问和挖掘。
I 改进 Improve
针对关键问题，聚焦根本原因，建立可落地的改进措施。通过调整“因”（影响因子），最终影响“果”（目标）的达成，并进入下一轮度量验证，持续跟踪改进效果，适时调整改进策略。
改进环节的要点在于聚焦关键少数问题和关键少数瓶颈，重点突破。在推行改进措施的过程中，先制定小目标，在小团队内试点验证，循序渐进将瓶颈逐个突破，再推广至全员。另外，在改进流程和工具时，优先从自动化、减少人工干预的思路入手，避免以增加团队工作量为代价进行改进。