古德哈特定律：当指标变成目标
"当一个指标变成目标时，它就不再是一个好指标。"——任何被用来衡量绩效的指标，最终都会被"玩坏"。
**预计时间：**25 分钟读完 + 25 分钟做练习 = 50 分钟。
一、古德哈特定律的运作机制
1.1 指标的”测量-扭曲”循环
- 设定指标：“我们要用代码行数来衡量开发效率”
- 指标变成目标：开发人员开始关注”怎么产出更多代码行数”
- 行为扭曲：不用更简洁的代码，写更冗余的代码；一个函数能解决的写成 5 个
- 指标上涨但真实目标下降：代码行数涨了，但代码质量、可维护性、开发速度都下降了
- 指标失效：原来用来衡量”效率”的指标，现在跟效率没关系了
二、科技/项目中的经典例子
| 指标 | 本意 | 扭曲行为 | 结果 |
|---|---|---|---|
| 代码行数 | 衡量开发效率 | 写冗余代码、复制粘贴 | 质量下降 |
| Bug 修复数 | 衡量 QA 效率 | 只报小 Bug、不抓大问题 | 严重 Bug 被忽略 |
| 任务完成数 | 衡量团队产出 | 把大任务拆小、选简单的做 | 真正的重点任务被推迟 |
| 用户满意度评分 | 衡量服务质量 | 诱导用户给高分 | 分数虚高，真实满意度不变 |
| SLA 达标率 | 保证服务可靠 | 把 SLA 定得宽松、规避风险操作 | 系统稳定但不敢做有价值的变化 |
| 合代码速度 | 衡量迭代速度 | 减少代码审查、降低质量要求 | 线上 Bug 增多 |
| DAU 增长 | 衡量用户活跃度 | 刷量、推送轰炸、做签到活动 | DAU 涨了业务没涨 |
三、如何对抗古德哈特定律
3.1 用”指标 + 定性评估”的组合
不要只用一个指标做判断。比如评估团队效率：代码行数 + 代码审查质量 + 线上 Bug 率 + 用户满意度（综合判断）。单一指标很容易被扭曲，多指标组合扭曲难度大大增加。
3.2 指标是信号，不是目标
指标告诉你”可能有问题了”——但不能替代你去看真实情况。当 DAU 下降时，你的反应不应该是”想办法提升 DAU”，而是”去了解用户为什么不用了”。指标是指南针，不是目的地。
3.3 定期验证指标-目标相关性
每季度检查：我们在用的指标，和它本应衡量的”真实目标”，还有相关性吗？如果相关性已经消失了（因为行为扭曲），那就废弃这个指标，换一个。
3.4 不要用指标来激励”超越”
如果销售目标是 100 万，团队做了 120 万——那下个季度目标就涨到 150 万。这会激励团队”刚好达标不超额”。更好的做法：设定目标时用”及格线”（必须达到）+“超额奖励”（超出部分有额外激励）。
四、实战案例
4.1 案例 1：SLA 指标的反效果
一个 OTP 系统的 SLA 目标：99.9% 可用性。运维团队的责任。团队怎么做？
- 不做任何有可能影响稳定性的变更（版本升级、安全补丁、架构优化）
- SLA 达标了 99.95%——但系统越来越脆弱（因为长期不打补丁）
- 最终因为一个已知漏洞被利用，宕机 8 小时
问题：SLA 指标只衡量了”正常运行时间”，没有衡量”系统健康度”和”风险积累”。
改进：SLA + “安全补丁更新时效” + “变更频率”三个指标一起看。
4.2 案例 2：用户故事点的”通胀”
产品团队用”故事点”来估算工作量。每 Sprint 的”故事点完成数”被用来衡量团队效率。结果：
- 团队开始把每个用户故事估得更大——“既然完成 30 点算优秀，我干脆每个故事都估成 5 点而不是 3 点”
- 或者：把大故事拆成很多小故事（每个故事点数小但数量多）
- 故事点”通胀”了——30 点的 Sprint 不再等于 30 点的真实工作量
改进：故事点只用于团队内部的估算——不要用来做跨团队的比较或绩效考核。
4.3 案例 3：“零 Bug”目标的悖论
某项目把”零线上 Bug”作为质量指标。结果：
- 团队不敢发布任何可能有风险的更新
- 测试人员在发现 Bug 后选择不提（瞒报），因为提了会影响团队指标
- 线上 Bug 确实少——但产品更新极慢，而且积累了很多没被记录的问题
改进：不追求”零 Bug”（那是不可能的）——而是追求”快速发现和修复 Bug 的能力”（平均发现时间、平均修复时间）。
五、测验（11 题）
古德哈特定律的核心是？
为什么代码行数不是好的效率指标？
古德哈特定律告诉我们指标的定位应该是？
下面哪种做法能最有效对抗古德哈特定律？
"DAU 涨了 20%——但我们发现是因为团队做了很多签到活动，真正的核心功能使用没变"——这是？
团队把用户故事从 3 点估成 5 点——本质上是？
为什么"零 Bug 目标"会适得其反？
芒格关于"激励"的论述和古德哈特定律的关系是？
"SLA 达标但系统长期不打补丁"——这说明了？
对抗古德哈特定律，管理者最重要的是？
场景题
R1. 场景：领导提出"我们要把所有 API 的响应时间降到 100ms 以内"作为团队 KPI。你担心古德哈特定律——应该怎么办？
R2. 场景：公司把"需求交付数量"作为 PM 团队的 KPI。你预感到了什么？
六、答题提示
展开提示
- Q1-3 核心：指标 → 目标 → 扭曲 → 失效。
- Q4-5 多指标 + 定性评估 = 对抗扭曲的最佳防御。
- Q6-7 故事点通胀和零 Bug 都是古德哈特的经典表现。
- Q8-10 激励结构 = 行为方向——这是芒格和古德哈特的共识。
- R1-R2 单一指标必有扭曲——组合使用才有效。
七、本课行动清单
- 列出你和你的团队最近使用的 5 个 KPI/指标——每个指标问：“如果把指标当目标，团队会怎么优化它？这会导致什么扭曲？”
- 对你最重要的那个指标，加一个”制衡指标”——防止目标被单方面扭曲。
- 在团队中发起一次”指标健康度对话”：哪些指标还有效？哪些已经”坏”了？
- 作为管理者或 PM，不要只看报告——定期去一线了解真实情况，验证指标是否仍然反映现实。
八、参考来源
- ② 经典：Charles Goodhart，“Problems of Monetary Management”（1975）——古德哈特定律的原始论文
- ③ 严肃著作：Marilyn Strathern，“Improving Ratings: Audit in the British University System”（1997）——将古德哈特定律推广到更广泛的领域
- ③ 严肃著作：Daniel Kahneman，《Thinking, Fast and Slow》——关于指标和认知偏差的关联
- ④ 实用读物：Jerry Z. Muller，《The Tyranny of Metrics》——指标如何侵蚀商业、医疗、教育领域
**下一步：**看 Lesson 0017 · 帕金森定律。