这篇解决「复盘了但下次还犯」的普遍失效问题，落点在产出物而非流程仪式。

最值得拿走的是有效性判据：复盘结束后，检查一下是否至少修改了一个清单条目、一条估算基线或一条升级规则，三样都没改的复盘等于没开。最容易跑偏的两个方向：开成表功会或追责会，以及开成发散的自由感想会——前者不敢碰真问题，后者不产出可执行物。

相比站内的度量与报告长文，这篇聚焦单项目收尾动作，并强调把个人教训固化成团队资产才是复盘的意义。再补一个频率上的判断：复盘不必等大项目结束，小项目每两周、长项目每个里程碑做一次轻量复盘即可；问题暴露得越早，教训转化成清单条目的成本就越低。

读完建议做一件事：把上一次项目复盘的结论翻出来，数一数它改了几样东西。

—— FDEChina编辑部 · 实战派

交付复盘怎么做才有用？

直接回答：判据很简单——复盘结束后，你是不是至少改了三样东西中的一样：一个检查清单的条目、一条工期或工作量的估算基线、一条问题升级的路径规则。改了，复盘才有用；没改，无论聊得多热闹、氛围多真诚，它都只是一次集体感想，下次照样踩坑。复盘的目的不是「总结感受」，而是把这一次项目的教训变成下一次项目的默认设置。

流程上，最小可行的复盘只需要三步。第一步，会前各自写事实：项目时间线上的关键节点——范围什么时候变的、数据什么时候就绪的、事故发生在哪一天——只写事实，不带评价。第二步，会中只答三个问题：哪些做法要在下一个项目里保留？哪些环节出了问题、根因是什么？下次遇到同样情况，具体要怎么做？注意根因要追问到流程层，而不是停在个人层，「某某太粗心」不是根因，「验收前没有固定的回归检查步骤」才是。第三步，会后 48 小时内落产出物：清单改了哪几条、基线怎么调整、升级路径补了什么规则，写成文档并指定归属。第三步是大多数复盘真正死掉的地方。

几个容易跑偏的方向值得提前防住。一是开成表功会：只挑顺利的部分讲，问题一笔带过，这种复盘对团队是负资产。二是开成追责会：一旦复盘变成找背锅的人，所有人下次都会本能地隐藏问题——所以主持人的纪律是「对事不对人」，谁先认错谁应该被感谢而不是被记过。三是开成发散会：感想天马行空，没有任何东西被写下来。守住的关键是把讨论锚在事实与产出物上，这与日常的交付节奏是一体的：平时没有周报与度量，复盘时就只有记忆和立场，见 FDE 报告手册与 FDE 交付度量。

最后，复盘的成果要流回团队的公共资产里：新踩的坑补进 PoC 验收清单这类检查表，返工的教训修正 范围界定手册里的估算参数，跨团队的问题更新升级路径。一个团队成熟的标志之一，就是新项目启动时用的清单，明显好于两年前的版本——那份差异，全是一次次有用的复盘攒出来的。