项目复盘概论

咱们直接进入正题。

你可能觉得复盘不就是"总结一下"嘛？说实话，我刚入行那几年也这么想。那时候项目做完，写个结项报告、开个庆功会，感觉就完事了。后来带过一个线上事故复盘，差点把整个团队搞崩——我才意识到，复盘和总结完全是两码事。

为什么需要复盘

先问个问题：你踩过的坑，第二次还会踩吗？

如果凭记忆，大概率还会。人类的记忆会美化、会遗忘、会添油加醋。我记得有一次做支付系统重构，上线后凌晨2点被报警叫醒——数据库连接池爆了。当天早上复盘时，大家七嘴八舌，有人说"早就发现测试环境配得不对"，有人说"压测报告那天没看完"……但这些"早知道"在项目进行中根本没人提。为什么？因为没有机制把碎片化的经验沉淀下来。

复盘解决的就是这个痛点。它强迫我们跳出"赶进度"的惯性，用结构化的视角重新审视已经发生的事。

我总结了三个核心理由：

• 组织记忆会丢 —— 核心成员离职，带走的经验比文档多十倍。复盘能把隐性知识显性化。
• 重复犯错太贵 —— 一个Bug在开发阶段修成本是1，线上修是100。避免重复犯错是性价比最高的投资。
• 局部最优 ≠ 全局最优 —— 各自为战的决策凑在一起，经常是灾难。复盘让团队看见拼图的全貌。

复盘的核心价值

价值这个词很容易写虚。我用一个真实的例子来讲。

前年带一个SaaS平台的项目，原计划6个月交付，结果拖到10个月。团队士气低，客户天天催。项目结束后，我硬拉所有人做了三次复盘。第一次大家都沉默，第二次开始有人吐槽需求变更太随意，第三次才挖到根因——我们缺少一个需求变更评审环节，开发直接听产品经理的，改一个字段就改一周的代码。

那次复盘产出了三样东西：

1. 一张决策缺陷清单 —— 白纸黑字写了"没有变更评审流程"、"缺少技术影响评估"。
2. 一份改进方案 —— 引入变更控制委员会（CCB）和影响分析模板。
3. 一个知识卡片 —— 把这次教训浓缩成"需求变更必须过三道门"，后面新项目直接拿来用。

你发现没有？复盘的价值不是"知道了"，而是"改变了"。

我习惯把复盘价值分为三个层次：

层次	表现	典型产出
第一层：个人	参与者自己想通了一些事	个人行动清单、反思笔记
第二层：团队	团队对齐认知、消除盲区	流程改进项、检查清单
第三层：组织	沉淀为制度或工具	规范文档、自动化检测、培训材料

大部分团队只做到了第一层。为什么？因为复盘太像"批斗会"了。我曾经见过一个团队复盘，主管指着屏幕说"这个Bug就是你写的"，会议室瞬间冷场。复盘变成追责，那就废了。

复盘的起源与演进

复盘这个词，最早来自围棋。棋手对弈结束后，把刚才的棋重新摆一遍，思考哪一步可以下得更好。后来被联想、华为等企业引入管理领域。

真正让复盘成为体系的是美国陆军——事后回顾（After Action Review，AAR）。AAR有四个核心问题：

1. 我们原本打算做什么？
2. 实际发生了什么？
3. 为什么会发生差异？
4. 下次怎么做？

这四个问题就是复盘的最小单元。后来各种方法论——GRAI、PDCA复盘法、KPT复盘法——万变不离其宗。

我这些年用过各种框架，最后发现最实用的还是"四个盒子"：

• 目标回顾：写下来，不要凭印象。我记得有一次团队说"目标都完成了"，结果翻出立项文档，发现三个核心指标只实现了两个。凭印象复盘，等于没复盘。
• 结果评估：用数据说话，不要"大概、可能"。超过预期/达到预期/低于预期，或者压根没做。
• 根因分析：追问"为什么"至少五层。不是"没测试"而是"测试环境与生产不一致"再往下是"配置管理流程缺失"。
• 行动提炼：必须可执行、可检查、有时间节点。不要写"加强沟通"，要写"每周三上午10点开15分钟站会"。

复盘的发展很有意思。一开始是事后复盘，项目结束了才做。后来变成阶段性复盘——每两周或每个迭一次。现在业界已经在推"实时复盘"：关键决策发生时立刻记录，出问题时马上回溯。我参与的阿里云SRE团队，就要求故障响应结束后1小时内出复盘草稿，当天出正式报告。

这张图展示了复盘最核心的循环结构：

这个循环最重要的特征就是闭环。很多复盘做成了"开个会、写报告、扔进文件夹"，根本没有跟踪。你想想看，如果一件改进措施没人跟进，等于浪费了所有人的时间。

复盘这个概念从围棋走到企业，经历了从"个人修炼"到"团队能力"，再到"组织机制"的进化。今天讲这些，是给后面的章节打个底。后面你会看到各种实际场景下的复盘方法——故障复盘、需求变更复盘、技术选型复盘——但核心骨架都是这个循环。

好了，这就是复盘的"为什么"和"是什么"。接下来我们进入具体操作。