上周四下午的复盘会，我刚推门进去，就看见产品经理把半页A4纸往桌上一拍，说“这次延期全是测试那边漏了用例”。
我当时没接话。
拉了把椅子坐下来，盯着墙上的项目进度表看了三分钟——那表上红笔圈的延期节点，从去年Q3到现在，已经换了四茬负责人，每次复盘都是这套说辞。
别一上来就问“谁的责任”
我刚带团队那会，最爱的就是在复盘会上追根究底。
错了就要罚，责任要到人，这不是天经地义的事？
直到那次ToB客户定制项目上线前一周，系统直接在客户的测试环境崩了。第一次复盘开得像批斗会，所有人都盯着负责后端的开发，说他代码写得糙，连基本的异常处理都没做。那个小伙子闷着头坐了半小时，最后把聊天记录甩在桌上——是销售在签合同的时候，偷偷答应了客户要加3个定制字段，根本没同步给技术团队，连需求文档里都没提。
我当时脸都热了。
没人喜欢被审判。当你在会议室上来就问“这次项目延期到底是谁的问题”的时候，你其实已经把大部分想要说真话的同事，推到了你的对立面——他们第一反应不是怎么解决问题，而是怎么把自己的责任摘干净，不要被当成那个出头鸟。
后来那个运营岗的小姑娘跟我说，之前有次活动上线，她明知道规则里的满减门槛算错了，但是怕被说“多管闲事”，硬生生憋着没在会上提，最后活动当天超了20万的预算。复盘的时候她憋了半小时才红着眼眶说出来，我当时心里堵得慌。
从那之后我改了规矩：复盘会上，先把人和事拆开来谈。所有的问题，先找流程上的漏洞，不先揪着某个人的错处不放。你是流程没卡好，还是沟通没同步，还是能力没匹配，这些都可以摊开说，但绝对不是上来就扣帽子。
就像上次那个拍桌子说测试漏用例的产品经理，我们顺着时间线倒，把所有的文档版本、聊天记录按顺序贴在白板上——是他自己在需求评审结束后，临时加了个数据导出功能，没给测试同步，测试的用例里根本没覆盖这个模块。我没当场拆穿他，就站在旁边看着，他自己盯着白板看了两分钟，主动说“是我当时没把变更同步到位”。
整个过程没人指责他，但是所有人都知道问题出在哪了。
别拿“正确的废话”凑复盘报告
之前我们抄过互联网大厂的复盘模板，什么目标达成率、偏差原因分析、经验沉淀，一套流程走下来，每次写的复盘报告都厚得像本小册子。
有啥用？
上次618大促的复盘，我们写了整整10页的报告，里面的经验总结全是“要加强跨部门沟通”“要提前做好风险预判”“要提高团队响应效率”。这些话错吗？半毛钱错没有，但是半毛钱用没有。
第二年618，运营和设计还是因为物料改了8版吵到老板办公室，技术还是因为临时加的需求排不上期，最后延期了3天上线。
我后来把那个模板直接扔了。
现在我们团队的复盘，所有写下来的结论，必须落到“下次遇到同样的场景，谁、在什么时间点、做什么动作”，但凡说虚话的，直接打回去重写。
比如之前说“要加强跨部门需求沟通”，我们改的落地规则是：所有涉及客户的需求变更，必须由销售在24小时内同步到项目专属群，且在需求文档里标注变更原因、影响范围，由项目负责人签字确认之后，技术团队才能启动排期。
就这么一条简单的规则，之前那种销售偷偷给客户承诺需求的事，之后再也没出现过。
说出来不怕你们笑，我之前有次复盘会开了整整三个小时，从下午两点开到五点，散会的时候大家都累得不想说话，最后总结的三条改进措施，我到现在都记不住是什么。后来我干脆把复盘会的时间砍到最多一个半小时，超过时间直接散会，剩下的问题大家线下拉小群沟通，效率反而高了好多。
复盘的结论，别让它躺在共享文档里吃灰
很多团队的复盘，开完全文往知识库一丢，就再也没人翻了。
我之前整理过团队的共享文件夹，里面存了快20份项目复盘文档，上次新来的开发问之前那个支付接口踩过什么坑，翻了半小时才在一个三级加密文件夹里找到，文档上的截图都快糊成马赛克了。
这哪是复盘，这是给团队添堵。
后来我们改了个很笨的办法：每次复盘完，所有要落地的动作，都写在便签上，贴在项目组门口的白板上。每周一开15分钟的站会，就盯着这张白板过——哪个动作已经落地了，哪个还在推进，哪个遇到了阻碍需要协调。
比如之前定的需求变更签字流程，我们直接把整个流程的步骤做成A4大小的海报，贴在会议室的门后面，每次开会抬头就能看见。三个月下来，大家根本不用刻意记，遇到客户提需求，第一反应就是走流程，不用等我追在后面问。
上周那个拍桌子的产品经理，后来在复盘会上主动提，下次做需求评审的时候，要专门留10分钟给测试团队过一遍可能的遗漏点。
你看，其实大家都不是故意要甩锅，只是之前的复盘方式，把所有人都逼成了要自保的状态。
哪有什么天生会做项目的团队。
不过是每次踩了坑，别着急骂，别着急甩，真的把问题解决了，下次就不会再摔同一个跟头。
