效能提升不来自于度量本身，而来自于针对性的改进｜直播回顾

9 月 7 日，ONES 研发管理大师课第四期课程正式开课，腾讯 DevOps 与研发效能资深技术专家张乐老师分享了《研发效能度量的行业趋势及五项精进》。借助效能度量的「五项精进」，剖析研发团队效能瓶颈问题，助力企业更好更快地提升研发效能。

以下是张乐老师分享的核心内容。

研发效能数字化

研发效能数字化是如今这个时代必须要做的事情。如何开始呢？要从有效的度量开始。我们在谈论效能度量的时候，应该分不同的层次来考虑问题。请看下图的「DIKW」模型：

「DIKW」模型

这个模型可以帮助我们很好地理解数据、信息、知识和智慧之间的关系。最下层是「数据」，数据是对物理世界的刻画，代码提交的原始日志、需求流转的信息等这些都是数据；有些数据需要经过鉴别才拥有价值，所以第二层我们把它称为有价值的「信息」；如果只有片面的信息还不够，并不足以去回答一个复杂的问题，我们需要再把多种信息进行聚合加工，辅以分析判断，达成理解，这就是第三层「知识」；然而，我们最终目的是做出效能改进，所以在多个知识的积累之上，我们运用专家的经验来生成解决方案，把知识聚合成最上层的「智慧」。

所以，一句话总结，数字化就是从物理世界中，开采出数据，粗炼出信息，精炼出知识，聚合出智慧，最终提高生产力。

价值流分析的五大流动指标

研发效能数字化需要有效的效能度量，没有度量，就无法改进和管理。接下来，我们来看看价值流分析的五大流动指标，分别是流动效率、流动时间、流动速率、流动负载和流动分布。

• 流动效率，用增值的时间除以总时间，可以算出流动效率这个指标；

• 流动时间，指的是从需求被接收到交付的整体周期；

• 流动速率，其实也就是吞吐量，指的是单位时间内能够完成多少有效的价值交付；

• 流动负载，指的是我们在交付管道里并行在做且尚未完成的工作项数量；

• 流动分布，可以衡量一个团队中不同工作的分布，比如分配了多少比例做业务需求、多少比例解决缺陷或技术债务等。

关于这五大流动指标，我们在下期课程里，会有用一整节课做详细的拆解以及讲述具体的分析方法，敬请关注下期课程。

ONES Performance 效能管理

要想做好研发效能，好的工具是必需的。ONES 开发了效能管理工具：ONES Performance，它的设计逻辑非常清晰。对于度量，我们除了考虑指标，也应该考虑场景，而场景是更关键的。也就是说，这个指标是给谁用的？给老板用，给 PMO 用，还是给研发用？每个层级关注不同的指标，它的使用场景也是不一样的。

ONES Performance 场景示意图

ONES Performance 覆盖了效能管理全场景，为团队效能改进提供数据支撑，有效地帮助团队进行效能的持续改进。

效能度量的五项精进

研发效能度量五项精进是效能度量的实施框架。

• 第一项，建立度量基础设施，把价值流网络建立起来；

• 第二项，建立度量指标体系，比如结果指标、过程指标、先导性指标、滞后性指标等；

• 第三项，洞察分析模型，对相对复杂的问题进行度量分析；

• 第四项，洞察产品建设，化繁为简，用产品帮助我们屏蔽底层实现复杂性，直接呈现用户结论和分析；

• 第五项，数据驱动，通过实验思维让效能度量不跑偏。

研发效能度量的五项精进示意图

接下来，我们来依次看看这五项精进的具体内容吧：

首先我们要建立一个度量的底座，但这个底座不仅仅是所谓的数据仓库，而是要承载更多的能力。我们把它分为三层：工具网络、工件网络和价值流网络。

工具网络的节点是每一个单点工具，比如管需求的工具、管代码的工具、管 CI/CD 工具，把这些工具通过相关的接口连接起来，做到互联互通；工件网络指的是我们在工具上产生的制品（需求、代码、制品包、流水线等）是否可以相互连接；价值流网络是指将工具和团队中流动着的工作，与业务级产品进行对齐。这也正印证着梅特卡夫定律：一个网络的价值随着其连通性而增长。

我们来看看下图的指标全景图，我设计的初衷是想把关键的度量指标组织进一个合理的结构。基于价值流的度量，研发过程可以分成交付效率、交付质量和交付能力这三个维度，还有业务结果的维度；研发阶段可以分为需求阶段、开发阶段、测试阶段、发布阶段、运营阶段。所以，这张图是基于二维图形形成的指标矩阵，是我在 2019 年首次分享出来的，行业里面也经常引用。

效能指标全景图

后来，我发现有的公司已经有成百上千个指标，他们并不知道重点指标应该在哪里。所以，我将指标全景图进一步升级，不再追求把每个关键指标都列举出来，而是建立一个结构化的模型——度量指标的 Cube 模型，把度量指标分成不同的层次，从多个维度更好地进行刻画和阐释。

这个模型不是一个平面，而是立方体，我们把中间蓝色这个点作为抓手，从图里往外拉，能看出来它其实是个立方体，它有「结果面」和「过程面」。从「结果面」我们需要关注的，分别是价值、效率、质量和成本，可以概括为我们经常说的「多、快、好、省」。这里面有很多结果性的指标，比如说需求交付周期、需求吞吐量、线上缺陷密度等等。所以，「结果面」是结果导向，对整个研发价值有着牵引和导向作用。为了达成结果指标，我们还有很多过程性的工作要做，所有也要看「过程面」，比如协作能力、工程能力、技术能力和组织能力的提升。

综上，我们要基于结果指标做整体的引导和驱动，通过过程指标的细化和分析，去驱动具体的改进活动。

下图是 GQM（Goal、Question、Metric）分析模型，它的基本思路是：数据的收集和分析要聚焦于清晰具体的目标，紧接着每个目标划归为一组可量化回答的问题，每个问题再通过特定的指标来说明。所以，GQM 分析模型一定要向目标去对齐，做到以终为始的度量。

然而，做效能度量不能光考虑指标，所有的度量分析方法应该烂熟于心。

十二种度量分析方法

这里的分析方法我列举了十二种，我们先来看以下几个比较常见的：

第一，趋势分析。研发效能有一句话是「趋势大于绝对值」，我们要做的是向量的度量，而不是绝对值的度量。所以，我们观察的是增量和波动，是变化和趋势，这个比绝对值更重要。

第二，组成分析。比如，需求交付周期是 20 天，我们就可以看到时间都花在哪里，在哪个阶段花费的时间最长；同时，也可以帮我们分析出在什么地方会爆出研发瓶颈。

第三，贡献分析法。这可以帮助我们避免「平均值陷阱」，我们要基于不同的分析维度做进一步剖析，找到对结果正/负向波动影响最大的因素，而不要只看平均值。

第四，帕累托分析。也被称为关键少数法则。指的是事物的主要结果很可能只取决于一小部分因素，核心在于要找到「关键的少数」，这才是优化、提升的空间。

第五，累积流图分析。累积流图反映很多信息，比如交付周期、在制品，交付速率以及团队的各个角色之间配合协作的模式等。

我认为产品建设适合有一定规模的企业去运作，因为做起来是比较有难度的，有的大厂甚至常年投入几十人研发和维护效能度量的工具系统，如下图：

效能度量工具产品设计图

最下面一层是数据的仓库，我们要把数据从数据源采集出来汇总到数仓，建立数据模型，同时对源数据和指标做一些灵活的配置；再往上依次是接入层、应用/产品/功能的展示、服务能力；最上面一层是目标用户，效能度量的工具产品一定要考虑目标用户，面向管理者、研发负责人、研效专家或一线工程师的场景都是不同的。

研发效能的提升不来自于度量本身，而来自于针对性的改进。对此，我总结了五个步骤：

• 第一步，明确一个改进目标；

• 第二步，通过洞察挖掘出价值流中可能的瓶颈；

• 第三步，选择研发效能地图实践中适当的实践（大师课第一讲中有过详细介绍）；

• 第四步，从小范围开始，纵向进行实验；

• 第五步，判断实验结果是否有效，如果有效，形成标杆效应。

在以上五个步骤也蕴含了四个关键点：

• 一次只解决一个问题；

• 系统思考，以整体方式考虑约束；

• 明确范围、时间、度量指标、成功标准；

• 基于数据的证据，持续实验。

- Q & A -

Q1：研发工作中往往会面对不同难度值的研发任务，如何做到公平的度量？

张乐老师：度量首先是自驱改进的工具，也就是自己跟自己比。我们说趋势大于绝对值，某一个人、某一个团队、某一个部门、某一个产品线，它随着时间的变化，效能是否在提升，这是首先要考虑的；然后才是横向的对比，但是注意，一定是同类别、同性质的团队才能够进行横向比较。

Q2：效能度量是否应该和 KPI 挂钩？如果不挂钩，靠员工的自驱力，感觉更不可靠，如何平衡这个矛盾呢？

张乐老师：很多企业的效能度量都曾经与 KPI 或考核进行过挂钩，但如果是这样做，失败的例子非常多。所以我觉得，要通过一种机制的设计，既要能解决导向性和团队自驱的问题，也要尽量消除度量与考核强绑定所带来的副作用。

我认为应该把度量拆成两个部分来看，第一部分是结果性指标，做整体牵引和引导。这部分可以和 OKR 的方式做衔接。比如说，一个研发团队的 OKR 里有一个「O」是和效能相关的，对应的「KR」则是效率、质量等方面的关键结果，通过这种方式做整体的导向；第二部分的指标是过程性指标，比如单元测试、Code Review、扫描通过率等，就不太适合直接与 KPI 及考核绑定，这些指标应该更多是给一线团队赋能，给他们更多的授权、选择权，让他们因地制宜地去使用和采纳对自己有效的改进措施，只要能达到目标即可。

因此，我们既有结果性指标去和目标导向对齐，让大家知道公司、部门重视什么；同时也有过程性指标给一线团队一些灵活度，不用很刻板地度量和考核，导致造数据、短视的行为。

Q3：有时候效率提高，质量就难以保证；但质量保证了，效率就又上不去。在效能度量过程中，如何平衡效率和有效性的关系呢？

张乐老师：实际上，在很多成功案例中，我们看到效率和质量在一定程度上是可以兼得的。和大家分享之前听到的一句有意思的话，上半句是：The 「Speed」 is the 「Quality」，我们要向质量要效率；下半句是：The biggest「Muda」 is 「Re-Do」，最大的浪费就是返工。我们要从根源上控制质量，把质量内建进去，也就是说，虽然多花了一些质量内建的工作量，但是最终端到端的成本反而是降低的。做好持续交付等工程实践，就可以让效率和质量在一定程度上实现兼得。

Q4：我们公司之前推行过一段时间的效能指标，但感觉还不如扁平化管理高效，效能度量似乎不适用小团队。老师建议团队达到什么规模开始做效能度量呢？

张乐老师：这个问题很有意思。除非团队特别小，只有三五个人，都知道对方在做什么，那确实不需要度量。但如果成长到一个有活力的小团队，比如十个人左右的 Scrum 团队，这个时候其实就可以开始度量了。当然，要控制度量的成本，也就是度量的 ROI 是要去控制好的，一开始不要花过多成本，搞得太复杂。

所以，我认为度量这个事，本质上都可以去做的，它是很有效的一种提供量化反馈的机制。小团队就用低成本去做，大团队就可以建立数据指标中台、度量的模型等等，可以做得更复杂一些，挖掘出更多有价值的信息。

Q5：我们公司是做游戏开发的，因为规模的扩张，各种问题频繁暴露，比如缺陷猛增，需求量大做不完。如果想要现在开始引入效能度量，老师您建议如何着手开始呢？

张乐老师：你需要思考的最核心的问题是，当前这个阶段什么事是最重要的。比如，公司在快速发展期，或是要和另外一个产品 PK，需求需要最快速地被实现，那么是不是可以主动选择负债，承担一定的质量风险？如果当前产品最重要的是质量和口碑，那么缺陷的移除和控制就更重要了。所以，在某个时期内，一定会有一个最痛的点，这个最痛的点就是你的阶段性目标，有了目标再去找指标，这个问题就迎刃而解了。

Q6：如何解决开发提测质量差，测试漏测率高的问题？

张乐老师：建议从产品呈现出来的外部质量入手，关注线上缺陷情况，并针对缺陷分级进行根因分析，明确问题引入阶段和最有可能应该被检出的阶段。

基于以上的分析，可以重新检视现有质量守护的分级情况，分析每个层级是否拦截了该层级本应拦截的问题，并持续完善质量保障手段，如代码评审、单元测试、各类测试的设计及测试用例的补充等。同时也要注意向质量左移的方向演进，比如通过建设开发自测流水线、MR 流水线、集成流水线，在代码提交及交付过程的关键节点建立质量门禁，只有满足质量门禁的代码和制品才能往下游传递，从源头和上游保障质量。

Q7：变更前置时间是从开始编码到部署到时间差吗？如果是，那么「阿里的 211」代表一天的变更前置时间、「开始编码到部署」还是「完成编码到部署」？

张乐老师：有多种周期类指标比较容易混淆，包括需求角度的前置时间（Lead time）、周期时间（Cycle time）、流动时间（Flow time）、工程角度的变更前置时间（Lead time for changes）等，这些会在下次度量的课程中详细展开说明。具体到「变更前置时间（Lead time for changes）」，官方定义是从代码提交到部署到生产环境的时间，衡量的是工程角度的效率水平，如 CI/CD 流水线的能力和效果。

「阿里 211」中，第三个「1」的定义，准确来讲是「变更集成发布时长」，衡量的是代码完成后，从提交集成到上线的时间，期望中是 1 小时内完成，与「变更前置时间」基本是同义的。

ONES 研发管理大师课第一季课程还在继续，下节课我们再次邀请到张乐老师为我们详解基于流框架的价值流分析方法、价值流的五大流动指标，以及国内外大厂落地实践案例。快快关注 ONES 视频号，更多直播即将来袭！