寻找合适的研发效能度量指标（中）

• 研发效能度量指标（1）
• 研发效能度量指标（2）
• 研发效能度量指标（3）

---

上篇中，咱们尝试回答了最近几年 “软件研发效能” 为什么会成为业界的热词 “Buzzword” ，有哪些合适的软件研发效能度量指标这两个问题。下篇 希望根据业务的情况，界定的团队上下文，给出一些推荐的度量指标。为了让这些内容更加有上下文和代入感，这里加入本文作为中篇，在本篇里聊聊我在一线开发过程中对效能的三个观察和观点。

观察和观点一：莫让度量变目标。

经济学家查尔斯·古德哈特在1975提出了古德哈特定律 : When a measure becomes a target, it ceases to be a good measure. “当一个度量本身成为目标时，它就不再是一个好的度量”。根据我们在项目中的观察和经验，古德哈特定律不光适用于经济学领域，一样适用于软件研发领域。

此定律在现实中的故事: 在法国殖民时期的越南，鼠患成灾，所以当地政府想出办法: 鼓励民众一起动手灭鼠并奖励灭鼠的民众，民众只需要上交死老鼠的尾巴就可以获得奖励。不久之后，越南的街头就出现了没有尾巴的老鼠，人们为了持续盈利，并没有杀死老鼠，而只是切下它的尾巴，等待它去生新老鼠给自己赚钱。

在正常情况下，「被切下的老鼠尾巴的数量」与「死去老鼠的数量」正相关，是一个好的指标。可是，一旦政府把「被切下的老鼠尾巴的数量」变成大家的优化目标，就会产生未曾预料到的结果。简单来说，这种度量变成了目标，驱动并产生了“上有政策，下有对策。”

在软件研发领域里，当你度量团队产出的代码行数并设置目标时，比如: 800行/人天，聪明的程序员，就会被驱动去优化「代码行数」并让它达到目标。比如: 多加点中间变量，多加点注释，多抽点方法和测试，目标不就达成了吗? (曾见过方法实现只有两行代码，注释20多行，而且在工程里经常看到类似的注释和方法。) 这种目标度量会给业务带来价值吗?

再比如你度量并设置团队每个迭代需要完成Story的点数或者个