项目复盘模板：5 个维度，把项目经验教训问到底

复盘会开到一半，项目经理念完进度，问了一句"大家还有什么想说的"，会议室安静了三秒。有人接了一句"整体挺顺利的，就是时间有点赶"，话题就转向了下周的排期。

三个月后，新项目启动，延期、返工、需求反复的老问题，换个形式又出现一次。

多数团队不是不重视复盘，而是没有固定口径。没有统一的取数来源和归因路径，讨论只能靠印象，而印象里最响的那件事，往往不是最该改的那件事。

下面这套项目复盘模板拆成五个维度，每个维度只问三件事：问什么、看什么数据、产出什么。看完可以直接照着开一次。

复盘和总结，差的是那句追问

总结回答两件事：做了什么，结果如何。复盘要多问一句：为什么是这个结果，下次改什么。

差别看着很小，却决定会议会不会滑成工作汇报。开之前，先把三条规则说清楚。

• 复盘结论不用于个人绩效评定。这条不讲明，会上只会出现安全答案。
• 先摆事实，再给判断。同一件事的事实没对齐之前，不进入归因。
• 讨论做法，不讨论人。要回答的是"当时为什么这么决定"，而不是"这是谁的问题"。

还有一件事容易忽略：会前发出去的应该是数据，不是结论。结论先发出去，讨论就变成了给结论找证据。

五个维度：照着问一遍就行

目标与范围：当初答应的事，做到了几件

问什么：当初承诺交付什么，实际交付了什么。

看什么数据：项目范围说明、需求清单、变更记录、验收结论。

产出什么：一张范围达成表，每条目标标注达成、部分达成、放弃还是追加。

重点在变更上。客户或市场变化带来的调整算外部变更，考验的是变更流程走不走得通；开发过程中顺手加的优化、测试阶段补出的边界处理算内部蔓延，暴露的通常是需求评审和任务拆分的问题。两类问题的改进动作完全不同。

进度与投入：偏差出现在哪一步

问什么：偏差出现在哪个节点，投入和计划是否匹配。

看什么数据：里程碑计划与实际对比、任务耗时、人力与成本记录。

产出什么：一张偏差定位表，写清阶段、偏差天数、主要原因和证据。

不要只看总工期。一个延期四十天的项目，偏差常常集中在两三个节点上。做法是把总偏差拆到阶段和关键路径，找最早偏离计划的那个点。

填"主要原因"时先克制一下。"人手不够"不是原因，往下拆才有用：是估算偏乐观，是外部依赖没约定时间，是在等审批，还是返工。拆不开，后面就定不出动作。

质量与风险：看分布，不看总数

问什么：Bug 和返工集中在哪，风险应对是否有效。

看什么数据：Bug 记录、返工工时、风险登记与实际触发记录。

产出什么：需要固化的检查点，以及要改的风险清单。

同样是一百个 Bug，集中在两个模块和散落在二十个模块，原因完全不是一回事。可以按三个角度切：集中在哪个模块，在哪个阶段被发现，上线后暴露的问题回溯到哪个环节。发现得越晚，处理成本越高。

风险部分对比两份清单：立项时识别出来的，和实际发生的。识别到却没触发预案的，是预案太笼统还是执行时忘了；完全没识别到的，是评估方法的问题还是经验盲区。前者改预案的可操作性，后者改识别清单。

协作与决策：找出"谁在等谁"

问什么：卡点在哪些接口，决策是否及时。

看什么数据：会议记录、变更审批链、跨团队交接记录、干系人反馈。

产出什么：一份协作卡点清单，每条对应一个可以调整的接口安排，比如指定唯一对接人、把评审结论写进任务描述、把口头确认改成变更单。

这一维度不用求全，挑两三个关键事件回溯就够：当时的情况是什么，拿到了哪些信息，谁做了什么决定，结果如何。写的时候只写事实和判断依据，不写"沟通不畅""配合度不高"。

接着看决策链。方案选型、变更批准、上线时机、资源调配，这几个关键决策各花了多久。项目里最贵的隐性成本是等待，而等待从来不会出现在进度表上。

经验沉淀：把结论变成能追踪的动作

问什么：哪些做法能复用，哪些要写进规则。

看什么数据：前四个维度的结论，加上上一次行动项的完成情况。

产出什么：三条线——可复用的做法写进流程，要避免的做法写进检查清单，还拿不准的假设安排小范围试验。

经验记得带上适用条件。"提前一周冻结需求"在需求相对稳定的项目里有效，放到探索型项目就可能误事。写清楚这条经验在什么条件下成立，换个项目才知道能不能用。

会议怎么开：会前 3 天，会中 90 分钟，会后 1 周

会前两到三天，把各维度的数据打包发出去，标注口径和统计时间。指定一名引导人，最好不是项目经理本人，负责控制节奏、打断重复观点。会议时长控制在九十分钟左右比较合适，团队人数多可以拆成两段开。

会中按五步走：对齐目标（十分钟）、呈现结果（二十分钟）、分析原因（四十分钟）、提炼经验（二十分钟）、确认行动项（二十分钟）。每一维设时间盒，到点先记下没聊完的问题，会后单独跟进。

会后一周内，行动项录入任务系统，指定跟踪人。下一次项目例会或迭代回顾，先花五分钟过一遍上次行动项的完成情况。这一步断了，前面所有工作都会退回成"写一份总结"。

一张能直接复制的一页清单

五个维度的提问清单：

1. 目标与范围：承诺了什么，交付了什么，哪些变了，谁提出的。
2. 进度与投入：偏差集中在哪个节点，主要原因是什么，证据在哪。
3. 质量与风险：Bug 集中在哪，返工多少工时，哪些风险没被识别。
4. 协作与决策：卡在哪个接口，关键决策各花了多久。
5. 经验沉淀：哪些做法写进流程，哪些写进清单，哪些先小范围试。

行动项每条写四件事：做什么、谁负责、什么时候完成、怎么算完成。缺一项，都容易被搁置。

下面是填写示例，数据为虚构示例，只用于说明格式：

• 环境申请纳入开发阶段启动清单。负责人：运维接口人。下个迭代开始前完成。验证方式：新项目启动检查表里出现该条目。
• 需求评审前完成待确认项梳理。负责人：产品负责人。下月底前完成。验证方式：评审纪要中待确认项不超过三条。
• 关键模块 Bug 按模块统计并月度公示。负责人：测试负责人。下月起每月执行。验证方式：月度质量报告包含分模块 Bug 分布。

"加强沟通""提升质量意识"这类写法没有验证方式，等于没有行动项。一条行动项如果回答不出"怎么算做完了"，就不该写进表里。

复盘不白开的四个检查点

1. 数据能不能核查，口径是否一致，而不是会议上的回忆。
2. 差异有没有定位到具体节点和具体原因，不停留在"时间紧、任务重"。
3. 经验有没有写明适用条件，换个项目知道能不能用。
4. 上次复盘的行动项，这次开会前有没有先检查完成情况。

第四条最容易被跳过，也最能说明一个团队的复盘是不是真的在运转。项目复盘模板的价值从来不在填得完整，而在于这一次得出的行动项，真的成为下一个项目的起点。