停止衡量开发者生产力，开始衡量决策速度

眼下软件工程中最危险的指标，并不是一个糟糕的指标，而是一个让人分心的指标。

我们仍在用 2015 年的方式来衡量开发者生产力：commit、PR、故事点、周期时间。这些都无法告诉你，你的工程组织是否在做正确的决策。而在 AI 时代，决策质量才是唯一重要的指标。

为什么传统指标会失效

AI 已经把写代码的成本压缩到接近为零。一个做出错误架构决策的团队，现在可以以两倍的速度交付错误的系统。他们可以为错误的抽象生成更多测试。他们可以在错误的地基上构建更多功能。

传统的生产力观念假设产出越多价值越大。这个假设已经破产了。当代码变得廉价，错误的决策就变得昂贵——而那些衡量产出的指标永远抓不住它们。

决策速度究竟意味着什么

决策速度不在于更快地做决定，而在于更快地收敛到正确的决定，并减少代价高昂的反复。

我通过四个信号来衡量它：

1. 决策速度: 做出一个可逆决策需要多长时间？（应当是几小时，而不是几天。）

1. 决策质量: 在 90 天内有多少决策被推翻？推翻的代价是什么？

1. 决策分布: 组织中有多少人被授权无需升级即可做出技术决策？

1. 决策复利: 今天的决策是在让明天的决策变得更容易，还是更困难？

当你开始衡量它时会发生什么变化

当你开始衡量决策速度时，有几件事会发生变化：

• 架构评审变得更快，因为在人们争论之前，基线信息已经建立

• 升级模式变得可见——你能确切看到决策在哪里被卡住以及为什么

• 推翻成本变得明确——团队开始衡量错误决策的成本，这会改变他们评估风险的方式

• 权限边界变得清晰——你能看到哪些决策在哪个层级做出，以及这种分布是否健康

取代冲刺指标的看板

我不在乎我的团队在上一个冲刺完成了多少个故事点。我在乎的是：

• 为这项新服务确定架构花了多长时间？

• 那个决策被推翻了吗？如果被推翻，代价是什么？

• 有多少技术决策是在没有工程领导层参与的情况下做出的？

• 从“我们遇到了问题”到“我们有了解法”的平均时间是多少？

这些才是能预测工程结果的指标。Commit 什么都预测不了。

最难的部分

衡量决策速度需要信任。它要求承认有些决策是错的，并公开地从中学习。大多数工程文化会惩罚错误的决策。而衡量决策速度要求恰恰相反：把推翻当作数据呈现，而不是当作失败。

做得好的团队会创造出一种文化，让“我错了”成为决策系统正在正常运转的信号。做得不好的团队会继续为产出速度而优化，而他们的竞争对手则在为学习速度而优化。

从这里开始

挑一个最近没有走通的决策。问问自己：我们花了多长时间才意识到它是错的？什么本可以更早地暴露这个问题？我们漏掉了哪个信号没去衡量？

那个缺口，就是你决策速度的所在。

你更愿意待在一个交付快但经常反复的团队，还是一个交付审慎、持续向前学习的团队？

觉得这套论述适合你的活动吗？跟我说说那个场合—— 日程是有选择的.