项目复盘怎么做？4步法让团队持续改进

你大概见过这样的复盘会：会议室里坐一圈人，项目经理对着表格念进度，念完问一句「大家还有什么要补充的」，没人说话。散会后纪要存进文档，下个项目开工，同样的问题再出现一遍。

这不是个别现象。项目管理协会（PMI）2018 年《职业脉搏调查》对全球 4,455 名项目管理从业者的调研显示，组织因项目表现欠佳造成的资金浪费平均占投资额的 9.9%，约 31% 的项目没有达到最初目标，48% 的项目没能按时完成。

问题不在开不开会，而在于复盘被开成了汇报。汇报是把结果讲清楚，复盘是把原因问明白、把下一次的做法定下来。

这套流程不复杂，说到底就是把四个问题摆到桌面上：原计划是什么，实际发生了什么，为什么会有差异，下次怎么改。问题都很朴素，难的是每次都问到底，并且把答案落到具体动作上。

搬到项目上就是四个动作，顺序不要打乱：

1. 回顾目标：把当初要打成什么说清楚，产出一份大家都认的目标基线。
2. 评估结果：用同一把尺子对照事实，产出一张差距清单。
3. 分析原因：顺着差距往下问，产出一份按可控性排序的原因清单。
4. 总结规律：把原因转成动作，产出一份带负责人和截止时间的改进清单。

四个词记不全也没关系，记住一句话就够了：先对齐目标，再看清事实，接着问透原因，最后写成动作。

复盘不是总结，也不是问责

项目总结回答的是「我们做了什么」，复盘回答的是「为什么是这个结果，下次怎么办」。两件事混在一起，会议就会变成念成绩。

值得专门开一场的信号有三个：结果与预期差距明显；过程中出现重复返工；协作反复卡在同一个环节。项目刚交付完，或者线上故障刚处理完，都是复盘的好时机，拖过一周，细节就记不清了。

还有一条边界要提前说死：复盘会上不评价人。一旦和绩效挂钩，每个人都会先想「这话会不会算到我头上」，原因分析就只能停在表面。

开会之前，先把下面几件事定下来：

• 材料：目标、结果数据、关键变更记录，提前一两天发给参会人。
• 主持：交给不直接背这个项目结果的人，项目经理专心讲事实。
• 人数：控制在十来个，核心成员必须到，其余按议题邀请。
• 时长：90 分钟左右，按项目规模增减。

第一步：回顾目标，先确认当初要打成什么

评估结果要有对照物，对照物就是当初的目标。这一步常见的失误，是目标、目的、里程碑三样混在一起分不清：

• 目标是可衡量的结果，比如「6 月底上线，首月线上异常率低于 1%」。
• 目的是背后的价值，比如「让客服不用再逐条人工核对」。
• 里程碑是中间的检查点，用来判断节奏是否正常。

让每个人先写下自己记得的目标，再对照立项文档。如果写出来的版本各不相同，说明当初就没传达到位——执行偏差多半从这里开始。

现场可以问四个问题：当初定的目标和验收标准是什么？哪些必须达成、哪些可以商量？过程中目标改过吗，改动由谁确认？当时的计划基于哪些假设，这些假设后来成立吗？

如果发现目标本身不可衡量，先把它重构清楚再往下走，别带着一个说不清的目标讨论结果。中途改过目标的，把变更前后两个版本都摆出来分开算，否则做得好与不好都会被混在一起算。

第二步：评估结果，只摆事实

把结果和目标逐条并列，做成一张对照表。常看的维度有五个：

比维度更容易出问题的是口径。同样是「延期」，按里程碑算和按上线时间算，结论可能完全相反。开会前先把口径统一，再谈差距。

这一步只回答「结果是什么」，别急着解释为什么。常见的一个场面是：刚说到第一条差距，就有人开始讲原因，二十分钟过去，后面几条还没看完。可以让记录人先把差距列完，原因留到第三步。

第三步：分析原因，别停在「时间紧」

差距列完了，往下追问。先把原因归成四类，分类的意义是决定下一步动作：

• 内部可控：方案选择、评审质量、人员安排、沟通机制。
• 内部不可控：其他项目抢资源、组织调整。
• 外部可控：供应商交付、合作方接口。
• 外部不可控：市场变化、政策调整。

工具上，鱼骨图用来把可能的原因摊开，避免只盯第一眼看到的那一个；5 Why 用来对单条差距往下追，追到能落成具体动作就停。追到「团队意识不够」这种层面，其实还没到底。

只复盘失败是另一种偏差。做成的事也要问：这次靠的是哪些动作，下次还成立吗？如果分不清「因为做对了」还是「因为外部条件宽松」，经验就带不走。

还有一个绕不过去的前提：会上得有人敢说真话。谷歌的亚里士多德计划用两年时间研究了内部 180 个团队，把心理安全感列为高效团队的五个关键特征之一；哈佛商学院的埃米·埃德蒙森研究这个课题更早，她早期的一个发现是，合作更好的团队上报的错误反而更多——不是错误更多，而是更愿意说出来。落到会议规则上就是三条：先讲事实再讲原因，管理者最后发言，讨论做法不评价人。

再用一条标准过滤原因：这件事下次再遇到，我们有没有能改变的动作。有，是原因；没有，是背景条件。停在「时间紧」等于没说，往下问——是排期估算偏乐观，是需求反复变更，还是人被临时抽走？

第四步：总结规律，写成能执行的动作

把每一条关键原因转成一句「下次遇到同类情况，我们这样做」。规律要能脱离这个项目，只对这一次成立的做法，写进项目文档就够了。

需要固化的结果分三类：继续沿用的做法、要修改的流程、应当停止的做法。

改进项很容易写成口号。「加强沟通」听着没错，但没人知道明天该做什么。换成这样就有动作了：需求评审提前一天把原型发到群里，产品经理在评审会上逐条确认验收标准。

每条改进项写清四件事：具体动作、负责人、完成时间、验证方式。 一次复盘留 3～5 条就够，多了没人跟。

会开完才是开始：让改进进入下一轮工作

会后 24 小时内把纪要和行动项发出去，行动项直接建成任务，指定负责人和截止时间。只留在纪要文档里的改进，等于没有——它不会出现在任何人的工作列表里，也就不会被想起来。

下次复盘的第一件事，是花几分钟回看上次的改进项：哪些做完了，哪些没动，为什么没动。改进有没有效果也要有验证方式，比如「评审前置」这条，可以用需求变更次数来衡量。

节奏上可以分三层：

• 项目级：项目或版本交付后做一次完整的。
• 迭代级：每个迭代结束前留半小时到一小时，只聊能立刻调整的做法。
• 事件级：线上故障处理完尽快做个短的，聚焦根因和预案，不等人到齐。

同一个问题连续两次复盘都出现，就别再当成执行问题讨论了，它已经变成机制问题，要放到更高一层去改。

常见问题

1. 复盘和敏捷里的迭代回顾（Retrospective）有什么区别？

迭代回顾是固定节奏的短会，对象是团队自己的协作方式，产出多半是下个迭代就能试的做法。项目复盘的对象是一次交付的整体结果，范围覆盖进度、质量、成本、协作，适合在阶段或项目结束时做。两者可以并存：迭代回顾处理过程中的小调整，项目复盘处理整体判断和规律沉淀，别用一个替代另一个。

2. 项目中途被取消，还值得复盘吗？

值得，而且要比正常项目更早做。这类复盘的重点不是交付结果，而是决策依据：当初支撑立项的假设是什么，哪条假设最早出现了不成立的信号，我们通过什么迹象、在什么时候发现的。产出物是一份中止判断的检查项和几个预警指标，让下一个项目更早看到同样的苗头。

3. 复盘时争起来了、收不拢结论怎么办？

先把事实和判断分开。对事实的分歧回到数据口径，口径不一致就先统一定义再讨论。对判断的分歧不必强行统一，可以保留两种结论，各自写清成立条件和验证时间点，交给下一次复盘检验。主持人把这些记成待验证项，比在会上压服一方有用。

4. 远程或跨地域团队怎么开复盘会？

材料提前发这一点更关键，因为少了走廊里的口头补充。可以让大家先在共享文档里写下自己记得的目标和差距，写完再口头讨论，避免先发言的人定调；主持人按名单轮流点名，防止全程只有几个人说话。会后纪要和行动项当场落到共享文档，谁改了什么都有痕迹。

项目复盘做一次不难，难的是每次都留下能被下一次用上的东西。四步走完，回到那句话上：对齐目标、看清事实、问透原因、写成动作。判断一场复盘有没有价值，只看一件事——下个项目里，有没有哪条做法因为这次复盘而变了。

参考来源：PMI《职业脉搏调查》（Pulse of the Profession®）2018 年报告；Google 亚里士多德计划相关公开资料。