复盘（After Action Review）¶

项目结束了，大家松一口气，很快投入下一个项目。三个月后，同样的坑又踩了一遍。经历本身不会自动变成经验——只有经过结构化的回顾，经历才会沉淀为下一次能用上的判断力。

复盘（After Action Review，简称 AAR） 是把一次经历转化为经验的标准方法。它起源于美国陆军：训练演习结束后，无论军衔高低，参与者围坐一圈回答几个固定问题，目的不是评判谁表现好坏，而是搞清楚到底发生了什么、为什么会这样、下次怎么做。这套方法后来被壳牌、通用电气等企业引入，在中文语境里通常被称为“复盘”——这个词本身来自围棋，指对局结束后把棋子重新摆回去，逐步推演当时的选择。

复盘的核心是四个问题：

原本的目标是什么？
实际发生了什么？
为什么会有差异？
下次怎么做？

看起来简单，但做好的关键在于：前两个问题必须先达成事实共识，才能进入后两个问题。绝大多数失败的复盘，都是因为还没说清“实际发生了什么”，就急着争论“谁该负责”。

要点速览

四个问题：原本的目标 → 实际的结果 → 差异的原因 → 下次的做法。顺序不能乱。
对事不对人：复盘的产出是改进措施，不是责任认定。
成功也要复盘：只复盘失败，团队学不到“为什么会成功”，也就无法复制。
趁热做：事情结束后 1~3 天内，细节还记得清楚。
必须有产出：每条结论都要有负责人和时间，否则下次还会重演。

复盘的四个核心问题¶

1. 原本的目标是什么？（What was supposed to happen?）¶

先把当初的计划、目标、预期摆出来，包括当时掌握的信息和做出的假设。关键是回到当时的认知状态，而不是用现在才知道的信息去评判当时的决定（这叫“后见之明偏差”）。

如果发现团队成员对“原本的目标是什么”都说法不一，那么这本身就是最重要的一条发现。

2. 实际发生了什么？（What actually happened?）¶

按时间顺序还原事实：关键节点、关键决策、关键数据。这个阶段只陈述可被验证的事实，不做评价、不做归因。

主持人要把“我觉得当时太仓促了”这类评价，引导回“3 月 2 日确定方案，3 月 5 日就要上线”这样的事实。等事实铺完，很多评价会自然浮现，也更容易达成共识。

3. 为什么会有差异？（Why was there a difference?）¶

对比目标和结果，分析差距的原因。这一步可以用五问法往下追问，或者用鱼骨图把原因列全。

同时分析做对的部分：哪些做法带来了好结果？是偶然还是必然？这一问常被忽略，但它决定了成功能否复制。

4. 下次怎么做？（What will we do next time?）¶

把前三问的结论转化成具体行动，分成三类：

继续做（Sustain）：有效的做法，写进流程或清单。
开始做（Start）：这次缺失、下次要补上的动作。
停止做（Stop）：确认无效或有害的做法。

每条都要写清负责人和时间。没有负责人的结论，等于没有结论。

复盘会议流程（60~90 分钟）¶

时间	环节	要点
0–5 分钟	开场	说明目的是学习不是追责；约定规则：对事不对人、人人发言、不打断
5–15 分钟	回顾目标	把当初的目标、计划、假设摆出来，确认大家理解一致
15–35 分钟	还原事实	按时间线铺事实，可用白板画时间轴，标出关键节点
35–60 分钟	分析差异	既分析没做好的，也分析做对的；聚焦 2~3 个关键点
60–80 分钟	行动计划	继续做 / 开始做 / 停止做，每条指定负责人和时间
80–90 分钟	收尾	复述行动项；约定下次检查的时间

主持要点

让级别低的人先发言。领导先开口，后面的人就只会附和。
把评价拉回事实。“当时很混乱”→“当时有三个人同时在改同一份文档”。
允许沉默。给人思考的时间，不要急着填满空白。
控制在 2~3 个关键问题。一次复盘解决所有问题，等于什么都没解决。
自己也要被复盘。主持人如果是负责人，主动说出自己的失误，是建立安全感最有效的方式。

复盘模板¶

基本信息：事件 / 项目名称、时间、参与者、主持人

问题	内容
1. 原本的目标	目标是什么？当时的关键假设是什么？
2. 实际发生	时间线：关键节点、关键决策、关键数据
3. 差异原因	做得好的：哪些做法有效？是必然还是偶然？
	做得不好的：根本原因是什么？（用五问法追问）
4. 下次怎么做	见下表

类型	行动	负责人	完成时间
继续做（Sustain）
开始做（Start）
停止做（Stop）

自检清单

事实部分没有混入评价和猜测
既分析了失败，也分析了成功
原因追问到了流程或机制层面，不是停在“某人没注意”
每条行动都有负责人和时间
约定了检查行动项落实情况的时间

应用案例¶

案例一：一次线上事故的复盘

目标：当晚的版本发布应在 30 分钟内完成，不影响用户下单。
实际：21:00 开始发布，21:12 支付接口报错率飙升，21:48 回滚完成，共影响用户 48 分钟。
差异原因：做得好的是监控告警在 2 分钟内就触发了，值班同学响应迅速；做得不好的是回滚花了 36 分钟——追问下去，根本原因是回滚脚本半年没演练过，执行时才发现依赖的配置项已经变更。
行动：继续做——保留当前的告警阈值（负责人：小李）；开始做——每季度演练一次回滚流程（负责人：小张，本月底前排期）；停止做——停止在周五晚上做大版本发布（负责人：技术负责人，立即生效）。

案例二：一次成功的市场活动复盘

团队常犯的错误是“成功了就不复盘”。这次活动超额完成 40%，复盘后发现：真正带来转化的不是投入最大的信息流广告，而是一位用户在社区发的使用心得被自然转发。这个发现让团队把下一季度的预算重新分配，并开始做系统性的用户内容激励。如果不复盘，团队很可能把成功归因于广告预算，继续加大投入。

案例三：个人复盘——一次没谈成的合作

个人也可以用 AAR。目标是签下一个合作意向；实际是对方在第二次会面后不再回复。还原事实时发现，第一次会面自己讲了 40 分钟产品，对方只说了约 10 分钟。差异原因是没有先了解对方真正关心什么就开始介绍方案。下次的做法：第一次会面不超过 1/3 时间讲自己，其余时间提问（可参考 ORID 聚焦式对话的提问结构）。

常见误区¶

复盘变成追责大会。一旦有人被追责，所有人都会开始自我保护，真相就再也问不出来了。开场必须明确：目的是改进流程，不是认定责任。
跳过事实直接归因。还没搞清楚发生了什么，就开始讨论“为什么”，结论往往建立在各自不同的记忆上。
只复盘失败。成功的经验如果不复盘，就无法复制，还容易把运气当成能力。
用现在的信息评判当时的决定。“早该想到的”——但当时并没有这个信息。要回到当时的认知状态看决策是否合理。
结论停在“某人不够细心”。这不是根本原因。要继续问：为什么流程没能拦住这个失误？
开完就结束。行动项没有负责人、没有时间、没有人检查，下次一定重演。
拖太久才做。一个月后再复盘，细节已经模糊，只剩下各自的印象。

复盘、项目总结与事前验尸的区别¶

	复盘（AAR）	项目总结报告	事前验尸（Pre-mortem）
时间点	事后，越快越好	事后，通常项目收尾时	事前，计划制定后、执行前
目的	团队学习，改进下次做法	向上汇报成果与经验	提前发现可能导致失败的风险
形式	开放讨论，人人发言	书面文档，常由一人撰写	想象项目已经失败，倒推原因
产出	继续做 / 开始做 / 停止做	总结报告	风险清单与预防措施
氛围	平等、安全	偏正式	允许“唱衰”

三者可以组合使用：事前验尸找风险 → 执行 → 复盘学经验 → 项目总结对外汇报。

常见问题¶

复盘和 AAR 是一回事吗？

基本是。AAR（After Action Review）是源自美国陆军的方法名称，中文语境里常译作“复盘”或“行动后回顾”。“复盘”一词本身来自围棋，含义高度契合，所以在中文企业里成了通用说法。

多大的事情才值得复盘？

看是否有可迁移的经验。一次线上事故、一个项目里程碑、一场重要谈判、一次营销活动都值得。小事可以做 15 分钟的轻量复盘，只问四个问题各一轮。

复盘应该多少人参加？

直接参与者都应到场，通常 5~12 人。人太多会让多数人沉默，可以拆成小组分别复盘再汇总。关键角色缺席时，宁可改期。

领导在场，大家不敢说真话怎么办？

几个办法：领导先主动说出自己的失误；让级别最低的人先发言；敏感问题用匿名便利贴收集；或者先由中立的人主持一轮不带领导的讨论，再汇总。

复盘和 ORID 有什么关系？

ORID 聚焦式对话是一套通用的引导提问结构（客观—感受—诠释—决定），可以用来主持复盘会议。AAR 的四个问题更聚焦于“目标与结果的差异”，ORID 则多了情绪层，适合涉及团队感受的复盘。

延伸与关联¶

ORID 聚焦式对话：主持复盘会议时非常好用的提问结构，尤其适合需要照顾团队情绪的场合。
五问法 与 鱼骨图：分析“为什么有差异”时的主力工具。
PDCA 循环：复盘相当于 PDCA 中的 Check 和 Act 两个阶段。
改善（Kaizen）：把复盘产出的改进措施固化下来，就是一次改善。
SBI 反馈模型：复盘中需要对个人给出反馈时，用 SBI 的结构更不容易引发防卫。
敏捷开发 与 Scrum：Sprint 回顾会议（Retrospective）是复盘在敏捷团队中的制度化形式。

来源参考：After Action Review 由美国陆军在 1970 年代发展为正式的训练回顾方法，后被收录进其领导力与组织学习体系，并被壳牌、通用电气等企业引入商业领域。哈佛商业评论、《第五项修炼》等著作对其在组织学习中的作用有专门讨论。