复盘五步法：目标回顾、结果评估、过程分析、根因挖掘、经验沉淀

复盘这件事，说起来简单，做起来难。

我刚带项目那几年，也搞过复盘。但说实话，那时候的复盘就是「大家坐在一起，把问题说一遍，然后散会」。结果呢？下次该踩的坑一个没少。后来我才明白——复盘不是批斗会，也不是流水账。它是一套有章法的方法论。

我个人习惯把这套方法论拆成五步。每一步都有它的目的，也有它的坑。下面我一个个说。

第一步：目标回顾

很多人觉得目标回顾就是翻翻文档，把当初写的需求念一遍。其实不是。

目标回顾的核心，是还原「当初为什么定这个目标」。

我在项目中遇到过这样的情况：产品经理说「我们要把响应时间降到 50ms 以内」，开发团队就闷头干。结果复盘时才发现，客户真正需要的是「在 95% 的场景下，响应时间不超过 100ms」。你看，目标本身就有偏差。

目标回顾要回答三个问题：

• 目标是什么？ —— 写清楚，别含糊
• 为什么定这个目标？ —— 客户需求？技术指标？商业诉求？
• 目标是否可衡量？ —— 没有量化指标的目标，复盘时根本没法评估

嗯，这里要注意：目标回顾不是找借口。别把「当初目标定得不合理」当成推卸责任的理由。我们只是还原事实。

第二步：结果评估

结果评估，说白了就是「拿结果跟目标比」。但怎么比，有讲究。

我见过最粗暴的做法：目标 A 完成了 80%，目标 B 完成了 120%，然后大家开始争论「到底算成功还是失败」。这种争论毫无意义。

我建议用「三档评估法」：

为什么要这么分？因为偏差 10% 和偏差 50%，根因完全不同。前者可能是优化不到位，后者可能是方案选型就错了。

第三步：过程分析

这一步是最花时间的，也是最容易被跳过的。

过程分析不是「谁做了什么」，而是「事情是怎么发生的」。你要把整个项目拆成几个关键阶段，每个阶段都问一遍：

• 这个阶段我们做了什么？
• 遇到了什么问题？
• 当时是怎么决策的？
• 有没有更好的做法？

你想想看，很多问题其实在过程中就有征兆。比如代码评审时发现某个模块的复杂度超标，但大家觉得「先上线再说」。结果呢？上线后那个模块成了最大的故障点。

过程分析的工具：

• 时间线梳理 —— 把关键事件按时间顺序列出来
• 决策树回溯 —— 每个决策点，列出当时的选项和选择理由
• 沟通记录复盘 —— 看看信息传递有没有失真

第四步：根因挖掘

这是复盘的核心，也是最容易翻车的一步。

很多人喜欢把问题归结为「沟通不足」「执行力不够」「时间太紧」。这些是根因吗？不是。这些都是表面现象。

根因挖掘，要问五个「为什么」。

举个例子：

1. 为什么项目延期？—— 因为测试阶段发现了严重 bug
2. 为什么会有这个 bug？—— 因为某个模块的边界条件没处理
3. 为什么没处理边界条件？—— 因为需求文档里没写
4. 为什么需求文档没写？—— 因为产品经理不知道这个边界场景
5. 为什么产品经理不知道？—— 因为客户自己也没意识到

你看，根因不是「开发不仔细」，而是「需求获取阶段遗漏了关键场景」。这才是真正需要解决的问题。

根因的分类：

第五步：经验沉淀

这一步决定了复盘的价值。如果经验不沉淀，复盘就是白做。

我个人的习惯是：每次复盘结束后，必须输出三样东西：

1. 一份问题清单 —— 列出所有发现的问题，标注根因和影响
2. 一份改进措施 —— 每个问题对应一个具体的改进动作，明确责任人和时间
3. 一份知识库条目 —— 把经验写成文档，放到团队知识库里

经验沉淀还有一个容易被忽略的点：正面经验也要沉淀。做得好的地方，同样要总结出方法论，下次复用。

复盘五步法全景图

下面这张图，是我自己画的一个复盘流程框架。每次做复盘前，我都会看一眼，提醒自己别漏步骤。

这张图我每次做复盘前都会看一眼。五步走完，复盘才算完整。少一步，效果就打折扣。