腾讯茹炳晟：你可能对研发效能的度量有误解

作者｜茹炳晟

来源｜InfoQ

一、度量失败的案例

1. 历史上度量失败的案例

这张是英国街头房子的照片，这个房子非常有意思，它的窗户都被石头封掉了。这就是非常典型的由于度量指标选择不合理，从而引发不良行为造成度量失败的一个案例。

△ 英国的窗户税
这件事情要从英国的房产税开始讲起，最早英国收房产税是根据壁炉的数量来收的，但是收房产税的人要跑到房间内去看点壁炉的数量非常不方便，所以英国税务局的官员提议根据窗户的数量收取房产税。
一般的理解是窗户越多面积越大，房产税应该也收得越多，那么可想而知，当这个政策被推行之后很多房主为了节省房产税就把窗户给封起来了。所以这样一个度量指标一旦落实，除了房主买了更多油灯，堵了很多窗户，开天窗（roof window）逐渐流行，以及培养了整个的英国的照明业以及眼镜行业以外，英格兰的那些税收官们其实是一无所获的。
在我们的身边也有类似的案例，比如海底捞通过对用户展示无微不至的关怀从而取得了很好的口碑。

为什么海底捞的服务员能够给出这么好的服务呢？因为他们服务的一些单向点都被定义了，如果服务员做不到会被扣除服务分。比如客户杯子里的饮料低于三分之一了，服务员必须给用户赶紧加上；比如服务员必须给戴眼镜的客户眼镜布；比如客人有手机，服务员必须用塑料袋帮忙把手机装起来等等。这些单向点如果服务员做不到就会被扣分。
海底捞的 CEO 张勇制定这样的规则的目的本质上是为了让用户有更高的满意度，但是一旦把这种东西变成了一种对服务员的考核，直接体现在他的工资和绩效上的时候，服务员的行为就会变形。
比如客人已经吃完不想再吃了，饮料不需要再加了，但对不起，必须加满才能走，如果不加满可能就要服务分。可能顾客并不想用塑料袋把手机套起来，但对不起，必须套起来才行。原来应当是出于好心的行为最终变成了对顾客的骚扰，顾客可能会很失望。这个事情海底捞的 CEO 也意识到了，于是他说：“每个 KPI 的体系背后都会有一个阴暗面” 。
我们身边类似的案例还有很多，如果你对这方面感兴趣，给你推荐一本书叫做《指标陷阱》。它是从英文翻译过来的，英文原名翻译得更准确一点应该叫《指标的暴政》。

△ 指标陷阱
这本书的作者不是度量领域的专家，而是一位历史学家，一位历史学的教授。写这本书是因为学校引入了许多针对学生的度量，比如学生就业率的度量、学生薪资水平的度量，这种度量任务让老师疲惫不堪。这位作者从历史的角度去探讨了度量指标在美国的发展过程，总结了很多很有意思的案例，里面绝大多数都是失败的案例。
比如书中提到一个关于警务系统的例子。警务系统有一种根据犯人逮捕量来考核警务系统的指标，这个指标落地之后警察就不会劳神费力地去抓大毒枭了，而是每天抓几个街头上小马仔。因为警察知道一旦把大毒枭抓掉之后小马仔就就没有了，逮捕率就没有办法完成。所以为了让指标长期处于比较好看的阶段，警察就不愿意去抓大毒枭了。

2. 研发效能度量领域的失败案例

关于度量的研究近几年非常火爆，讲研发效能必然会谈研发效能的度量，软件研发领域有一个度量失败的案例是需求按时完成率。

△ 按需求完成率
这个指标在软件研发效能度量领域里也是一个非常常见的指标，但如果你不去提它就没有人关注它，一旦提了，这个指标很快都会变成 100%，所有的团队都会趋向完美。
但是，实际上最终需求的交付可能比原来还慢，原因是原本大家尽可能多做，现在用需求按时完成率来考核，相关人员可能会在定目标时偏向保守，原本可以做 20 个故事点，保险起见而留有余量，只承诺 15 个，甚至更低，这样一来，需求按时完成率就能达到 100%。实际效果可想而知，真正的业务的交付很可能会变得更慢。
还有一个典型的例子，在工作中我们会去推广单元测试，推了单元测试之后，如何知道单元测试做的完备性和覆盖程度怎么样？有的公司会通过单元测试执行之后的覆盖率指标进行度量。

△ 单元测试覆盖率
曾经我们用这个指标来度量团队的时候发现有些团队的单测的覆盖率挺高，但是实际上会发现它的单元测试用例里面都没有断言，他们只是为了这个覆盖率调用了被测代码，让它被执行到有覆盖率数据。在测试用例里面没有对预期结果进行任何断言，换句话说就是为了这个指标能上去编了一些为了指标而指标的一些行为。
这种行为浪费了工程师的时间也没能把代码写得更好，纯粹为了数据做得更好看，这样的度量毫无意义。
有些企业存在很多历史债务，补单元测试时很难去追究历史上遗留的 legacy code，可能只会抓新的代码去测试，因此会引入一种单元测试覆盖率，叫做增量覆盖率。也就是说会引入一种“不比原来差策略”，什么叫不比原来差呢？如果原来覆盖率只有 60%，增加新的代码之后，改动代码改动之后，覆盖率指标不能往下降，必须大于等于 60%。
这似乎是一个好指标，但是在实际操作过程中也会存在问题。有些工程师会采取一种投机取巧的方法，当新增的代码业务逻辑比较复杂，如果不做单测覆盖率上不去，他会选一些之前没有做单测的，非常简单的 get 和 set 方法写一些单测，让覆盖率不至于降低从而骗过系统。此时就失去了原本度量的意义。

3. 研发效能度量是手段而不是目标

度量这件事情很难做，永远不要把度量作为目标，度量只是手段，我们要清楚度量背后的意义。在做度量指标设计的过程中一定要考虑人性的因素，否则对研发效能这种看不见摸不着的度量就会带来很多不好的后果。
举个例子，请问你所在的公司或者你所在的团队当中谁是技术大牛？你脑子里肯定反映出一个人来，那么你以什么标准来度量大牛？你有度量标准吗？可能没有度量标准，但是谁是团队当中比较厉害的，技术比较牛的人，其实你会发现大家脑子里都有自己的一本账，这就是一种度量。这种度量客观吗？公正吗？公平吗？不一定，但是至少会有这样的度量的概念。
比如正在读这篇文章的人，我想度量一下你们的能力，给屏幕前的各位排个序，你认为能排出来吗？可能你是搞数据库的，他是搞前端的，另一个人是搞测试的，还有人是搞运维的，怎么度量大家的能力？其实能够度量，搞个度量排名，只要把每个人的年薪拉出来排排队就知道了。但是这个度量客观吗？不一定客观，但是从宏观层面来讲有一定的合理性。

二、研发效能度量的“第一性原理”

什么是研发效能度量的“第一性原理”呢？“第一性原理”就是从最底层的逻辑去看待事物，要拨开事物的表象看本质。我们很容易用比较思维思考问题，别人已经做过的事情或者正在做的事情我们也尝试去做，这是非常危险的，尤其是研发效能度量。
看到大厂或者行业内的标杆企业都在做度量我也跟风去做，往往会吃不了兜着走。原因很简单，大厂在做度量一定是想解决某些问题，如果没有看到他的问题，只看到他的行为，只去模拟他的行为是非常被动的，这就叫做比较思维。
正确的逻辑应该是先找到问题，再找到问题的解决方案。提出问题比解决方案更重要，不要手上拿着锤子看什么都像钉子，在研发效能度量领域里发现钉子的能力往往比锤子更重要。一个好的度量一定是回答了一个本质问题，并且能够为这个本质问题的解决引导出正确行为。
因此一个好的度量一定具有两个特征，一个就是能够回答一个本质问题，另一个是能够引导出正确的行为，两者缺一不可。但是要回答一个本质问题往往比想象得要难。

不知你是否去西贝餐厅吃过饭？顾客在西贝点完菜之后，服务员会在餐桌上放一个沙漏，沙漏倒计时结束如果还没有上菜，本餐可能会免单。很多人可能以为这样的设计是为了顾客考虑，好像挺人性化。但这种度量方式，这种对于上菜速度的度量方式真的是为了客户吗？它的第一出发点，它的“第一性原理”真的是为了客户的用餐体验吗？貌似是这样，但实际不是。
像这种餐饮类的企业，销售存在峰值效应，比如午高峰、晚高峰，餐饮类的企业要盈利，其实比拼的是翻台率。也就是说单位面积内盈利能力取决于一个餐桌在一个高峰时段能被重复用几次。
翻台率由两部分的时间决定，一部分是上菜速度，另二部分是顾客的用餐时间。想提高翻台率，让用户能够快速地吃完换下一波，这个过程当中只有一段上菜的时间是能够控制的。所以这种度量方式本质上是为了提高翻台率，而用户的满意度只是一个附带的效应。
刘润曾说局部思维的可怕之处在于能够用快意恩仇的方式赢得一场战役，却用悲天悯人的方式输掉整场战争。回答一个本质问题往往需要全局思维。

△ 能够引导出正确的行为
一个好的度量指标除了能够回答一个本质问题，还要引导出正确的行为。比如用平均缺陷修复时间替代千行代码 bug 率，能够引导出正确的行为，这就是比较好的指标。
在做代码静态质量分析时往往会用 Sonar 对代码的静态质量进行度量，我认为接入 Sonar 的项目数量就是一种虚荣性的指标，因为这个指标能引导出的行为是让更多的项目接入 Sonar。但是接入 Sonar 只是个手段，真正的好处在于接入 Sonar 之后发现问题，进行修复。

如果想把它变成一个可执行的指标，建议使用 Sonar 问题的增长的趋势或者 Sonar 严重问题的平均修复时间等等，这种指标才能引导出正确行为。问题有没有修、修的时间多长这类问题才能被反映出来，因此要尽可能把虚荣性指标变成可执行的指标。

三、关于度量的十条常见误区

用一个度量指标去考核个人时，永远不要去低估人们追求这些指标时的“创造性”。这个创造性当然是打了引号的，基本上度量什么就会得到什么，但是一定不是以你所期望的方式来得到。因此不要面向指标开展工作，而要看清这些指标背后真正的含义，或者说要解决什么样的本质问题。

我罗列了关于度量的一些常见的误区，叫做“度量十宗罪” 之避坑指南。现实世界的事物是复杂而多面的，度量只是从某个局部描述一个事物，是对一个事物的抽象，一种简化，所以从某种意义上来讲度量的结果一定是片面的，只能反映部分事实，关于度量是没有银弹的，更遑论完美的度量。

1. 使用容易获得量化指标

度量指标收集的难易程度不同，那些越容易收集的指标往往用处越小，比如代码行人天数、千行代码缺陷率等。越难以收集的指标的度量价值往往越大，比如产品用户价值、用户满意度，NPS 等等。人们总有一种天然倾向，就是把焦点放在那些比较容易获得的目标上，将其作为解决复杂问题的抓手，久而久之人们就只看那些数据，那些可量化的目标，忽略或者忘记了背后更大的目标。

2. 试图通过单一维度进行度量

看一下这张图，这是个圆柱体，看到方块是“真相”，看到圆形也是“真相”，但真正的真相是圆柱。我们看问题的角度决定了我们看到的“真相”。
对于研发效能的度量也是如此，因此度量研发效能尽可能采用雷达图，从问题出发，找出能够反映这些问题的一些指标的集合，把这些指标集合拼成一个雷达图，从多方位多角度客观地审视这个问题。设计得比较好的度量指标一定是相互牵制的，人为可能“粉刷”某些指标，但很难做到所有的指标同时被粉刷，当粉刷某些指标时，其他指标会把你出卖，这样一来度量目的才比较容易达到。

3. 研发过程数据采集需要依赖人工录入

采用人工录入是非常坑的一个点。大家可以看一下这个在敏捷里面的一个燃尽图，理想情况下燃尽图应该随着时间的推移往下降，但是实际大家在工作当中能看到的燃尽图都是前面不变的，到最后一天一下子降下去了。原因就是任务完成后数据没有及时更新，为什么没有及时更新？因为需求状态的流转是靠人工录入的，这种情况下获得的度量数据全部失去了原始的意义，全部失真了，没有任何实际价值。

4. 将度量与个人 KPI 绑定

法则表明如果去度量工人生产钉子的数量，得到的是一堆小钉子；如果度量钉子的重量，得到的就是几颗大钉子。也就是说 Goodhart 法则告诉我们，你度量什么就会得到什么，但是一定不是以你所期望的方式来得到，尤其是将度量和个人考核绑定的时候。因此永远不要纯粹面向指标去开展工作。

5. 盲目建立度量数据中台

度量是有成本的，通过海量数据获取或使用大数据分析挖掘信息的成本往往很高。研发效能领域里面有太多可以优化的地方，有很多地方甚至不需要大数据，一线工程师、一线的 Tech Leader 或者一线的技术管理者其实都知道问题大概在哪里。
相比于建立一个大而一统的花里胡哨的看板数据中台，具体问题具体分析的实际效果要更好一些。这种数据中台在大厂里容易犯错误是因为在大厂里有一种叫做面向老板的编程。老板要一个数据，要有一个总的驾驶仓图，所以我们所谓的投入就投入在面向老板的编程里。这是很危险的，虽然研发效能的结果是为老板服务的，但是研发效能的过程要为工程师服务。

6. 忽视度量的滞后效应

度量有一个非常明显的滞后效应。采取度量措施之后，通过度量指标反馈出来需要很长时间。这往往会让原来明明是正确的措施，由于反馈周期过慢使得对原来的措施失去信心。作为管理者对于度量指标的反馈周期要有一定的耐性。

7. 业务还没搞起来就开始搞度量

还有一个常犯的错误就是业务还没搞起来就开始做度量了。这通常发生在大厂的人空降到初创团队时，业务永远是王道，业务没有搞起来任何度量都是多余的。在初始阶段以“快超猛”的方式对商业模式进行验证才是王道，度量可以慢慢来，先野蛮生长，让子弹飞一会儿再做度量。

8. 忽视工程师的主观感受

研发效能是为工程师服务的，不要面向老板编程，不要忽略工程师的主观感受。凡是忽略工程师直观感受的度量往往很难取得实质性的成果。研发效能提升过程中永远不要忽视“人”的重要性和决定性因素。

9. 高层过多地关注下层目标

高层过多关注下层的指标也是一个危险的信号，但是下层应该更多地关注高层的指标。高层如果不往“外”看，而是一味地过度关注内部的各种指标往往是业务开始走下坡路的一个信号，用现在流行的话来讲就是“内卷”了。但是反过来下层应该需要时刻关注上层的目标，这样才能让高层的目标能够顺利落地，用现在流行的话来讲这个就是对齐 OKR。

10. 人天 vs 故事点应该选哪一个

度量时到底应该用人天还是故事点进行估算？因为人天是时间单位，而故事点数是工作量的单位，两者其实不能画等号。
以搬砖为例，一百块砖是工作量，我去搬一天只能搬一百块，要十天才能搬完，我来干是十个人天。如果我找一个工人来干，他一天可以搬五百块砖，两天搬完，两天是他的人天。那么这个工作量到底是两个人天还是十个人天？显然工作量是这一千块砖。
所以人天和故事点能够对应起来的时候，就假定了一个前提——工作速率是恒定的。但每个工程师的工作速率一定不是恒定的，工作速率一定受他的心情、工作的上下文、工作的难易程度和工作的熟悉程度影响。因此在做敏捷实践时，这种度量选用故事点，而不用人天。

四、研发效能宣言

我们一直在追求达到更高的研发效能，可以更高效、更高质量、更可靠、可持续地交付更优的业务价值，身体力行的同时也帮助他人。因此提出了如下价值观：

△ 研发效能宣言
最后，无论是研发效能还是研发效能度量，通常来讲困难的路会越走越简单的，但是简单的路一定会越走越困难。以上就是本文的全部内容，你有没有踩过研发效能度量的坑呢？欢迎在评论区留言。作者简介
茹炳晟腾讯 Tech Lead
业界知名实战派研发效能和软件质量双领域专家，中国计算机协会 CCF TF 研发效能 SIG 主席，腾讯研究院特约研究员，腾讯云、阿里云、华为云最具价值专家，Certified DevOps Enterprise Coach，年度 IT 图书最具影响力作者，畅销书《测试工程师全栈技术进阶与实践》、《软件研发效能提升之美》、《软件研发效能提升实践》和《高效自动化测试平台：设计与开发实战》作者，极客时间《软件测试 52 讲—从小工到专家的实战心法》专栏作者。
- End -

精彩回顾