PREMORTEM / 项目失败预演
开发开始前，先假设项目已经失败
失败预演不是泛泛列风险，而是让参与者假设项目在上线时失败，再倒推最可能的原因、最早能观察到的信号，以及现在就能安排的预防动作。
SCOPE / 项目范围
先看这类项目通常包含什么。
- 01失败场景
用具体事件描述失败，例如接口未开放导致核心任务无法联调。
- 02早期信号
寻找在真正失败前能够观察到的延期、缺席或数据异常。
- 03预防动作
把验证、样板、备选方案和决策时点提前放进计划。
- 04责任与检查
每项高风险都有观察人、检查频率和升级路径。
DECISIONS / 关键判断
开始开发前，先把这些问题回答清楚。
优先处理不可逆风险
先验证会让项目整体失效的接口、数据、合规和上线前提。
区分风险与问题
已经发生的问题直接进入处理清单，不再用“可能”弱化。
预案必须能触发
写清出现什么信号时采用降级、延期、替代或停止方案。
WORKED EXAMPLE / 填写示例
把一句担忧改写成可以检查的风险
担忧：第三方接口可能影响上线。
正式环境未授权，订单状态无法回写，核心闭环不能完成。
接口文档缺字段、测试账号迟迟未提供、对方没有明确接口人。
原型阶段完成最小联调，并准备人工导入的临时降级方案。
技术接口人每周更新授权与联调状态，阻断项立即升级。
- 01团队分别写下失败原因
- 02合并并排序高影响事件
- 03为前三项设置验证动作和触发条件
BOUNDARY / 项目说明
预演的价值是提前行动， 不是制造一份永远增长的风险表。
FAQ / 常见问题
怎样开一次有效的失败预演
01
失败预演会不会让团队过度悲观？
不会。讨论要落到可观察信号和具体动作，目的是减少意外，不是证明项目一定失败。
02
风险很多时怎样排序？
先看是否会阻断核心闭环，再看发生可能性、发现时间和恢复成本，优先验证最晚发现且代价最高的事项。
NEXT / 继续了解
从相关服务、案例或资料继续判断。
PROJECT CONTEXT / 项目沟通
问题已明确，直接讨论首期范围。
不用先整理完整需求文档，说明当前做法、使用角色、预算与首期目标即可。