做项目风险分析，可以先让团队回答一个具体问题：“假设这次上线已经失败，用户最先遇到的是什么？”再把答案写成触发条件、失败路径、可观察信号和处理动作。与笼统写“进度风险、质量风险”相比，这种失败预演更容易暴露计划中尚未连接起来的环节。
在墨刀白板上组织上线前的风险讨论时，可以把发布目标放在左侧，把每条失败路径连到右侧的负责人和动作卡。团队讨论的是方案中的薄弱环节，不是给某个人贴上“不配合”的标签。
失败预演与项目复盘有什么区别
复盘从已经发生的事实中寻找改进；失败预演发生在关键决策或上线之前，目的是发现尚有机会处理的风险。Gary Klein在项目失败预演方法中提出，先假设项目失败，再寻找可能原因。
它特别适合方案看起来已获得一致支持、但依赖多、参与角色多的项目。例如会员权益改版，界面可能已经设计好，仍有计费口径、老用户迁移、客服话术和退款处理等接缝。只检查页面完成度，很难把这些接缝放在一起看。
项目结束后，可以改用帆船回顾总结推动力和阻碍。不要拿事后复盘的结论直接填满预演白板；历史经验只是线索，本次规则与依赖仍要重新梳理。
先写出失败的画面，避免泛泛列风险
以“会员权益改版”作为讨论练习：计划给符合条件的会员开放新的权益页，并让客服能够解释新旧规则。主持人不应只问“大家觉得有什么风险”，而应给出足够具体的未来画面：
上线后的第一个工作日上午，用户进入权益页，却无法确认自己能否领取。客服收到咨询后，也无法从后台解释权益为什么变化。请各自写出导致这一结果的可能路径。
这个画面没有预设技术、产品或运营谁有责任，却迫使讨论同时覆盖用户端、后台与解释机制。若成员提出“服务器崩了”，继续问“哪个动作首先失败、用户看到了什么、团队靠什么知道”，直到风险能被定位到一段流程。
| 过于笼统的写法 | 更可处理的风险描述 |
|---|---|
| 需求有问题 | 规则说明没有区分旧会员的保留权益，权益页与客服后台给出不同解释 |
| 测试不充分 | 只验证新注册账号，未覆盖改版前已购买但尚未使用的权益 |
| 跨部门沟通慢 | 上线前一天权益文案变化，客服知识库仍沿用旧版本 |
| 数据异常 | 权益同步失败后页面继续显示“领取成功”，用户再次操作又生成请求 |
一次预演会怎样推进
Atlassian的预演练习建议先独立书写，再归并相近想法并讨论。用于产品上线时，可以按下面的顺序组织；时间长度根据项目规模安排，不必套固定会议时长。
把项目边界放在所有人看得见的位置
先写清本次改变的内容、覆盖用户、保留的旧规则、计划上线方式和明确不做的部分。没有这个边界，运营可能在讨论全年活动，研发却只在讨论当前接口，所有风险都会“有道理”却难以取舍。
让参与者先写自己的担忧
产品、设计、研发、测试、客服分别写便签，一张只描述一条失败路径。先收集再解释，避免第一个发言者把所有人带到同一方向。对暂时没有证据的担忧，可以标为假设；不要为了让它上墙而编出发生概率。
按断点归并，不按部门分摊
把“权益页解释不清”和“客服答不上来”归到规则版本不一致，可能比各放在设计问题、客服问题下面更有用。同一个失败结果可能有多条原因；保留这些分支，不要用一句“加强沟通”把它们合并掉。
挑出现在处理最有价值的几条
先看后果是否严重，再看是否难以及时发现、是否还能低成本预防。没有可靠概率时，不强行填写“发生概率30%”。可以记录“过去出现过类似条件”“本次尚未验证”“已有自动检查”等证据，用它们解释排序。
风险卡要同时写预防和触发后的动作
只有“加强测试”的风险卡，很容易在会议后失效。预防动作回答现在做什么；触发动作回答风险真的出现时怎么收敛影响。两者还需要一个可观察信号连接起来。
| 会员权益风险 | 上线前动作 | 触发信号 | 触发后动作 |
|---|---|---|---|
| 旧会员规则解释不一致 | 选取不同购买时间的账号，逐一对照页面、后台与客服说明 | 同一账号在三个位置显示不同权益或有效期 | 暂停扩大开放范围，由产品负责人统一规则，再修正展示和说明 |
| 领取失败却显示成功 | 覆盖同步失败、超时与重复点击，写清各状态含义 | 页面成功记录与权益到账记录不一致 | 关闭相关领取入口或切换到可解释的处理中状态，按既定规则补查记录 |
| 客服沿用旧话术 | 把新规则、差异问答和发布日期放在同一份材料中确认 | 抽查问答仍使用旧权益名称或旧期限 | 更新材料并明确当班联络人，收集尚未覆盖的问题 |
上述信号是本例的讨论方向。实际阈值和监控方式应由系统负责人根据现有能力定义。不要在风险卡中写一个团队无法观察的指标，也不要写一个没有权限执行的回退动作。
如果涉及多个团队的先后交付，可把风险卡关联到需求依赖关系梳理中的前置节点。例如“客服材料完成”应明确依赖哪个版本的业务规则，而不是笼统依赖“产品确认”。
让预演结果进入上线决定
结束时，每条重点风险应进入明确状态：已处理、有条件放行、延期处理或仍阻塞上线。“已讨论”不是解决状态，“负责人已知晓”也不等于后果能够接受。
风险编号：R-03
失败结果：旧会员无法解释权益变化
触发条件：历史购买规则与新页面规则不同
当前依据：规则对照表中仍有一类账号未确认
预防动作：补齐该类账号的页面、后台、话术对照
负责人：具体角色或姓名
完成依据：对照表与确认记录
未完成时：仅开放已确认的用户范围
触发信号：同一账号多处权益解释不一致
触发后的负责人和动作：
下一次检查时间：若决定先向部分用户开放，把风险卡中的条件带入灰度发布方案，形成真实的放量门槛。后续发现新风险时继续补充路径，而不是把预演白板当成一次会议的留影。
可以从正在准备上线的一项功能开始：在白板上放一张“失败后的用户画面”，请每个角色补一条最担心的路径，再选出本周就能完成的预防动作。风险分析的成果，是计划因此发生了哪些具体改变。
