古德哈特定律与敏捷开发
在我多年的工作中，我不停地看到在成功的现代组织中，管理人员对制定考核指标和衡量考核指标的理解日益加深。
不过在有些时候，我也看到对于考核指标的滥用，在实践中出现意想不到的结果。
与之而来带来的更有破坏力的后果是，企业将重点放在流程执行上，而不是衡量行为造成的最终结果，进而就有可能闹出南辕北辙的笑话。
荒谬的衡量指标，无厘头的结果
前苏联有一个关于工厂经理的经典故事，这位工厂高管想让他的员工做更多的事情 - 因此他决定工人生产的钉子数目来衡量工人的劳动成果。
很快，他就得偿所愿 - 他发现员工正在生产大量小钉子，小到其实没有办法使用。
他迅速决定用新的衡量指标来解决这个问题 - 生产钉子的重量，结果第二天他发现员工开始生产了不少的大而重的钉子。
这个故事其实想说的就是古德哈特定律 - 正如玛丽莲·斯特拉瑟恩（Marilyn Strathern）所说：“当一项措施成为目标时，它就不再是一项好措施。”
古德哈特定律（Goodhart’s law），是以 Charles Goodhart的名字命名的，这是一个非常有名的定理：当一个政策变成目标，它将不再是一个好的政策。作为前英格兰银行的建议者，提出：当政府试图管理这些金融财产的特别标识时，它们便不再是可信的经济风向标。他在1975年的文章中首次提出，后来便成为批评英国的扩张或紧缩的货币政策的重要依据。
古德哈特定律，或者说是古德哈特陷阱
在实际工作中，如果不了解古德哈特定律而仓促建立度量标准，就可能驱动那些带来非预期结果的行为。。。。
以下是我经历过的一些场景，这些场景与敏捷开发和技术支持有关：
场景1：注重Sprint的绝对成功而导致保守
我在上家公司见过某个团队，该团队对每个sprint的绝对成功有偏执的追求，也就是说每个Spring结束的时候，每个Story都是完全交付的。而且这个团队将其直接与Scrum团队员工的绩效挂钩。
当时这项措施的目标是鼓励团队尽一切所能达到承诺，按期交付，为客户带来价值。在实施过程中，逐渐古德哈特定律这个幽灵出现了，结果导致Scrum团队倾向于高估了Story需要的人力和资源投入，非常保守的计划在Sprint中每个Story，成员害怕承担可能导致风险的新方案新设计，即使这些新方案新设计在业界已经得到验证。
场景2：重视Ticket响应的数目，而不是质量
这个经典的场景发生在服务支持团队中。服务支持团队需要遵守服务水平协议（SLA），因此我见过很多服务团队的管理人员制定问题响应时间和问题解决时间这两个指标来衡量服务支持团队。
这样的话，服务团队管理人员推动他的团队更快地做出响应。但其实这并不一定是客户期望的度量标准。对客户而言，他需要的是Bug更少的产品。
服务团队管理人员无需建立更多流程来快速响应客户，他们更需要集中精力与产品研发团队一起找出导致客户问题的根本原因，并支持研发团队解决它们。
场景3：将测试数量作为质量指标
第三个场景是一个研发团队，该团队用创建的测试总数来衡量代码与产品质量，目的是增加代码覆盖率并确保代码都经过测试。
我们看到的大量的类似的测试用例代码执行，每次测试之间的输入数据只有很小的差异 - 测试一个功能，组件或场景数百次，而所有测试基本上只测量某些核
心场景，没有充分确保这些测试遍及所有代码，也没有确保这些测试能有效衡量代码的质量。
结语
这些场景（还有更多类似场景）往往背后都有共同的原因。原因是管理者更关心指标而不是结果，每当他们意识到自己的指标或过程导致一个未预期的后果时，就会引入更多的指标，过程和控制来作为应对措施，控制员工并要求其贯彻这些措施，期待实现最终结果。
因此，下次您需要设置一些可衡量的目标时，请确保执行以下操作以避免古德哈特定律陷阱：
- 以终为始
- 小心古德哈特定律
- 衡量结果，而不是措施
- 制定清晰的愿景
- 避免因缺乏信任而采取的措施
最重要的还有一点，己所不欲，勿施于人。
参考：
