审校 | 蔡芳芳

作者 | 茹炳晟

腾讯 T4 级技术专家，腾讯研究院特约研究员，业界出名实战派研发效力和软件品质双领域专家。腾讯云、阿里云、华为云最具价值专家，Certified DevOps Enterprise Coach，年度 IT 图书最具影响力作者，多本技术畅销书作者，极客工夫《软件测试 52 讲》作者，新书《软件研发效力晋升之美》也行将出版。屡次负责国内各大技术峰会的联席主席、出品人和主会场演讲嘉宾。

前段时间我写了一篇文章《如何用研发效力搞垮一个团队》引起了业界同行大量的探讨与关注，明天想持续聊聊研发效力晋升过程中另一个话题：“度量”。探讨度量的目标不是争执对错，而是心愿可能引发大家对这一话题的深刻思考。

1 度量失败的案例

首先来看一个因为度量体系设计不当而引发“内卷”等不良行为的案例。

比方以“点击量”来度量自媒体经营的成绩，那么就有可能呈现点击量显著晋升，然而公众号的关注人数却降落的景象。起因就是应用“题目党”等伎俩诱骗读者关上链接，然而理论内容徒有虚名，几次之后读者就不会持续关注该公众号了。

2 时代变了，很多事物底层逻辑都变了

明天的度量为什么容易失败呢？正如我在之前那篇文章中提到的，面对改革，最重要的并不是办法和技术的降级，而应该是思维模式的降级。咱们身处数字化的改革之中，须要将工业化时代科学管理的思维彻底转为字节经济时代的全新思维。

对于软件研发效力的度量，咱们绝大多数时候还在用工业化时代造成的治理理念来试图改良字节经济下的研发模式。但时代变了，很多事物底层逻辑都曾经变了，工业化时代造成的科学管理理念在字节经济的明天是否还仍然实用？值得沉思。

本文将站在软件研发效力的视角，来探讨字节经济时代下研发效力度量中几个必须要答复的问题：

• 研发效力到底要不要度量？
• 研发效力到底能不能度量？
• 研发效力到底如何来度量？
• 研发效力的度量指标如何来选取？

3 研发效力到底要不要度量？

要。这个问题的答案不容质疑。

古代管理学之父 Peter Drucker 说过，“没有度量就没有改良”，这一底层逻辑从头至尾都没有变过，只是工业化时代的度量和字节经济时代的度量在理念和办法上会有很多不同的中央。

度量对于研发流程改良的意义十分明确 。工业化时代的实体产品研发与生产，其中的危险是绝对显著的，比拟容易找到防备的办法，也分得清相干的责任。然而字节经济时代的软件产品研发（曾经没有了生产），是通过越来越多工程师的数字化合作来推动的。 参加研发的人越多，人与人之间的沟通老本越高，产生随机偏差的概率也会越大，再加上软件研发过程自身的可视化水平很低，危险的可见性就容易被各个环节覆盖，但它最终会在看不见的中央积攒起来。如果没有适当的度量体系去显性化这些危险，后果可想而知，更不必谈什么继续改良和治理了。

度量对于人的公平性诉求也是必须的。“我尽管没有功绩，然而我也有苦劳。”大部分人可能只关注本人的付出，但并不关怀付出所取得的实际效果。作为管理者应该为“苦劳鼓掌，为功绩付钱”。而功绩和苦劳的体现也须要借助主观的度量数据来体现，否则团队中的成员会逐步陷入碌碌无为的困境。

4 研发效力到底能不能度量？

明确了研发效力必须度量之后，咱们再来看看一个更理论的问题：研发效力到底能不能度量？“要不要”和“能不能”是两个层面的问题，“要”不示意“能”，就像“我要赚钱”和“我能赚钱”是截然不同的两个问题一样。

对于这个问题，业界有两派截然不同的观点，一派是以古代管理学之父 Peter Drucker 的实践为根据，主张研发效力可能度量的；另一派是以世界级软件开发巨匠 Martin Fowler 为代表，主张研发效力不可度量的。

在这个问题上，我的观点比拟中庸，我认为可能度量，然而没有完满的度量。起因有以下几点：

4.1 度量自身的片面性无奈防止

事实事物简单而多面，度量正是为形容和比照这些具象事实而采取的形象和量化措施，从某种意义上来说，度量的后果肯定是全面的，只能反映局部事实。

管理者往往会把指标拆解为可度量的指标。然而，指标和指标经常并不是简略的全局与部分的关系。指标的拆解过程看起来很顺畅，是那么地天经地义，然而当把拆解完的指标合并起来的的时候，后果往往让人啼笑皆非。

有一个笑话说的是，“你问人工智能，我要找一个女朋友，像赵薇一样的大眼睛，像朱莉娅·罗伯茨一样的大嘴，青睐静止，陆上静止、水上运动都会。人工智能就依据这几个指标给出了母青蛙的答案”。所以，指标和指标经常并不是充沛必要的关系。

4.2 度量过程容易陷入部分思维

指标是为了实现目标的，然而在实际过程中，指标很多时候却是与指标为敌的。

管理者经常把指标拆解为指标，工夫久了当前，他就只晓得指标，而忘了背地更重要的指标。如果指标是林，那么指标就是木，工夫久了就是只见树木，不见森林。这个时候遗记了指标是什么的管理者就会变得十分短视。那些不懂数据的人很蹩脚，而最最蹩脚的人是那些只看数字的人。

在福特汽车的发展史上，有一段至暗期间。那些实践经验丰盛，然而没有上过商学院的的老一辈管理层被干掉，取而代之的名校治理背景的数据分析师，公司试图通过精细化的数字治理来实现业务的增长。因为这些数据分析师并不熟悉业务，所以就只能看度量数据，越是不懂业务就越依赖度量数据来做决策，最初使整个公司陷入了泥潭。

软件研发也有相似的难堪，为了更好地代码品质，所以就制订了严格的代码测试覆盖率要求。工夫一久，大家都机械性的谋求这个指标，而遗记了过后设立这个指标的初衷，于是就呈现了高覆盖率的大量单元测试中没有断言这样难堪的场面。

4.3 度量数据的解读具备很强的误导性

度量数据自身不会骗人，但数据的出现和解读却有很大的空间能够利用。很多时候，同样的数据，通过不同的解读会疏导出截然不同的后果，这点很容易被人为利用来达成各自的目标。

举个例子，有钻研人员问承受调查者一个问题：如果你得了绝症，有款新药能够治愈，然而会有危险，20% 的服用者可能因而而丧命，你吃吗？大多数人会抉择不吃。然而如果反过来问：如果你得了绝症，有款新药可治愈 80% 的患者，但此外的人会死，你吃吗？绝大多数人会抉择吃。实际上这两个问题的根本数据是一样的，然而失去的答案却相同。起因很简略，在后面的问题中，强调的是“失去”，在前面的问题中，强调的是“取得”。人的本能会更喜爱“取得”，而不是“失去”。

研发效力畛域也有很多相似的案例，雷同的数据到了不同的人的嘴里就有了截然不同的解读，由此做出的决策也会不同。

综上所述，我认为研发效力到底能不能度量是要基于场景的，脱离了场景去谈能不能度量没有太大意义。就像没有什么货色实质上就是脏的，是放错了地位的货色才是脏的。饭菜，在碗里就是洁净的，泼到了衣服上才是脏的。泥土，在花园里就是洁净的，抖落到了床上就是脏的。

5 研发效力到底如何度量？

那么研发效力到底如何度量，以下是我的一些想法。

5.1 要聆听管理者的度量诉求，然而不要照着做

在汽车还没有被创造的时代，你问马车用户，你要一个什么样的交通工具，很有可能失去的答案是“更快的马车”，如果你按着这个思路去做的话，就会陷入钻研马蹄设计、马饲料优化的误区，就不会有汽车的创造了。很多时候用户通知你的需要往往都只是自以为是的“解决方案”。

当管理者通知你我要这些度量数据、我要那些度量数据的时候，你不应该一头扎进数据获取的细节中，齐全按管理者通知你他想要的去做，而是应该从 实质下来了解管理者想要看这些数据背地真正的动机，管理者通过这些数据到底是想解决什么样的问题。要了解管理者的深层次需要，这才是问题的实质。只有这样才有可能在此基础上给出绝对完满的度量计划。

5.2 度量应该是有层级构造的

高层管理者、中层管理者和一线工程师关怀的度量维度必定是不一样的。不要试图去提供一个看似大而全的度量体系，当你的度量体系能服务于所有人的时候，恰好意味着它什么都不能。

比拟现实的做法能够参考 OKR 的实际。先由高层管理者制订度量体系的总指标，而后中层管理者分解成可执行可量化的指标，最初再由一线工程师分解成工程维度的的指标。各个层级只关怀以后层级的指标以及上一层级的指标，不应该呈现高层过多、过细地关注上层指标。

5.3 度量的设计指标是要可能疏导出正确的行为

度量从来不是目标，而应该是实现目标的伎俩。度量是为目标服务的，所以好的度量设计肯定对目标有正向牵引的作用，如果度量对指标的负向牵引大于正向牵引的话，这样的度量实质上就是失败的。

举个例子，当初国内很多软件企业都应用 Sonar 来实现代码动态品质的把控，为了推动 Sonar 在团队内的遍及，不少企业会用“Sonar 我的项目接入率”这样的指标，也就是有多少百分比的我的项目曾经在继续集成 CI 中启用了 Sonar，来掂量动态代码查看的普及率。这个指标看似中肯，实际上对于实现最终目标的牵引力是比拟无限的。应用 Sonar 的最终目标是晋升代码的品质，只是接入 Sonar 并不能理论改善代码的品质，而且还容易陷入为了接入而接入的指标比赛。了解了这层逻辑，你会发现应用“Sonar 重大问题的均匀修复时长”和“Sonar 问题的增长趋势”其实更有实际指导意义。

所以，一个好的度量，肯定要为解决实质问题服务，并且要可能疏导出正确的行为。

5.4 切记不要基于“比拟思维”而采纳“追星式”的度量

咱们看到一个人取得了胜利，就会立即认为他过来所有的行为都是那么地有情理。咱们看到一公司取得了胜利，就会感觉他们采取的策略和工程实际是如许无效。这正是“比拟思维”的可怕之处。实际上，没有哪家企业是通过盯住竞争对手而获得成功的。

OKR 在 Google 的胜利利用使得很多公司对此实际趋之若鹜，然而通过应用 OKR 取得成功的企业又有多少？这种“追星式”的度量只能让你陷入更深的内卷。

对于研发效力的度量体系，切记不要自觉生吞活剥“大厂”所谓的最佳实际，也不要拿本人的度量实际去和大厂的比拟，你们的上下文不同、组织生态不同，这药给大厂吃能够治病，给你吃可能致命。

5.5 度量不要广撒网，而应该精准捕捞

不要在没有任何明确改良指标的前提下发展大规模的度量，因为度量是有老本的，而且这个老本还不低。很多大型组织往往会花大老本去建设研发效力度量数据中台，指望通过研效大数据的剖析来获取改良点。这种“广撒网”的策略尽管看似无效，实则收效甚微。事实证明，度量数据中台的建设老本往往会大幅度高于理论获得的成果。

比拟现实的做法应该是通过对研发过程的深度洞察，发现有待改定的点，而后寻找可能证实本人观点的度量汇合并采取相应的措施，最初再通过度量数据来证实措施的理论价值，这种“精准捕捞”的策略往往更具实用价值。

6 研发效力的度量指标如何选取？

这个问题太大了，很难开展。然而这里想通过两个典型案例来解释指标选取的问题。很多时候，当咱们无法解释什么是正确的时候，咱们能够通过逆向思维尝试着看看什么是谬误的，以此来给咱们一些启发。

6.1“千行代码缺陷率”引发的血案

千行代码缺陷率是被大家宽泛熟知并且不少企业正在应用的一个代码品质相干的度量指标，然而这个指标真的能主观反馈代码的品质吗？这个指标真的是一个合格的指标吗？这里我不间接给出论断，而是带着大家一起来剖析一下，让你本人得出结论。

下面的图给出了千行代码缺陷率的定义，即每千行代码的缺点数量。假设个别状况下，团队均匀的千行代码缺陷率大略是在 5-10 的范畴。

当初咱们有这么三个工程师：

• 工程师 A 的技术能力比拟差，实现需求 X 用了 20000 行代码，同时引入了 158 个缺点，由此计算出工程师 A 的千行代码缺陷率 =7.9，这个值正好在 5-10 这个均匀范畴内，所以从千行代码缺陷率来看，工程师 A 属于失常程度，并不会引起大家的留神，属于无功也无过。
• 工程师 B 是一个技术大牛，实现雷同的需要 X 只用了 3000 行代码，然而也引入了 10 个缺点，由此计算出工程师 B 的千行代码缺陷率 =3.3，这个值显著低于 5-10 这个均匀范畴，你认为工程师 B 会因而受到褒扬？大错特错，工程师 B 很有可能会被断定为没有进行充沛的测试，被责令增强测试。
• 工程师 C 是一个有技术谋求、致力想让本人成为技术大牛的人，他实现雷同的需要 X 用了 4000 行代码，然而因为目前的技术能力无限，所以引入了 58 个缺点，由此计算出工程师 C 的千行代码缺陷率 =14.5，这个值显著高于 5-10 这个均匀范畴，所以毫无疑问，工程师 C 必然会蒙受批评，被责令改良代码品质。

由此看出，基于千行代码缺陷率对这三个工程师的评估显然是有失公允的。

更蹩脚的是，之后的需要有可能会发变动。这个时候工程师 B 和工程师 C 的代码具备较好的可维护性，能够不便地变更，所以能够很快实现变更工作，并且根本不会引入新缺点。而工程师 A 的代码因为不足设计模式的反对，大量代码须要重写，同时还会引入了很多新缺点。然而因为代码量够大，工程师 A 的千行代码缺陷率仍旧在均匀范畴内。所以在现有的度量体系下，工程师 A 仍然无功也无过，而工程师 B 和工程师 C 则持续失去差评，因为他们的工作看起来太简略了，显著工作量“不丰满”。

由此可见，千行代码缺陷率的度量体系是失败的，其所传播的价值观与咱们所冀望的南辕北辙。从工程师 B 的遭逢能够看出“咱们不置信你可能写出高质量的代码”，从工程师 C 的遭逢能够看出“咱们不激励技术晋升阶段的阵痛”，而从工程师 A 那边咱们看到的是“咱们欢送那些平庸的程序员”，这些都间接违反了咱们理论的价值观。

上述的剖析还是在没有人为“粉刷”指标的前提下进行的，在理论工作中，工程师往往会采取浓缩代码的形式来升高千行代码缺陷率，而不是理论去缩小缺点数量。因为与缩小缺点数量相比，间接浓缩代码（比方：一行写成多行、括弧必须换行、多写正文、多加空行等）的难度更低，而且更可控。所以我始终说，永远不要低估工程师面对度量指标时的“创造性”。

此时度量体系的设计者可能很快会意识到工程师们的小伎俩，所以全新的“开发当量缺陷率”指标应运而生，这个指标用开发当量去代替千行代码数。开发当量是对开发工作量的一种正当预计，能够了解为源代码编译成的形象语法树 AST 的复杂度。与代码行数这类浅层统计相比，开发当量不易受到编程习惯或特定行为的烦扰（比方换行、正文等），这样一来，想通过浓缩代码来升高代码缺陷率的路就走不通了。

乍一看，用开发当量仿佛能够解决问题，然而当你深刻思考后会发现，用开发当量可能会让状况更蹩脚。因为工程师仍旧能够通过人为减少开发当量（比方缩小封装等）来升高代码缺陷率，只不过减少开发当量的难度比间接浓缩代码要大，这将间接导致“粉刷”指标的难度变大，进而陷入“算法反抗”的困境。最初的后果是工程师为了升高代码缺陷率，在谬误的中央破费了更多工夫和精力，而最终代码品质仍旧没有任何改善。

那么到底是什么中央出了问题呢？你静下心来认真想一下，代码行数和代码品质到底有没有关系？如果有关系，两者之间到底是因果关系还是仅仅是相关性？这时你可能会豁然开朗，原来代码行数和代码品质之间仅仅是相关性，基本不是因果性，代码品质不会因为代码行数变多而变差，所以试图用千行代码缺陷率来对代码品质进行度量的大前提根本就是不成立的，从源头上就错了。这就如同森林火灾率和冰淇淋销量之间就是相关性，这个相关性是由天热而产生关联的，两者之间不存在任何因果性。换言之，想通过升高冰淇淋销量来升高森林火灾率是齐全行不通的。科学千行代码缺陷率就如同扔砖头还要看风向一样自欺欺人。

那么正确的做法是什么呢？咱们晓得，只有缺点能够很快被修复，那么有缺点就并不可怕，缺点多也不可怕，咱们怕的是每个缺点的修复难度都很高，一个缺点几天都修不了，咱们更怕缺点修复对原有代码的改变会“伤筋动骨”。

所以咱们齐全能够 采纳均匀缺点修复工夫 (Mean Time To Repair) 来掂量代码的品质。均匀缺点修复工夫可能更好地反映代码自身的品质情况，以及团队的技术成熟度。往往均匀修复工夫较长的代码都是复杂度高、耦合度高的代码。而均匀修复工夫短的代码则是构造绝对清晰、命名标准、容易了解、扩大和变更的代码。相比千行代码缺陷率，均匀缺点修复工夫对代码品质会有更强的正向牵引作用。

6.2 麻利模式下工作量估算的是是非非

在麻利模式下的工作量度量，到底应该用“故事点”作为单位呢，还是应该用“人天”作为单位？很多人可能感觉都能够，他们认为这个次要还是看团队的应用习惯。其实这个答案是齐全谬误的，正确的做法是用“故事点”，而不应该用“人天”。

要了解其中的原因其实并不简单，因为工作量是量的概念，而人天是工夫的概念。要搬一千块砖，这一千块砖就是工作量的概念。

搬得快，它是一千块砖，搬得慢，还是一千块砖。工作量自身的大小和工夫是没有关系的。

工作量与工夫产生关系是通过速率这个概念。同样搬一千块砖，你每分钟搬 10 块，100 分钟搬完；我每分钟只能搬 5 块，那就 200 分钟搬完。所以，只有当速率确定了，能力把工作量换算成工夫。

问题是当咱们在打算迭代的时候，咱们是没有方法明确晓得速率值的，速率会随着很多因素动态变化，并不是肯定不变量。比方工程师的熟练程度、是否之前解决过同类型的问题、须要加入会议的多少、家里的各种琐事都会对速率产生间接影响。因而咱们无奈将代表工作量的“故事点”和代表工夫的“人天”等同起来。

为什么很多团队仍然会间接应用工夫来估算工作量，并认为“以故事点为单位”和“以人天为单位”没区别呢？因为在他们的观点中，速率是常量，所以工作量与工夫就能够线性换算，所以这个看似“正当”假如，背地其实是一个微小的逻辑谬误。

7 总结

本文系统性探讨了研发效力度量的方方面面，重点聚焦研发效力度量的具体实际，同时通过千行代码缺陷率和麻利工作量估算等具体案例探讨了度量指标选取的常见误区。

其实你会发现，研发效力度量的过程往往是对软件研发全流程进行形象和简化的过程，但简化就会带来失真和扭曲，那些具备理性色调、意味深长、须要重复斟酌的中央隐没了，只剩下言之凿凿的度量指标，稍有不慎，就会让咱们产生手握真谛的幻觉。

那么在云原生的加持与数字化风潮下，企业应该如何疾速死记硬背，推动研发效力降级？本文作者茹炳晟 诚邀各位读者，加入 腾讯云 CIF 工程效力峰会 – 数字化风潮下的企业研发治理摸索 论坛。来自不同企业的 5 位业内专家，将聚焦企业研发效力降级痛点，联合实践与实际，立足企业倒退，放眼产业共建，通过实在案例帮忙企业更高效、更高质量、更牢靠、可继续地交付更优的业务价值。

2021 年 10 月 19 – 20 日

CIF 线上峰会 炽热报名中

扫描海报二维码

更多精彩议程等你开启！