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

# 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完整模板

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

```markdown
# 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.1-inversion-thinking-basics.md)** - 理论基础和原理
- **[2.2.2 失败模式分析](./2.2.2-pre-mortem-failure-patterns.md)** - 常见失败模式和避坑指南
- **[2.3 减法思维](../2.3-subtraction-thinking/)** - MVP和不做清单