几个月前，我被拉进了一个与工程对手及其老板（恰好是我们工程副总裁）的通话中。出了点问题，不算灾难，但足够重要，以至于我现在正和一位 SVP 通话。我刚开始解释它是如何发生的，他们却打断我说：“Michael，我不想细节”。随后他们说：我知道如果我们深入细节，原因会完美合理。你会解释发生了什么，我会理解每个人做出决定的原因，我会同情你。所以我不想要细节。他们想知道我们正在改变什么。起初我认为“我不想要细节”听起来很轻视。他们怎么可能在没有了解细节的情况下做出明智的决策？然后我意识到“我不想要细节”并非轻视。这位高管假设我们有能力，是在说“我已经相信你了。现在让我们谈谈接下来会发生什么”。

问对问题

事情出错后，大多数组织会问“为什么会发生这种情况？”这是我们都很熟悉去回答的问题。我们编写时间线。我们重构决策。我们解释依赖关系。最后，我们交出一份包含导致事件的具体事件组合的文档。每个人都点头表示“这说得通”，然后我们继续一天的工作。理解问题不等于修复它。一个好的解释可能会让事情变得更糟。一旦每个人都同意这种行为是合理的，对任何事情改变的紧迫感就会消失。当一次故障是不幸但可理解的一系列事件，且没有人有过错时，什么都不会改变。六个月后同样的事情再次发生，每个人都在惊讶于我们又是如何再次陷入这种境地的。为了在你的组织中推动变革，不要问“为什么会发生这种情况？”。相反，问：我们正在改变什么，以便下次同类故障不太可能再次发生？

合理的人

这位 SVP 不感兴趣了解问题是如何发生的，也没人涉及。他们不想被说服每个人都合理地行为了。那是基本期望。他们的问题变成了：“鉴于合理的人产生了这个结果，需要改变什么？”

请考虑这些例子：“我们错过了，因为 Alice 在假期，Bob 以为 Widgets 团队负责它”。好的。当有人不可用时，我们如何让所有权明确化？“三天前发布前要求变更”。当然它们变了！当要求在发布窗口内变更时会发生什么？“警报触发了，但值班工程师那天晚上已经处理了二十个低价值警报”。这说得通。我们如何改善警报的信噪比？专注于改变系统。人们通常不是需要改变的东西。

一个好的解释不是修复方案

如果你的事后复盘充满了类似“我们应该更早涉及支持”和“我们需要更好地沟通”，或者我个人最喜欢的“下次我们会更小心”的句子，你就有一堆希望被包装成进展。如果你的纠正措施依赖于人们记住六个月前的对话，你就没有纠正措施。你有一种组织民间传说。如果涉及这次事件的所有人明天离开公司，修复措施还会起作用吗？如果答案是不，那么人们可能学到了些什么，但系统仍然注定会失败。为了让事后复盘推动持久变革，问：如果明天发生同样的情况，什么会导致不同的结果？一个在该点强制做出决定的流程是改进。一个能防止这一类错误的系统更加坚固。

为了流程而流程

你可以把“系统防止这一类错误”推得太远。并非每一次失败都值得新的流程。这就是你建立没人想工作的环境的方式。有时防止复发的成本更高...