1、复盘的价值：为什么嵌入式项目必须复盘？

做嵌入式开发十几年，我见过太多项目“做完就扔”。代码一烧录，板子一发货，团队立刻扑向下一个需求。结果呢？同样的Bug换个马甲又回来，同样的延期理由反复出现。

说白了，不复盘的项目就像在黑夜里开车还不开灯。你撞了坑，下次还得撞。

为什么嵌入式项目尤其需要复盘？

嵌入式项目有几个特点，决定了复盘不是“锦上添花”，而是“雪中送炭”：

特点	不复盘的风险	复盘的价值
软硬件强耦合	硬件改版成本高，软件Bug定位难	提前暴露接口问题，减少改版次数
资源极度受限	RAM/Flash溢出、性能瓶颈反复出现	积累优化经验，形成团队“避坑清单”
调试手段有限	线上问题难以复现，靠“猜”修Bug	沉淀调试技巧，提升问题定位效率
多团队协作	驱动、算法、应用层互相甩锅	明确责任边界，建立信任机制
产品生命周期长	人员流动导致知识断层	形成组织资产，新人快速上手

我记得有一次做车载项目，MCU的SPI通信在实验室跑得好好的，一上车就丢数据。团队折腾了两周，最后发现是硬件上拉电阻选型问题。如果当时做了复盘，把“SPI抗干扰检查清单”沉淀下来，后续三个项目至少能省一半的联调时间。

复盘与总结的区别

很多人把复盘和总结混为一谈。我个人的理解是：总结是“记流水账”，复盘是“挖根因”。

举个例子。项目延期了，总结会写：“由于驱动开发比预期多花了5天，导致整体延期。” 复盘则会追问：

• 为什么驱动开发会多花5天？
• 是需求不清晰？还是芯片手册有坑？
• 有没有办法在方案阶段就识别这个风险？
• 下次遇到类似芯片，我们该怎么做？

你看，总结停在“发生了什么”，复盘要回答“为什么会发生”和“如何不再发生”。

复盘的核心原则

复盘不是批斗会，也不是表功会。我见过不少团队把复盘开成了“甩锅大会”或“沉默大会”，最后不了了之。要避免这种情况，必须守住三条原则：

原则一：坦诚

不藏着掖着，不粉饰太平。项目出了问题，每个人都有责任。我自己就犯过这样的错——明明是自己代码里有个临界区没处理好，复盘时却说是“硬件时序不稳定”。结果呢？问题在下一个项目里又炸了，而且炸得更狠。

原则二：开放

允许不同声音，鼓励“反直觉”的观点。嵌入式项目里，很多问题都不是单因单果。比如一个死锁问题，可能是调度策略、锁粒度、中断优先级共同作用的结果。如果复盘时只有项目经理或架构师在说，其他人不敢开口，那很多深层原因就挖不出来。

我习惯在复盘开始时说一句话：“今天没有上下级，只有工程师。谁发现问题最准，谁就是今天的MVP。” 这句话很管用，气氛一下子就松了。

原则三：就事论事

对事不对人。复盘要讨论的是“这个决策为什么错了”，而不是“你这个人怎么总犯错”。

举个例子，不要说：“小王，你写的I2C驱动太烂了，导致传感器数据一直读错。” 应该说：“I2C驱动在时钟延展场景下没有做超时处理，导致总线挂死。我们来看看怎么修复，以及后续怎么在代码审查中提前发现这类问题。”

你看，前者是人身攻击，后者是技术讨论。方向完全不同。

复盘的核心逻辑框架

说了这么多，复盘到底怎么做？我画了一张图，把整个逻辑串起来：

这个框架我用了很多年。每次复盘都按这七步走，不跳步、不省略。尤其是最后一步“跟踪闭环”，很多团队做到“知识沉淀”就停了，觉得文档写完了就完事了。其实不然——没有跟踪的复盘，等于白做。

举个例子，复盘发现“代码审查流于形式”，制定了“增加审查Checklist”的行动项。两周后谁去检查？Checklist用了吗？效果怎么样？这些都要有人跟踪。我习惯在项目看板上加一列“复盘行动”，每个行动项指定负责人和截止日期，每周站会过一遍。