许多著名的定律因其发现者而得名，牛顿定律、欧姆定律、墨菲定律。然而，对软件度量的人来说，最重要的，是不太为人所知的古德哈特定律。

古德哈特定律是由英国央行顾问、后来的伦敦经济学院教授、诺贝尔经济学奖获得者（1995）——查尔斯·古德哈特Charles Goodhart，于1975年7月，在其给澳大利亚储备银行的论文中提出的。论文中并没有明确给出定律的定义。所以，对于这个定律也有着不同的理解。较为常见的有以下三种：

一、古德哈特教授自己写的《货币理论与实践》：任何观察到的统计性规律，一旦为着控制的目的而被施加了压力，都将失去其规律性。

二、1990年出版的《皮尔斯百科全书》：一旦政府视图控制任何一个特定的金融产品时，它们作为经济发展趋势指示器的作用就会变得不再可靠。……因为金融机构可能……很容易发明出新的金融资产形式。

三、不列颠学会（FBA）会员马里利安·斯特拉瑟恩：当一个度量标准成为调控目标时，它就不再是一个好的度量标准了。

在经济学中，能称得上“定律”的，并不多见。古德哈特定律便是其中一个非常著名的。它在经济学上的影响逐渐渗透到了其他学科，被解读为“当一个指标变成目标，它将不再是一个好指标”。因为，变成既定目标的指标，会因为目标而失去它原有的信息价值。

从软件度量的角度来说，当一个度量指标成为项目目标时，它就不再是一个好的度量指标了。因为工程师会有一种倾向，通过某种有利的方式调整编码行为，从而达成目标。

一个典型的例子是度量代码行（LOC）。代码行是软件规模的常见度量项，对软件项目的策划与监控都极具价值。一旦项目经理，或者更高层级的管理者将LOC作为开发人员的KPI时。他们就会被“激励”，从而编写更多，但效率低下的代码。根据这样的LOC数据，估算、策划和监控项目时，就会因为度量数据缺乏客观的信息价值，而无法起到实际的管理效用。

如果你觉得LOC太“老派”，我们举个敏捷的例子。

User Story是sprint估算的基础，可以用来反映敏捷团队的完成项目的速度。起初，它被用来预测发布时间。现在，它不仅已经成为开发团队要实现的目标。PO甚至更高层级的管理者试图推动团队的高绩效。于是，单位时间内完成了多少story（即速度）的指标，便成了很多敏捷团队的工作目标。接下来便会发生story的“通货紧缩”——单个story的规模会越来越小，用来描述同一软件产品的story会越来越多。团队在单位时间内完成的story数量的指标上去了，但管理者希望加快速度的目标却并没有达成。

我写这篇文章的出发点，不是为了提醒管理者留心“绩效造假”的可能性，其实很多时候，这样的状况也压根谈不上“造假”。但是“上有政策，下有对策”是普遍存在的社会现象。古德哈特定律就是社会科学中的“测不准”原理。它并不否定指标的重要性，而是指出了一个深刻的悖论，指出在政策制定与执行中存在一个博弈的过程。

拉回到软件项目的环境中，不是不能度量，也不是不能考核。我建议在进行有针对性的过程改进时，只度量、不考核，以指标变化客观评价改进成果。而当改进已经稳定，需要考核时，要考虑度量对不同利益主体的影响，达到利益的高度统一。

还是举敏捷中提高速度的例子。在某个项目的执行阶段，管理者提出提高开发速度从而提前交付的目标。开发团队按照验收标准，成功提前交付便可获得奖励。我们仍然用story度量开发速度。平均每个sprint完成story最多的个人，可以获得额外的奖励。

在这种情况下，团队为了按标准提前交付，就不会浪费时间写更多的story来撑大速度指标，也不会一味追求速度而少写story。一旦项目的规模（story的数量）得到了控制，为了节省时间便只能提高效率。度量开发人员的编码效率这个指标，就可以有效激励开发人员，支撑提高开发速度的目标。

到这还不算完。为了提前交付，团队可能会在进行下一个项目策划时，多估算规模，从而拉长交付周期，达到提前交付的目标。这个时候，管理者可以借助以往项目的历史数据，以及设立同行评审的机制，对规模的合理性进行评价，并将这样的评价机制，作为项目策划环节的常规审查机制，纳入标准工作过程中。如此制定的度量，不仅可以支撑管理目标，还能积累到比较客观的项目数据。当管理目标变化时，管理者仍能找到有效的办法，使得管理朝着目标迈进，而不会失去效用或者适得其反。

参考文献：《古德哈特定律的博弈分析》林海，《The Problem with Software Measurement and Metrics》Lee Copeland