1. 项目复盘基础：什么是嵌入式项目复盘？
大家好，我是老周。做嵌入式开发十几年，带过的项目少说也有几十个。今天咱们聊聊项目复盘这件事。
很多人一听「复盘」就觉得是走形式。开个会，大家坐一起，说几句「下次注意」，然后该干嘛干嘛。我告诉你，真正的复盘不是这样的。
1.1 什么是嵌入式项目复盘？
复盘这个词，最早来自围棋。棋手下完一盘棋，把棋子重新摆一遍，看哪步走得好，哪步走臭了。嵌入式项目复盘，道理一样——把项目从头到尾「回放」一遍，找出做得好的和做得差的。
但要注意，复盘不是批斗会。我见过不少团队把复盘开成了「甩锅大会」。项目经理怪开发进度慢，开发怪测试没测出来，测试怪需求没写清楚……这种复盘，开一百次也没用。
复盘的核心是对事不对人。我们找的是流程、方法、工具上的问题，不是追究谁的责任。
嵌入式项目复盘的定义：
项目复盘是在项目结束后（或关键里程碑后），团队系统性地回顾项目过程，分析成功与失败的原因，提炼可复用的经验教训，并形成改进措施的活动。
1.2 复盘与总结的区别
这个问题我经常被问到。很多人觉得复盘就是总结，其实差别很大。
我举个例子。有一次我们做一款智能门锁，项目延期了两个月。项目经理写了个总结：
- 项目延期2个月
- 原因是蓝牙模块驱动调试时间过长
- 下次注意预留更多时间
这叫总结。记录发生了什么，原因是什么，下次注意什么。听起来没毛病，但有用吗？下次该延期还是延期。
复盘就不一样了。我们会追问：
- 为什么蓝牙模块调试花了这么长时间？
- 是因为选型时没评估好？还是供应商提供的资料不全？
- 我们的硬件工程师有没有提前做兼容性测试？
- 项目计划里为什么没考虑到这个风险？
你看，复盘是在找根因，总结只是在找表面原因。
| 维度 | 总结 | 复盘 |
|---|---|---|
| 时间点 | 项目结束后 | 项目结束后或关键里程碑 |
| 深度 | 表面原因 | 根因分析 |
| 方法 | 罗列事实 | 结构化分析（5Why、鱼骨图等） |
| 产出 | 经验教训列表 | 可执行的改进措施 |
| 参与人 | 项目经理或负责人 | 全体项目成员 |
| 氛围 | 汇报性质 | 开放、坦诚、学习导向 |
说白了，总结是「知道了」，复盘是「改进了」。
1.3 复盘的核心价值
你可能会问：花时间做复盘，值吗？
我跟你算笔账。一个嵌入式项目，从需求到量产，少说半年。如果每次犯的错都重复犯，那成本太高了。复盘的价值，就是让团队避免重复踩坑。
具体来说，复盘有这几个核心价值：
- 知识沉淀——把个人经验变成团队资产。我见过太多团队，老员工一走，经验就丢了。复盘能把隐性知识显性化。
- 流程优化——找到流程中的堵点。比如我们之前发现，硬件原理图评审总是拖到最后一周才做，导致改板时间不够。复盘后把评审提前到原理图完成50%时做，效果好了很多。
- 团队成长——新人通过复盘能快速了解项目中的坑。我带过一个应届生，参加三次复盘后，独立负责模块时基本没出大问题。
- 风险预判——积累的风险库能帮新项目提前规避问题。我们团队有个「踩坑清单」，每次新项目启动前先过一遍，至少能避开80%的常见问题。
我的经验：
复盘最大的价值不是「回顾过去」，而是「改变未来」。如果复盘后没有形成改进措施，那就是浪费时间。
1.4 复盘的核心原则
做了这么多年复盘，我总结了几条原则。这些原则看着简单，但真正做到不容易。
原则一：坦诚开放
复盘不是表演。我见过有人复盘时只说好的，不好的轻描淡写。这样搞，复盘就废了。团队必须建立一种「说真话不会被骂」的氛围。
原则二：对事不对人
这个前面提过。我再强调一次：复盘找的是系统性问题，不是个人问题。如果发现某个工程师代码质量差，我们要问的是「为什么代码评审没发现？」而不是「你怎么写的代码？」
原则三：数据说话
不要凭感觉。我记得有一次复盘，有人说「测试时间太长了」。后来一查数据，实际测试时间只占项目周期的15%，比计划还少了5%。所以，感觉不靠谱，数据才靠谱。
原则四：行动导向
复盘必须有产出。每次复盘结束，至少要形成3-5条可执行的改进措施，并且指定负责人和完成时间。没有行动的复盘，就是走过场。
避坑指南：
我曾经带过一个项目，复盘时大家提了十几条改进建议，结果一条都没落实。为什么？因为每条建议都太模糊了，比如「加强沟通」。这种建议没法执行。改进措施必须具体到「谁、做什么、什么时候完成」。
1.5 本章知识结构
下面这张图，把本章的核心内容串起来了。你可以把它当作复盘的「知识地图」。
这张图把复盘的四个核心维度串起来了。你每次做复盘前，可以对照着看看：定义清楚了吗？和总结的区别搞明白了吗？价值想清楚了吗？原则遵守了吗？