章节 36

宁可上线，也不认错

沉没成本如何把过去的投入变成糟糕的决定

你知道该停了，却还是继续。这不只是因为路线图那么写。你继续，是因为团队已经投入太多时间，砍掉它比发布一个自己都不信任的东西更让人难受。

这就是沉没成本陷阱。时间和努力已经收不回来，却仍然笼罩着下一个决定。团队不再问现在怎样才合理，而开始寻找一种办法，让过去的投入显得没那么白费。

为什么团队继续保护本该砍掉的工作

沉没成本是你无法收回的金钱、时间或努力。正确的决定本该不考虑它。Hal Arkes 和 Catherine Blumer展示了，人们在这一点上做得有多差。一旦投入过，就会忍不住想继续，即使证据说该停下。他们把它称为“一旦作出投入，就倾向于继续某项行动”（译自英语）。

Richard Thaler帮助解释了原因。损失会痛。如果你在一个功能上花了几个月，砍掉它就像正式确认了那份损失。发布它，却让人觉得也许还能救回点什么。逻辑很糟。那股拉力却是真的。

计划可能已经没了。截止日期可能已经改了。团队仍然让一个糟糕的东西活着，因为他们无法忍受直视那笔早已发生的成本。

这就是沉没成本与路线图压力的区别。甚至不必再有人要求这个功能。工作能活下来，是因为团队自己不忍心把努力一笔勾销。过去一直坐在会议室里。

2010 年，Microsoft 推出了 Kin，两款面向年轻用户的手机。公司花了大约两年、约 10 亿美元开发这个平台。然后，发布了一个只存活 48 天的产品。

Kin 这个案例值得一提，不只是因为它失败了。而是因为警告在发布前就已经存在。2012 年，Wired公布了内部可用性视频，测试者在基本任务上卡住，说手机让人沮丧、困惑。问题并不隐蔽。Microsoft 还是发布了。

沉没成本在产品里就是这个样子。多年的工作。巨额投入。已经做出来的东西太多。到了这一步，砍掉它就意味着直截了当地承认损失。

团队一旦走到这里，几乎任何补丁听起来都很诱人。再做一个迭代。再改一轮。在有问题的部分周围，再加一层解释。不是因为这些能解决根本问题，而是因为它们推迟了那个时刻：必须有人说，最初的投入没有得到回报。

Concorde是这个模式最著名的版本。飞机在工程上非凡卓越，但早在项目结束之前很久，经济上就已经说不通了。政府仍然继续支持，部分原因是已经花了太多，停下来就像直接认下损失。

Kin 更接近产品团队会作的那类决定。东西已经做出来了。测试结果很糟。人们在基本任务上卡住。产品用起来让人困惑，问题明显得很难忽视。

然后有人说，也许我们可以补一补。加标签。加引导。再改一轮。不是因为这些能解决问题，而是因为把东西扔掉，比发布一个坏版本更难受。我见过团队在几个月的工作之后、一次大型演示之后、一个内部发布日期宣布之后这样做。功能活下来，是因为没人愿意承认桌上那笔已经发生的成本。

这里要问的，就是这个。忘掉“我们承诺过吗？”忘掉“它在路线图上吗？”改问：我们还在保护这项工作，是因为我们已经为它付出了太多吗？我听过这种逻辑被包装成对一致性、品牌、势头和团队士气的关心。

这时，团队开始用体面的说辞包装同一个决定。他们说，功能快好了。他们说，用户会学会的。他们说，上线会让团队学到更多。有时，发布确实能让你学到更多。有时，团队已经知道得够多，所谓进一步学习，只是拒绝止损的掩护。

问一个问题：如果今天这个东西出现在你桌上，没有附带任何历史，你会发布它吗？

这个问题剔除了大脑一直偷偷塞进来的部分。那些工时。那些演示。那些压力。那些被拖乱的排期。如果东西仍然不对，这些都帮不了用户。

Kahneman在这里很有用，因为他一直推动同一种纠偏：走出困住你的故事，从一个更冷静的位置看这个决定。过去的投入是真实的，但它仍然没有资格决定什么。

我喜欢这个问题，因为它能逼历史暂时离开会议室。如果这个东西今天第一次被看见就过不了关，背后的几个月也不会让它更强。只会让它更难被砍掉。通常就在这时，大家终于看到了功能现在的样子，而不是三个月前的样子。

这是管理问题，不是用户问题。别把它交给用户。