2.2.3 Pre-mortem实战指南：操作步骤与工具模板

理论学习和失败模式了解之后，本节将提供具体的操作指南，帮助你在实际项目中应用Pre-mortem技术。

Pre-mortem完整操作步骤

第一步：设定失败场景

清晰地描述失败的状态。要具体，不要模糊。

关键要素：

• 时间范围：多久后失败（1个月？3个月？6个月？）
• 失败程度：完全失败还是部分失败
• 具体表现：用户数、收入、使用频率等可衡量指标
• 回归状态：失败后你回到了什么状态

示例：

现在是3个月后，我的待办清单App已经彻底失败了。 具体表现是：

• 日活跃用户不足5人
• 我自己也回到了使用便利贴的日子
• 代码已经2个月没有更新了

失败场景模板：

现在是[时间周期]后，我的[项目名称]已经彻底失败了。

具体表现是：
- [具体失败指标1]
- [具体失败指标2]
- [具体失败指标3]

我回到了[描述失败后的状态]。

第二步：失败原因列举

列出可能导致失败的原因。要深入挖掘，不要停留在表面。

头脑风暴技巧：

1. 独立思考：每人先独立列出至少5个原因
2. 分类思考：从需求、技术、场景、习惯四个维度考虑
3. 深入挖掘：每个原因都要问"为什么会导致这个"
4. 开放态度：不要否定任何可能性，先列出来

数量要求：

• 至少10个原因
• 鼓励15-20个原因
• 覆盖不同维度

示例： 这个项目失败是因为：

1. 功能太多，复杂度失控
2. 没有解决真实痛点，现有方案够用了
3. 技术选择错误，AI兼容性差
4. 目标用户不明确，不知道为谁设计
5. 没有考虑用户习惯，迁移成本太高
6. 界面设计复杂，学习成本高
7. 性能问题，用户使用体验差
8. 市场推广不足，没人知道
9. 竞品太强大，没有差异化
10. 自己不够坚持，三分钟热度

第三步：分类与评估

对每个失败原因进行分类、评估可能性和严重性。

分类框架：

失败原因	类型	可能性	严重性	优先级	备注
原因1	需求/技术/场景/习惯	高/中/低	高/中/低	⚠️/⚡/✓	具体说明
原因2

评估标准：

可能性评估：

• 高：发生的可能性>70%
• 中：发生的可能性30-70%
• 低：发生的可能性<30%

严重性评估：

• 高：一旦发生，项目基本失败
• 中：发生但可以挽救
• 低：发生但不影响核心目标

优先级确定：

• ⚠️ 必须解决：高可能性 + 高严重性
• ⚡ 建议解决：中可能性 + 高严重性 或 高可能性 + 中严重性
• ✓ 考虑解决：其他情况

第四步：预防措施制定

针对高优先级风险制定具体的预防措施。

预防措施原则：

1. 具体可操作：不是"要注意"而是"如何做"
2. 时间明确：什么时候开始，什么时候检查
3. 责任人明确：谁负责执行
4. 成本可控：不会因为预防措施导致项目无法进行

预防措施模板：

优先级	失败原因	具体预防措施	执行时间	负责人
⚠️	复杂度失控	严格限制在3个核心功能内	立即执行	本人
⚠️	技术选择错误	选择成熟技术栈	开发前	本人
⚡	用户习惯难改	提供数据迁移工具	测试阶段	本人

第五步：需求调整

根据预防措施调整项目需求和优先级。

调整清单：

• [ ] 缩小项目范围，专注核心功能
• [ ] 调整技术方案，选择更合适的技术
• [ ] 重新定义目标用户群体
• [ ] 修改项目时间计划
• [ ] 增加用户研究阶段
• [ ] 制定推广和留存策略

Pre-mortem完整模板

以下模板可以直接复制使用：

# Pre-mortem分析：[你的项目名称]

## 项目基本信息
- **项目名称**：
- **项目类型**：[App/网站/自动化脚本/数据分析/其他]
- **目标用户**：
- **核心功能**：
- **预计完成时间**：

## 第一步：失败场景设定

现在是[时间周期]后，我的[项目名称]已经彻底失败了。

具体表现是：
- [描述失败的具体状态]
- [描述你回到了什么状态]

## 第二步：失败原因列举

这个项目失败是因为：

1. ________________________________
2. ________________________________
3. ________________________________
4. ________________________________
5. ________________________________
6. ________________________________
7. ________________________________
8. ________________________________
9. ________________________________
10. ________________________________
（至少写10条，越多越好）

## 第三步：分类与评估

| 失败原因 | 类型 | 可能性 | 严重性 | 优先级 | 备注 |
|---------|------|-------|-------|-------|------|
| 原因1 | 需求/技术/场景/习惯 | 高/中/低 | 高/中/低 | ⚠️/⚡/✓ | |
| 原因2 | | | | | |
| 原因3 | | | | | |
| 原因4 | | | | | |
| 原因5 | | | | | |

## 第四步：预防措施制定

| 优先级 | 失败原因 | 具体预防措施 | 执行时间 | 负责人 |
|-------|---------|-------------|----------|-------|
| ⚠️ | 原因1 | [具体的预防措施] | [时间] | [人员] |
| ⚡ | 原因2 | [具体的预防措施] | [时间] | [人员] |
| ✓ | 原因3 | [具体的预防措施] | [时间] | [人员] |

## 第五步：需求调整

基于以上分析，决定：

- [ ] 缩小项目范围，专注核心功能
- [ ] 调整技术方案，选择更合适的技术
- [ ] 重新定义目标用户群体
- [ ] 修改项目时间计划
- [ ] 增加用户调研阶段
- [ ] 制定推广策略
- [ ] [其他调整措施]

## 风险监控计划

- **定期检查**：[多久检查一次]
- **关键指标**：[要监控的关键指标]
- **预警信号**：[什么情况需要重新评估]
- **应急方案**：[如果发生问题如何应对]

## 下次Pre-mortem时间
- [ ] 1个月后
- [ ] 项目中期
- [ ] 重要里程碑前
- [ ] 需求变更时

进阶技巧与最佳实践

1. 定期重新做Pre-mortem

项目进行过程中，定期重新做Pre-mortem，因为情况会发生变化。

执行时机：

• 项目启动前：初始风险评估
• 重要里程碑前：评估新阶段的风险
• 遇到重大问题时：分析问题根源
• 需求变更时：评估变更影响
• 每个月：常规风险回顾

2. 多角度Pre-mortem

邀请不同角色的人参与Pre-mortem，发现更多潜在风险。

参与者角色：

• 项目负责人：关注战略和资源风险
• 技术人员：关注技术实现风险
• 用户代表：关注用户体验和需求风险
• 业务人员：关注市场和经济风险
• 外部顾问：提供客观视角

执行方法：

1. 每个人独立思考15分钟
2. 轮流分享，不互相批评
3. 合并和分类所有风险点
4. 一起评估和制定措施

3. 结合JTBD分析

把Pre-mortem发现的问题，用JTBD框架重新验证用户的真实需求。

验证问题：

• 这个失败原因是否影响用户完成核心任务？
• 预防措施是否有助于用户更好地完成任务？
• 是否误解了用户真正要"雇佣"产品完成的工作？

4. 分层次Pre-mortem

针对不同复杂度的项目，采用不同深度的Pre-mortem。

个人项目：

• 简化版Pre-mortem
• 关注个人技能和时间风险
• 重点考虑技术可行性

团队项目：

• 完整版Pre-mortem
• 增加团队协作风险
• 考虑沟通和管理问题

企业级项目：

• 深度Pre-mortem
• 增加市场和竞争风险
• 考虑合规和安全问题

5. 数字化Pre-mortem

使用在线工具和模板提高效率。

推荐工具：

• 思维导图工具：XMind, MindNode
• 协作白板：Miro, Mural
• 项目管理工具：Notion, Trello
• 文档工具：Google Docs, 腾讯文档

6. Pre-mortem后的跟进

Pre-mortem不是一次性的活动，需要持续跟进。

跟进机制：

1. 风险监控：定期检查预防措施执行情况
2. 指标追踪：监控关键风险指标
3. 应急预案：制定风险发生时的应对方案
4. 经验积累：记录Pre-mortem的准确性和改进点

常见误区与避免方法

误区1：Pre-mortem变成悲观主义

表现：

• 过度关注负面可能
• 导致团队士气低落
• 放弃有挑战的项目

避免方法： Pre-mortem不是要你变得悲观，而是要你变得现实。目标是识别可控风险，而不是放弃项目。保持建设性态度，关注"如何避免"而不是"可能会失败"。

误区2：只列表面原因

表现：

• "用户不喜欢"
• "技术有问题"
• "市场不接受"

避免方法： 要深入挖掘"为什么"。如果"用户不喜欢"，要问"为什么会不喜欢？"

• 是功能不满足需求？
• 是体验不够好？
• 是价格太高？
• 是习惯难以改变？

误区3：没有后续行动

表现：

• 做完Pre-mortem就结束了
• 没有制定具体措施
• 没有落实到项目中

避免方法： 识别风险只是第一步，关键是制定预防措施并落实到行动中。

• 为每个风险指定负责人
• 设定检查节点
• 建立预警机制

误区4：一次就够了

表现：

• 认为Pre-mortem只需要做一次
• 忽视项目进展中的新风险
• 不根据新信息调整计划

避免方法： Pre-mortem应该是一个持续的过程：

• 定期重新评估风险
• 根据新信息更新分析
• 在关键节点重新进行Pre-mortem

不同场景的应用示例

场景1：个人App开发

项目背景：开发一个学习辅助App

Pre-mortem分析：

1. 失败场景：3个月后，App下载量<100，自己也不使用
2. 主要风险：需求不明确、功能复杂、用户留存低
3. 预防措施：MVP验证、简化功能、建立用户反馈渠道

场景2：企业自动化系统

项目背景：为公司开发财务报表自动化系统

Pre-mortem分析：

1. 失败场景：系统上线后，财务部仍然使用Excel处理
2. 主要风险：数据安全、系统稳定性、用户培训
3. 预防措施：分阶段上线、建立数据备份、提供详细培训

场景3：数据分析项目

项目背景：为销售部门做客户行为分析

Pre-mortem分析：

1. 失败场景：分析报告完成，销售团队完全不采纳建议
2. 主要风险：数据质量问题、分析结果不实用、沟通不足
3. 预防措施：需求调研、阶段性沟通、建立验证机制

AI辅助Pre-mortem

使用AI进行风险识别

可以给AI提供项目信息，让它帮助识别潜在风险：

请帮我做一个Pre-mortem分析。

项目信息：
- 项目名称：[项目名称]
- 项目类型：[App/网站/系统/工具]
- 目标用户：[用户描述]
- 核心功能：[功能列表]
- 技术方案：[技术栈]

请从以下维度帮我分析可能的失败原因：
1. 需求层面：用户需求、市场定位、竞争环境
2. 技术层面：技术选型、实现难度、维护成本
3. 场景层面：使用习惯、迁移成本、用户体验
4. 习惯层面：用户粘性、持续使用、推广难度

每个维度请列出至少3个可能的失败原因。

使用AI评估风险优先级

基于以下Pre-mortem分析结果，请帮我评估每个风险的优先级：

[粘贴Pre-mortem分析结果]

请按以下格式整理：
⚠️ 高优先级风险：[原因] - [评估理由]
⚡ 中优先级风险：[原因] - [评估理由]
✓ 低优先级风险：[原因] - [评估理由]

并为每个高优先级风险建议具体的预防措施。

核心原则总结

✓ 预防胜于治疗：提前识别风险比事后补救成本更低
✓ 客观分析：基于数据和事实，而不是感觉和假设
✓ 持续改进：Pre-mortem应该是一个持续的过程，不是一次性活动
✓ 团队协作：多人视角比单个人更全面
✓ 具体行动：每个风险都要有具体的预防措施和责任人

检查清单与速查

Pre-mortem执行检查清单

在开始你的项目之前，确保你能回答以下问题：

• [ ] 我做过Pre-mortem分析吗？
• [ ] 我列出了至少10个可能的失败原因吗？
• [ ] 我识别出了高可能性、高严重性的风险吗？
• [ ] 我为这些风险制定了具体的预防措施吗？
• [ ] 我把预防措施落实到项目计划中了吗？
• [ ] 我设立了风险监控机制吗？

关键概念速查

概念	定义	核心问题
Pre-mortem	假设项目已经失败，追溯可能的原因	如果失败了，是因为什么？
风险评估	评估失败可能性和影响程度	这个问题多严重？
预防措施	针对风险的具体行动方案	如何避免这些失败？
风险监控	持续跟踪风险指标的变化	风险是否在可控范围内？

实战练习

现在轮到你了。无论你想做的是一个小工具、一份数据分析、一个自动化脚本，还是给家人做的小网页，都可以用这个方法做一次Pre-mortem。

选择一个项目进行分析

项目选择：

1. 当前正在进行的项目
2. 计划要做的项目
3. 曾经失败的项目（用于分析总结）

完整分析流程

1. 使用完整模板：下载或复制Pre-mortem模板
2. 独立思考：先自己填写，不要参考他人
3. 多人验证：找2-3个人帮你检查是否有遗漏
4. 落实措施：将预防措施加入项目计划
5. 定期回顾：按照设定的时间间隔重新评估

分享和讨论

如果你有团队，邀请团队成员一起做Pre-mortem。不同视角会发现不同的问题。

定期回顾

项目进行过程中，定期重新做Pre-mortem，根据新情况调整策略。

通过系统的逆向思维实践，你可以显著提高Vibe Coding项目的成功率。记住：预测失败，比追求成功更有效。

这不是悲观，而是智慧。不是放弃，而是准备充分。不是限制创新，而是让创新走得更远。

相关资源

• 2.2.1 逆向思维基础 - 理论基础和原理
• 2.2.2 失败模式分析 - 常见失败模式和避坑指南
• 2.3 减法思维 - MVP和不做清单