跳转至

项目开始前，先假设它已经失败

状态：待验证。

问题

项目评审常问“这个方案行不行”，很容易变成支持者解释方案、反对者证明自己。真正担心的问题要么说得委婉，要么等项目失败后才在复盘里变得显而易见。

做法

方案已经讲清、但还没有正式开工时，做一次 20–30 分钟的 pre-mortem：

  1. 宣布失败结局 —— “现在是三个月后，这个项目已经彻底失败。”
  2. 每个人静默写原因 —— 先写 3–5 分钟，避免第一个发言者给全组定方向。
  3. 轮流报风险 —— 每轮每人只说一条，直到没有新项；暂时不辩解。
  4. 合并并排序 —— 按发生可能性和破坏程度，挑出最值得处理的 3–5 项。
  5. 给每项加动作 —— 选择预防、监测、准备预案或明确接受。
  6. 写负责人和信号 —— 没有观察信号和负责人，风险清单只是一张情绪清单。

最终只留一张表：

失败原因 最早信号 现在的动作 负责人
示例：关键接口比计划晚两周 连续两次联调缺席 第一周先打通最小假数据链路 张三

不要问“可能有什么风险”，直接假设“已经失败，为什么”。前者仍允许大家相信一切会顺利；后者把讨论从是否唱衰，改成解释一个既定结局。

为什么

Pre-mortem 把通常发生在项目结束后的复盘，搬到资源还没有大规模投入之前。Gary Klein 对这个方法的定义就是：团队先接受计划失败的假设，再共同生成可能的威胁和障碍。

它最有价值的地方不是预测准，而是降低说坏消息的社交成本。每个人都被要求解释失败，提出风险不再等于反对项目。

什么时候别用

  • 方案还没讲清时别做 —— 大家只会攻击五种不同版本的计划
  • 已经决定取消时别做 —— 不要拿风险工作坊假装仍在开放讨论
  • 没人能处理结果时别做 —— 收集一百条风险却不改计划，只会训练团队以后闭嘴

先试一次

挑一个两周以上、至少涉及三个人的项目。会议后只追踪前三项风险：

风险是否出现：
最早信号是否真的提前：
预防动作是否执行：
漏掉的最大风险：

项目结束后回看一次，下一次 pre-mortem 才会越来越像自己的方法。

来源