9月7日，ONES 研发治理巨匠课第四期课程正式开课，腾讯 DevOps 与研发效力资深技术专家张乐老师分享了《研发效力度量的行业趋势及五项精进》。借助效力度量的「五项精进」，分析研发团队效力瓶颈问题，助力企业更好更快地晋升研发效力。
以下是张乐老师分享的核心内容。
研发效力数字化是现在这个时代必须要做的事件。如何开始呢？要从无效的度量开始。咱们在议论效力度量的时候，应该分不同的档次来思考问题。请看下图的「DIKW」模型：
这个模型能够帮忙咱们很好地了解数据、信息、常识和智慧之间的关系。最上层是「数据」，数据是对物理世界的刻画，代码提交的原始日志、需要流转的信息等这些都是数据；有些数据须要通过甄别才领有价值，所以第二层咱们把它称为有价值的「信息」；如果只有全面的信息还不够，并不足以去答复一个简单的问题，咱们须要再把多种信息进行聚合加工，辅以分析判断，达成了解，这就是第三层「常识」；然而，咱们最终目标是做出效力改良，所以在多个常识的积攒之上，咱们使用专家的教训来生成解决方案，把常识聚合成最上层的「智慧」。
所以，一句话总结，数字化就是从物理世界中，开采出数据，粗炼出信息，精炼出常识，聚合出智慧，最终进步生产力。
价值流剖析的五大流动指标
研发效力数字化须要无效的效力度量，没有度量，就无奈改良和治理。接下来，咱们来看看价值流剖析的五大流动指标，别离是流动效率、流动工夫、流动速率、流动负载和流动散布。
- 流动效率，用增值的工夫除以总工夫，能够算出流动效率这个指标；
- 流动工夫，指的是从需要被接管到交付的整体周期；
- 流动速率，其实也就是吞吐量，指的是单位工夫内可能实现多少无效的价值交付；
- 流动负载，指的是咱们在交付管道里并行在做且尚未实现的工作项数量；
- 流动散布，能够掂量一个团队中不同工作的散布，比方调配了多少比例做业务需要、多少比例解决缺点或技术债权等。
对于这五大流动指标，咱们在下期课程里，会有用一整节课做具体的拆解以及讲述具体的分析方法，敬请关注下期课程。
ONES Performance 效力治理
要想做好研发效力，好的工具是必须的。ONES 开发了效力管理工具：ONES Performance，它的设计逻辑十分清晰。对于度量，咱们除了思考指标，也应该思考场景，而场景是更要害的。也就是说，这个指标是给谁用的？给老板用，给 PMO 用，还是给研发用？每个层级关注不同的指标，它的应用场景也是不一样的。
ONES Performance 笼罩了效力治理全场景，为团队效力改良提供数据撑持，无效地帮忙团队进行效力的继续改良。
效力度量的五项精进
研发效力度量的五项精进是效力度量的施行框架。
- 第一项，建设度量基础设施，把价值流网络建设起来；
- 第二项，建设度量指标体系，比方后果指标、过程指标、先导性指标、滞后性指标等；
- 第三项，洞察分析模型，对绝对简单的问题进行度量剖析；
- 第四项，洞察产品建设，化繁为简，用产品帮忙咱们屏蔽底层实现复杂性，间接出现用户论断和剖析；
- 第五项，数据驱动，通过试验思维让效力度量不跑偏。
接下来，咱们来顺次看看这五项精进的具体内容吧：
（1）建设度量基础设施
首先咱们要建设一个度量的底座，但这个底座不仅仅是所谓的数据仓库，而是要承载更多的能力。咱们把它分为三层：工具网络、工件网络和价值流网络。
工具网络的节点是每一个单点工具，比方管需要的工具、管代码的工具、管 CI/CD 工具，把这些工具通过相干的接口连接起来，做到互联互通；工件网络指的是咱们在工具上产生的制品（需要、代码、制品包、流水线等）是否能够相互连接；价值流网络是指将工具和团队中流动着的工作，与业务级产品进行对齐。这也正印证着梅特卡夫定律：一个网络的价值随着其连通性而增长。
（2）建设度量指标体系
咱们来看看下图的指标全景图，我设计的初衷是想把要害的度量指标组织进一个正当的构造。基于价值流的度量，研发过程能够分成交付效率、交付品质和交付能力这三个维度，还有业务后果的维度；研发阶段能够分为需要阶段、开发阶段、测试阶段、公布阶段、经营阶段。所以，这张图是基于二维图形造成的指标矩阵，是我在2019年首次分享进去的，行业外面也常常援用。
起初，我发现有的公司曾经有成千盈百个指标，他们并不知道重点指标应该在哪里。所以，我将指标全景图进一步降级，不再谋求把每个要害指标都列举进去，而是建设一个结构化的模型——度量指标的 Cube 模型，把度量指标分成不同的档次，从多个维度更好地进行刻画和阐释。
这个模型不是一个立体，而是立方体，咱们把两头蓝色这个点作为抓手，从图里往外拉，能看进去它其实是个立方体，它有「后果面」和「过程面」。从「后果面」咱们须要关注的，别离是价值、效率、品质和老本，能够概括为咱们常常说的「多、快、好、省」。这外面有很多后果性的指标，比如说需要交付周期、需要吞吐量、线上缺点密度等等。所以，「后果面」是后果导向，对整个研发价值有着牵引和导向作用。为了达成后果指标，咱们还有很多过程性的工作要做，所有也要看「过程面」，比方合作能力、工程能力、技术能力和组织能力的晋升。
综上，咱们要基于后果指标做整体的疏导和驱动，通过过程指标的细化和剖析，去驱动具体的改良流动。
（3）洞察分析模型
下图是 GQM（Goal、Question、Metric）分析模型，它的基本思路是：数据的收集和剖析要聚焦于清晰具体的指标，紧接着每个指标划归为一组可量化答复的问题，每个问题再通过特定的指标来阐明。所以，GQM 分析模型肯定要向指标去对齐，做到以终为始的度量。
然而，做效力度量不能光思考指标，所有的度量分析方法应该烂熟于心。
这里的分析方法我列举了十二种，咱们先来看以下几个比拟常见的：
第一，趋势剖析。研发效力有一句话是「趋势大于绝对值」，咱们要做的是向量的度量，而不是绝对值的度量。所以，咱们察看的是增量和稳定，是变动和趋势，这个比绝对值更重要。
第二，组成剖析。比方，需要交付周期是20天，咱们就能够看到工夫都花在哪里，在哪个阶段破费的工夫最长；同时，也能够帮咱们剖析出在什么中央会爆出研发瓶颈。
第三，奉献分析法。这能够帮忙咱们防止「平均值陷阱」，咱们要基于不同的剖析维度做进一步分析，找到对后果正/负向稳定影响最大的因素，而不要只看平均值。
第四，帕累托剖析。也被称为要害多数法令。指的是事物的次要后果很可能只取决于一小部分因素，外围在于要找到「要害的多数」，这才是优化、晋升的空间。
第五，累积流图剖析。累积流图反映很多信息，比方交付周期、在制品，交付速率以及团队的各个角色之间配合合作的模式等。
（4）洞察产品建设
我认为产品建设适宜有肯定规模的企业去运作，因为做起来是比拟有难度的，有的大厂甚至长年投入几十人研发和保护效力度量的工具零碎，如下图：
最上面一层是数据的仓库，咱们要把数据从数据源采集进去汇总到数仓，建设数据模型，同时对源数据和指标做一些灵便的配置；再往上顺次是接入层、利用/产品/性能的展现、服务能力；最下面一层是指标用户，效力度量的工具产品肯定要思考指标用户，面向管理者、研发负责人、研效专家或一线工程师的场景都是不同的。
（5）数据驱动，试验思维
研发效力的晋升不来自于度量自身，而来自于针对性的改良。对此，我总结了五个步骤：
- 第一步，明确一个改良指标；
- 第二步，通过洞察挖掘出价值流中可能的瓶颈；
- 第三步，抉择研发效力地图实际中适当的实际（巨匠课第一讲中有过具体介绍）；
- 第四步，从小范畴开始，纵向进行试验；
- 第五步，判断试验后果是否无效，如果无效，造成标杆效应。
在以上五个步骤也蕴含了四个关键点：
- 一次只解决一个问题；
- 零碎思考，以整体形式思考束缚；
- 明确范畴、工夫、度量指标、胜利规范；
- 基于数据的证据，继续试验。
– 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 视频号，更多直播行将来袭！
发表回复