营出凝聚力
赢得团队心

项目复盘不是写年终总结:那些没人敢说的实操真相

上周三在楼下咖啡馆碰到之前带过的小周,他刚从互联网公司离职,吐槽说上周的项目复盘会开了三个小时,最后领导拍板说“下次注意”,就散了。

我听完差点把冰美式喷出来。

这场景我太熟了。我刚做管理的前三年,开过的复盘会没有一百也有八十,踩过的坑能堆半人高。直到现在我都觉得,大部分公司的复盘,都是在走形式——要么是批斗会,要么是功劳簿,要么是开完就忘的废纸。

第一坑:把复盘开成“追债大会”

四年前我带第一个SaaS定制项目,上线前三天突然出了数据同步bug,一半客户的后台订单都串了。当时急得我连夜在公司打地铺,好不容易熬到bug修好,上线成功,转头就开复盘会。

我那时候不懂啊,刚当负责人,就觉得复盘就是要找出来谁的错。开场第一句就问:“这个bug到底是谁的责任?”

整个会议室冷了十分钟。窗外的梧桐叶被风吹得沙沙响,我坐在主位上,连手里的笔都握出了汗。

开发低着头说测试没测全边界用例,测试红着眼说产品上周改了三次字段名,根本来不及补用例,产品摊手说销售昨天才传了客户的新要求,他也是临时改的。

企业项目复盘会冷场现场实拍图
企业项目复盘会冷场现场实拍图

我那时候才反应过来,我犯了最蠢的错——把复盘的前提搞反了。

复盘的第一原则是对事不对人,甚至要先把“责任”两个字从会议室白板上擦掉。

后来我直接叫停了甩锅的环节,拿了一张大白纸,拉了整个事件的时间线:3月12号销售微信给产品说客户要加“订单备注”字段,3月13号产品直接改了数据库字段,没同步给开发和测试,3月15号开发写同步逻辑的时候,还是用的旧字段名,3月18号测试上线前测的时候,没覆盖到这个新字段的同步场景。

你看,根本不是某个人的错。是我们的跨部门同步机制烂透了——私下微信传需求,没有留痕,没有同步,没有checklist。

后来我们当场定了规矩:所有跨部门的需求改动,必须走在线文档的评论@,涉及到数据库字段的,必须拉开发和测试进评论,没有同步的改动,一律不算数。之后三个月,我们没出过同类的同步bug。

第二坑:复盘只记“做对的事”,像在写功劳簿

很多人觉得,失败的项目才要复盘,成功的项目复盘就是大家凑在一起吹牛逼。我之前也这么想,直到去年我们做了一个制造业的解决方案项目,续约率超了目标20%,拿了公司的季度大奖。

当时开复盘会,大家轮流发言,销售说自己怎么陪客户喝了三次酒搞定了决策人,产品说自己怎么熬了两个大夜改了生产报表的功能,实施说自己怎么蹲在客户机房里调了三天的网络。

我听了二十分钟,直接打断:“停。今天不说你们做对了什么,先说说这个项目里,有哪件事是你们现在想起来还冒冷汗的?”

会议室又静了。过了半分钟,实施开口说:“上线前一周,客户的IT总监突然换了,新的总监要求我们把所有的权限体系全部重做,不然就不让上线。我们当时离 deadline 只剩七天,根本做不完。最后是找了客户那边的生产部经理帮忙说情,新总监才同意宽限了两天。”

销售也补充:“当时我们的报价比竞品低了15%,本来已经要输了,结果竞品的系统上线第一天就崩了,客户才转头选了我们。”

项目复盘白板上的时间线梳理实拍图
项目复盘白板上的时间线梳理实拍图

我当时就冒了冷汗。之前我们总觉得这个项目成了,是因为我们能力强,结果仔细扒开看,大半都是运气。

成功项目的复盘,比失败项目的复盘更重要,因为成功的运气,最容易被当成实力。

后来我们改了复盘的规则,成功项目的复盘,必须先列三个“不可复制的运气成分”,再列三个“下次还能用上的可复制动作”。刚才那个项目的运气是:竞品出事故、新总监通融、老员工帮忙。可复制的动作是:我们提前给客户的所有对接人都做了关系维护,不是只盯着最高决策人;还有我们的权限体系是模块化的,重做的速度比竞品快三倍。

后来这个模块化权限的思路,我们用到了另外三个制造业的项目里,每个项目都省了至少两周的开发时间。

第三坑:复盘的结论,转头就忘

我之前犯过最蠢的错,就是复盘会开完,记了满满十几页的笔记,存在共享盘的某个文件夹里,除了当时参会的三个人,没人看过。

有一次做新的零售项目,我们直接全量上线,没做灰度测试,结果上午十点上线,中午就出了支付bug,影响了两千多个订单。我当时气得要死,翻共享盘的旧笔记,才发现半年前的一个复盘会里,明明写了“所有上线必须先做10%的灰度,跑24小时再全量”。

但是没人记得。

你说复盘做了有什么用?

复盘的价值,从来不是写了多少笔记,而是下次做同样的事的时候,能不能直接用上。

后来我们把复盘的流程全部改了。每次复盘的结论,最多写三条,每条都要有具体的动作、责任人、落地时间——绝对不允许写“要加强沟通”“要重视测试”这种空话。比如之前的灰度测试的事,我们就写成:“由测试负责人在上线checklist里新增‘10%灰度跑24小时’的项,本周五之前更新完,所有项目上线前必须核对checklist。”

所有复盘的结论,我们都贴在团队门口的公共看板上,每个新项目启动的时候,负责人必须先把之前所有同类型项目的复盘结论看一遍,签字确认。

从那之后,我们再也没出过“明明之前踩过坑,又踩一遍”的蠢事。

上周小周给我发微信,说他们公司这周开了新的复盘会,他照着我给的方法,开场先把白板上的“责任”两个字擦了,拉了整个事件的时间线,最后列了三条可落地的动作,领导说这次复盘终于没白开。

我回了个偷笑的表情。

其实哪有什么高大上的复盘方法论啊。说白了就是别把它当任务,别把人当对立面,别把结论当废纸。就够了。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。如有侵权请联系删除。
文章名称:项目复盘不是写年终总结:那些没人敢说的实操真相
文章链接:https://www.tuanjian1.com/changdi/1055.html