开会前先"验尸"：五分钟 pre-mortem 能救回多少项目

上周我帮一个朋友复盘了一次产品改版。新版本上线两周，核心转化率掉了 11%，团队的第一反应是"用户变了"、"大盘不好"，开了三次会谁是凶手都没找出来。后来一位同事问了句："如果现在告诉你这次改版彻底失败了，最可能的原因是什么？"会议室安静了三秒，然后七个人写出了九条原因，其中两条是建在"我们假设用户能看懂新导航"上的错误假设——而这正是掉转化率的直接原因。事后看，如果上线前花五分钟做一遍 pre-mortem，这两条假设会被当场拦住。

一句话规则

**在投入之前，先假设这件事已经失败了，用五分钟写下"它是怎么死的"，把写出来的每一条当成待验证的风险清单。**

注意顺序：默认"会失败"，然后找死因。它不是普通的头脑风暴，而是把人的乐观偏差强行调低一档。

具体使用场景

**1. 重大发布或改版前。** 新功能上线、定价调整、全站改版。开场白固定："假设现在是三周后，这次改版失败了。为什么？"每人独立写 3 条，再合并去重。重点盯"我们没意识到自己在假设什么"的那几条——失败几乎都死在隐藏假设上。

**2. 重要承诺给出去之前。** 答应客户三天交付、答应领导月底前上线。先问：什么情况下我会交不出？资源不够、依赖方拖、范围蔓延、自己高估速度。哪条最可能，今天就先处理哪条，而不是等它发生。

**3. 写第一篇长文或方案之前。** 长文方案的下马威不是"写得差"，而是"写给错了人"或"前提就是错的"。假设三个月后这篇文章没人转发/这个方案被毙，最可能的原因是什么？答不上来就先别动笔。

**4. 接手不熟悉的系统做第一次大改。** 改老代码、动老配置前，先写"这次改动会怎么搞出事故"：依赖它的地方有哪些？回滚要走几步？谁会被通知？写不出事故链的人，往往是因为没真正理解这个系统。

什么情况不需要 pre-mortem

- **三分钟内能做完的小事**：回个消息、改个错别字、部署一次改了一个常量的热修。验尸的开销比事故本身还大，纯属浪费。

- **风险极高到"随时可能死"的场景**：生产数据正在丢失、安全事件正在发生。这时候的动作是止血和回滚，不是坐下来讨论它为什么死。

- **你已经做过三期同类项目、流程全熟**：pre-mortem 的价值在于暴露未知，熟手的重复项目里它产出的是套话，带一个新人一起做反而更值。

五分钟执行清单

- [ ] 开头那句话是"假设它已经失败了"，不是"你觉得有什么风险"（后者会得到客气的标准答案）

- [ ] 每人**独立写**，禁止边写边讨论——人会在讨论中把自己的想法说圆、把尖锐的怀疑磨掉

- [ ] 每条风险写下来后补一句"**怎么验证它不存在**"，验证不了的风险等于实锤

- [ ] 合并后只挑**最可能发作的前 2-3 条**处理，不追求列尽所有可能

- [ ] 给这 2-3 条指定负责人和检查时间，写进待办；没有负责人的风险清单 = 废纸

容易踩的坑

**坑一：把 pre-mortem 开成追责会。** 一旦有人在找"谁写的这个烂需求"，后面的人就会集体沉默。事前讨论失败是安全的，事后讨论失败才危险。主持人看到火苗立刻拉回来："对事不对人，我们讨论的是假设中的失败。"

**坑二：只写"不会发生"的那几条。** 大家习惯性地列出熟悉的、可控的风险（服务器挂了、人手不够），然后互相点头"哦这个我们有预案"，会就散了。真正值钱的答案是那些让人"嗯"了一声、忘了反驳的——追问它。

**坑三：无期限地用它防风险。** 每个决定都做 pre-mortem，等于每次出手前都要慢 20 秒，团队会开始跳过它或敷衍它。只对"撤销贵、影响面大"的决策做，小的照常。

收尾

pre-mortem 的产物不是那份清单，而是清单里那两三条被提前拦住的死因。下次要发版、要承诺、要动老系统之前，先问出那句"假设它已经失败了"。五分钟，换一次不用复盘的运气。