事前复盘（Pre-mortem）怎么开？在变更实施前，先假设它已经失败了
本文介绍事前复盘（Pre-mortem）：由心理学家Gary Klein提出，并经《哈佛商业评论》文章广泛传播，做法是在项目或变更开始前，请团队想象它已经失败，然后各自写下可能的失败原因。文章说明这一方法为何有效——它让质疑变成任务本身，缓解了评审会上“不愿扫兴”的群体压力。文章给出开会的步骤，比较它与FMEA的区别：前者重在发散并让大家敢于发言，后者重在量化排序。结合ServiceDesk Plus的变更管理，说明如何把识别出的风险落实到变更计划、回退方案和审批中。
变更评审会上，大家都对方案表示认可，会议很快结束。变更实施后却出现了一个没人在会上提过的问题：事后才有人小声说，“其实我当时就有点担心……”
为什么会上没人说？因为在一个已经倾向于通过的评审氛围里，提出顾虑很容易被看成“泼冷水”。事前复盘（Pre-mortem）通过改变问题的提法，让说出顾虑变成会议的任务，而不是个人的风险。
本文将围绕三个问题展开：事前复盘是什么、怎么开？为什么它能让团队更敢于说出顾虑？借助ServiceDesk Plus，如何把识别出的风险落实到变更计划中？
什么是事前复盘（Pre-mortem）？
事前复盘由心理学家加里·克莱因（Gary Klein）提出，并通过他发表在《哈佛商业评论》的文章《Performing a Project Premortem》被广泛了解。与项目结束后才总结失败原因的“事后复盘”相反，它要求团队在项目开始前就想象：这个项目已经失败了，失败的原因可能是什么？然后每个人各自写下自己能想到的失败原因。这种“把失败当作既定事实”的假设，让团队更容易发现平时被忽视的风险。
一、事前复盘怎么开？五个步骤
第一步，说明变更计划。由负责人简要介绍变更内容，确保所有人对方案理解一致。
第二步，设定情境。告诉大家：想象现在是变更实施后的某一天，它失败了，而且是严重的失败。
第三步，各自独立写下原因。每个人用几分钟，写下自己能想到的所有失败原因，先不讨论，避免被他人想法带偏。
第四步，汇总并分类。逐一读出并汇总，合并重复项，按可能性和影响初步排序。
第五步，转化为行动。针对排在前面的风险，补充预防措施、监控手段或回退方案，并指定责任人，把讨论结果写进变更计划。
行业观察：事前复盘并不是要否定计划，而是在计划之外多一层保险。目标是识别出可以提前预防或准备的风险，而不是让团队因为害怕失败而不敢推进变更。
二、为什么它能让团队更敢于说话？
在常规评审中，质疑往往被看成对方案或提出者的否定；而在事前复盘中，“找出失败原因”本身就是任务，提出越多顾虑反而越有贡献。这种角色的转换，缓解了群体中常见的“从众”和“不愿扫兴”的压力。
此外，“已经失败”这一假设让人们更容易想象具体的失败场景，而不是停留在“应该没问题”的抽象乐观中。
三、ServiceDesk Plus如何承接事前复盘的结论？
ServiceDesk Plus作为一套完整的ITSM系统，可以把会议中识别出的风险落实到变更流程中：变更管理中的变更计划、回退计划和影响分析字段，可以记录针对风险制定的预防措施和回退方案；变更审批流程可以要求相关方在实施前确认这些风险已被评估；CMDB 的依赖关系有助于核实某项风险可能波及的系统范围；变更失败后的复盘记录，也可以反过来作为下次事前复盘的素材。
核心要点速览
- 事前复盘：在变更开始前，假设它已经失败，再倒推失败的原因。
- 让“找出失败原因”成为任务本身，缓解了评审会上不愿扫兴的从众压力。
- 五个步骤：说明计划、设定失败情境、独立写下原因、汇总排序、转化为行动。
- 它与FMEA互补：前者擅长发散并让大家敢于发言，后者擅长量化排序。
- ServiceDesk Plus的变更计划、回退计划、审批和CMDB，可以承接并跟踪识别出的风险。
写在最后：让顾虑有地方说出来
很多变更失败后，人们才发现当初“其实有人想到了”。事前复盘的价值，是给这些顾虑一个合理、安全的出口，让它们在变更实施之前被听见。
下一次重要变更评审时，不妨留出十分钟，请大家先假设它失败了，再把写下的原因逐条落实到 ServiceDesk Plus 的变更计划和回退方案里，团队面对变更的底气会更足。
立即体验 ServiceDesk Plus，把变更风险想在前面
| ☁️ 免费注册云版本 | 💻 下载本地版 | 📅 预约专家演示 |
常见问题解答（FAQ）
延伸阅读：
