复盘流程：复盘四步法与会议组织

复盘这件事，说起来简单，做起来难。

我在嵌入式行业摸爬滚打十几年，见过太多项目做完就扔到一边的团队。代码跑通了，功能实现了，大家开个庆功宴，然后下一个项目继续踩同样的坑。说实话，这是最可惜的。

为什么？因为经验没有沉淀下来。

今天我就把复盘的核心流程拆开来讲。你照着做，至少能避免80%的重复错误。

复盘四步法

我个人习惯把复盘分成四个步骤。不多不少，刚好够用。

第一步：回顾目标

很多人觉得这步多余——目标不就在需求文档里吗？

嗯，问题就在这里。文档里的目标和实际执行的目标，往往是两回事。

我在项目中遇到过这样的情况：需求文档写的是「系统响应时间小于100ms」，但开发过程中大家默认成了「界面不卡就行」。结果复盘时才发现，大家对目标的理解根本不在一个频道上。

回顾目标时，你要问三个问题：

• 原始目标是什么？——翻出项目启动时的文档，白纸黑字写清楚
• 目标有没有变化？——中途改需求、加功能，目标可能已经漂移了
• 大家理解一致吗？——项目经理、开发、测试，每个人对目标的认知是否相同

第二步：评估结果

目标定好了，接下来看结果。

评估结果不是简单说「完成了」或「没完成」。你要把结果量化出来。

举个例子：

维度	目标	实际	偏差
响应时间	≤100ms	85ms	达标
内存占用	≤256KB	312KB	超标22%
开发周期	8周	11周	延期37.5%
Bug数量	≤10个	23个	超标130%

你看，数据一摆出来，问题就清晰了。不用争，不用吵，数字说话。

第三步：分析原因

这是最核心的一步，也是最难的一步。

为什么？因为人天生会找借口。「时间太紧了」「需求变太多了」「硬件不给力」——这些听起来都像原因，但都不是根本原因。

我建议用「5Why分析法」。就是连续问五个「为什么」，直到找到根因。

举个例子：

问题：内存占用超标22%

Why1：为什么超标？ → 因为缓存区开太大了
Why2：为什么开这么大？ → 因为怕数据丢失
Why3：为什么怕数据丢失？ → 因为没有做流控机制
Why4：为什么没做流控？ → 因为设计时没考虑这个场景
Why5：为什么没考虑？ → 因为需求评审时遗漏了边界条件

你看，问到第五层，根因就出来了——不是技术问题，是需求评审流程的问题。

分析原因时，我习惯把原因分成三类：

• 技术原因： 算法选型不对、数据结构不合理、驱动有Bug
• 流程原因： 评审不充分、测试覆盖不全、沟通不到位
• 管理原因： 计划不合理、资源不足、优先级混乱

第四步：总结规律

这一步是把经验变成可复用的资产。

总结规律不是写「下次注意」，而是提炼出可以执行的规则。

比如：

• ❌ 错误的总结：「下次要更仔细」
• ✅ 正确的总结：「所有涉及DMA的模块，必须做边界测试，测试用例覆盖最大和最小传输长度」

我自己的做法是，每次复盘后输出三样东西：

1. 一条规则： 以后做类似项目必须遵守的硬性要求
2. 一个检查清单： 下次启动项目前逐项核对
3. 一个改进项： 需要修改的流程或工具

复盘会议组织

复盘四步法讲完了，但怎么组织会议也是个技术活。

我参加过很多复盘会，有的开得热火朝天，有的开得昏昏欲睡。区别在哪？

会议前的准备

• 提前发资料： 至少提前2天把项目数据、问题清单发给大家。别指望会上大家现看
• 定好角色： 主持人、记录员、计时员。主持人最好不是项目经理，避免主观倾向
• 定好规则： 不追责、不甩锅、不打断。这三条写在白板上

会议中的节奏

我建议按这个时间分配：

环节	时间	内容
回顾目标	10分钟	主持人宣读原始目标，确认是否有变化
评估结果	15分钟	逐项对比目标与实际，列出偏差
分析原因	30分钟	针对主要偏差，用5Why法深挖根因
总结规律	20分钟	提炼规则、检查清单、改进项
行动计划	15分钟	明确责任人、完成时间、验收标准

总时长控制在90分钟以内。超过这个时间，大家的注意力就开始下降了。

复盘记录规范

会议开完了，记录怎么写？

很多人写复盘记录，洋洋洒洒几千字，结果没人看。为什么？因为太啰嗦了。

我建议用「一页纸复盘」的格式：

项目名称：智能家居网关V2.0
复盘日期：2024-03-15
参与人员：张三、李四、王五、赵六

一、目标回顾
- 原始目标：响应时间≤100ms，内存≤256KB，8周交付
- 实际变化：第5周新增OTA功能，目标未调整

二、结果评估（关键偏差）
1. 内存超标22%（目标256KB，实际312KB）
2. 开发延期37.5%（目标8周，实际11周）
3. Bug超标130%（目标10个，实际23个）

三、根因分析
1. 内存超标 → 缓存区设计未考虑边界条件 → 需求评审遗漏
2. 开发延期 → OTA功能未纳入计划 → 变更管理流程缺失
3. Bug超标 → 测试用例覆盖不足 → 测试评审流于形式

四、总结规律
1. 规则：所有新增功能必须走变更管理流程
2. 检查清单：需求评审时逐项核对边界条件
3. 改进项：测试用例必须经过三方评审（开发、测试、产品）

五、行动计划
| 改进项 | 责任人 | 完成时间 | 验收标准 |
|--------|--------|----------|----------|
| 建立变更管理流程 | 张三 | 3月30日 | 流程文档+试点运行 |
| 完善需求评审清单 | 李四 | 3月25日 | 清单覆盖所有边界场景 |
| 测试评审制度 | 王五 | 4月5日 | 至少完成一个项目的试点 |

六、遗留问题
- OTA功能的稳定性需要长期跟踪
- 建议在V2.1版本中增加内存监控模块

你看，一页纸，该有的都有了。谁负责、什么时候完成、怎么验收，清清楚楚。

复盘这件事，说白了就是「把经验变成资产」。

你想想看，一个项目做完了，代码、文档、测试报告都在，但最值钱的东西——经验——却留在每个人的脑子里。复盘就是把这些经验挖出来，变成团队都能用的东西。

我做了十几年嵌入式，最大的体会就是：项目可以失败，但经验不能浪费。

好了，复盘流程就讲到这里。下一章我们聊聊「复盘中的常见陷阱」，到时候我会分享几个我踩过的坑，保证让你少走弯路。