浅谈科技中心研发效能度量体系建设
效率是“以正确的方式做事”，而效能则是“做正确的事”。对企业而言，不可缺少的是效能，而非效率。—— 彼得·德鲁克
背景
在后疫情时代经济增长放缓，市场竞争更加激烈。在此环境下，新一轮的数字化转型升级正在兴起，其中降本增效将是重要的主题之一。马化腾说：“很多业务该砍就砍掉，不要留恋。降本增效，应该要形成一个习惯。”。在软件研发领域，效能提升的方法和实践一直在持续发展，敏捷实践和Devops实践引入已有数年的时间。然而，当组织在研发效能上投入了时间、成本和人力后，有一些问题亟需回答。我们的研发效能水平如何？研发效能是否可以量化？阻碍研发效能的瓶颈是什么？效能改进措施实施后，提升效果如何？效能持续优化该怎么做？
这就是为什么要进行研发效能度量的原因，通过设计一套能够客观量化研发效能的指标体系，从而能反映团队研发效能的水平，达到“顺畅、高质量地持续交付有效价值”的改进目标。与此同时，随着“研发效能”的热度不断提升，已得到了越来越多的组织和公司的重视。2022年9月，中关村智联软件服务业质量创新联盟、中国软件协会过程改进分会发布了《软件研发效能度量规范》标准（下称“标准”），为研发效能度量提供了一个效能度量框架的标准。
在研究研发效能度量如何做之前，我们先要看一下研发效能是什么？可以用一个简单的公式表达：
效能 = 目标 * 效率
软件研发工作是以达成业务目标为前提的，因此软件交付内容是可实现业务目标的最优功能集合。在理想情况下交付功能和交付的质量水平可以满足业务目标要求。在效率方面，软件研发会选择合适的研发模式、恰当的流程、高效的工具，并投入理想的工作量。不过，有理想就有现实，在现实情况下，理想交付的功能、质量与业务目标之间存在差距，称之为有效性，理想工作量和实际工作量也存在出入，称之为效率。有效性关注产出了什么，业务目标是否能够达成，目标价值是否能实现，也就是做正确的事情。效率关注如何投入，用怎么样的方式投入，即正确的做事。因此，研发效能提升的目标也可以表述为最优的投入产出比。
（注：图参考《软件研发效能权威指南》）
关于研发效能的讨论一直不绝于耳，在今天数字化转型升级背景下，有何不同意义？在移动互联网的红利期，信息技术能力是企业竞争的核心能力之一。为了满足海量业务需求，可以通过堆人和堆资源，靠高强度的加班来应对，但不健康的发展模式无法持久。长期积累的技术债，以及软件规模复杂度上升使得研发效能的增长速度与人员扩张的规模不匹配，流程效率和交付效率下降，影响客户满意度。研发效能是通过明晰需求价值，采纳敏捷精益协作模式，引入云原生研发范式，使用高效自动化CI/CD流水线，自动化测试，结合效能度量等举措，以更可科学、更可持续的发展方式，使研发过程向更高效的业务价值的交付模式转变，从而避免“内卷”，走向“反内卷”。如“熵增定律”所示，孤立系统内部复杂度（混乱程度）总是不断增加。研发效能的意义在于减缓熵增的程度，保持研发效能的有效性和效率。
效能度量体系建设目标是能客观量化分析研发效能水平，通过度量体系发现关键瓶颈，牵引研发效能提升。然而，在效能体系的建设过程中，面临三大挑战：
度量指标不够准确：正如那句名言：“你度量什么，就会得到什么”。一旦将度量指标与团队绩效挂钩，指标的准确度就可能会失真，效能度量就可能会陷入古德哈特陷阱。
度量指标难以统一：不同产研团队的协作模式不同，研发过程标准不一。各团队在需求、开发、测试、部署等阶段的任务和活动有所不同，给度量指标标准定义带来了困难。
度量无法带来提升：以终为始，度量的目的并不是要形成一系列指标，而是能通过度量指标带来改变，提升效能。度量是有成本的，若度量结果不能影响或改变决策，那它就没有价值。
面对挑战，团队持续探索，并寻找适合科技团队且有价值的效能度量体系。在标准中效能度量框架归纳为E3CI，由效能目标（E3CIObjectives）、认知域（Cognition Area）、改进域(Improvement Area）三部分共同构成。结合框架体系，在建设效能体系实践过程中遵循三个原则。
1）效能目标导向：以效能目标为导向设计度量体系，以解决团队实际问题和效能提升为目标导向，效能度量不是武器，而是数字化管理和改进的工具。
2）多维指标使用：综合使用多维度指标，避免仅使用单一指标，采纳效率、质量、能力、价值等多维指标，综合评估效能水平。
3）改进措施推动：关注效能改进措施的实施和落地，在敏捷协作、工程卓越、质量内建等方面推动改进措施落地。
（注：图参考《软件研发效能度量规范》）
维度 | 标准 | 实践 |
效能度量体系的建设主要共分为5个步骤：基础数据采集，指标体系设计，度量平台建设，效能度量分析，改进措施推进。
基础数据采集:
目标：规范化的产研需求流程，沉淀产研过程数据。
方法：需求价值流。
实践：在产研流程未标准化之前，团队都有各自的交付流程，需求流动规则不统一。因而需要先建立标准的需求价值流流程，而后才能采集过程数据。首先，根据ToC端和ToB端团队交付特点分别梳理敏捷模式和瀑布模式的需求价值流。其次，按业务线对业务、产品、技术等工作内容设计与之匹配的工作项，建立业务-需求-任务三层需求层次模型。最后，基于一站式、一体化的业产研协作平台，固化需求价值流过程，线上化采集研发活动过程数据，沉淀数据资产。
指标体系设计：
目标：建立科学，可量化的效能度量指标库。
方法：度量指标设计原则。
实践：根据Devops成熟度的度量指标，标准中的度量框架以及行业头部的实际经验，结合团队实际情况，建设效能度量指标库。以指标设计的七原则（结果指标>过程指标、全局指标>局部指标、定量指标>定性指标、团队指标>个人指标、指导性、全面性、动态性）为指导设计指标。在指标体系的建立过程中与产研团队充分沟通，确保指标的适用性、可靠性。最终，在交付效率、交付质量、交付能力、交付价值四个维度上形成效能度量指标的指标库。同时，指标库由效能委员会、质量委员会和架构委员会共同负责维护迭代。
度量平台建设：
目标：建设具有多维度指标卡、指标图表的数据可视化平台，支持度量指标分析和洞察。
方法：DIKM（数据、信息、知识、智慧）
实践：通过效能度量的分析，以数据可视化的方式表达效能度量指标（包括北极星指标、群星指标）。提供基础的统计和分析工具，为不同部门、团队、用户提供多维度数据度量看板，使用户可以基于平台分析研发效能水平、洞察效能瓶颈、提出改进方案。在此，引入第三方效能度量工具，基于效能洞察的功能，分别在效率、质量、工程等方面按项目特点，选择对应的指标卡编制效能度量看板。
效能度量分析：
目标：洞察关键问题，提供科学、客观的可量化研发效能评估。
方法：趋势分析，下钻分析，相关性分析，流效率分析，流负载分析等
实践：数据分析主要有效率、价值、质量和能力四个维度。在效率方面，同时关注资源效率和流动效率，以人均需求吞吐量和需求交付周期为北极星指标，观察团队交付效能的趋势变化。结合开发交付周期、阶段停留时间、在制品数量、资源负荷等群星指标，以需求变更次数为围栏指标，观察交付效率的趋势变化。在价值方面，基于业务目标构建经济指标和非经济指标的需求价值评估模型，在业务增长、运营优化、基础建设、战役分解等方面，量化评估需求的ROI。需求价值使用于需求准入、资源匹配和上线回顾。在质量方面，以高危缺陷比为北极星指标，关注冒烟测试通过率、缺陷解决时效、缺陷新增趋势、缺陷重开率等指标，综合评估团队的交付质量水平。交付能力主要分析团队的工程能力，基于代码库、流水线的基础数据分析，评估团队工程卓越水平。以上分析通过可视化的方式呈现给不同团队负责人，并以北极星指标牵引，持续关注效能水平提升。
改进措施推进：
目标：以效能度量为工具，推动改进措施落地，持续提升效能。
方法：GQM（目标-问题-方法）、MARI（度量-分析-回顾-改进）
实践：从团队实际要解决的目标出发，提出影响该目标的问题，进一步分析度量指标，确认可行的实施方案，推动改进方案的落地。以提升营销类需求的交付效率为例，目标是如何降低营销类需求的交付周期，对目标分析，关注的问题包括目前交付周期多久？开发交付周期多久？各阶段停留时间多久？当前的流负载如何等。采集需求、UI设计、开发、测试、发布等各阶段的指标数据及工作项任务数据，经对比分析、下钻分析，发现营销需求在UI设计和前端页面开发时间较多，为保证展示效果的一致性，每次都要进行设计走查、代码评审和页面测试等。针对此问题，通过共建组件库和组件共享，可减少设计走查和前端开发的时间，既能提升交付质量，又能提升需求交付效率。
（注：图参考《GQM效能洞察分析模型》）
总结
效能度量是一个敏感的领域，在效能度量过程中，在指标的采集、分析、呈现和解释过程中会受到诸多因素的干扰。因而，效能度量应该被正确的引导，度量本身不是目的，效能持续改进才是目标。如果将度量指标看成一组数字，就会陷入数字游戏的陷阱，消耗不必要的精力维护失真的数字。如果将度量与考核挂钩，则会陷入古德哈特陷阱，使度量与现实脱节。
所以，效能度量应回到研发效能的具体问题中，结合度量指标和研发实践，务实地解决问题。通过效能平台将效能度量的数据流变为价值流，以结果为导向为效能持续提升创造价值。
参考材料
1）《软件研发效能度量规范》，中关村智联软件服务业质量创新联盟
2）《软件研发效能提升实践》，茹炳晟，张乐等著
3）《软件研发效能权威指南》，茹炳晟 张乐等著
4）《精益产品开发原则、方法与实践》，何勉著
5）《GQM 概述：构建研发效能度量体系的根本方法》，作者：任晶磊