研发效能之一

研发效能度量核心方法与实践：难点和反模式

如何构建度量的体系化框架、如何进行度量指标的选取、如何进行度量分析、如何进行落地运营，对以往经验进行了总结和提炼，包括以下内容：

1. 效能度量的难点和反模式

2. 效能度量的行业案例和关键原则

3. 效能度量的实践框架和指标体系设计

4. 效能度量的常用分析方法

5. 效能度量的落地实施建议

在数字化的时代，研发效能已经成为一家科技公司的核心竞争力。

在软件研发领域，能够有助于效能提升的方法论和实践一直在快速发展。比如，我们熟知的敏捷开发方法已经诞生了二十年，DevOps 也已经发展了十多年，相信很多朋友都已经对这些方法有了比较深刻的理解，在行业中也已经有很多企业对其进行了引入、落地和实践。

对着你现在的团队情况，试着回答下面的问题：

• 你们的研发效能到底怎么样否量化/p>

• 你们比所在行业平均水平、比别的公司、比别的团队更好还是更差/p>

• 研发效能的瓶颈点和问题是什么/p>

• 在采纳了敏捷或 DevOps 实践之后，有没有效果没有实质上的提升/p>

• 你们下一步应该采取什么样的行动以继续优化效能/p>

这就是为什么我们希望进行研发效能度量。我认为研发效能度量的目标就是让效能可量化、可分析、可提升，通过数据驱动的方式更加理性地评估和改善效能，而不要总是凭直觉感性地说出“我觉得…”。

拥有了一些研发基础数据的基础之上，如何有效地度量，却成为了困扰着很多企业和管理者的一大难题。

根据我的经验，度量这件事情不仅困难，而且稍不留神就可能会跑偏，结果经常是非但没有带来所预期的、对效能提升的正面引导作用，反而带来了很多严重的副作用，让企业在消耗了很多时间和资源的情况下，进行了一场看似轰轰烈烈但却没有什么价值的数字游戏，或是一场看似政治正确但却让员工变得更加“内卷”的无效运动。

那么我们下面就来看一看，研发效能度量的难点和常见的反模式。

研发效能度量的难点

相信每一个从事研发效能度量的实践者或专家都听说过管理大师彼得·德鲁克的名言“没有度量就无法管理”，这句话出自《管理的实践》，在被引用了 60 多年后的今天依然适用。德鲁克强调了度量对于管理的价值和作用，度量，是对某个事物的客观认知，知道组织或团队所处的位置和问题在哪里，如何进行决策，应该如何进行改进。所以我们需要基于事实的度量指标，为管理提供可靠的效能分析和决策支持。

但是，在软件研发领域，为什么说效能度量这件事情比较困难呢/p>

在 2003 年，软件开发领域的大师马丁·福勒就写过一篇名为“无法度量生产力”的博客，他认为当时的软件工业缺乏一些度量软件开发有效性的基本元素的能力。仔细思考下，软件研发过程跟生产制造行业实体产品的制造过程的确有着很大的区别，那么在度量的问题上就会充斥着一些比较困难的因素。虽然本质上都是通过一定的工作来生产（研发）出所需的产品，但不同于生产制造行业，软件研发过程有其特殊性：

1. 软件研发过程中的可视性差

软件研发过程是靠业务、产品和工程师的数字化协作来推进的，涉及到业务、产品、研发、运维等不同职能，多个团队多种角色协作时，任务处理的进度、队列、依赖、瓶颈可能很难清晰观察到，其中的风险也容易被各个环节掩盖，以至于很多项目管理软件中填写的任务进度百分比只是简单的粗略估算，可能只有部分参考意义，实际上根本无法保证准确。

2. 软件研发过程中工作切分的随意性

有时管理者会制定一些 KPI 来度量团队绩效，但就像那句名言所说：你度量什么，就会得到什么。其实这句话只说了上半句，而下半句是：只是不一定是用你所期待的方式得到。所谓上有政策、下有对策，由于软件工作切分的随意性，也许把一个需求拆成多个小需求，一行代码拆成多行来写，那些度量产能或者吞吐量的 KPI 指标也许就被用非预期的方式达成了。

3. 敏捷研发过程中工作是并行开展的

随着企业中敏捷研发模式的持续推进，我们很难再像传统项目管理模式一样清晰界定软件研发的各个阶段，很多情况下不同需求所对应的开发/测试/部署工作都是并行的，产品也是不断迭代、持续演进的，这也对准确度量造成了一定困难。

另外，现代信息工作的特点就是经常容易被各种不断到来的干扰打断。这些干扰可能来自外部事件（例如，一个同事问你一个问题、来自微信上的消息通知），也可能是自我的打断（例如，在两个不同的系统之间来回切换才能完成一项任务）。

最近，一项针对 IT 专业人士的观察研究发现，有些人在专注工作几分钟后就会被打断。这种高度并行、频繁被打断的场景往往无法被度量出来，我们也许看到每个人都在很饱满地忙于各种任务，但其实这种工作流的中断对于效能的影响是非常巨大的。这就是所谓的“忙忙碌碌一整天，好像啥也没做成”，相信很多人都有这种经历。

研发效能度量的反模式

正所谓“成功大都相似，失败各有不同”。

下面我们就一起来看看这些反模式：

1. 使用简单的、易于获取的指标

如果按照传统的、针对体力劳动者的度量思路，会通过考察单位时间内的工作产出来衡量生产率。那么对于软件开发人员来说，是不是就可以通过度量每天编写的代码行数来实现呢码行这是一种简单的、易于获取的指标，而且符合传统的度量思路，在实际工作中我们经常看到有管理者会使用。比如度量单位时间内不同工程师的新增代码行，以此来衡量每个人工作是否努力、工作是否饱满、产出是否合理，更有甚者，还会进行团队内代码行倒排名来作为奖惩措施。

但是我认为，无论如何，代码行都不会是一个好的度量指标。比尔·盖茨曾经说：“用代码行数来衡量软件的生产力，就像用飞机的重量来衡量飞机的生产进度一样。”虽然代码行很容易度量，但却有很大的问题，因为代码越多不一定就越好。在这个度量的导向下，工程师可能倾向于提交大量重复、冗余的代码来“凑指标”，让数据变得很好看，但这对企业没有任何价值。

当然，这里只是举了一个例子，还有很多看起来很简单、容易度量的指标，比如下面即将讲到的工时和资源利用率等，这些指标都很容易会让度量跑偏。我们应该做的是提供给管理者更多的管理抓手，从正确的度量理念和方向上入手，选取符合数字化时代特征的度量指标集，这在后文中会展开描述。

2. 过度关注资源效率类指标

随着内卷的不断加剧，很多人学会了“表演型”加班。当加班文化盛行，身处其中的每个员工都容易被裹挟其中，即便没有工作安排，也宁愿下班后留在公司继续“磨洋工”。而过度加班会降低工作效率，让员工患上严重的“拖延症”。

也有理性声音指出，把提高员工效率寄托在延长工作时间上，本就是管理上的“懒政”。阿里某 P8 同学曾经发帖说，“当一个管理者的智慧无法衡量一支团队的产出的时候，他就会把‘工时’当做最后的救命稻草，死死抱住——这是他唯一听得懂的东西了。”

以上这些讨论其实都在围绕一个主题，就是工程师的资源利用率。比如上下班打卡、填写工时（有的公司称为 工）等，都是非常典型和常见的管理手段。所谓的“996″更多强调的是工作时长，但在内卷和“表演型”加班的氛围里，这种工作时间的延长其实根本无法转化为实际有效的产能。我们经常看到的情况是，研发似乎忙得热火朝天，但是业务仍然抱怨做得太慢，根本不买账。即使大家真的都在忙，也会导致更多的衍生问题。比如资源利用率的饱和会导致上下游协作时的大量排队和等待，这种局部的过度优化会导致全局的效率劣化，对企业来讲得不偿失。

另外，长期强调超高的资源利用率，有把员工当成“资源”而不是“工程师”的倾向，员工长期在这种压力下会产生疲惫、幸福感下降。有研究表明，这不仅会影响代码编写过程的生产力，还会影响结果代码的质量。

所以，我们不要过度关注资源效率类指标，还需要考虑流动效率类指标，比如从产品或团队视角下的需求交付周期、流动速率、流动效率等，后文会展开说明。

3. 使用成熟度评级等基于活动的度量

研发效能应该度量结果而不仅是过程，端到端价值流的局部优化对结果的改进效果很小，因为可能根本就没有解决效能瓶颈。

4. 把度量指标设置为 KPI 进行绩效考核

效能度量显然很重要，企业迫切希望效能提升的愿望也可以理解，但千万不要把指标设置为 KPI 用于绩效考核，因为把度量与绩效挂钩就一定会产生“造数据”的数字游戏。这时，使用效能度量非但起不到正面效果，还会对公司和团队造成伤害。

有个著名的定律称为古德哈特定律，其内容是：当某个度量变成了目标，它便不再是一个好的度量。有朋友也将其戏称为“好心人”定律，效能度量的出发点是好的，但当它演变成了与绩效考核挂钩的 KPI，大家都有追求自己切身利益的动机，那么各种有创造性的、为了提升指标而进行的不优雅的短视行为就会纷纷上演，度量走偏就在所难免了。

其实从理论上讲，所有的度量都可以被操纵，而数字游戏式的度量会分散员工的注意力并耗费大量时间。把度量指标设置为 KPI 进行考核，只是激励员工针对度量指标本身进行优化，这通常比他们在度量之前所做的工作效率要更低。因此，试图把度量武器化为绩效考核，不仅是一种浪费，而且往往适得其反，特别是当薪资与度量的 KPI 挂钩的时候。

那么，如果不把效能度量与绩效考核挂钩，那怎样才能使用度量提高研发效能呢案是：把度量作为一种目标管理方法、一种效能提升的参考工具，促进团队明确效能目标、分析效能问题，指导团队针对性优化，从而最终获得效能提升。比如，对线上缺陷密度的度量和分析，可以让团队了解产品的质量走向和问题的根因，有助于持续优化交付质量；对需求交付周期的度量和分析，可以让团队了解产品端到端交付效率和细化每个阶段的耗时占比，可以针对性的采取干预措施，让团队获得有效的提升。

5. 片面地使用局部过程性指标

我们对于度量指标的理解，有时存在一定的片面性，比如认为某个效率类指标的提升就代表了研发效能的提升。需求交付周期是常见的效能度量北极星指标，在行业实践中引用的比较多。但是，如果一个组织或团队仅仅认为交付快了、周期短了就代表效能提升了，其实这就是一种片面的追求了。

研发效能的提升不仅是有“效率”这一个方面，还有很关键的另外一个部分是“有效性”。软件研发过程中最大的浪费，是构建没有人在乎的东西。我们所谓的效能提升，一定是要从业务目标出发的，构建的功能、质量是需要达到期望要求的，在此基础之上当然效率越高越好、成本越低越好，所以我们说的效能实际上综合考虑了关于产出和投入的多个要素。

回到需求交付周期这个指标的例子，追.求这个指标的优化当然很重要，但是需要在功能有效，吞吐量和质量稳定、安全合规的基础之上才有价值，片面地使用局部过程性指标对于研发效能提升的效果有限，而跳出来看到全局的研发体系和结构才是关键。

6. 手工采集，人为加工和粉饰指标数据

我在建设服务于全集团数万研发的研发效能度量平台时，其中一个最基本的要求就是度量数据的公信力。也就是说，只有在我们这个平台上自动采集、汇聚、计算出来的数据，才是被集团官方认可的，这些数据才可以被用来进行管理和技术决策。我认为这才是一个研发效能度量产品或平台的立足之本。有了这样一个有公信力的平台之后，那些手工处理的 Excel 表格、人工做图的 PPT 胶片，就会慢慢淡出大家的视野。

7. 不顾成本，堆砌大量非关键指标

研发效能的度量不是免费的，为了做到准确、有效的度量，各种成本加在一起是很高的。比如我们经常会去度量团队的需求交付周期及其在设计、开发、测试、部署等每个阶段的时间消耗和占比。这样一个看似简单的度量需求，其实背后要做很多事情。

比如团队的研发流程要定义清晰、每个阶段的完成的定义（DoD）要足够明确、研发管理工具的配置要合理，以及最重要的是，团队中每个人的操作过程要规范并及时。比如某个需求其实已经部署到预发环境了，但在看板系统中的状态还停留在“开发中”，原因可能是开发人员提交代码、测试人员进行验证后，并没有及时同步看板工具中的需求状态。在实际研发过程中，这是很常见的现象，以至于统计发现很多需求的交付周期都是 0 天，因为这些需求都是在开发完成之后，开发人员补录的需求，然后从看板第一个阶段列直接拖动到最后一列，这样统计出来的数据就会有极大地失真。当然，我们应该更多使用自动化的手段来同步状态，比如开发提交、提测、部署等行为会自动触发对应需求状态的流转，但这也需要工具平台开发出对应的能力，实际上也需要成本的投入。

既然度量有这么高的成本，那我们还需要做么的答案是，当收益大于成本的情况下，度量就是值得做的。度量指标应该少而精，每个指标都要追求其投资回 比。

8. 货物崇拜，照搬业界对标的指标

• 代码质量（Quality of the code）

• 工程师注意力（Attention from engineers）

• 智力复杂性（Intellectual complexity）

• 速度与速率（Tempo and velocity）

• 满意度（Satisfaction）

这个指标体系看起来很不错，但是如果一个组织或团队的成熟度还比较低，连最基本的需求流转、敏捷协作都没有做好，上来就引入和对标这些对工程能力和工程师文化有一定要求的指标，很可能适得其反，落入货物崇拜的误区。另外，前两年在 上也有关于高效的工程师每天能写多少行代码的讨论，据说 Google 的工程师平均每天能编写 100-150 行代码。但如果不管其上下文（技术架构、平台能力、工程师级别、协作模式、质量标准、统计口径等），直接使用这个指标来进行对标，一定会搞得工程师苦不堪言。

9. 舍本逐末，为了度量而度量

我们经常说：不要因为走得太远，而忘记了为什么出发。官僚主义的一个问题是，一旦制定了一项政策，遵循该政策就成了官僚主义的目标，而不管该政策所支持的组织目标是什么。研发效能度量是为目标服务的，如果一种度量真的很重要，那是因为它必须对决策和行为产生一些可以想象的影响。

比如软件开发团队的经理希望通过引入新的持续集成系统来提高生产力，这就是一个明确的目标，在初期落地执行时，可能会采用持续集成系统注册用户数这个指标来进行度量。但是系统的使用不是目的，而是提升生产力的手段，我们更应该度量的是应用系统后，是否解决了开发人员对测试快速反馈的需求，质量和效率是否得到了有效提升。

在 Google，使用 GSM（目标/信 /指标）框架来指导目标导向型指标的创建：

• 目标是期望的最终结果。 它是根据从更高层次上理解的内容来表达的，不应包含具体的度量方法的参考。

• 信 是目标达成与否的结果。 信 本身也可能无法度量。

• 指标是信 的代理。 代理的含义是指由于信 本身可能无法量化，因此需要通过指标来  代理信 的量化。指标是一定可度量的内容。

举个例子，比如企业希望代码的可读性提高，这样可以得到更高质量、更一致的代码，也能促进健康的代码文化，那么按照 GSM 框架：

• 目标：由于可读性的提高，工程师编写了更高质量的代码

• 信 ：可读性过程对代码质量有积极的影响

• 指标：可读性评审对代码质量没有影响或负面影响的工程师比例、参与可读性过程并改善了其团队的代码质量的工程师比例

10. 仅从管理角度出发，忽略了为工程师服务

在与国内一些企业的交流中我发现，很多公司的研发效能度量都是主要从管理者的视角出发的，无论是工时、人员饱和度等衡量资源利用率的指标，还是需求交付周期、吞吐量等衡量流动效率的指标，本质上都是从管理维度看待研发效能这件事情。但是在前文中我也提过，我们不应该把员工当成一种”资源”，而是要作为”工程师”来看待。员工幸福感的下降不仅会影响代码编写过程的生产力，还会影响结果代码的质量。

所以我们做研发效能提升，本质上还是要多关注工程师的感受，他们对工作环境、工作模式、工作负载、研发基础设施、项目协作、团队发展、个人提升是否感到满意，是否有阻碍工程师发挥更大创造性和产生更大生产力的因素存在。工程师个人效能的有效提升是组织效能提升非常关键的组成部分。就像 Facebook 会把“不要阻塞开发人员”作为贯穿公司研发和管理实践中的核心原则之一，就是强调公司流程和实践也要从工程师视角来考虑问题。

那么，我们如何度量工程师的满意度呢们可以选择 eNPS（Employee Net Promoter Score）来衡量员工的忠诚度，更高的员工忠诚度可以让工程师提供更卓越的服务，让客户满意，最终助力企业业务的成功。当然，我们不仅关注 eNPS 指标的数值本身，还可以将其与其他人力资源指标结合起来，这样就可以知道为什么员工会给出负面反馈，这将揭示表象背后的原因，并帮助管理者寻找改进的方法。

小结

研发效能度量“难不难”和“做不做”是两回事情，正因为其蕴含的巨大价值，我们还是要想办法去探索和实践。在下一篇文章中，我会具体介绍 BAT 等多个“互联 大厂”和业界标杆企业的效能度量案例，并总结和提炼出其中隐含的度量设计思路和关键原则。敬请期待！

系列文章推荐阅读：研发效能启示录

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92731 人正在系统学习中