1、复盘基础：什么是项目复盘、复盘与总结的区别、复盘的核心价值、复盘的文化建设

1.1 什么是项目复盘

项目复盘，说白了就是「把做过的事重新过一遍」。

我习惯把它比作「手术后的病理分析」。手术做完了，病人醒了，不代表就完事了。你得把切下来的组织拿去化验，看看当初的判断对不对，刀口开得是否合理，有没有更好的方案。项目复盘也是这个道理——不是秋后算账，而是为了下次做得更好。

在我带过的团队里，很多人把复盘理解成「开个会，说说哪里做得不好」。这其实是个误区。复盘的核心动作是「还原」和「反思」。

举个例子。我之前带过一个智能家居的项目，网关模块在量产前突然出现死机问题。团队花了三天排查，最后发现是内存泄漏。如果只是修 bug，那叫「救火」。但如果我们复盘一下：为什么代码评审没发现？为什么单元测试没覆盖到这个场景？为什么压力测试只跑了标准用例？——这才是复盘。

1.2 复盘与总结的区别

这个问题我经常被问到。很多人觉得复盘就是总结，其实差别挺大的。

维度	总结	复盘
时间点	项目结束后	项目过程中或结束后
关注点	结果好坏	过程与原因
输出物	报告、数据	经验、改进措施
心态	评判性	学习性
深度	表面现象	根因分析

你想想看，总结通常是什么样？「这个月完成了3个需求，延期了1个，原因是需求变更。」然后呢？没了。下次该延期还是延期。

复盘就不一样了。我会追问：需求变更是谁提出的？为什么在开发中期才提？我们的需求评审流程有没有漏洞？变更管理机制是否形同虚设？

我曾经带过一个项目，硬件工程师和软件工程师因为 I2C 时序问题吵了三天。最后总结报告里写的是「沟通不足」。这有用吗？没用。复盘时我们深挖下去，发现是需求文档里时序参数写错了，硬件按 datasheet 来，软件按需求文档来，两边都对不上。后来我们改了文档审核流程，加了交叉确认环节。这才是复盘的价值。

1.3 复盘的核心价值

复盘到底能带来什么？我总结了三点。

第一，避免重复踩坑。

嵌入式开发有个特点：很多坑是隐性的。比如某个 GPIO 在休眠模式下会漏电，某个外设在特定时序下会挂死。这些经验如果不复盘，就会随着项目结束而流失。新来的工程师大概率会再踩一遍。

第二，提升团队能力。

复盘不是一个人的事。当大家坐在一起，把各自踩过的坑、用过的技巧摊在桌面上，整个团队的能力边界就扩展了。我见过最有效的团队，不是代码写得最快的，而是复盘做得最勤的。

第三，优化流程和规范。

很多流程问题，平时是看不出来的。只有在复盘时，你才会发现：哦，原来代码评审的 checklist 里漏掉了电源管理部分；原来测试用例的覆盖率要求太低了。这些改进，直接决定了下一个项目的质量基线。

1.4 复盘的文化建设

这是最难的部分。技术问题好解决，人的问题最难搞。

我见过不少团队，复盘会开成了「批斗会」。项目经理拿着数据，一个个问「这个 bug 是谁写的」「这个延期是谁造成的」。结果呢？下次复盘没人愿意说真话了。

复盘文化建设的核心就一句话：对事不对人。

具体怎么做？我分享几个经验。

• 建立安全氛围：复盘会上不追责，不扣绩效。谁都可以说「我当时判断错了」，不会有人拿这个说事。
• 领导先认错：如果项目经理或技术负责人先承认自己的决策失误，下面的人才会放下防备。我记得有一次，我主动说「这个方案是我拍板的，我低估了功耗问题」，之后整个复盘会的气氛就变了。
• 用数据说话：不要凭感觉。比如「这个模块测试覆盖率低」比「你们测试不认真」要好得多。
• 形成闭环：复盘出来的改进措施，要有人跟进，要有 deadline。否则复盘就是走过场。

嗯，这里还要说一点。复盘不是越频繁越好。项目周期短的话，可以每个迭代做一次。项目周期长，可以在关键里程碑做。我个人不建议每天复盘，那会变成形式主义。

最后说一句：复盘文化不是一天建成的。它需要耐心，需要示范，需要坚持。但一旦建立起来，你会发现团队的成长速度远超你的预期。