复盘五步法：目标回顾、结果评估、过程分析、根因挖掘、经验沉淀

复盘，说白了就是把做过的事重新捋一遍。不是批斗会，也不是表功会。我做了十几年嵌入式项目，最怕的就是那种「做完就完」的团队——问题重复出现，同样的坑踩了又踩。

我个人习惯把复盘拆成五个步骤。每一步都有它的目的，跳不得，也省不得。

第一步：目标回顾——搞清楚当初要什么

很多人复盘上来就讲「哪里出了问题」。我建议先停一下。你连当初的目标都没对齐，怎么判断结果是好是坏？

目标回顾要回答三个问题：

• 目标是什么？ 要具体，不能是「提升产品质量」这种空话。应该是「Bootloader 启动时间从 3 秒降到 1.5 秒以内」。
• 谁定的目标？ 是客户提的？产品经理定的？还是技术团队自己拍脑袋的？来源不同，复盘时的评判标准也不同。
• 目标有没有变过？ 项目做到一半需求变更，目标也跟着变了。这种情况很常见，复盘时要把变更记录翻出来。

第二步：结果评估——用数据说话

目标回顾完了，接下来看实际结果。这一步最忌讳「我觉得还行」「差不多吧」这种模糊表述。

我一般会用表格把目标和结果摆在一起对比：

你看，这么一摆，哪些达标、哪些没达标，一目了然。别急着分析原因，先把事实摆清楚。

第三步：过程分析——还原发生了什么

结果摆出来了，接下来要还原过程。这一步最容易变成「甩锅大会」。你想想看，如果每个人都在说「是某某环节的问题」，那复盘就废了。

我建议用时间线的方式，把关键事件列出来：

1. 项目启动 —— 团队组建、任务分解、排期
2. 开发阶段 —— 编码、单元测试、代码评审
3. 集成测试 —— 模块联调、硬件在环测试
4. 系统测试 —— 压力测试、边界测试、稳定性测试
5. 发布阶段 —— 版本打包、OTA 推送、灰度验证

在每个阶段，问三个问题：

• 实际做了什么？
• 计划做什么？
• 差距在哪里？

我曾经在一个项目中，发现 Bootloader 启动时间超标。过程分析时才发现，开发阶段为了赶进度，跳过了代码尺寸优化。集成测试时又因为硬件平台没到位，用模拟器跑的测试，根本没暴露真实性能问题。你看，问题不是出在最后，而是从中间就开始偏了。

第四步：根因挖掘——别被表面现象骗了

这是五步法里最难的一步。很多人挖到「代码写得不好」「测试不充分」就停了。但这不是根因，只是表面现象。

我常用的方法是「5 Whys」——连续问五个为什么。举个例子：

• 问题： OTA 升级失败率偏高
• 为什么？ 升级过程中断导致固件损坏
• 为什么？ 升级时没有做断点续传
• 为什么？ 当初设计时没考虑网络不稳定场景
• 为什么？ 需求文档里没写这个场景
• 为什么？ 产品经理不了解嵌入式 OTA 的常见风险

你看，根因是「产品经理缺乏嵌入式领域知识」，而不是「代码写得烂」。根因挖到这个层面，改进措施就不一样了——不是改代码，而是建立产品经理的技术培训机制。

第五步：经验沉淀——把教训变成资产

最后一步，把复盘结果变成可执行的东西。不是写一篇复盘报告就完事了，那东西大概率没人看第二遍。

我一般会输出三类成果：

我个人习惯把经验沉淀成「检查清单」。你想想看，下次做新项目时，拿着这份清单逐项核对，比翻十篇复盘报告管用多了。

嗯，五步法讲完了。记住这个顺序：目标回顾 → 结果评估 → 过程分析 → 根因挖掘 → 经验沉淀。下次做项目复盘时，拿这个框架试试，你会发现团队成长的速度明显不一样。