如何从复盘中获得真正的收获?持续改进是关键!

2023-06-10 14:33:32 浏览数 (2)

复盘,本是围棋术语,每次博弈结束后,双方棋手把刚才的对局复演一遍,分析对局当中得失关键,提升自己棋力的好方法。复盘是对思维的训练。 通过复盘,当类似局面再次出现,你就能快速预测接下来的动态走向,更好应对。

项目复盘会则是 项目团队有意识从过去行为经验中,进行集体学习的过程。 一般在项目或里程碑完结后,由项目经理组织召集项目成员,一起回顾项目整个历程中,团队做对哪些事,做错哪些事,再来一次,如何做更好,沉淀该项目产生的集体智慧。

多做复盘肯定有好处,可现实项目是一个接一个做,忙上线,忙变更,忙返工,哪有时间复盘?我之前有个老板,倒是经常拉大家复盘,但会上就是骂,出问题就追责到底,自然各种甩锅。我也想开好复盘,可是,怎么才能让复盘不流于形式,真正做到集体学习?

如何做好项目复盘,如何通过复盘去培养团队的持续改进能力?

1 复盘会的基调设定

复盘会前,想清楚复盘的目的,设定好复盘基调,更重要

曾组织过复盘“坑爹功能”大搜罗。参与复盘十多TL,在现场写20多页纸,满满当当罗列曾经做的、却没人用的功能。实际上,只有当大家真正摊开不太愿意面对的真相,去认真思考背后的深层原因时,我们才能共同进入真正的集体反思区。这样坦诚地直面问题的复盘,才能促发有意识的集体学习。

想让参与者真正进入集体反思区,会前就要设定好开放的复盘基调。每个人都可以在自己所处的环境中,看到各种问题。若复盘是追责,那会议刚开始时,大家就能迅速感受到。这样每个人都会小心避开自己的问题,转而说别人的问题,复盘失去意义。

如何设定开放的基调

自己要先进入反思区。

在那次复盘会之前,我跟这个部门的负责人,就部门中反复出现的各种问题,进行过多次深度沟通。一开始,这位负责人觉得团队到处是问题。但当我们把问题层层剖析开来看,发现很多问题背后深层原因。

在会议刚开场,要展示出自己的开放与坦诚,给复盘会奠定基调:这次复盘不是来挑问题的,而是为了找到问题的根源并改进的。

那次复盘会,这负责人特意讲了自己这一年深刻反思,带动了大家敞开心扉直面问题。大家自发地找到了在各个环节有效避免无用功能的方法。会议结束后,部门还发起“整风运动”,从增强用户意识的讲座,到用户调研方法的培训,再到激励与考核制度的挂钩,让复盘会反思的成果,逐渐渗透到每个人的日常工作。

2 复盘会的会前准备

还需要充分的会前准备。

复盘会前,要梳理整个版本的历程,包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等,都是客观数据总结。还可提前收集这版本期间,团队满意度的问卷调查,为复盘会引入更多主观输入。

视频也是好的回顾材料。某次重要版本复盘会前,我熬夜加班,为团队准备段回顾视频。因为团队刚完成一件几乎不可能完成任务。客户需求急切,往常要做一个半月大版本,直接压缩到3w,团队辛苦。虽然视频制作手法粗糙,但那些加班到深夜开迭代演示会的照片,还是让现场很多人感动,瞬间为疲惫团队注入能量。

复盘会的基调设定及会前准备工作,在开会前,就很大程度决定复盘会的效果。

3 复盘会的简易流程

最高效的复盘流程:

  • 现场回顾总结项目/里程碑的整体概况,包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录
  • 与会人员便签纸写下项目过程中做好、做不好的3点,按项目各环节分类,分别贴在白板,确保大家意见充分、自由表达
  • 在白板前逐条review大家意见,共同发现问题,并针对性展开讨论
  • 对大家总结出的好、不好点,进行集体投票
  • 由项目经理整理投票结果,对做得好的环节,总结经验;做得不好的环节,当场讨论出改进方案

我们来看看一次真实的项目复盘会的投票结果:

做得好:

  • (10票) Bug Bash 活动成功开展,对产品质量控制有很大帮助,提升了团队合作意识及产品Ownership。
  • (7票)专职的 项目经理 角色让项目各项进度控制更加有序。
  • (6票) WBS 工作分解进一步明确范围及职责,为Schedule进度控制提供更加准确的基准依据。

有待改进:

  • (7票)后台开发与各端的沟通不畅,接口变更频繁,异地沟通成本高
  • (3票)缺少对开发质量的控制机制:缺少适当的Code Review;单元测试做得很不够
  • (2票)自动测试缺失:自动测试覆盖率不够

这项目是第一次引入项目经理。这次复盘会,项目经理的工作得到一致认可,包括Bug Bash引入、WBS工作分解、进度控制等措施,帮助团队快速从混乱到有序。再看待改进项,投票最多一项:后台研发与各端沟通瓶颈,这就是你在下版本一定要解决。

分析

发现是由于工期紧张,在后端接口没成熟时,前端、客户端须同时开发,如此快节奏迭代,后台接口频繁变动,牵一发动全身,让后端成项目瓶颈。为改善问题,成立专门Triage小组(判别小组),由各端主程组成,每天固定15min,参与者线上同时连线,对每端提出的接口变动需求,进行统一判断,并决策,确保接口变更信息第一时间同步。

无法促发行动的复盘,说再好都空谈!一开始开复盘会,大家会期待解决的问题越多越好,但焦点增多后,哪个都是蜻蜓点水,哪个都没改彻底。下次再开会,发现之前反馈问题依然在,谁还有动力继续提问?

改进措施要落地,重点行动别太多,一个就够! 若每次复盘聚焦改进项的Top 1,确保改进措施真正落地,长期坚持下去就会形成持续能力提升。

复盘次数不宜多,你不需每个版本、每个迭代都例行公事做一遍,确保每个季度有一到两次里程碑复盘,可完整地对项目做系统化的梳理,达到落地效果更重要

4 打造团队持续改进能力

其实,项目复盘不只是一次会议,它更应该成为团队持续改进的推动力。那么,怎样才能让一次成功的复盘发展成为复盘文化,激发团队自主地持续精进呢?

实际上,想要让团队进入自发改进的正向循环,你需要更好地激发团队的主人翁意识,让团队成为复盘的主角,而不是你。最重要的是,你不仅要关注事,还要关注人

我曾经为某部门组织过一次复盘会,取名叫作“研发代表大会”。当时,我们把部门中所有资深的程序员召集在一起,让他们给平台越来越严重的技术债问题出谋划策。这次复盘我采用了“批奏章”的玩法,各位代表把自己的意见写在纸上,然后围成一个圈,依次传递给左边的同学,每个人把手上的“奏章”批阅完成后,继续往左传。这样一圈转下来, 1数最多的那份“奏章”,就会被选出成为年度力荐。

最后,这份“奏章”得到了最多的关注和资源,这项建议迅速得到了改善。同时,这样的复盘方式,也让更多的研发同学享受到了“批奏章”的愉悦感,一旦他们发现,自己选出的“奏章”会得到采纳和落地,那么这个“研发代表大会”也就可以真正自行运转起来,更多人愿意主动参与进来,通过这个平台,发表自己的见解,为整体的持续改进贡献一份力量。

越困难时期,越是塑造团队能力大好机会。团队遇到重大困难时,你也能及时组织复盘会,深度关注调整个人状态。我曾试过让每个人画出自己进入项目组后的状态变化曲线,跟大家分享高光时刻、至暗时刻。业务低落期,这样的复盘会会成为重要转折点,让团队力量得到深度聚合。

这些对人的关注,都会让复盘会超越问题解决层面,推进事的同时,促使团队自发地推进问题的解决,并把经验内化下来,从而不断提升团队的持续精进能力。

5 复盘方法

帮助提升团队在复盘会中的参与感,进而达到有效复盘的目的:

  • 3点法:使用最多、最常见
  • 奏章法:“坑爹功能大搜罗”“研发代表大会”都这法,用来集结群智,每人发一张白纸,写上几条意见,然后依次传给左边的同学批阅,同意就 1,也可以在上面盖楼写评论
  • 状态图法:当团队士气遇到挫折时,凝聚士气的一个方法。每人发一张白纸,在上面画出自己进项目组以来的心情曲线,轮流公开呈现,并讲出自己的波峰和波谷事件及感受。具体操作起来,让Leader先讲,创造坦诚氛围,大家自然就踊跃

复盘方法可多样,便签、白纸等都是匿名方式,帮助大家卸下包袱。其实,不管你怎么玩,能让大家能够畅所欲言,才是关键。

听到这里,艾文恍然大悟,“这下我明白了,团队的参与感最重要。不过,如果团队自己通过复盘,找不到问题的要害或者解决方案,那又怎么办呢?”

复盘会是集体智慧的总结,产出肯定跟参与的群体直接相关,这里的解法,一个是引入可以直接提供有效意见的人员参与进来。另外,有些情况下,你需要有不同层面的复盘会,去解决不同层面的问题,比如执行团队复盘之后,反馈出整体规划层面的重要问题,那就应该召开负责人层面的复盘会,或推动更高层面讨论解决。

6 总结

当人们在说复盘时,往往会把焦点放在复盘会本身。但我认为决定复盘成功与否的关键,不在会议本身,而在于复盘会的一前、一后两环:

  • 复盘会前,复盘基调的设定是否开放,复盘会前的各项准备是否充分,对于复盘会的效果非常关键。组织一个复盘会本身并不难
  • 难的是在复盘会后,持续跟进这些反思,落地为切实的改进措施,让团队真正看到效果,从而打开团队持续改进的正向循环

做好一次复盘,每次复盘后聚焦一个改进点。聚焦点别太多,一个就够!

FAQ

你经历过的印象最深刻的一次复盘,打动你的是什么?回顾一下你经历过的那些项目,若可再来一次,你最想要做好的是啥?

0 人点赞