指标剧场：当Dashboard全是绿色，产品却在死亡
去年我见过一个团队，他们的监控大屏挂在办公室最显眼的位置：API响应时间95分位数12ms，错误率0.03%，测试覆盖率89%，部署频率每天4.2次。所有指标都是绿色的。三个月后，这个产品被关停了。
不是因为技术问题。是因为没人用。
这不是个例。这是现代软件开发的系统性疾病，我称之为指标剧场（Metrics Theater）——团队花费大量精力优化可测量的东西，而真正重要的工作在指标之外悄悄死去。
Goodhart定律的技术实现
经济学家Charles Goodhart说过："当一个指标成为目标，它就不再是一个好指标。"在软件工程里，这句话的技术实现是：任何可以被测量的东西，都会被优化；任何被优化的指标，都会失去它原本要衡量的意义。
举个例子。你设置了"代码审查响应时间"这个指标，希望提高团队协作效率。很快你会发现，工程师开始在收到PR通知后立即点开、留一个"LGTM"、然后关掉。响应时间从平均6小时降到了15分钟。指标变绿了。但代码质量呢？没人真正在看。
这不是工程师的道德问题。这是系统设计的必然结果。当你告诉一个智能体（无论是人还是AI）"这个数字很重要"，它会优化这个数字。至于这个数字背后原本想衡量的东西？那是另一个问题。
更糟糕的是，现代监控工具让这种优化变得前所未有的容易。Datadog、Grafana、New Relic——它们都很优秀，但它们也让"让dashboard变绿"成为了一种可以脱离实际工作独立存在的活动。你可以花一整天调整告警阈值、优化查询性能、美化图表，而完全不碰产品代码。
管理者为什么更相信数字而不是产品
这里有一个更深层的问题：为什么管理者会陷入这个陷阱？
因为数字是确定的，而产品质量是模糊的。当你问一个工程师"这个功能做得怎么样"，你得到的答案可能是"还行吧，但有些边界情况没处理好，用户反馈也不太清楚"。这种回答让管理者焦虑——它没有给出明确的信号，没有告诉你是该继续投入还是该砍掉。
但如果你问"测试覆盖率多少"，答案是"87%"。清晰、可比较、可追踪。上周是84%，这周是87%，进步了3个百分点。这个数字让人安心——它给了你一种控制感，一种"我们在进步"的确定性。
问题在于，这种确定性是虚假的。测试覆盖率87%不能告诉你：
- 这些测试是否测了关键路径，还是只是为了凑数字
- 产品的核心价值主张是否被验证
- 用户是否真的愿意为此付费
- 技术债务是否已经积累到了临界点
但管理者需要在董事会上汇报进展。"我们的测试覆盖率提升了3个百分点"比"我们修复了一个用户很少遇到但一旦遇到就会导致数据丢失的边界情况bug"更容易讲。前者是成就，后者听起来像是在承认之前有问题。
于是整个组织的激励机制开始扭曲。工程师学会了优化指标而不是优化产品。因为优化指标有明确的反馈循环——dashboard会立即变绿，周报会立即好看。而优化产品？可能要几个月后才能看到效果，而且效果还不一定能被量化。
认知陷阱：为什么大脑偏好数字
这不只是管理问题，这是人类认知的底层缺陷。
人类大脑进化出来的能力是处理具体的、即时的威胁——比如一只老虎，或者一个敌对部落。我们不擅长处理抽象的、延迟的、多因素的复杂系统。所以当面对"这个产品是否在正确的方向上"这种问题时，大脑会本能地寻找简化的信号。
数字就是这种简化信号。它把复杂的现实压缩成一个可以快速处理的符号。87%、12ms、0.03%——这些数字让大脑感到舒适，因为它们看起来是客观的、可验证的、不需要进一步思考的。
但产品质量不是一个数字，它是一个多维的、动态的、上下文相关的判断。一个功能可能在技术指标上完美，但在用户体验上是灾难。一个bug可能在错误率统计中微不足道，但它恰好影响了你最重要的客户。
这种判断需要的不是数字，而是品味（taste）——对产品、对用户、对市场的深度理解。但品味是不可测量的，所以它在指标驱动的组织里没有生存空间。
三个真实案例
案例1：代码行数的诅咒
某公司设置了"每周代码提交量"作为工程师绩效的参考指标。结果？工程师开始拆分commit，把一个功能拆成10个小PR。更糟的是，有人开始写冗余代码——能用一行解决的问题，写成十行。代码库膨胀了40%，但没有任何新功能。
案例2：响应时间的幻觉
某团队被要求把API响应时间从200ms降到50ms。他们做到了——通过在前端加缓存，在后端加异步处理。用户体验变好了吗？没有。因为真正的瓶颈是数据一致性问题，而异步处理让这个问题变得更隐蔽、更难调试。六个月后，他们花了三倍的时间来修复由此引发的数据不一致bug。
案例3：测试覆盖率的骗局
某创业公司为了融资，需要展示"工程质量"。他们在两周内把测试覆盖率从60%提升到95%。投资人很满意。但这些新增的测试大部分是trivial的——测试getter/setter、测试常量、测试框架自带的功能。真正的业务逻辑？依然没有被充分测试。产品上线后，核心支付流程出现了严重bug，导致用户投诉激增。
解决方案：建立指标的免疫系统
我不是说不要用指标。指标是必要的。但我们需要建立一套指标的免疫系统，防止它们被滥用。
1. 定期进行"指标审计"
每个季度，团队应该坐下来问：我们追踪的这些指标，真的在衡量我们关心的东西吗？还是它们已经变成了自我目的？如果一个指标在过去三个月里没有引发任何有意义的行动，删掉它。
2. 建立"反指标"机制
对于每一个正向指标，设置一个反向指标来制衡。比如，如果你追踪"功能交付速度"，同时追踪"生产环境回滚次数"。如果你追踪"代码审查响应时间"，同时追踪"审查后发现的bug数量"。这样可以防止单一指标被过度优化。
3. 保留"不可量化"的评估空间
在每次产品评审中，留出时间讨论那些无法被量化的问题：用户的情绪反馈、团队的直觉、长期的技术债务。这些讨论不应该被"数据驱动"的口号压制。有时候，最重要的信号恰恰是那些无法被测量的。
4. 让决策者直接接触产品
管理者应该定期使用自己的产品，阅读用户反馈，参与客户支持。不是为了微观管理，而是为了建立对产品质量的直觉。这种直觉无法从dashboard上获得，但它是判断指标是否有意义的唯一方法。
最重要的工作往往是不可测量的
这是这篇文章的核心论点：最重要的工作往往是不可测量的，而这正是它重要的原因。
重构一个混乱的模块，让代码变得可维护——这很难量化，但它决定了团队未来两年的开发速度。
花时间理解用户的真实需求，而不是他们表面的要求——这无法进入sprint报告，但它决定了产品是否能找到product-market fit。
在技术选型时多花一周时间做深度调研，而不是选最热门的框架——这会拖慢当前的进度指标，但它可能避免一年后的重写。
这些工作不会让dashboard变绿。它们不会出现在周报里。它们不会被自动追踪、不会被实时监控、不会触发Slack通知。
但它们是真正的工作。它们是产品成功与失败的分界线。
当你的团队盯着绿色的dashboard，却感觉产品在滑向深渊时——不是指标错了，是你在衡量错误的东西。真正的问题不在数字里，它在数字之外，在那些你没有勇气去面对的模糊地带。
而那，才是CTO应该花时间的地方。
—— https://www.80aj.com