收尾：项⽬复盘，⼩团队也要持续改进
复盘原本是围棋术语 ，是指每次博弈结束之后 ，双⽅棋⼿把刚才的对局复演⼀遍 ，分析对局当中得失的关
键 ，是提升⾃⼰棋⼒的好⽅法。其实 ，复盘是对思维的训练。 通过复盘 ，当类似的局⾯再次出现在你⾯前的 时候 ，你就能够快速地预测接下来的动态和⾛向 ，并且更好地应对。
⽽项⽬复盘会 ，可以说是项⽬团队有意识地向过去的⾏为经验学习的过程。 在项⽬或⾥程碑完结之后 ，项⽬ 经理会组织召集项⽬成员 ，⼀起回顾⼀下 ，在项⽬的整个历程中 ，团队做对了哪些事 ，做错了哪些事 ，再来 ⼀次 ，如何做得更好 ，借此把项⽬⾏进过程中产⽣的集体智慧沉淀下来。
但是 ，现实情况经常是 ，项⽬⼀个接⼀个地做 ，忙上线、忙变更、忙返⼯ ，哪有时间坐下来复盘？ ⼜有多少 复盘会 ，是为了复盘⽽复盘 ，逐渐地流于形式 ，成为了可有可⽆的摆设？ 除此之外 ，还有很多复盘会 ，成为 了追责者的⼯具 ，除了锻炼出花样百出的各种甩锅技能之外 ，留下的只有“⼀地鸡⽑”。
由此可⻅ ，要想做好项⽬复盘 ，并不是⼀件容易的事情。今天 ，我就带你来看⼀看 ，如何做好项⽬复盘 ，以 及如何通过复盘去培养团队的持续改进能⼒。
复盘会的基调设定
我们都知道复盘很重要 ，但实际上 ，在复盘会之前，想清楚我们复盘的⽬的，设定好复盘的基调，其实更为重要。
我曾组织过⼀个复盘 ，叫作“坑爹功能”⼤搜罗。参与复盘的⼗多位团队Leader，在现场写了20多⻚纸，
满满当当地罗列着我们曾经做的、却没什么⼈⽤的功能。 实际上 ，只有当⼤家真正摊开不太愿意⾯对的真相 ，去认真思考背后的深层原因时 ，我们才能共同进⼊真正的集体反思区。这样坦诚地直⾯问题的复盘 ，才 能促发有意识的集体学习。
要想让参与者真正进⼊集体反思区 ，会前就要设定好开放的复盘基调。其实 ，我们每个⼈都可以在⾃⼰所处 的环境中 ，看到各种各样的问题。如果复盘是出于追责 ，那么在会议刚开始时 ，⼤家就可以迅速地感受到 ， 这样⼀来 ，每个⼈都会⼩⼼地避开⾃⼰的问题 ，转⽽去说别⼈的问题 ，这样的复盘就失去了意义。那么 ，如 何设定开放的基调呢？
⾸先，我们⾃⼰要先进⼊反思区。 其实 ，在那次复盘会之前 ，我跟这个部⻔的负责⼈ ，就部⻔中反复出现的 各种问题 ，进⾏过多次深度沟通。⼀开始 ，这位负责⼈觉得团队⾥到处都是问题。但当我们把问题⼀层层地 剖开来看时 ，我们发现了很多问题背后的深层原因。
除此之外 ，在会议刚开场 ，就要展⽰出⾃⼰的开放与坦诚 ，给复盘会奠定基调：这次复盘不是来挑问题的，⽽是为了找到问题的根源并改进的。 在那次复盘会上 ，这位负责⼈特意讲了⾃⼰这⼀年来的深刻反思 ，这就 带动⼤家敞开⼼扉 ，直⾯问题。那次会上 ，⼤家⾃发地找到了在各个环节有效避免⽆⽤功能的⽅法。会议结 束以后 ，这个部⻔还发起了⼀项“整⻛运动” ，从增强⽤⼾意识的讲座 ，到⽤⼾调研⽅法的培训 ，再到激励 与考核制度的挂钩 ，让复盘会反思的成果 ，逐渐渗透到了每个⼈的⽇常⼯作中。
复盘会的会前准备
除了设定基调 ，你还需要充分的会前准备。在复盘会之前 ，你要去梳理整个版本的历程 ，包括项⽬或⾥程碑
的各项数据和信息、 ⽬标和达成结果、进度计划、需求变更、质量状况等 ，这些是客观数据的总结。 同时， 你还可以提前收集这个版本期间 ，团队满意度的问卷调查 ，为复盘会引⼊更多主观的输⼊。
除此之外 ，视频也是⾮常好的回顾材料。 曾经 ，在某次重要版本的复盘会前 ，我熬夜加班 ，为团队准备了⼀ 段回顾视频。这个团队刚刚完成了⼀件⼏乎不可能完成的任务。 因为客⼾的需求⾮常迫切 ，往常要做⼀个半 ⽉的⼤版本 ，直接压缩到三周内完成 ，团队⾮常⾮常⾟苦。 虽然视频的制作⼿法很粗糙 ，但那些加班到深夜 开迭代演⽰会的照⽚ ，还是让现场的很多⼈感动不已 ，瞬间为这个疲惫的团队注⼊了能量。
其实，复盘会的基调设定，以及会前的准备⼯作，在开会之前，就很⼤程度地决定了复盘会的效果，你⼀定要特别留意。
了解了这些之后 ，我们就来看看复盘会的流程。
复盘会的简易流程
复盘会的流程 ，其实并不复杂。在实战中 ，我总结出了⼀套最为⾼效的复盘流程。
1. 现场回顾总结项⽬/⾥程碑的整体概况 ，包括⽬标达成情况、进度计划及变更情况、需求变更情况、质量 报告等项⽬历程记录。
2. 与会⼈员⽤便签纸写下项⽬过程中做得好的以及做得不好的3个点 ，按照项⽬的各个环节分类 ，分别贴在 ⽩板上 ，确保⼤家的意⻅能够充分、 ⾃由地表达。
3. 在⽩板前逐条review⼤家的意⻅ ，共同发现问题 ，并有针对性地展开讨论。
4. 对⼤家总结出的好和不好的点 ，进⾏集体投票。
5. 由项⽬经理整理投票结果 ，对于做得好的环节 ，总结经验；对于做得不好的环节 ，当场讨论出改进⽅ 案。
我们来看看⼀次真实的项⽬复盘会的投票结果：
这个项⽬是第⼀次引⼊项⽬经理。在这次复盘会上 ，项⽬经理的⼯作得到了⼀致的认可 ，包括Bug Bash的 引⼊ 、WBS⼯作分解、进度控制等措施 ，帮助团队快速地完成了从混乱到有序的转变。再来看看待改进项， 投票最多的⼀项是 ，后台研发与各端的沟通瓶颈 ，那么很显然 ，这就是你在下个版本⼀定要去解决掉的问 题。
经过分析之后 ，我们发现 ，由于⼯期紧张 ，在后端接⼝没有成熟的情况下 ，前端、客⼾端必须同时开发 ，如 此快节奏迭代之下 ，频繁的后台接⼝变动 ，牵⼀发⽽动全⾝ ，这让后台技术成为了整个项⽬的瓶颈。 为了改 善这个问题 ，我们成⽴了专⻔的Triage⼩组（判别⼩组） ，由各端的主程组成 ，每天固定15分钟时间 ，参与 者线上同时连线 ，对每个端提出的接⼝变动需求 ，进⾏统⼀判断 ，并作出决策 ，确保接⼝变更信息第⼀时间 的同步。
⽆法促发⾏动的复盘，说得再好都是空谈！ ⼀开始开复盘会 ，⼤家会期待 ，解决的问题越多越好 ，但焦点增 多之后 ，哪个都是蜻蜓点⽔地过⼀遍 ，哪个都没改彻底。 下次再开会的时候 ，⼤家发现之前反馈的问题依然 还在 ，那谁还有动⼒继续提问题呢？
所以 ，改进措施⼀定要落地，重点⾏动不要太多，⼀个就够了！ 如果每次复盘聚焦于改进项中的Top 1 ，确 保改进措施真正落地 ，⻓期坚持下去 ，就会促进持续的能⼒提升。 同时 ，复盘的次数也不要太多，你并不需要每个版本、每个迭代都例⾏公事地去做⼀遍，确保每个季度有⼀到两次⾥程碑复盘，可以完整地对项⽬做系统化的梳理，达到真正的落地效果，才是更重要的。
打造团队持续改进能⼒
其实 ，项⽬复盘不只是⼀次会议 ，它更应该成为团队持续改进的推动⼒ 。那么 ，怎样才能让⼀次成功的复盘 发展成为复盘⽂化 ，激发团队⾃主地持续精进呢？
实际上，想要让团队进⼊⾃发改进的正向循环，你需要更好地激发团队的主⼈翁意识，让团队成为复盘的主⻆，⽽不是你。最重要的是，你不仅要关注事，还要关注⼈。
我曾经为某部⻔组织过⼀次复盘会 ，取名叫作“研发代表⼤会”。 当时 ，我们把部⻔中所有资深的程序员召 集在⼀起 ，让他们给平台越来越严重的技术债问题出谋划策。这次复盘我采⽤了“批奏章” 的玩法 ，各位代 表把⾃⼰的意⻅写在纸上 ，然后围成⼀个圈 ，依次传递给左边的同学 ，每个⼈把⼿上的“奏章”批阅完成
后 ，继续往左传。这样⼀圈转下来 ，+1数最多的那份“奏章” ，就会被选出成为年度⼒荐。
最后 ，这份“奏章”得到了最多的关注和资源 ，这项建议迅速得到了落实。 同时 ，这样的复盘⽅式 ，也让更 多的研发同学享受到了“批奏章” 的愉悦感 ，⼀旦他们发现 ，⾃⼰选出的“奏章”会得到采纳和落地 ，那么 这个“研发代表⼤会”也就可以真正地⾃⾏运转起来 ，更多⼈愿意主动参与进来 ，通过这个平台 ，发表⾃⼰ 的⻅解 ，为整体能⼒的提升贡献⼀份⼒量。
另外 ，越是困难时期，越是塑造团队能⼒的⼤好机会。 在团队遇到重⼤困难时 ，你也可以及时组织⼀场复盘 会 ，深度关注和调整个⼈的状态。我就曾经试过让每个⼈画出⾃⼰进⼊这个项⽬组以后的状态变化曲线 ，跟 ⼤家分享⾃⼰的“⾼光时刻”和“⾄暗时刻”。在业务低落期 ，这样的复盘会会成为⼀个重要的转折点 ，让 团队的⼒量得到深度聚合。
这些对⼈的关注 ，都会让复盘会超越问题解决的层⾯ ，在推进事的同时 ，促使团队⾃发地推进问题的解决， 并把经验内化下来 ，从⽽不断提升团队的持续精进能⼒。
总结
好了 ，让我们对复盘做个⼩结。其实 ，当⼈们在说复盘时 ，往往会把焦点放在复盘会本⾝ 。但我却认为 ，决定复盘成功与否的关键，不在会议本⾝，⽽在于复盘会的⼀前⼀后两个环节。
复盘会前 ，复盘基调的设定是否开放 ，复盘会前的各项准备是否充分 ，对于复盘会的效果⾮常关键。组织⼀ 个复盘会本⾝并不难 ，难的是在复盘会后 ，持续跟进这些反思 ，落地为切实的改进措施 ，让团队真正看到效 果 ，从⽽打开团队持续改进的正向循环。
最后 ，我建议你认真地做好⼀次复盘，每次复盘后聚焦⼀个改进点。再提醒你⼀句：聚焦点别太多，⼀个就够了！
