08 收尾：持续改进，从真正有效的复盘开始
你好，我是雷蓓蓓。今天我们来聊一聊复盘。
复盘原本是围棋术语，是指每次博弈结束之后，双方棋手把刚才的对局复演一遍，分析对局当中得失的关键，是提升自己棋力的好方法。其实，复盘是对思维的训练。通过复盘，当类似的局面再次出现在你面前的时候，你就能够快速地预测接下来的动态和走向，并且更好地应对。
而项目复盘会，可以说是项目团队有意识地从过去的行为经验中，进行集体学习的过程。一般是在项目或里程碑完结之后，由项目经理组织召集项目成员，一起回顾一下，在项目的整个历程中，团队做对了哪些事，做错了哪些事，再来一次，如何做得更好，借此把项目行进中产生的集体智慧沉淀下来。
艾文听到这里，忍不住举手打断，“老师，多做复盘肯定有好处，可现实情况，项目是一个接一个地做，忙上线，忙变更，忙返工，哪有时间坐下来复盘？我之前有个老板，倒是经常拉大家复盘，但会上就是一顿骂，出问题就要追责到底，大家自然是各种甩锅。我也想开好复盘，可是，怎么才能让复盘不流于形式，真正起到集体学习的作用呢？”
其实，要想做好项目复盘，并不是一件容易的事情。今天，我就带你来看一看，如何做好项目复盘，以及如何通过复盘去培养团队的持续改进能力。
复盘会的基调设定
我们都知道复盘很重要，但实际上，在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，更为重要。
我曾组织过一个复盘，叫作“坑爹功能”大搜罗。参与复盘的十多位团队Leader，在现场写了20多页纸，满满当当地罗列着我们曾经做的、却没什么人用的功能。实际上，只有当大家真正摊开不太愿意面对的真相，去认真思考背后的深层原因时，我们才能共同进入真正的集体反思区。这样坦诚地直面问题的复盘，才能促发有意识的集体学习。
要想让参与者真正进入集体反思区，会前就要设定好开放的复盘基调。其实，我们每个人都可以在自己所处的环境中，看到各种各样的问题。如果复盘是出于追责，那么在会议刚开始时，大家就可以迅速地感受到。这样一来，每个人都会小心地避开自己的问题，转而去说别人的问题，这样的复盘就失去了意义。那么，如何设定开放的基调呢？
首先，你自己要先进入反思区。其实，在那次复盘会之前，我跟这个部门的负责人，就部门中反复出现的各种问题，进行过多次深度沟通。一开始，这位负责人觉得团队里到处都是问题。但当我们把问题一层层地剖析开来看时，我们发现了很多问题背后的深层原因。
除此之外，在会议刚开场，就要展示出自己的开放与坦诚，给复盘会奠定基调：这次复盘不是来挑问题的，而是为了找到问题的根源并改进的。
在那次复盘会上，这位负责人特意讲了自己这一年来自己的深刻反思，这就带动大家敞开心扉，直面问题。那次会上，大家自发地找到了在各个环节有效避免无用功能的方法。会议结束以后，这个部门还发起了一项“整风运动”，从增强用户意识的讲座，到用户调研方法的培训，再到激励与考核制度的挂钩，让复盘会反思的成果，逐渐渗透到了每个人的日常工作中。
复盘会的会前准备
除了设定基调，你还需要充分的会前准备。在复盘会之前，你要去梳理整个版本的历程，包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等，这些是客观数据的总结。同时，你还可以提前收集这个版本期间，团队满意度的问卷调查，为复盘会引入更多主观的输入。
除此之外，视频也是非常好的回顾材料。曾经，在某次重要版本的复盘会前，我熬夜加班，为团队准备了一段回顾视频。因为这个团队刚刚完成了一件几乎不可能完成的任务。客户的需求非常急切，往常要做一个半月的大版本，直接压缩到了三周，团队非常辛苦。虽然视频的制作手法很粗糙，但那些加班到深夜开迭代演示会的照片，还是让现场的很多人感动不已，瞬间为这个疲惫的团队注入了能量。
其实，复盘会的基调设定，以及会前的准备工作，在开会之前，就很大程度地决定了复盘会的效果，你一定要特别留意。
了解了这些之后，我们就来看看复盘会的流程。
复盘会的简易流程
复盘会的流程，其实并不复杂。在实战中，我总结出了一套最为高效的复盘流程。
- 现场回顾总结项目/里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录。
- 与会人员用便签纸写下项目过程中做得好的以及做得不好的3个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。
- 在白板前逐条review大家的意见，共同发现问题，并有针对性地展开讨论。
- 对大家总结出的好和不好的点，进行集体投票。
- 由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案。
我们来看看一次真实的项目复盘会的投票结果：
做得好：
- （10票）Bug Bash活动的成功开展，对产品质量控制有很大帮助，提升了团队合作意识及产品Ownership。
- （7票）专职的项目经理角色让项目各项进度控制更加有序。
- （6票）WBS工作分解进一步明确范围及职责，为Schedule进度控制提供更加准确的基准依据。
有待改进：
- （7票）后台开发与各端的沟通不畅，接口变更频繁，异地沟通成本高。
- （3票）缺少对开发质量的控制机制：缺少适当的Code Review；单元测试做得很不够。
- （2票）自动测试缺失：自动测试覆盖率不够。
这个项目是第一次引入项目经理。在这次复盘会上，项目经理的工作得到了一致的认可，包括Bug Bash的引入、WBS工作分解、进度控制等措施，帮助团队快速地从混乱到有序。再来看看待改进项，投票最多的一项是，后台研发与各端的沟通瓶颈，那么这就是你在下个版本一定要去解决的问题。
经过分析之后，我们发现，由于工期紧张，在后端接口没有成熟的情况下，前端、客户端必须同时开发，如此快节奏迭代之下，后台接口的频繁变动，牵一发而动全身，这让后台技术成了整个项目的瓶颈。为了改善这个问题，我们成立了专门的Triage小组（判别小组），由各端的主程组成，每天固定15分钟时间，参与者线上同时连线，对每个端提出的接口变动需求，进行统一判断，并作出决策，确保接口变更信息第一时间的同步。
无法促发行动的复盘，说得再好都是空谈！一开始开复盘会，大家会期待，解决的问题越多越好，但焦点增多之后，哪个都是蜻蜓点水地过一遍，哪个都没改彻底。下次再开会的时候，大家发现之前反馈的问题依然还在，那谁还有动力继续提问题呢？
所以，改进措施一定要落地，重点行动不要太多，一个就够了！如果每次复盘聚焦于改进项中的Top 1，确保改进措施真正落地，长期坚持下去就会形成持续的能力提升。同时，复盘的次数也不宜太多，你并不需要每个版本、每个迭代都例行公事地去做一遍，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的。
打造团队持续改进能力
其实，项目复盘不只是一次会议，它更应该成为团队持续改进的推动力。那么，怎样才能让一次成功的复盘发展成为复盘文化，激发团队自主地持续精进呢？
实际上，想要让团队进入自发改进的正向循环，你需要更好地激发团队的主人翁意识，让团队成为复盘的主角，而不是你。最重要的是，你不仅要关注事，还要关注人。
我曾经为某部门组织过一次复盘会，取名叫作“研发代表大会”。当时，我们把部门中所有资深的程序员召集在一起，让他们给平台越来越严重的技术债问题出谋划策。这次复盘我采用了“批奏章”的玩法，各位代表把自己的意见写在纸上，然后围成一个圈，依次传递给左边的同学，每个人把手上的“奏章”批阅完成后，继续往左传。这样一圈转下来，+1数最多的那份“奏章”，就会被选出成为年度力荐。
最后，这份“奏章”得到了最多的关注和资源，这项建议迅速得到了改善。同时，这样的复盘方式，也让更多的研发同学享受到了“批奏章”的愉悦感，一旦他们发现，自己选出的“奏章”会得到采纳和落地，那么这个“研发代表大会”也就可以真正自行运转起来，更多人愿意主动参与进来，通过这个平台，发表自己的见解，为整体的持续改进贡献一份力量。
另外，越是困难时期，越是塑造团队能力的大好机会。在团队遇到重大困难时，你也可以及时组织一场复盘会，深度关注和调整个人的状态。我就曾经试过让每个人画出自己进入这个项目组以后的状态变化曲线，跟大家分享自己的高光时刻和至暗时刻。在业务低落期，这样的复盘会会成为一个重要转折点，让团队的力量得到深度聚合。
这些对人的关注，都会让复盘会超越问题解决的层面，在推进事的同时，促使团队自发地推进问题的解决，并把经验内化下来，从而不断提升团队的持续精进能力。
复盘方法
最后，我还想跟你分享一些专栏中提到的复盘的小方法，来帮助提升团队在复盘会中的参与感，进而达到有效复盘的目的。
- 3点法：使用最多也是最常见的一种复盘方式，文中已经有详细流程步骤。
- 奏章法：文中提到的“坑爹功能大搜罗”“研发代表大会”都是用的这个方法，可以用来集结群智，每人发一张白纸，写上几条意见，然后依次传给左边的同学批阅，同意就+1，也可以在上面盖楼写评论。
- 状态图法：当团队士气遇到挫折时，凝聚士气的一个方法。每人发一张白纸，在上面画出自己进项目组以来的心情曲线，轮流公开呈现，并讲出自己的波峰和波谷事件及感受。具体操作起来，让Leader先讲，创造坦诚氛围，大家自然就踊跃了。
复盘的方法可以多种多样，便签、白纸等都是在用匿名的方式，帮助大家卸下包袱。其实，不管你怎么玩，能让大家能够畅所欲言，这才是关键。
听到这里，艾文恍然大悟，“这下我明白了，团队的参与感最重要。不过，如果团队自己通过复盘，找不到问题的要害或者解决方案，那又怎么办呢？”
复盘会是集体智慧的总结，产出肯定跟参与的群体直接相关，这里的解法，一个是引入可以直接提供有效意见的人员参与进来。另外，有些情况下，你需要有不同层面的复盘会，去解决不同层面的问题，比如执行团队复盘之后，反馈出整体规划层面的重要问题，那就应该召开负责人层面的复盘会，或推动更高层面讨论解决。
总结
好了，让我们对复盘做个小结。其实，当人们在说复盘时，往往会把焦点放在复盘会本身。但我却认为，决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节。
复盘会前，复盘基调的设定是否开放，复盘会前的各项准备是否充分，对于复盘会的效果非常关键。组织一个复盘会本身并不难，难的是在复盘会后，持续跟进这些反思，落地为切实的改进措施，让团队真正看到效果，从而打开团队持续改进的正向循环。
最后，我建议你认真地做好一次复盘，每次复盘后聚焦一个改进点。再提醒你一句：聚焦点别太多，一个就够了！
畅所欲言
我想请你来聊一聊，你经历过的印象最深刻的一次复盘，打动你的是什么？回顾一下你经历过的那些项目，如果可以再来一次，你最想要做好的是什么？
欢迎你畅所欲言，我在留言区等你，也欢迎你把文章分享给你的朋友。
- X.J👸 👍（28） 💬（4）
万一项目经理成了复盘会的吐槽对象，那是有多尴尬😅
2019-12-20 - maks 👍（13） 💬（1）
蓓格格,你好。感谢你的回复，对我很有帮助。人很多时候就是一叶障目。 至此对应五大过程组的最佳实践已经介绍完毕，我也整理成我自己的思维导图，感谢你的分享。 虽然因为我的能力有限很多细节都没能理解透彻，但是依然不妨碍我“好听课，不求甚解”的心思，所以每一遍我都会在上班途中，下班途中。繁复多遍的聆听，每一次都会有所收获. 在IT中有一句话，没有绝对的“银弹”，但是你的最佳实践给我们很多启发。 而且我发现你每次在发布栏目的时候总是在深夜凌晨，我想每一讲的内容与讲述都是来之不易的。 现在我已经把你的专栏推荐给我的同事，她们刚好想要考PMP，走项目管理一道。 所以每次在听完你的最佳实践后，一起讨论一下其中细节也是一件怡然自得的事情。 最后，再次感谢你的最佳实践，感谢你的分享。
2019-11-16 - zw_learn_2 👍（6） 💬（4）
老师你好，我们研发团队采用的是敏捷Scrum研发，主要环节包括每日站会、计划会议、评审会议以及回顾会议。我们的回顾会议跟老师讲的复盘会议流程很相似。我们是每两周举行一次，每次大约为1小时，研发团队人数为9人。 我的现状是每次举行这种复盘会议的时候，大家情绪不高、参与度低、经常提一些不痛不痒的问题，最后形成的改进项基本上都是3条，真正能落实改进的项就寥寥无几了，大家都是为了复盘而复盘，更谈不上团队和个人能力的持续提升了。 请问老师，针对以上现状，该如何破？谢谢
2019-11-14 - PM它不好转啊 👍（5） 💬（2）
我突然想到一个好玩的。在复盘会上大家其实都知道复盘的目的是什么，大家也大概都了解自己在这次项目/版本的问题 或者说认为别人的问题是什么，但是由于自己的面子或者为了别人的面子不太好说出口，因为说出来了可能会害怕被背地里骂，导致后续合作出现裂痕。那我们在复盘会上一人发个面具会不会让大家更有自信一些，虽然大家都知道彼此是谁，但是面具会让大家心里有个隐形的支柱，戴上面具大家是互相的监督者，摘下面具大家就是共同进步提高自己的执行者
2020-11-04 - 陈怀哲 👍（4） 💬（1）
我目前所负责的一个项目，是负责开发我们公司内部内部的研发管理系统、订单和客户管理系统以及工厂生产及品质管理系统。我每个月初会开一次当月的重点研发计划会，梳理一下上个月任务的完成情况、没有完成的原因、哪些需求变更了、以及总结一下开发过程中的技术难点并指派人抽时间组织技术分享；然后粗略过一下过当月的研发重点，安排后面2周的开发任务，然后是大家提意见及讨论。 一般到月中的时候，会发布一个小版本，发布完成之后，会对当前阶段做一个小的总结，安排后面两周的任务。因为项目组的研发人员同时兼顾着其他项目，有时公司项目优先级有变动，一般研发方向、资源和重点有改变，也会在这个计划会上提出来。 我每周一向项目发起人，也就是我们的CEO汇报一次上周完成了哪些内容，本周预计会完成哪些内容，同时也会和他讨论一些需求和方向相关的事宜。 我定期还会组织一些公司内部的关于管理系统使用相关的培训。 听了老师的课，我觉得我一直没有做过比较好的复盘。我们的功能一直是慢慢推进的，所以感知不明显。但其实现在想想，这一年也做了很多东西，是时候做一个复盘了。
2019-11-16 - 穷查理 👍（4） 💬（5）
第一次在音频中听到蓓蓓老师的笑声，很开心~ 我印象最深的一次“复盘”，是我做项目管理之后负责的第二个项目。项目第一次提测结束后，测试部门反馈了很多的问题，当时看到问题之后也有点不知所措。 但是又不想像以前那样“问题来了，各自拿回去修改，改完后，继续提交测试，一次、两次、三次...” 记得当时突发奇想，把项目组所有成员全部召集起来，针对这次测试结果做一次分析、总结： 1、把报告中的问题一个一个的讨论，确定哪些问题要修改，哪些问题不用修改； 2、要修改的问题，统一修改方案和最终要达成的效果； 3、问题修改完成后，项目组成员交叉验证修改结果是否达标； 之所以印象最深，是因为项目第二次测试居然通过了，要知道在之前，没有三四次，根本不可能的事。 也是从那时起，我开始思考、尝试、总结工作中的方法（我们项目组小伙伴好可怜啊，都成了小白鼠）。 现在，我常常把自己当初趟出来的“捷径”，用来“忽悠”我的几个项目负责人。但是自己趟的毕竟是“野路子”，用来培养项目负责人感觉很心虚啊，当然也促使自己学习。
2019-11-14 - 牺牲 👍（3） 💬（1）
今天开会运用了“复盘会的简易流程”中的便签法。 为了提高大家的发言率和意见独立性，将会议内容拆分成小问题和小主题，让参会人在便签上写下自己的想法。收集并贴在白板上，根据大家的想法丰富分享会流程。气氛比之前有问无答活跃多了，大家也比较喜欢这种新方式。 蓓蓓课程中的各个实战经验都非常有用，用起来就会变成自己的。
2020-04-23 - 酷飞不会飞 👍（2） 💬（1）
之前的项目也做过多次的复盘，在一个合作默契的团队里，大家对项目复盘的问题基本也是了熟于心，对于各种问题也基本能够避免大部分。 后来，大家分开到其他团队，发现每次复盘，大家热情也很高涨，也基本总结了大部分问题，但是到下一个项目里依旧会出现这些问题，多几次以后发现，每个人关注的问题优先度不一致，而团队也未规定必须处理那些问题，这就导致了，每次每个问题出现在不同的身上，这也基本符合了老师说复盘要有重点，而且不宜过多。 朝着同一个方向努力改进，效果要远远超过同时改进所有问题。 再说复盘，每次复盘的效果永远会在下一个项目或者迭代时提现出来，复盘带给我们的不仅仅是问题的解决，还有经验的沉淀，思路的碰撞。 多谢老师的文章，看到复盘更多的实施方式和方法，也看到复盘的重要性与重点。
2019-11-14 - 桃子-夏勇杰 👍（2） 💬（2）
改进分两种，一种是软件研发团队类似的，一种是对于每个团队特有的，对于各个团队类似的这个部分，蓓蓓老师可以分享一下么？有哪些优先级和回报比较高的改进？团队自己通过复盘找不到问题的要害或者解决方案怎么办？
2019-11-14 - 胖虫子 👍（1） 💬（1）
以前我们的复盘就是每个小组给其他小组打分，最后呢，大家都打4分，你别打低我，我也不打低你，最后这个就没意义了
2021-03-05 - panqing 👍（1） 💬（1）
我所在的研发小组也是scrum, retrospective 两周一次。开始总是scrum Master 和lead Dev说这不好，那不好，说领导不好，阻拦信息，说后端不好沟通，说产品经理拿不了主意，说了一堆，每次都一样。这些问题组内没办法，讨论了也没人去解决。
2019-11-29 - Cy23 👍（1） 💬（1）
复盘是为了发现问题，解决问题，而不是推卸责任，解决问题不要一次贪多，挑出最主要的一个确实解决掉，不再发生，复盘的目的就达到了，不知道我理解对了吗？
2019-11-14 - AllenGFLiu 👍（1） 💬（2）
原来项目管理还有这么多小魔术，如此有趣，在原本平淡无奇的项目开发中还能带来一点乐趣。
2019-11-14 - 亢（知行合一的路上） 👍（0） 💬（1）
复盘是个提高团队战斗力的好工具，用好了意义很大。 复盘不是目的，而是复盘的结果对后续的行为产生了积极的影响。我们每天的总结也是这样，如果只是记录流水账，而没有反思今天哪些地方做得好，哪些没做好，为什么没做好，如何才能做好。好的经验要持续发扬，不好的地方要找到解决办法，这样每天反思都在进步。复盘的频率不能太高，主要是涉及的人很多，改进措施的落实也需要时间，所有人接受并拥护需要一个过程。 重点行动一个就够了！每次只抓主要矛盾，集中精力办大事，要允许存在一些问题，团队是在不断进化，只有更好！
2020-02-14 - 秦滈 👍（0） 💬（2）
我完成了一个项目，又做砸了一个项目。三个人的团队，我居然是项目经理。项目经理是跟项目算的。那种三个人的开发部，有两个项目经理的感觉很扯。可以负责也可以不负责。结果项目做砸了，我被迫离职。加了一个月的班。还是感触很多。正在反思和复盘呢。这是我第二次做项目经理。现在是学习课程最好的时候了。
2019-12-21