几个月前，迈克尔（Michael）被拉进一个电话会议，与工程对口同事及其老板（公司工程高级副总裁）讨论一个非灾难但重要的问题。他刚解释起因就被对方打断，迈克尔我不想要细节。对方表示，深究细节理由虽合理却会重演，只想知道要改变什么。迈克尔起先以为这话轻蔑，后明白高管是信任团队，说已相信他们，谈谈下一步。

几个月前，我被拉进一个电话会议，参会的有我的工程对口同事和他的老板——恰好是我们工程部的 SVP。出了点本不该出的岔子。不算灾难性，但严重到足以让我和一位 SVP 通话。

我刚要解释事情是怎么发生的，就被打断了：“Michael，我不想听细节。”

他接着说：

我知道，一旦进入细节，原因都会显得完全合理。你会解释发生了什么，我会理解每个人为什么做出那些决定，我也会共情你。

然后同样的事还会再发生。

所以我不想听细节。我想知道我们要改变什么。

起初我觉得“我不想听细节”听着很轻慢。不理解细节，怎么做出有依据的决策？

后来我意识到，那不是轻慢。这位高管假定我们是称职的，等于在说“我已经相信你了。现在谈谈接下来怎么办”。

问对问题

出事后，多数组织会问“为什么会发生？”这是我们都熟悉要怎么回答的问题。

我们写时间线，复盘决策，解释依赖关系。最后交出一份文档，里面是导致这次事故的那组特定事件。

所有人点头说“说得通”，然后各自继续过日子。

理解问题不等于解决问题。一个好的解释反而可能让事情更糟。一旦大家都认同当时的行为是合理的，改变的紧迫感就消失了。

当一次事故是一连串令人遗憾但可以理解、且无人有过错的事件，就什么都不会变。六个月后同样的事再次发生，所有人都纳闷怎么又走到这一步。

要推动组织改变，别问“为什么会发生”。

要问：

我们要改变什么，才能让同一类失败下次更不容易发生？

讲道理的人

SVP 不关心问题怎么发生的、涉及了谁。他不需要被说服所有人当时都行为合理——那是基本预期。

他的问题变成了：

“既然讲道理的人做出了这个结果，那需要改变什么？”

看几个例子：

“我们漏掉了，因为 Alice 在休假，Bob 以为 Widgets 团队负责这块。”

好。当有人不在时，我们怎么让责任归属变得没有歧义？

“上线前三天需求变了。”

当然会变！当需求在上线窗口内变化时，会发生什么？

“告警响了，但那晚值班工程师已经处理了二十条低价值告警。”

说得通。怎么提高告警的信噪比？

把重点放在改变系统上。人通常不是需要改变的东西。

好的解释不是修复

如果你的复盘里满是“我们应该更早让支持团队介入”“我们需要更好地沟通”，或者我个人最爱的一句“下次我们会更小心”，那你收集的是一堆希望，冒充进展。

如果你的纠正措施依赖于人们记得六个月前的一次对话，那你就没有纠正措施，只有组织民间传说。如果参与事故的所有人明天都离职，这个修复还成立吗？如果答案是否定的，那可能有人学到了东西，而系统仍然注定失败。

要让复盘带来持久改变，问：

如果明天发生同样的情况，什么会让结果不同？

一个在这一点上强制做出决定的流程，是一种改进。一个能防止这类错误的系统，还要更强。

为了流程而流程

“系统防止这类错误”也可能做过头。

不是每次失败都值得搞一套新流程。那样只会建出没人愿意在其中工作的环境。有时防止复发的成本高于偶尔接受失败的成本，这没关系。

但你必须睁着眼睛接受失败。“我们是有意识地接受这个风险”和“我们说过会更努力，大家感觉好多了”是两回事。

信任

我还是经常想起那位 SVP 说的话。听起来像不耐烦，其实是一种信任的声明。他不需要我证明涉事的人称职或出于好意，他愿意从这一点出发。如果调查显示并非如此，我们可以另外处理。

他不想要的，是共情变成组织给自己免除改变责任的机制。

人通常是在自己掌握的信息、激励和约束下做出最好的决定。所以“修人”往往是错误答案。

有时领导者能说的最有用的那句话是：

我相信你。我不需要细节。告诉我我们要改变什么。

社区对文中“工程高管事故后拒听技术细节、只问改变什么”的做法态度分裂：较多人质疑其脱离实际且回避同理心，少数人视其为基于信任的成熟管理，另有相当多意见强调标准复盘本应细节与行动兼备。

认为跳过细节只问改变是信任与聚焦改进

• 高管假设团队胜任，避免共情变成组织不改系统的借口，直接谈风险缓解与流程调整更高效，是成熟管理的表现（认可度：较多人）
• 需要引用时，只用一句中文意译： > 高管要的是婴儿而非分娩阵痛，意指只取解决方案而非过程倾诉（@tanseydavid）

认为领导必须了解细节才能有效改进

• 不知故障缘由就无法判断改变是否对症；不完全信任却拒听细节是脱离一线，且员工需要倾诉与尊重，否则像推卸责任（认可度：较多人）
• 需要引用时，只用一句中文意译： > 若不信他们怎知下一步合适？最佳领导自下而上也关注（@FartyMcFarter）

标准复盘应同时包含细节根因与行动项

• 实际事故复盘普遍有时间线、五为什么与可行项，只给结论缺乏背景则改动可能无效，两者皆不可少（认可度：较多人）
• 需要引用时，只用一句中文意译： > 我做过的复盘都有时间线、影响和五为什么，从没见过没有行动项的（@insanetake）

视此类文章为职场鸡汤

• 行文像领英风味的领导术心得，部分人认为这类高管本身价值存疑（认可度：少数人）
• 需要引用时，只用一句中文意译： > 这文章也许更适合发在领英（@groundzeros2015）

有价值的补充

• 持续改进常只做加法堆叠规则，需定期回看移除旧流程；复杂故障多贡献因素而非单根因，建议用“贡献因素分析”替代“根因分析”（@juancn）
• 医疗药房经验显示，无责文化下改环境流程比追究个人更有效，因人力状态本就波动（@wolfy1993）
• 告警疲劳等案例说明需专人角色整合多方细节以调整系统，仅追个人视角会漏掉结构性问题（@Lerc）
• 沟通中“提供选项而非借口”是建立信任的务实原则，与文中聚焦改变的精神一致（@plourens）