有度量才有真管理 研发效能的度量体系建设实践 | GTLC南京
演讲嘉宾 | 陈东
责任编辑 | 何坤
视频编辑 | 李傲
近两年，互联网行业的增速明显下降，无论公司规模大小都有一个共同的诉求，就是如何降低研发团队的成本并增加效能。
今天我会围绕《研发效能的度量体系建设实践》这一话题，将自己带领不同规模研发团队所积累、沉淀下来的思考和实践，从度量体系对于研发效能的意义、度量体系的建立原则、度量体系的架构设计与案例、度量体系的系统运营，共四方面为大家进行分享。
提高研发效能的方法非常多，比如引入先进工具、优化工作流程和调整组织结构等。不过无论用什么方法，最终都要回答一个问题：研发效能提升了吗？提升了多少？如果回答不出这个问题，前面许多的工作是无法证明它的价值。因此，研发效能的度量很重要。
管理大师彼得·德鲁克讲过，“没有度量就没有管理。”管理者的一项重要职责，就是思考如何做好度量，以及基于度量做决策。
然而度量并不好做，为什么？因为没有理解度量体系建设的本质——研发管理思维的数字化转型。很多研发团队的管理者主要凭借主观感觉来对团队成员进行度量，对研发团队的能力，缺乏量化、数字化的判断标准。大多研发团队都是在帮公司做各种业务的数字化转型，但其自身工作方式却是“拍脑袋”决策，从这个角度来讲，不做度量体系管理的研发团队，就是公司数字化转型的最后一块短板。
度量体系建设的目的是在帮助公司进行数字化转型的同时，实现研发团队的数字化转型；研发团队不能只知道埋头苦干，还要学会“抬头看天”——团队开工前定下度量体系的原则指引，以免团队之后的工作变形。
原则二，以团队主要工作流程为线索，建立研发流程的度量。度量体系指标选取选取逻辑是以团队的主流程为线索，从主流程选指标来搭建研发效能的度量体系。除主流体系的之外的其他指标都不是重点指标。
原则三，度量体系需要有层次，不同的人关注不同的指标。整个度量体系指标需要有层次，不是简单的指标罗列，因为不同的人关注不同的指标，所以要对指标进行分层。
原则四，度量体系需要不断迭代。这与原则一相关，度量体系的指标要反映客户的痛点，若痛点解决了，这个指标就没有必要考核了。接下来，还需要去思考当前的痛点是什么，指标权重和考核方式是否要做修改，整个指标体系处于不断地迭代状态。
有了上述四点原则做支撑，如何进行下一步实施呢？具体分三点：第一，度量体系的指标选取；第二，度量体系的分层架构；第三，度量指标的几个讨论案例。
度量指标的选取维度。比如，如何判断一个团队好不好呢？答案是“多快好省”，这四个字基本上可以覆盖大部分对研发团队研发效能的要求。进一步来看，“多”对应“产能”，“快”对应“响应力”，“好”对应“质量”，“省”对应“成本”，因此产能、响应力、质量、成本就是对研发团队进行度量的四个维度。
但是四个思维没有必要全做，可以排优先级的。根据第一个原则：要以客户的价值为导向。研发团队的客户是谁？是业务团队 。业务团队关心研发团队的“响应力”、“质量”和“产能”，对这三个维度再排优先级，则是质量第一，响应力第二，产能第三。
为什么质量是第一？可以反过来思考，如果质量不好，响应力越快，产能就越高，线上的 Bug 就越多。当 Bug 增多时，线上系统就会呈现崩溃的状态。这说明，没有质量保障的产能是无效的；而从另一个角度来看，若产品质量做得好，会间接促进响应力和产能的增长，因为工程师从线上紧急问题响应环节节省的时间，可以投入至原来规划的研发工作，更好保证了响应力和产能的提升。
但是只选质量这个维度是不够的，因为它太片面了，也不是客户唯一需要的。研发团队要将质量和响应力两个维度同时做起来并做得足够好，才能最小化的满足客户痛点。
如何具体设计指标。设计指标需要分层的思考，因为不同的人关心不同的指标。比如对外进行交付，业务团队关心的指标比较简单，我们列出了两个大类、四个指标。在响应力维度，关注需求的按时完成率和需求交付时长；在质量维度，关注故障的数量和故障时长。对外交付的研发项目指标不需要太复杂，掌握四个核心指标就可以。
真正复杂的是对内面向过程管理的指标设计，如何拆解上述四个指标、指标落地路径如何实现，才是研发效能度量体系建设最重要的环节。因为上述四个指标不是可以轻松达成的，并且四个指标中至少有存在两个明显问题。
问题一，在需求交付时长上存在度量是否精准的问题。需求从提出到上线之间经历的环节众多，有非常多的角色和岗位都在参与，甚至有来回拉锯的情况，因此如何定义需求的交付时长存在问题；此外，不同需求的颗粒度也是不同的，有的需求可能要花一个月交付，有的需求花一天就可以，因此需求的力度如何度量准确也存在问题。
问题二，在故障数量上存在指标稀疏和指标滞后的问题。根据经验，每一个研发部门，每季度的故障数一般是 0 到 1，表现差一点会到 2；如果一个部门的故障数量按季度统计的话，可能就是 0、1、0、1，这样的数据是没有统计意义的；还有，如果一个季度中的前 2 个月一直没出事故，但这时就能保证质量真的好吗？不一定。如果只是简单看“零事故”这个指标，而不做任何的管理动作，是存在隐患的。当事故真正发生时，再做任何的事情这个指标也已经改不回来了。滞后性的指标，没有办法进行日常的优化。因此，如果做不好内部的管理拆解，就很难向业务团队保障最终的响应力和质量的交付。
对内的度量体系指标的设计方面，可以先将需求、设计、开发、测试、发布、运维主流程拉出来，在主流程中看每个环节的响应力和质量，这是选取指标的核心的逻辑，像是考勤、满意度考评这些指标都不需在考察范围内。
研发流程支撑指标众多，也不一定都有效。首先，从需求角度来看。理想的度量区间，是从业务开始提需求到最终发布。但是现实往往只能度量和管理设计和开发这两个环节。前面的需求环节，因为有大量的与业务团队来回拉锯讨论的时间，所以只能观测不能考核。后面测试的环节需要在测试环境里去进行验收，只要没有验收通过，是不会往下发布的。所以，为了让整个的研发效能的流程和度量的区间变得更加合理，我们做了以下改变。
第一，提供了一个预发环境，将业务验收环节从测试环境中剥离。测试环境完全回归到研发团队里，把可控的度量空间延长，从设计、开发、测试延长到了预发部。对于头尾两部分，业务的验收和前面需求的沟通是作为观测指标进行观察，虽不考核研发团队但会进行分析，以及与业务团队沟通，使整体效能有更大的提升；第二，对于“需求颗粒度”不一致的问题。我们把需求拆解成不同的 Story，通过考核 Story 的交付时长，相对统一了考核口径，使得交付时长的统计数据也变得有意义。
接下来是工程师开发。工程师开发中有一个经典指标叫“缺陷密度”，公式为：加权的缺陷数 / 代码行数 = 工程师的缺陷密度，意思是代码写得越多，缺陷数可能会越多。但是如果按这个指标的设定，会存在有效的代码行数定义不清楚，以及工程师没有动力优化代码，对团队带来负面导向。
业界还有一个更成熟的理论，即不考量代码行数，转而考量“功能点数”，公式为：加权的缺陷数 / 功能点数 = 工程师的缺陷密度。但是这个考量方式需要人工预估功能点数，若没有专业的人员去做功能预估，是会耗团队工作量，在实际操作中不一定对所有的公司都适合。
因此我们最终采用的是第三个方案，我们用“工作量”来代替，公式为：加权的缺陷数 / 工作量 = 工程师的缺陷密度，工作量指工程师登记的工作时长。其优点在于它相对比较简单，工程师可以自主提交工作时长。当然也可能存在填写时长过长的问题，不过这一弊端有制衡的因素，如果把工作量填得很大，那响应和交付时长就会变长，从而影响产能，这一制衡因素可以避免做假和偏移的情况出现。
下一个环节是测试。测试有一个经典指标，叫缺陷逃逸率。公式为：缺陷逃逸率 = 生产缺陷数 / （测试缺陷数 + 生产缺陷数）），但是这个公式会把刚才提到的预发环境和放 10-20% 的流量的灰度环境跳过了，只能看到生产环境的缺陷。而前两个环节，发现问题概率是最大的。
因此我们重新定义了一个发布缺陷数的概念：发布缺陷数 = 验收缺陷数 + 灰度缺陷数 + 生产缺陷数，只有把所有客户感知到的环节记录下来作为分母，才能更好的反映我们的客户价值。因此缺陷逃逸率公式变成，缺陷逃逸率 = 发布缺陷数 /（测试缺陷数 + 发布缺陷数）。
最后，故障数量的改进。对于内部团队而言，考核的是事件处理，而不是事故本身。团队每周都会接到告警、业务反馈的线上问题，这些告警和线上问题不一定是事故，但的确是反映了当前系统的问题。对于每周都会发生的事情，我们会进行相关的响应力和质量进行考核，每周也都会对上一周的事件进行复盘，把对事故的管理转变成对事件的管理。
总结一下，度量指标需要客观反映现状，避免主观打分；度量指标尽可能在前后环节、响应力和质量之间有制衡；度量指标需要尽可能覆盖全流程，避免只关注拒不缓解；度量指标需要可频繁观测，指导日常工作。
再次强调一下度量的重要性。提升研发效能方法非常多，比如培养团队的研发能力、流程优化等，这些事情都可以做，但是很漫长。最简单、快速、有效的方法，就是把度量指标定义和调整好。只要大家能看得到正确的度量指标，团队自然有动力和方向去优化自己的研发效能。
上述所讲都是度量体系如何建立，它只是一个模型，真正运行还需要系统支持，所以要做系统化、做自动化、做可视化。
我们打造的这套系统，拥有底层的基础系统层、中间的逻辑层以及最上面的展示层，通过这套系统，可以更便捷地使用和管理数据。
这套系统能够实现一定程度的自动化数据采集、数据分析以及自动化运营。如果没有做好数据自动化采集，整个体系是建立不起来的。必须基于底层研发工具，自动抓取工程师在这个上面工作的时间和状态，实现自动化采集数据。对于自动化运营的思路是，当指标发生偏离的时，主动去告警和推送。
在整个体系的日常运营管理上。要明确责任主体，即谁为研发效能指标负责。我们定义的主体是研发部门，让部门承担这个指标，不考核个人。如果考核个人，个人就有可能对这些指标动手脚，因为所有的数据都是由工程师在工作中产生的，如果知道这个指标会直接考核到他的绩效，就会基于数据本身做优化，而不是基于事件优化，所以我们不考核个人。
另外，日常运营中要周期性跟进。每周把数据贴出来让大家看，然后进行考评，自然而然整个团队就会投入更多关注，会做得越来越好。
最后，指标是要迭代的，只有不停的更新迭代，才能不断的进步。如果不去迭代、更新这些指标，最后很可能是每个季度的考核都是一百分，失去了度量地意义。所以，度量指标一定要调整，并聚焦在做得不好的地方。
最后我想用一句话来结束今天的演讲：度量是为了改进。要以客户价值为导向，体现当前痛点，才能找到正确的前进方向。感谢大家的聆听！
TGO 鲲鹏会是极客邦旗下科技领导者聚集和交流的组织，学员由 CTO、架构师、技术 VP、具有技术背景的 CEO 等组成，目前已经在北京、上海、深圳、广州、杭州、成都、硅谷、南京、台北、厦门、武汉、苏州等 12 个城市定期举办学习活动。
TGO 鲲鹏会采用了“学员共建”的组织形式，希望通过“共建、自治”的方式维护各城市的健康发展，为学员提供必要的服务，帮助学员个人更好地学习和成长，助力学员企业之间更好地合作与交流。加入 TGO 鲲鹏会，全方位提升自身价值，成为卓越科技领导者！
点击阅读原文或扫码加入 TGO 鲲鹏会！