事后分析

/em:postmortem — 对失败原因的坦诚分析

命令： /em:postmortem <事件>

核心不在于责备，而在于理解。无论是失败的交易、未达标的季度、遇冷的功能，还是不合适的招聘。分析实际发生了什么，原因是什么，以及随之而来的改变。

---

为什么大多数事后分析（Post-Mortem）会失败

它们通常会演变成以下两种情况之一：

责备大会 —— 找个替罪羊，导致人们产生防御心理，真正的原因未被探讨，同样的问题以不同形式再次出现。

粉饰太平 —— “我们学到了很多，我们会做得更好，这里有 12 项模糊的行动计划。” 结果毫无改变。同样的问题，换个季度再次发生。

真正的 Post-Mortem 两者都不是。它是一次对系统失效的严谨调查。关注的不是“是谁的错”，而是“在事后看来，什么样的条件导致了这一结果的必然性？”

目的： 从失败中榨取最大的学习价值，从而防止再次发生并优化系统。

---

框架

第一步：精准定义事件

在分析之前：准确描述发生了什么。

• 预期结果是什么？

• 实际结果是什么？

• 差距何时首次显现？

• 产生了什么影响（财务、运营、声誉）？

精准度至关重要。“我们没完成 Q3 营收目标”不够精准。“我们的新 ARR 仅为 42 万美元，目标是 68 万美元 —— 缺口 26 万美元，主要原因是三笔交易推迟到 Q4，一笔交易输给了竞争对手”才叫精准。

第二步：正确执行 5 Whys

目标：从发生了什么（症状）推导至为什么发生（根本原因）。

典型的错误 5 Whys：

• 为什么营收没达标？因为交易推迟了。

• 为什么交易推迟？因为销售周期比预期长。

• 为什么？因为客户的采购流程很复杂。

• 为什么？因为我们在做企业级销售。

• 为什么？企业级销售就是这样。

→ 结论：无能为力。这就是企业级销售的特性。

真正的 5 Whys：

• 为什么营收没达标？三笔交易在季度末推迟了。

• 为什么这些交易会推迟？因为这些交易都没有找到拥有预算权限的内部支持者（Champion）。

• 为什么我们在没有支持者的情况下推进交易？因为我们的资格审核标准（Qualification Criteria）没有要求这一点。

• 为什么审核标准没有要求？因为 8 个月前制定标准时，我们面向的是中小企业（SMB）而非企业级客户。

• 为什么在理想客户画像（ICP）转移后没有更新审核标准？因为没有负责人，也没有审核标准的复盘流程。

→ 根本原因：资格审核标准过时，缺乏负责人，缺乏复盘流程。
→ 解决方案：更新标准，指定负责人，增加季度复盘。

判断根本原因是否有效的标准： 你能否通过一个具体、明确的改变来防止问题再次发生？如果能，你就找到了真正的原因。

第三步：区分促成因素与根本原因

大多数事件都有多个促成因素，但并非所有因素都是根本原因。

促成因素（Contributing factor）： 使情况恶化，但不是核心原因。如果消除它，结果可能会有所不同，但同类问题仍会再次发生。

根本原因（Root cause）： 导致该结果极大概率发生的根本条件。修复它，同类问题将不再发生。

示例 —— 招聘失败：

• 促成因素：流程仓促、跳过了背景调查、团队压力过大

• 根本原因：缺乏定义的能力框架，导致面试流程取决于面试官的个人标准

这种区分至关重要。 如果你只解决促成因素，下次虽然形式不同，但结构上依然会发生同样的失败。

第 4 步：识别被忽略的预警信号

每一次失败都有前兆。事后看来，这些前兆显而易见。这一步的价值在于让这些信号在未来也能被预见。

思考：

• 在哪个时间点，负面结果是可以预见的？

• 当时出现了哪些可见信号？

• 谁看到了这些信号？当他们提出时发生了什么？

• 为什么没有采取行动？

常见模式：

• 信号已提出，但被高层忽视

• 信号未被提出，因为没人觉得敢于直言

• 信号被察觉，但没人有明确的权限去处理

• 数据可用，但没人关注

• 团队过于乐观，没有认真对待负面信号

这一步对于系统性问题尤为重要——“我们觉得不敢提出顾虑”比“交易资格审核有误”要深刻得多的根本原因。

第 5 步：区分可控因素与不可控因素

有些失败即便决策正确也会发生，有些则是由于决策错误导致。区分两者可以避免过度修正或修正不足。

• 可控因素： 流程、标准、团队能力、资源分配、已做出的决策

• 不可控因素： 市场状况、客户决策、竞争对手行为、宏观事件

针对不可控因素：如何提高面对类似事件时的韧性？
针对可控因素：具体需要改变什么？

警告： “这在我们的控制范围之外”有时被用来逃避责任。请保持严谨。

第 6 步：建立变更登记表

每场复盘都应以变更登记表结束——包含具体的承诺、负责人和截止日期。

糟糕的行动项：

• “我们将改进资格审核流程”

• “沟通将变得更好”

• “我们将更严谨地进行预测”

优秀的行动项：

• “Ravi 负责在 3 月 15 日前重写资格审核标准，将‘识别关键支持者’设为硬性要求。新标准将于 3 月 22 日起在每周销售例会中审核。”

• “Elena 将在 3 月 10 日前在 CRM 中为任何超过 60 天且未进行产品演示的开放机会添加‘交易延迟风险’标记。”

• “Maria 将从 4 月 1 日起每 6 周与企业销售团队进行一次 30 分钟的回顾会议，分析赢单/输单数据。”

针对每项行动：

• 具体改变了什么？

• 谁负责？

• 何时完成？

• 如何验证其有效性？

第 7 步：验证日期

这是最容易被跳过的步骤。如果没有人检查变更是否真正实施且真正有效，复盘就毫无意义。

设定一个验证日期：“我们将在 6 月的董事会上审查资格审核标准是否已更新，以及交易延迟率是否有所改善。”

没有这一步，复盘就成了走形式。

---

复盘输出格式

事件：[名称与日期]
预期：[原本应该发生什么]
实际：[实际发生了什么]
影响：[量化结果]
时间线
[日期]：[发生了什么或出现了什么信号]
[日期]：...
5 WHY 分析
1. [为什么 X 发生了？] → 因为 [Y]
2. [为什么 Y 发生了？] → 因为 [Z]
3. [为什么 Z 发生了？] → 因为 [A]
4. [为什么 A 发生了？] → 因为 [B]
5. [为什么 B 发生了？] → 因为 [根本原因]
根本原因：[用一句清晰的话概括]
促成因素
• [因素] — 如何产生影响
• [因素] — 如何产生影响

可控因素：[列表]
不可控因素：[列表]

变更登记表
| 变更项 | 负责人 | 截止日期 | 验证方式 |
|--------|-------|----------|-------------|
| [具体变更] | [姓名] | [日期] | [如何验证] |

验证日期：[检查日期]
```

---

复盘报告的基调

责备很容易，理解很难。

复盘的目标不是为了证明谁犯了错，而是为了理解系统为何产生该结果，从而改进系统。

“销售人员没有正确地筛选客户”是责备。
“当我们向高端市场转型时，客户筛选框架尚未更新，且没有人负责维护其时效性”是理解。

第一种方式会导致人员被解雇或蒙羞；第二种方式则能构建一个更具韧性的组织。

两者可能同时成立。但关键的区别在于：哪一种方式能真正防止问题再次发生？