软件研发效能度量之十大反模式
The following article is from InfoQ Author 张乐
在软件研发领域，能够有助于效能提升的方法论和实践一直在快速发展。比如，我们熟知的敏捷开发方法已经诞生了二十年，DevOps 也已经发展了十多年，相信很多朋友都已经对这些方法有了比较深刻的理解，在行业中也已经有很多企业对其进行了引入、落地和实践。
但是，我们经常遇到的一种现象是，当一个组织或者团队在消耗了大量的"变革"时间、花费了大量的人力资源和成本后，却无法有效回答一些看似非常基本的问题，比如：
你们的研发效能到底怎么样？可否量化？
你们比所在行业平均水平、比别的公司、比别的团队更好还是更差？
研发效能的瓶颈点和问题是什么？
在采纳了敏捷或 DevOps 实践之后，有没有效果？有没有实质上的提升？
你们下一步应该采取什么样的行动以继续优化效能？
这就是为什么我们希望进行研发效能度量。我认为 研发效能度量的目标就是让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能，而不要总是凭直觉感性地说出“我觉得..."。
研发效能度量的出发点虽然很好，但是如何正确度量却是一个挺有难度的技术活儿。尤其是这几年，在研发效能实践被普遍采纳、研发效能平台逐步被构建起来，很多企业已经拥有了一些研发基础数据的基础之上，如何有效地度量，却成为了困扰着很多企业和管理者的一大难题。
根据我的经验，度量这件事情不仅困难，而且稍不留神就可能会跑偏，结果经常是非但没有带来所预期的、对效能提升的正面引导作用，反而带来了很多严重的副作用，让企业在消耗了很多时间和资源的情况下，进行了一场看似轰轰烈烈但却没有什么价值的数字游戏，或是一场看似政治正确但却让员工变得更加“内卷”的无效运动。
这就是本文要讨论研发效能度量的十大反模式。
正所谓“成功大都相似，失败各有不同"。
在有些企业，管理者的初心的确是想有效提升组织的研发效能，但是其管理理念还停留在往前推数十年的两场技术革命之前，那种适合于管理重复的体力劳动工作者的模式上。当时的生产环境是重复的、可知的、确定性的，通常是物理活动，这与当前软件开发这种创造性的、未知的、不确定性很高的知识工作完全不同。那么，度量的方式肯定也截然不同。
如果按照传统的、针对体力劳动者的度量思路，会通过考察单位时间内的工作产出来衡量生产率。那么对于软件开发人员来说，是不是就可以通过度量每天编写的代码行数来实现呢？代码行这是一种简单的、易于获取的指标，而且符合传统的度量思路，在实际工作中我们经常看到有管理者会使用。比如度量单位时间内不同工程师的新增代码行，以此来衡量每个人工作是否努力、工作是否饱满、产出是否合理，更有甚者，还会进行团队内代码行倒排名来作为奖惩措施。
但是我认为，无论如何，代码行都不会是一个好的度量指标。比尔·盖茨曾经说：“用代码行数来衡量软件的生产力，就像用飞机的重量来衡量飞机的生产进度一样。” 虽然代码行很容易度量，但却有很大的问题，因为代码越多不一定就越好。在这个度量的导向下，工程师可能倾向于提交大量重复、冗余的代码来“凑指标”，让数据变得很好看，但这对企业没有任何价值。
在许多情况下，只要能满足客户的需求，实际上代码越少越好。但我们同样不能度量实现同一个业务逻辑，谁的代码写的最少，因为这样的代码可能大量使用复杂语法和表达式来精简行数，只有作者一个人能看得懂，不利于代码传承和经验共享。
当然，这里只是举了一个例子，还有很多看起来很简单、容易度量的指标，比如下面即将讲到的工时和资源利用率等，这些指标都很容易会让度量跑偏。我们应该做的是提供给管理者更多的管理抓手，从正确的度量理念和方向上入手，选取符合数字化时代特征的度量指标集，这在后文中会展开描述。
互联网大厂一直自带上热搜的体质，而互联网圈流行已久的“996"向来是内卷的代名词。大家肯定还记得，2020 年网络上对于“996"有着深度的讨论，“996"话题似乎与互联网大厂有着某种深度绑定，某些话题确实也是从大厂内部发源的。比如：阿里的马云老师说，能 996 是一种巨大的福气，很多公司、很多人想 996 都没有机会；京东的东哥说，混日子的不是我兄弟；字节跳动、快手一段时间以来都在采用“大小周"的工作制度。
随着内卷的不断加剧，很多人学会了“表演型”加班。 当加班文化盛行，身处其中的每个员工都容易被裹挟其中，即便没有工作安排，也宁愿下班后留在公司继续“磨洋工”。而过度加班会降低工作效率，让员工患上严重的“拖延症”。
也有理性声音指出，把提高员工效率寄托在延长工作时间上，本就是管理上的“懒政”。阿里某 P8 同学曾经发帖说，“当一个管理者的智慧无法衡量一支团队的产出的时候，他就会把‘工时’当做最后的救命稻草，死死抱住——这是他唯一听得懂的东西了。”
以上这些讨论其实都在围绕一个主题，就是工程师的资源利用率。比如上下班打卡、填写工时（有的公司称为报工）等，都是非常典型和常见的管理手段。所谓的“996"更多强调的是工作时长，但在内卷和“表演型”加班的氛围里，这种工作时间的延长其实根本无法转化为实际有效的产能。我们经常看到的情况是，研发似乎忙得热火朝天，但是业务仍然抱怨做得太慢，根本不买账。即使大家真的都在忙，也会导致更多的衍生问题。比如资源利用率的饱和会导致上下游协作时的大量排队和等待，这种局部的过度优化会导致全局的效率劣化，对企业来讲得不偿失。
另外，长期强调超高的资源利用率，有把员工当成“资源”而不是“工程师”的倾向，员工长期在这种压力下会产生疲惫、幸福感下降。有研究表明，这不仅会影响代码编写过程的生产力，还会影响结果代码的质量。
所以，我们不要过度关注资源效率类指标，还需要考虑流动效率类指标，比如从产品或团队视角下的需求交付周期、流动速率、流动效率等，后文会展开说明。顺便说一句，在我写下本文时（即 2021 年 8 月），许多互联网大厂都纷纷取消了“大小周”的工作制度，也许行业已经更深刻认识到，追求资源效率有其弊端，效能的全面提升才是解决效率问题的良药。
成熟度模型在软件行业的发展中由来已久，很多企业都通过了 CMMi 成熟度评估，甚至在敏捷、DevOps 领域也有人照方抓药，试图通过这种模式来评估和衡量软件过程，通过研发活动的标准化和一致性来提升软件研发的效率和质量。我在这里先讲一个案例。
有一家大型跨国公司，曾经是某领域绝对的市场领导者，市值一度达到 2500 亿美元。这家公司的高管们非常开明，意识到敏捷软件开发对于他们适应快速变化的市场极为重要。于是，高层对大规模敏捷转型给予了极大的支持，从上而下，投入巨大。难得的是，基层开发人员对任何敏捷实践也都没有异议，而且自我感觉良好。他们定义了公司级别期望发生的敏捷活动和行为，并与当时的最佳 Scrum 实践进行对比，以成熟度的形式进行度量评估。
在具体操作过程中，他们把期望发生的敏捷活动分成 9 个维度，分别是迭代、迭代中的测试、用户故事、产品负责人、产品待办列表、估算、燃尽图、中断和打扰、团队。然后对每个维度给出一系列评估细则。比如，对于迭代维度，他们的评估内容是：
当团队对迭代进行承诺时，需要知道迭代的长度，以便按更好的节奏交付价值。
评估方式（不加总）：
迭代长度 4~6 周，得 2 分
迭代长度 4 周之内，得 4 分
过去三个迭代，迭代长度稳定在 1 个月，得 5 分
过去三个迭代，迭代长度稳定在 4 周，得 6 分
过去三个迭代，迭代长度稳定在 3 周，得 8 分
过去三个迭代，迭代长度稳定在 2 周之内，得 10 分
以此类推，每个维度都有详细的评估内容，最终可以得到一张敏捷成熟度的雷达图，如下图所示。
这个模型一度被行业广泛引用，并且作为敏捷开发方法可以在大规模企业落地的证据之一。也许你已经猜到了，这个模型就叫做 Nokia Scrum Test。我们当然不能简单粗暴地把这家公司手机业务的衰落直接归结为敏捷度量方式的无效，但从客观的角度来看，我们依然能发现其中隐含的问题。
按照这个模型，管理层看到这些团队的敏捷成熟度一直在提升，已经实现了理论上的敏捷性。但是实际上敏捷转型并未成功，业务结果也证明了这一点。在《Transforming Nokia》一书中，描述了一些当时的实际情况：
企业级的敏捷工具没有被开发人员真正接受，他们更喜欢简单的以开发为中心的工具
很多开发人员在迭代末尾，工作已经完成后，后补一个用户故事
把敏捷工具变成了文档记录工具，而不是流动和反馈机制
看起来所有正确的敏捷活动都在发生，但开发者饱受构建和部署的折磨
由于 Symbian60 操作系统的规模和架构，增加新功能很困难
在构建和部署软件时，下游的分离和低效意味着进展非常缓慢
技术债务积重难返， 2010 年 Symbian60 系统构建异常缓慢，要花整整 48 小时
反思这个案例，我们可以总结为：这种狭隘的、以活动为导向的敏捷观是其转型失败的根本原因之一。 研发效能应该度量结果而不仅是过程，端到端价值流的局部优化对结果的改进效果很小，因为可能根本就没有解决效能瓶颈。
效能度量显然很重要，企业迫切希望效能提升的愿望也可以理解，但千万不要把指标设置为 KPI 用于绩效考核，因为 把度量与绩效挂钩就一定会产生“造数据”的数字游戏。这时，使用效能度量非但起不到正面效果，还会对公司和团队造成伤害。
有个著名的定律称为古德哈特定律，其内容是：当某个度量变成了目标，它便不再是一个好的度量。有朋友也将其戏称为“好心人”定律，效能度量的出发点是好的，但当它演变成了与绩效考核挂钩的 KPI，大家都有追求自己切身利益的动机，那么各种有创造性的、为了提升指标而进行的不优雅的短视行为就会纷纷上演，度量走偏就在所难免了。
其实从理论上讲，所有的度量都可以被操纵，而数字游戏式的度量会分散员工的注意力并耗费大量时间。把度量指标设置为 KPI 进行考核，只是激励员工针对度量指标本身进行优化，这通常比他们在度量之前所做的工作效率要更低。因此，试图把度量武器化为绩效考核，不仅是一种浪费，而且往往适得其反，特别是当薪资与度量的KPI挂钩的时候。
那么，如果不把效能度量与绩效考核挂钩，那怎样才能使用度量提高研发效能呢？答案是：把度量作为一种目标管理方法、一种效能提升的参考工具，促进团队明确效能目标、分析效能问题，指导团队针对性优化，从而最终获得效能提升。比如，对线上缺陷密度的度量和分析，可以让团队了解产品的质量走向和问题的根因，有助于持续优化交付质量；对需求交付周期的度量和分析，可以让团队了解产品端到端交付效率和细化每个阶段的耗时占比，可以针对性的采取干预措施，让团队获得有效的提升。
我们对于度量指标的理解，有时存在一定的片面性，比如认为某个效率类指标的提升就代表了研发效能的提升。需求交付周期是常见的效能度量北极星指标，在行业实践中引用的比较多。但是，如果一个组织或团队仅仅认为交付快了、周期短了就代表效能提升了，其实这就是一种片面的追求了。
记得之前也有专家说过：如果你不能度量一个事物的所有方面，就无法管理或者发展它。研发效能的提升不仅是有“效率”这一个方面，还有很关键的另外一个部分是“有效性”。 软件研发过程中最大的浪费，是构建没有人在乎的东西。我们所谓的效能提升，一定是要从业务目标出发的，构建的功能、质量是需要达到期望要求的，在此基础之上当然效率越高越好、成本越低越好，所以我们说的效能实际上综合考虑了关于产出和投入的多个要素。
回到需求交付周期这个指标的例子，追求这个指标的优化当然很重要，但是需要在功能有效，吞吐量和质量稳定、安全合规的基础之上才有价值，片面地使用局部过程性指标对于研发效能提升的效果有限，而跳出来看到全局的研发体系和结构才是关键。
研发效能度量的过程实际上是要把数据转化为信息，然后将信息转化为知识，这样就可以让用户自主消费数据，进行分析和洞察。在企业进行研发效能度量的初始阶段，可能会存在各种各样的研发工具产生出来的原始效能数据，但缺少对其进行分析和加工成信息的自动化工具。所以很常见的是，用户从系统中导出数据到 Excel 表格，然后进行各种筛选、关联、透视和加工，最终形成度量报表。
在这个过程中，经常存在大量的人工干预行为。那么，在数据分析和加工过程中，就很容易有意或无意地引入一些数据集合的筛选或“异常数据”排除的行为。有时甚至是仅仅为了让数据变得好看、达标而做出一些看似合理但颇有欺骗性的报表来。我曾经接触过一家通过了 CMMi 四级的企业，会周期性统计研发效能报表。有一次，在查看报表中的数据时，我发现某个团队的单元测试覆盖率一直在 83%~85% 之间浮动，非常地规律。当我仔细询问这个数据的时候，相关人员相互对视一笑，跟我说：“这些数据其实都是手工采集、人工上报的，其实很难保证准确性。”如果效能数据都是这种方式被手工统计出来、一层层地上报上去，对企业来讲其实是非常有害的，不但无法发现现存的实际问题，还会把管理和技术决策引导到错误的方向上去。
我在建设服务于全集团数万研发的研发效能度量平台时，其中一个 最基本的要求就是度量数据的公信力。 也就是说，只有在我们这个平台上自动采集、汇聚、计算出来的数据，才是被集团官方认可的，这些数据才可以被用来进行管理和技术决策。我认为这才是一个研发效能度量产品或平台的立足之本。有了这样一个有公信力的平台之后，那些手工处理的 Excel 表格、人工做图的 PPT 胶片，就会慢慢淡出大家的视野。
研发效能的度量不是免费的，为了做到准确、有效的度量，各种成本加在一起是很高的。比如我们经常会去度量团队的需求交付周期及其在设计、开发、测试、部署等每个阶段的时间消耗和占比。这样一个看似简单的度量需求，其实背后要做很多事情。
比如团队的研发流程要定义清晰、每个阶段的完成的定义（DoD）要足够明确、研发管理工具的配置要合理，以及最重要的是，团队中每个人的操作过程要规范并及时。比如某个需求其实已经部署到预发环境了，但在看板系统中的状态还停留在“开发中”，原因可能是开发人员提交代码、测试人员进行验证后，并没有及时同步看板工具中的需求状态。在实际研发过程中，这是很常见的现象，以至于统计发现很多需求的交付周期都是 0 天，因为这些需求都是在开发完成之后，开发人员补录的需求，然后从看板第一个阶段列直接拖动到最后一列，这样统计出来的数据就会有极大地失真。当然，我们应该更多使用自动化的手段来同步状态，比如开发提交、提测、部署等行为会自动触发对应需求状态的流转，但这也需要工具平台开发出对应的能力，实际上也需要成本的投入。
既然度量有这么高的成本，那我们还需要做么？我的答案是，当收益大于成本的情况下，度量就是值得做的。度量指标应该少而精，每个指标都要追求其投资回报比。但是一些企业仍然倾向于定义大量的度量指标以彰显其专业性，有的甚至达到了成百上千个指标。这样的做法除了给企业带来巨大的成本，好像很难体现出应有的价值。
在度量指标的选择上，我们经常提到一个词叫做“北极星指标”，也被称为是首要关键指标（One Metric That Matters）。北极星是天空北部的一颗亮星，离北天极很近，几乎正对着地轴，从地球北半球上看，它的位置几乎不变，所以古代人们经常依靠它来辨别方向。在度量领域，我们可以根据当前企业的上下文，在不同领域选取少量的北极星指标来指导我们改进的方向，从目标出发驱动改进，从宏观下钻、定位到微观问题后再引入更多的过程性指标进行辅助分析。
货物崇拜（Cargo Cults）是一种宗教形式，尤其会出现在一些与世隔绝的落后土著部落之中。当货物崇拜者看见外来的先进科技物品，便会将之当作神祇般崇拜。第二次世界大战期间，盟军为了对战事提供支援，在太平洋的多个岛屿上设立了空军基地，以空投的方式向部队及支援部队的岛民投送了大量的生活用品及军事设备，从而极大的改善了部队以及岛民的生活，岛民也因此看到了人工生产的衣物、罐头食品以及其他物品。战争结束后，这个军事基地便被废弃，货物空投也就自然停止了。此时，岛上的居民做了一件非常有意思的事情——他们把自己打扮成空管员、士兵以及水手，使用机场上的指挥棒挥舞着着陆信号，进行地面阅兵演习，试图让飞机继续投放货物，货物崇拜因此而诞生。
这种现象在研发效能领域时有发生，尽管货物崇拜的度量指标制定者们并没有像岛民一样挥舞着指挥棒，但他们却大量的复制和粘贴着从网上的各类文章中找来的度量指标，这些指标的定义有其场景和上下文，但他们对这些背景和工作原理并不是很了解。
Google 可以说是国内公司膜拜和学习的典范，其在度量工程生产力方面也有明确的“QUANTS”模型，分别是：
代码质量（Quality of the code）
工程师注意力（Attention from engineers）
智力复杂性（Intellectual complexity）
速度与速率（Tempo and velocity）
满意度（Satisfaction）
这个指标体系看起来很不错，但是如果一个组织或团队的成熟度还比较低，连最基本的需求流转、敏捷协作都没有做好，上来就引入和对标这些对工程能力和工程师文化有一定要求的指标，很可能适得其反，落入货物崇拜的误区。另外，前两年在网上也有关于高效的工程师每天能写多少行代码的讨论，据说 Google 的工程师平均每天能编写 100-150 行代码。但如果不管其上下文（技术架构、平台能力、工程师级别、协作模式、质量标准、统计口径等），直接使用这个指标来进行对标，一定会搞得工程师苦不堪言。
我们经常说：不要因为走得太远，而忘记了为什么出发。官僚主义的一个问题是，一旦制定了一项政策，遵循该政策就成了官僚主义的目标，而不管该政策所支持的组织目标是什么。研发效能度量是为目标服务的，如果一种度量真的很重要，那是因为它必须对决策和行为产生一些可以想象的影响。
比如软件开发团队的经理希望通过引入新的持续集成系统来提高生产力，这就是一个明确的目标，在初期落地执行时，可能会采用持续集成系统注册用户数这个指标来进行度量。但是系统的使用不是目的，而是提升生产力的手段，我们更应该度量的是应用系统后，是否解决了开发人员对测试快速反馈的需求，质量和效率是否得到了有效提升。
在 Google，使用 GSM（目标 / 信号 / 指标）框架来指导目标导向型指标的创建：
目标是期望的最终结果。它是根据从更高层次上理解的内容来表达的，不应包含具体的度量方法的参考。
信号是目标达成与否的结果。信号本身也可能无法度量。
指标是信号的代理。代理的含义是指由于信号本身可能无法量化，因此需要通过指标来代理信号的量化。指标是一定可度量的内容。
举个例子，比如企业希望代码的可读性提高，这样可以得到更高质量、更一致的代码，也能促进健康的代码文化，那么按照 GSM 框架：
目标：由于可读性的提高，工程师编写了更高质量的代码
信号：可读性过程对代码质量有积极的影响
指标：可读性评审对代码质量没有影响或负面影响的工程师比例、参与可读性过程并改善了其团队的代码质量的工程师比例
在与国内一些企业的交流中我发现，很多公司的研发效能度量都是主要从管理者的视角出发的，无论是工时、人员饱和度等衡量资源利用率的指标，还是需求交付周期、吞吐量等衡量流动效率的指标，本质上都是从管理维度看待研发效能这件事情。但是在前文中我也提过，我们不应该把员工当成一种”资源”，而是要作为”工程师”来看待。员工幸福感的下降不仅会影响代码编写过程的生产力，还会影响结果代码的质量。
所以我们做研发效能提升，本质上还是要多关注工程师的感受，他们对工作环境、工作模式、工作负载、研发基础设施、项目协作、团队发展、个人提升是否感到满意，是否有阻碍工程师发挥更大创造性和产生更大生产力的因素存在。工程师个人效能的有效提升是组织效能提升非常关键的组成部分。就像 Facebook 会把“不要阻塞开发人员”作为贯穿公司研发和管理实践中的核心原则之一，就是强调公司流程和实践也要从工程师视角来考虑问题。
那么，我们如何度量工程师的满意度呢？我们可以选择 eNPS（Employee Net Promoter Score）来衡量员工的忠诚度，更高的员工忠诚度可以让工程师提供更卓越的服务，让客户满意，最终助力企业业务的成功。当然，我们不仅关注 eNPS 指标的数值本身，还可以将其与其他人力资源指标结合起来，这样就可以知道为什么员工会给出负面反馈，这将揭示表象背后的原因，并帮助管理者寻找改进的方法。
“成功大都相似，失败各有不同"。 本文分析了研发效能度量常见的“反模式"，希望大家能够在开启效能度量之旅之前，先辨别清楚方向，避免一开始就陷入到沼泽泥潭之中。
但是，研发效能度量其蕴含的巨大价值，我们还是要想办法去探索和实践。在下一篇文章中，我会具体介绍行业中有关的权威报告、多个互联网大厂的研发度量案例，并总结和提炼出其中隐含的度量设计思路和关键原则。敬请期待！
作者介绍：
张乐，DevOps 与研发效能资深实践者，长期工作于拥有数万研发的互联网大厂（百度、京东等），主攻敏捷与 DevOps 实践、DevOps 平台建设、研发效能度量体系设计等方向，历任资深敏捷教练、DevOps 平台产品总监、研发效能度量标准化联盟负责人等岗位。长期活跃于技术社区，目前是 DevOps 起源国际组织 DevOpsDays 中国区核心组织者，同时也是国内多个技术峰会的联席主席、DevOps/ 研发效能专题出品人、特邀演讲嘉宾。EXIN DevOps 全系列国际认证授权讲师、凤凰项目 DevOps 沙盘国际授权教练。历任埃森哲、惠普等全球五百强企业资深咨询顾问、技术专家，多年敏捷与 DevOps 转型、工程效率提升和大型项目实践经验。畅销书《独角兽项目：数字化时代的开发传奇》译者。
链接参考：
谷歌软件工程：文化、实践与工具 研发效能工具的破局：产品化与场景化 困在系统里的“研发效能度量” 该如何自救？ 许多研发管理者并不想提升研发效能，这才是最大的问题！ 演讲实录：从灵魂拷问到研发效能提升的正确姿势 大规模信息流推荐系统 研发效能提升之优秀实践 灵魂拷问五：研发效能的提升一定是有技术驱动的吗？