如何避免度量指标变成“造假”指标

本文写于2022年1月20日，作者：刘佳、于晓南
晓南整理文稿时，在保留原意基础上稍有修改。

为什么聊这个话题？

今天想跟大家聊聊如何避免度量指标变成“造假”指标。

开发团队在落地研发效能相关实践、尝试提升研发速度与开发质量时，常常会制定一些度量指标，如测试覆盖率、流水线构建时长和迭代速率等。这些度量指标在制定之初被寄予厚望，期望能引导团队落地实践并提升研发效能。然而，结果往往事与愿违。

例1：某团队选取代码行数来度量程序员的工作量，以期提升交付速度。然而，施行后不仅交付速度未得到提升，代码中还出现了大量冗余。

例2：某团队制定了高标准的测试覆盖率指标，用以驱动开发人员写自动化测试，进而提升软件质量。施行一段时间后，测试覆盖率高达99%，但软件质量没有任何提升，还多出了一堆只要运行就必定通过的测试。

相信大家对上述场景并不陌生。我们不禁要问：为什么度量指标常常陷入“上有政策，下有对策”的困境？我们该如何应对？要解决这个问题，我们需要逐一讨论以下几点：

1. 使用度量指标的目的是什么？
2. 度量指标是否应与绩效挂钩？为什么？
3. 如何制定/使用度量指标来帮助团队达成目标？

使用度量指标的目的是什么？

先来看几个常见的度量指标的设定目的：

1. 测试覆盖率：期望提升代码质量
   制定者期望开发人员能编写自动化测试，在编码阶段就考虑代码的可测性。这不仅可以获得全面且能快速发现问题的自动化测试，还能促使开发人员在编码时进行更深入的思考。从整体来看，这种做法可以提升代码质量。

2. 研发代码行数：估算开发人员交付速度
   制定者希望能衡量开发人员的产出效率，认为代码行数在一定程度上能反映程序员的交付速度。他们计划根据交付速度给予不同的激励，以此提升团队的开发效率。

3. 测出的缺陷数量：期望提升最终上线产品的质量
   制定者希望测试人员能在上线前尽可能地发现产品问题，以避免上线后出现重大问题或影响用户体验。

观察这些度量指标及其目的可以发现，常见的度量指标带有两类目标：

1. 促进某件事情的达成、落地
   如：提升代码质量、估算交付速度、提升产品质量

2. 驱动目标群体发生期望的行为转变
   如：开发人员写自动化测试、交付更多功能，测试人员更详细的检查产品

那么我们在工作中使用到的度量指标是否都能达成这两类目的呢？答案是否定的。

1. 为什么没法促进事情的达成、落地？制定的度量指标不能正确反应你想达成的事情的状态。
如：代码行数越多，并不能反应开发人员工作效率高、单位时间交付的功能多。测试测出的缺陷数量多，也不能保证上线的产品质量好，在某些情况下甚至标志着产品质量过低。不然怎么能测出这么多bug？

2. 为什么没法驱动目标群体发生期望的行为转变？忽略了人的自主性，把知识工作者当体力工作者管理。

接下来我们可以详细讨论下该怎么做才能让度量指标达成目标。

度量指标是否应与绩效挂钩？为什么？

度量指标最好不要与绩效挂钩。

将度量指标与绩效挂钩，采用“胡萝卜加大棒”的方式来驱动目标群体按规定工作，对软件开发团队而言效果并不理想。

工业革命后，泰勒的科学管理为提升绩效和生产力做出了卓越贡献。其核心观点之一是“胡萝卜加大棒”能确保工人按预期方式工作。泰勒主张尽可能减少车间里的“各种脑力工作”，“以看待机械部件的眼光来看待组织中人的作用”，认为车间工人不应拥有任何主动精神。

然而，21世纪以来，劳动主体逐渐由体力工作者转变为知识工作者——软件开发就是典型的知识工作（彼得·德鲁克《21世纪的管理挑战》）。如果我们仍然使用泰勒这种否定一线工作者自主性和脑力活动重要性的方法来管理软件开发人员，显然是不合适的。

那么，如何驱动软件开发人员呢？可以关注三个关键词：

• 自主：我做什么我决定 -- 给予开发团队一定的自主权
• 专精：我把想做的事情做得越来越好 -- 相信开发团队想把事情做好
• 目的：我超越自身的渴望 – 相信开发团队愿意持续改善和精进

下面我们聊聊在度量指标制定时，如何落实这三个抽象的关键字。

如何制定与使用度量指标，帮助团队达成目标？

度量指标最好不要与绩效挂钩。相反，它应该作为一种进度标识，告诉我们距离目标还有多远。我们应将度量指标视为帮助达成目标的工具，而非目标本身。

在制定和使用度量指标时，建议考虑以下四个关键词：

• 团队共识
• 目标可行
• 小步成功
• 定时检查

接下来我们逐一讨论。

1. 团队共识

很多团队在使用度量指标时，常由单个人独断专行，其他成员只能被动接受。有时，团队成员甚至不清楚这些指标究竟要解决什么问题。这样制定出来的指标往往难以帮助团队解决实际问题。

从驱动力的角度来看，知识工作者更渴望自主——我做什么，我决定。在与团队达成共识的过程中，让每个人都能发挥自主性至关重要。只有这样，最终达成的一致解决方案才会被团队成员视为“我决定”的方案。

2. 目标可行

作为研发团队负责人，如果真心实意想推行一项实践，制定的目标必须适配团队现状，让团队能够达到。假如他制定的目标团队明显达不到，说得好听点，他可能陷入了逻辑悖论；说得难听点，这不就是自欺欺人吗？

所以，制定不可行的目标，就是在明明白白的告诉大家：我是闹着玩的，这个目标大家就看个热闹得了，年底总结的时候编一编就可以交差了。正所谓：人有多大胆，地有多高产。领导都这么号召了，大家不响应实在过不去。

看到这里，可能有些伙伴会着急了：“我是真心想达到90%的测试覆盖率啊！不这么定目标还能怎么办？” 别急，咱们继续讨论。

3. 小步成功

我们喜欢说一句话：Think big, start small and move fast. 可以理解为：志存高远，小步前进，快速迭代。

公司经常会接遗留系统重构的项目。我们曾经接手过一个开发了十年的系统，需要一边添加新功能，一边重构原有代码。注意，这里说的“重构”不是“重写”，两者有本质区别。了解重构的人都知道，重构需要有足够的测试覆盖。因此，给这个老系统添加自动化测试是我们必须解决的问题。

怎么解决呢？定一个90%的测试覆盖率目标，然后开始拼命加班？显然不合适。十年的老系统，即使连续加班三个月，也不一定能达到。不，不是不一定，而是肯定达不到。这样做只会打击团队的信心和积极性。

对于这种情况，我们的做法是：90%的测试覆盖率是一个灯塔，一个长期目标。为了让大家能真切的体验到自己在前进，项目开始的时候，我们将目标定为：每次提交都比上次提交测试覆盖率要高，那怕只高0.1%，那也是成功。

小步成功就和大家玩游戏一样，有短期的、频繁的正向反馈，才能促使团队长期坚持一项改进。

4. 定时检查

谈到定时检查，大家很容易想到的是定期检查目标是否达到。其实我想强调的是，我们需要定期检查度量指标是否仍能给我们提供正确、合适的反馈。

近两年，许多客户都在内部推行代码审查这一实践。为了让这个实践真正起效，他们在推行初期会制定一个度量指标：单次代码审查发现的问题数量。推行代码审查的初衷是提升团队代码质量，这个指标起初确实能帮助团队评估代码审查的有效性。

然而，推行后三到六个月，客户们都出现了相同的现象：每次代码审查都发现不了问题了。这是否意味着大家的代码质量都变得非常好，没有任何可改进的地方了吗？显然不是。事实上，大家的代码质量仍有相当大的改进空间。

真正的原因是什么呢？实际上，在代码审查推行初期，团队发现的问题大多会转化为编码规范。经过一段时间的反复反馈，团队成员都熟悉了这些规范，自然就不会再犯同样的错误。如果团队想进一步改进代码质量，就需要提升整体的软件设计和软件工程能力。此时，如果仍然使用“单次代码审查发现的问题数量”作为度量指标来促进代码质量的提升，就无法提供“合适”的反馈了。

度量指标在制定时可以提供正确、合适的反馈。但随着时间流逝，我们的情况会发生变化：团队成员能力可能会提升，软件可能会变得更复杂，旧问题会消失，新问题会出现。度量指标也会随之失效。正如古语所言：“逝者如斯夫，不舍昼夜。”

随着团队状态的不断变化，度量反馈的敏感度和有效性也在动态调整。因此，定期检查度量指标是否仍能为我们提供准确、适当的反馈变得尤为重要。

总结

回到最开始的问题：“如何避免度量指标变成造假指标？”

我们聊了以下几点：

• 度量指标不应与绩效挂钩
• 度量指标是工具不是目的，目的是解决问题、改善现状
• 度量指标的制定与使用方式，应遵循四个原则：团队共识、目标可行、小步成功、定时检查