上周刚跟团队开完一个延期了三周的客户项目收尾会，散会的时候行政小姑娘抱着一摞A4纸追过来，问要不要把会议记录归档成正式的“管理复盘材料”。我当时头都大了。
说出来不怕笑话，我刚升部门负责人那会，真把这事搞砸过。那会做一个老客户的内部系统升级项目，上线前一周突然爆了数据兼容的问题，我急着给老板交差，拉着团队开了三个小时的追责会，从产品经理问到测试岗的小伙子，最后定的“复盘结论”是测试漏了边缘场景，扣了他的季度绩效。结果散会第二天，他交了离职申请。他说自己前后提了三次，要把老系统的历史数据迁移测试排进排期，每次都被我压到后面——因为要先赶客户要的演示版本，怕客户等不及。现在想起来都臊得慌。
别把复盘开成“追责批斗会”
从那之后我才明白，为什么大家一提复盘就皱眉头。本质上不是大家怕总结经验，是怕一坐下来，所有人的眼睛都盯着“谁错了”，没人愿意说当时的真实情况。毕竟谁都不想刚开口就被扣个“能力不行”的帽子。
后来我改了开复盘会的第一个规则：开场先把“问责”的牌子摘下来。不先说“谁的问题”，先问“当时我们所有人拿到的信息是什么”。
就说上周那个延期的项目，坐下来捋了半小时才发现，那个把进度拖慢的需求变更，根本不是设计师理解错了。是商务同事三个月前跟客户对接的时候，把新需求记在了自己的私人微信备忘录里，忘了同步到项目共享文档。设计师拿到的还是三个月前的旧需求，等客户那边对设计稿提意见的时候，已经离原定上线时间只剩一周了。
这种事说出来都可笑，但真的会发生。
你看，如果按以前的开法，肯定第一时间骂设计师“怎么不提前确认需求”，骂商务“怎么不做好同步”。但坐下来捋清楚信息差就会发现，没人是故意要把事情搞砸，大家都是在自己拿到的信息里，做了当时觉得最对的选择。
以前我总觉得，管理就是要把责任钉到具体的人头上。现在才懂，复盘会要是把人逼得不敢说话，就算写出来的报告再漂亮，也全是假的。
别拿“下次注意”当复盘结论
我之前见过太多复盘材料，写得冠冕堂皇，最后落到改进措施上，全是“下次要加强沟通”“下次要提前做好排期”“下次要注意细节”。
这话说了跟没说一样。
有次我们做线下行业沙龙，活动结束复盘，大家七嘴八舌说了一堆问题，最后总结的改进项是“下次要提前跟场地方确认好电源位置”。我当时直接把笔停了，问了三个问题：那这次没确认，是安排的谁去对接？对接的时间点是在活动前几天？上次没确认到位，是因为对接的人忘了，还是根本没把这项列进检查清单里？
问完大家都沉默了。
所有写不出责任人、写不出具体时间节点的改进项，全都是正确的废话。
后来我们把之前那句空泛的“提前确认电源”，改成了：活动前3天，由现场执行的同事拿着提前打印好的12项检查清单，逐项跟场地方核对，每核对完一项打个勾，拍照片同步到项目群。从那之后，我们再办活动，再也没出现过“投影仪没电源”“话筒没电”的低级问题。
说实话，刚开始定这些规则的时候，有老员工吐槽，说搞这么细，是不是太麻烦了。但真的跑了两次就知道，把“下次注意”换成具体的动作，比开三小时会喊口号有用得多。
毕竟人都是有惰性的。你不把动作拆到最细，下次遇到一样的场景，还是会踩一样的坑。
复盘不是只有项目结束才做
以前我也觉得，复盘是“事后算账”，必须等整个项目全部收尾了，才能坐下来慢慢总结。平时天天赶进度，哪有空坐下来聊这些。
结果就因为这个想法，去年那个系统升级项目，我们中间攒了好几个小问题，硬扛着没开中途复盘，最后全成了大窟窿。比如当时开发同事提了三次，说接口响应速度有点慢，影响用户操作。我们都觉得是小问题，等上线前再统一优化就行。结果真上线那天，客户那边的老员工本来就对新系统抵触，一打开就卡半分钟，直接拍桌子说我们做的东西不能用，前后花了整整一周才把情绪安抚下来。
从那之后我改了个规矩：不管项目大小，只要连续出现两次同类型的小问题，就拉着相关的人花20分钟开个迷你复盘。不用做PPT，不用写汇报，就拿个白板写三行字：刚才发生了什么，为什么会发生，接下来要调整哪个小动作。
刚开始大家都觉得这是浪费时间。直到上个月做那个小程序项目，我们中途发现产品、开发、设计三拨人，对“用户登录流程”的理解完全不一样——产品觉得要加短信验证，开发觉得直接用微信授权就行，设计还在按最老的版本画界面。要是等开发完了才发现这个问题，至少要耽误五天工期。我们花了15分钟开了个小会，把流程捋顺，最后整个项目比原定上线时间还早了两天。
没人天生会做管理。踩的坑多了，自然就知道哪块路滑。
我现在再也不会让团队为了归档去凑那些漂亮的复盘报告了。毕竟真的能帮大家少踩坑、少加班的东西，从来都不是写在纸上的套话。是你坐下来，敢把当时犯的错摊开说，敢把虚头巴脑的改进项换成能落地的小动作，敢真的盯着每一条改进项落地——这些事，比任何高级的管理模型都有用。
