复盘的基本流程：PDCA 循环的精髓

很多人觉得复盘就是「开个会，聊一聊」。说实话，这个认知差了十万八千里。

真正的项目复盘，有一个非常标准化的流程：回顾目标 → 评估结果 → 分析原因 → 总结规律。你仔细看，这四个步骤本质上就是 PDCA 循环（Plan-Do-Check-Act）在项目管理里的落地。

我过去带项目时，经常发现团队做完事就散了，根本不走完这套流程。结果第二次掉进同一个坑里，你还不知道怎么回事。嗯，这其实挺可怕的。

下面我们来拆开看看，每一步到底该做什么。

第一步：回顾目标（Plan）

复盘的第一步，不是急着看哪里出了问题，而是先把目标拉出来。

• 目标要清晰：当初定的目标到底是什么？是「完成上线」还是「在 Q2 完成上线且用户留存率超过 30%」？
• 目标要可量化：我在项目中遇到过，团队说「我们要提升系统性能」。结果复盘时，有人觉得快了30%算提升，有人觉得快一倍才算。这种目标根本没法对齐。
• 要确认目标是否变过：项目进行中，需求方会不会悄悄改了目标？这一点经常被忽略。

第二步：评估结果（Do & Check）

有了目标，接下来就是把实际结果摆出来。这一步最容易出现的问题是：「我觉得挺好的」。

作为复盘专家，我建议大家，一定要用数据说话。你想想看，如果有人说「用户反馈不错」，那「不错」到底是多不错？

• 列出实际数据：比如原定上线时间 6月1日，实际上线时间 6月15日。
• 对比差距：目标 vs 结果，差距是多少？是数量差距还是质量差距？
• 区分事实和观点：事实是「服务器响应时间 2.3秒」，观点是「服务器很慢」。复盘只认事实。

拿到这张表，大家才真正站在同一个事实基础上。否则，复盘只会变成互相扯皮。

第三步：分析原因（Check）

这是整个流程里最难，也是最值钱的部分。太多人在这里犯了一个错误——找到表面原因就停了。

举个例子，为什么上线延迟？你听到的答案可能是：「因为测试环境不够」。但这是真因吗？不是。你继续追问：为什么测试环境不够？因为环境搭建晚了。为什么搭建晚了？因为硬件资源申请流程太慢。为什么申请慢？因为流程里需要 3 个领导签字，且没有预审机制。

• 区分主观原因和客观原因：主观原因（人懒、沟通差）要转化为流程改进；客观原因（服务器宕机、政策变化）要建立预警机制。
• 不要做「批斗大会」：我见过很多复盘变成甩锅大会。复盘分析原因是「面向事的优化」，不是「面向人的追责」。
• 分类统计：把原因按照「技术、流程、沟通、资源」四个维度归类，更容易发现系统性问题。

第四步：总结规律（Act）

分析完原因，不能拍拍屁股走人。我们要把经验提炼成规律，然后落实为行动。

规律是什么？是那些可复用的、能指导未来决策的东西。

• 流程优化建议：比如「以后硬件申请必须提前 2 周发起」。
• 检查清单：把这次踩的坑写成一份清单，下次同类项目启动前，逐项检查。
• 知识库沉淀：好的复盘案例要写进 wiki。我曾经吃过亏，以为大家都会记住教训，结果三个月后又有人犯了同样的错。

知识体系总览

下面这张图，把整个复盘流程和 PDCA 的对应关系整理清楚了。你可以把它当作你每轮复盘的操作框架。

如何在日常项目中落地这套流程？

很多团队会觉得，搞这么复杂，时间成本太高。其实不然。我的经验是：越简单的复盘，越容易沦为形式。

我给大家推荐一个「轻量级复盘模板」，你可以直接拿去用：

| 项目名称        | XXXXX                                 |
|----------------|---------------------------------------|
| 复盘主持人      | 张三 (轮值)                            |
| 复盘时间        | 项目结束 + 3天内                        |
| 回顾目标        | 原始目标：_____。 当前认知：_____。      |
| 评估结果        | 完成项：_____。 未完成项：_____。        |
| 分析原因        | 技术原因：_____。 流程原因：_____。      |
| 总结规律        | 未来行动项1：谁+时间+动作。             |
|                | 未来行动项2：谁+时间+动作。             |

好了，说得再多，不如你亲自试一次。下次项目结束，别急着开庆功宴，先花 1 小时把复盘走一遍。你会回来感谢我的。