上周三的复盘会，我刚翻开准备好的三页PPT，就被新来的产品经理打断。
“这事儿当初不是技术说做不了吗？”
空气瞬间僵了半秒。
我靠在椅背上，看着满屋子各怀心事的脸，突然想起三年前第一次踩复盘的坑时，也是这么个让人头大的下午。
别把复盘开成“甩锅茶话会”
那时候我们刚上线迭代完一套客户管理系统，上线第三天就出了大问题——老客户的标签同步功能漏了，导致销售团队打了三百多个无效电话，客户投诉的消息刷了半屏的内部群。第一次开复盘会，大家从下午两点扯到四点半，技术说产品需求里没写老数据的映射规则，产品说测试用例里没覆盖历史数据校验，测试说开发没做对应单元测试，谁都没说错，谁都没担责，最后散会时的结论是“下次大家多注意”。
这有啥用啊？
散会的时候销售总监在走廊里跟我吐槽，说再这么开下去，下次上线他第一个跳出来拦着。说实话，那时候我脑壳都快炸了，俩小时的会，半句话有用的内容都没有，纯纯的情绪内耗。
哦对了，我那时候还傻呵呵的在会议室白板上写“对事不对人”，现在想想，那几个字写得跟领导训话似的，大家看着都紧张，能不互相甩锅吗？
复盘要抓“可控的细节”，别追着情绪跑
后来我干脆把之前的复盘规则全废了，定了个死规矩：所有发言必须先说“这件事如果重来，我会在哪一步做什么调整”，不准翻旧账式的追责，不准说“谁当初怎么怎么样”。
还是那个漏了标签同步功能的项目，重新拉会的时候，气氛完全不一样。技术负责人先说，当初需求评审看到文档里只写了新数据的同步逻辑，没敢问老数据的边界，怕显得自己对业务不熟悉；产品经理说，当初写需求的时候满脑子想着新功能的交互流畅度，忘了上次同类迭代踩过老数据的坑，没把校验项加进测试用例；测试说，拿到的用例里没列老数据校验，就默认这部分已经由开发做了覆盖，没主动提。
你看，这么一聊，根本没冲突，所有问题都落到具体的动作上了。我还记得那次会开到一半，我自己也主动说，当初项目赶进度的时候，我把原定的需求评审时间压缩了半小时，才导致规则没对齐，这个锅我背。
从那之后，我再也没在复盘会上见过甩锅的场面。有次跨部门合作出了纰漏，我在会上第一个说，当初变更通知发在部门群里，没单独@对方对接人，下次所有跨部门变更，必须发单独的消息，还要拿到对方的已读回执才算数。本来等着看笑话的几个主管，也开始主动说自己漏的环节，根本没人再揪着别人的错处不放。
那些复盘写的“改进项”，别只存在文档里
我之前还踩过一个更大的坑。每次复盘完，大家把改进项整理成漂亮的PDF，存在共享盘的文件夹里，下次做同类项目的时候，根本没人翻。比如上次办线下客户沙龙，复盘的时候明明白白写了“要提前三天确认到场人数”“要给嘉宾准备带全名的桌牌”，结果下个月办下一场的时候，还是忘了提前确认人数，现场多摆了二十个空座位，桌牌临开场十分钟才打印，还打错了两个嘉宾的名字。
那时候我才反应过来，之前的复盘根本没有闭环。写在文档里的改进项，没有责任人，没有截止时间，没有提醒机制，跟没写有什么区别？
后来我们把所有复盘的文档要求全改了。所有的改进项，必须拆成具体的、有明确责任人的动作，而且要贴在项目组的共享看板最上面，不是存在冷掉的文件夹里。比如“提前三天确认到场人数”，责任人是活动执行的小周，截止时间是活动前72小时，还要把这个动作加进所有线下活动的SOP清单里，下次做活动的时候，第一项就要打勾确认。甚至我们现在每次项目启动会的第一件事，不是喊目标，不是拍胸脯，而是先把上次同类项目的复盘改进项拿出来，一条一条过，看看这次有没有提前规避。
有次新入职的运营小姑娘问我，这么搞会不会太麻烦？我给她翻了去年的复盘记录，去年办六场客户沙龙，因为到场率不准、物料准备错的问题，多花了快两万块的冤枉钱，今年按这个流程走，到现在办了四场，这部分的支出直接砍了七成。她听完就不说话了，转头就把上次参与的活动复盘改进项，全部贴到了自己的待办清单里。
上周三的那个复盘会，按新规则走，一个半小时就把所有问题聊透了，最后定了四个改进项，其中一个还是我自己的问题——中期看到进度滞后，我催着大家赶工，把原定的规则对齐环节跳过去了。散会的时候天已经黑了，大家收拾电脑往外走，技术的小伙子还跟产品的小姑娘开玩笑，说下次你要是再漏写老数据规则，我就把你上次写的需求文档打印出来垫咖啡杯。
你看，这才是复盘该有的样子啊。不是要谁认错，不是要把谁骂一顿，就是大家坐在一起，把踩过的坑都标出来，下次走的时候，别再摔同一个跟头就行。
