必要条件一：事实底稿
没有记录就没有复盘，只有回忆。会前要把时间线、沟通记录、变更单与数据报表整理成一页底稿，参会人先读再议。缺这一步，会议会迅速变成各自印象的争论，结论谁都不认，也无法在下一周期验证。边界是没有底稿就不开这场会。
必要条件二：分开三类陈述
事实是发生了什么，判断是对原因的解释，决策是当时选了哪条路。三者混在一起，讨论就会在归因上打转。主持人要在白板上分栏，凡出现因为就先归到判断栏，等事实补全再讨论，这一条能省掉大半争吵。边界是判断没有依据就先搁置。
必要条件三：改进项有人有期
每条改进项写清动作、负责人、完成时间与验证方式，进入台账跟到下个周期。没有责任人的改进项只是情绪出口，写完就散；复盘的价值不在会上的共识，而在会后是否真的改掉一件具体的事。边界是没有责任人的改进项不入台账。
边界：不替代调查与考核
涉及安全、质量事故与法律责任的，要走正式调查与认定程序，复盘只能作为内部学习；也不宜把复盘记录直接当绩效依据，否则参会人会先保护自己，事实底稿立刻失真，越复盘越看不见问题。边界在此：调查优先于复盘。
适用与不适用
适合谁
- 项目结束、版本上线或重大变更后需要沉淀经验的团队
- 跨部门协作反复出问题、需要统一事实口径的组织
- 希望把改进项真正跟到闭环的管理者
不适合谁
- 只想找人承担责任、不准备改流程的管理层
- 没有过程记录、也不愿补底稿的临时会
典型场景
一家软件公司的一个交付项目延期两周。项目经理提前整理出需求变更、测试排期与客户确认的时间线，会上先对事实，再把各人的解释写到判断栏，最后只留三条改进项：变更必须当天录系统、测试环境提前一周锁定、客户确认由同一人对接。三条都写进台账，由交付负责人月底核对。
可执行步骤
- 会前整理时间线与关键单据，形成一页事实底稿并提前分发，留出静读时间
- 会上先逐条核对事实，再讨论原因与当时可选的决策，不评价个人，并留出五分钟静读
- 把改进项写成具体动作、负责人、完成时间与验证方式，最多三条，避免滑向追责
- 下个周期固定时间核对改进项，未完成的说明原因并重排，不留悬空项
常见坑
- 没有底稿直接开会，讨论很快变成各自印象的争论，结论无人认账，下次照旧，改进无从谈起
- 把复盘开成追责会，之后没人愿意讲真实情况，问题被藏起来，信息质量持续下降，管理层看到的是假象
- 改进项写得宏大，没有负责人和时间，下次复盘还在原地打转，团队逐渐失去耐心，会议终被取消
自检与验收清单
- 是否有会前分发、参会人已读过的事实底稿，参会人是否已读
- 事实、判断与决策是否分栏记录并标注依据，依据是否可查
- 每条改进项是否有负责人、时间与验证方式，是否有验证方式
- 上次改进项是否已核对，未完成是否有说明，是否重新排期
常见问题
复盘和工作总结有什么区别
总结侧重陈述成果与经验，复盘要求还原过程并检验当初的判断；总结往往向上汇报，复盘对自己。两者可以共用材料，但复盘必须产出可跟踪的改进项，否则只是换了名字的总结。
小团队也需要正式复盘吗
需要，但可以很轻。三四个人、一张白板、四十分钟，按事实、判断、改进项三段走完即可；关键不是形式，而是有没有底稿、有没有人跟改进项，缺这两样，再正式的会也白开。
复盘要不要请外部人主持
当议题涉及部门利益或负责人本人时，外部主持更容易保持中立；日常迭代复盘由团队内轮值主持即可，成本更低，也更能形成习惯，不必每次都请外部人。比事后补救更省时间。