上周三的复盘会，我刚推开门就看见产品经理攥着笔记本攥得指节发白——上次上线的满减活动出了bug，叠加优惠券后实付比0元还低，所有人都怕被点名。
太糟了。
之前我也以为复盘就是把项目从启动到结束的时间线捋一遍，把出问题的人揪出来骂两句，再写个一万字的改进方案存进共享盘吃灰，直到前年那次做客户系统升级的项目砸了，我才真的搞明白，之前做的根本不是复盘，是走流程。
第一个坑：把复盘开成”找责任人大会”
那次升级项目，我们本来拍胸脯跟客户保证，上线后投诉量能降30%，结果上线当天崩了三次，投诉量直接涨了两倍。第一次复盘会开得像菜市场，开发说产品需求改了八遍没给最终版，产品说运营临时要加功能没走审批，运营说销售拍胸脯说这个大客户的需求必须满足。我当时火上来了，拍着桌子说谁的问题谁担，结果散会之后整个团队三天没人跟我说话，有个做后端的小伙子甚至偷偷投了简历，我是从HR那听说的。
后来我才反应过来，我要的是解决问题，不是把人骂跑。我重新约了所有人，进门先把之前打印的责任认定表撕了，跟所有人说，今天谁都不许说”谁谁谁错了”，只说”当时我们遇到了什么情况，手里有什么选项，最后选了哪条路”。
那天会开了两个小时，我才知道藏在下面的真相：那个改了八遍需求的产品，每次提的需求评审都被我打回来，说要”更有亮点”，她不敢定最终版就是怕我又改；那个偷偷加功能的运营，是销售总监直接找的他，说这个大客户要是拿不下来，整个季度的团队奖都没了。说来说去，根因在我自己。
第二个坑：复盘的结论全是”正确的废话”
之前我们复盘完，写的报告永远是那套：加强跨部门沟通、提高需求评审效率、做好风险预案。这些话谁都懂，但是下次该犯还是犯。
我印象特别深，有次复盘会结束，我把”加强跨部门沟通”这七个字写在白板上，过了一周开需求会，开发还是不知道运营要给新用户发多少优惠券，跟之前没写的时候一模一样。
后来我改了规则，所有的复盘结论必须落到”谁，在什么时间，做什么事，做到什么标准”。比如之前的”加强跨部门沟通”，直接改成：以后所有需要跨部门确认的需求，必须在需求文档的最后一页附三个对接人的签字截图，没有签字的需求，开发有权直接拒接。
第一次用这个规则的时候，有个运营拿了个没有签字的需求来找开发，开发直接把文档弹回去了，运营当时还气冲冲来找我告状，结果过了两周他自己拎着奶茶来谢我——那个需求的客户后来改了三次，要是当时接了，他得跟着开发白忙一周。
真的，那些飘在天上的改进建议，不如一句能直接落地的破规则有用。
别整虚的。
别等项目全黄了才想起复盘
我之前还有个误区，觉得复盘是项目结束了才要做的事，中途复盘就是给团队添乱，打击士气。
前年做那个中型客户的定制项目，做了一半发现进度慢了20%，所有人都憋着不说，怕说了我发火，也怕影响大家的信心，等到最后上线的时候，已经比预期晚了一个半月，客户那边的对接人说话都带刺了，说我们公司的效率还不如他们小作坊。
从那之后我改了习惯，每个项目每两周做一次15分钟的小复盘，不用写长篇报告，每个人就说三句话：现在的进度跟预期比差多少？差的原因是什么？接下来两周要调整什么。
上次做内部OA系统升级的项目，第二周复盘的时候，开发说之前预估的第三方接口开发时间少算了一半，因为对方给的接口文档漏了三个核心字段。我们当天就拉了对接会，把非核心的功能往后挪，最后上线的时候一点没晚，客户那边还夸我们效率高。
我之前总觉得，中途说问题是唱衰，后来才发现，你藏着掖着的问题，只会像滚雪球一样越滚越大，到最后根本兜不住。
早发现，早省事。
现在我开复盘会，进门第一句话永远是：”今天我们不说谁错了，只说下次怎么能更顺。”桌上永远放着一盒砂糖橘，谁发言之前先剥一瓣吃，紧张感能消大半。
上次那个攥着笔记本指节发白的产品经理，上个月做618活动复盘的时候第一个发言，说上次做活动她没提前跟技术确认优惠券的叠加规则，差点出大问题，现在她每次做需求之前，都会先拉技术开个10分钟的小会，把所有可能出问题的点列成清单打勾。
其实哪有那么多完美的项目啊。复盘的意义，不就是让下次踩坑的时候，能少摔两个跟头吗。
