一、复盘概述

2020年主导多次复盘之后，复盘过程，落地执行效果并不怎么好，刚好遇到极客时间《跟着高手学复盘》专栏，落地时间优化相关，整理相关内容。

1.1 由来

从围棋中借来的一个术语。围棋中的本义是,当我们下完一盘棋之后,要重新在棋盘上走一遍,看看哪些子下得好,哪些子下得不好,哪些地方可以有不同甚至是更好的下法,等等 image

由此可见，复盘的关键是推演,通过推演这个动作,复盘就不仅仅是对过去的复制呈现,而是可以对各种可能性进行探讨。正是因为推演这个动作,将复盘与总结从本质上区别开来。

1.2 目的

对未来的优化，对原因的分析，对认知的修正。

但是日常迭代，在项目中的福怕往往是复盘变成了甩锅和背锅，不知道怎么得到有价值的复盘理论，复盘结论得不到别人的支持。

1.3 形式

1.3.1 自我复盘

我个人理解为自我复盘是最常见的个人反思，是一种最具操作性的复盘形式，不受时间和空间等外在条件的限制，不受事情本身进展的约束。只要我们自己愿意，只要形成习惯，就可以随时，随地，随意的复盘。一闪念，一回想，一反思，一对照，一总结，都可以是复盘。

1.3.2 团队复盘

最常用

团队复盘是一个有很多人参与并期望得出“真知”的会议，它是讨论会而不是宣讲会。讨论会需要大家各自发挥自己的聪明才智,然后才有可能得岀大家认可并接近事情真相的认识。 通常情况下讨论会要么因为无人愿意发言变成主持人的自弹自唱,要么变成争论会,两者都可能造成团队复盘的一无所得。

1.3.3 复盘他人

这种复盘形式，在日常迭代中用的应该相当少。用他山之石，磨自己之刀，在围棋术语中，称之为：打猎。 就是自己做了—件事情，对手也做了件差不多的事情，两者对比复盘。比较下自己和对手不同的做事思维、不同的着力点,别人哪里比自己做得好，哪里自己做得比别人好，最终效果有什么差别，为什么他人将着力点放在某个地方而不是其他地方。

1.4 方法

1.4.1 情景重现

实践程度有点苦难，人都是有私心的，不一定会表达真实的想法

日常在做项目中，刚开始难免有各种个人因素，例如：某个项目中需要用到机器学习相关技术，但是因为自己不会又怕说出来被人笑话，就隐瞒了下来，最后导致项目失败；某个项目中分配了两名测试人员，但是迭代过程中人员请假，流动等不可控的因素，导致项目延期； 情景重现，字面意思，把项目迭代中发生的事还原出来。遵从真实，全面，完整的三个标准。勇敢袒露自己的所思所想，不担心别人笑我幼稚，不担心人说没逻辑，像旁观者一样，看待当时的情绪，不能将当时的情绪带入到现在的复盘中，但是，能做到的团队，不太多。

1.4.2 关键点

小目标的形式，迭代计划的各个主要的时间点

围绕着关键点进行重现，思考和推演的复盘方法。评审时间 一般的关键点，是常说的里程碑，时间关键点，里程碑时间。一般是评审会议根据以前的经验，先行确定事件成功必须满足的关键成功因素，然后围绕关键成功因素进行复盘，看看自己和他人所做的事情，哪些因素做得比较好，哪些因素做得不够好，究竟哪些因素最终导致了事情的成功或者失败。然后针对复盘得岀的结论,进行弥补和强化，最终赢得下一次迭代的成功。

1.4.3 疑问法

复盘会议之前和负责人确定复盘主题

疑问法，就是对存疑的地方提岀问题，然后针对这些疑问进行提问，挖岀逻辑和原因，并找到做得好与坏的地方。这就相当于是围棋选手在复盘的时候，先将棋盘中的疑问手下岀来，然后围绕这些疑问手进行思考和重现，渐渐地整局棋被复盘。

二、复盘内容

2.1 复盘总结

现在情况是什么样的（实际结果），一般项目中，就是需求完成度，用户满意度，线上BUG率等，帮助我们知道事情的进展情况。

参考问题
 现在做到什么程度？
 当时定的目标是多少？
 现在的结果和目标对比处于什么状态？
 有没有当时没预计到的结果出现有没有当时预计过，但实际没出现的情况等

当初是怎么决定的（预期结果），当我们决定做这件事而不是另外—件事情的时候，是什么支撑我们作出这种选择?当我们决定这样做而不是那样做的时候，是什么支撑我们作岀这种选择?当确定做一件事情的时候，又是什么支撑我们设定不同的目标? 主要的问题是：

• 事情是如何确定的？
• 事情是根据什么确定的？
• 执行的如何？
• 事情是上面摊派强压的，还是自己主动思考得来的？</pre>

参考问题：
 当初决定的时候,是大家达成共识的吗?
 有没有听取其他人的意见?
 有没有让其他人畅所欲言?
 我们当时是如何确定执行目标的?
 支撑我们当初设置目标的依据有变化吗?
 执行过程是怎么样的?
 是不是完全按照我们的计划执行的?
 为什么××部门没有参加?
 为什么××活动没有做?
 我们做对了什么?
 我们做错了什么?
 还可以采取什么新的做法?

2.2 资料准备

这部分往往是最难做收集的，项目中的流程与规范记录不太完整，资料保存不完整

image.png

2.3 成员分工

image

2.4 复盘定向

确定复盘内容，边界，流程等

• 确定复盘主题 ，集中讨论解决问题

• 复盘结果对团队有什么帮助

• 创造一个什么样团队氛围等

2.5 会议流程

• 回顾目标

• 结果比对

• 叙述过程

• 自我剖析

• 众人设问

• 总结规律

• 通过现象找本质

• 案例佐证

• 复盘归档

  • 对复盘的过程和结论简历档案，形成有据可查的资料

  • 将复盘得到的认知知识化，方便传播和查阅

  • 保留真实的，准确的信息

2.6 ToDo部分

摘自恒捷大佬的评论

• 结论本身比较虚。比如很多时候有些代码里的隐藏问题，会得出一个 “加强代码 review ” 这种结论。但实际这个结论实际操作很难，怎么算加强，多看几次？谁去加强，leader 还是开发自己？连怎么确认是否有落地都难，那落地就更难了。

  • “分页不传参数的 BUG 多次出现” ，有时候产生的结论是 “以后每次分页记得传参数” 。说实话，这类 bug 容易出现，是不是说明这个地方写起来不符合人性所以容易遗漏？那是不是应该改进写法，比如这个传参数内置到分页库里，而不是开发每次手动加？

    • 复盘结论可量化，解决方案可实施

• 结论具体了，但没有负责人和约定的完成时间，或者就算有也没有人监督。复盘产生的结论很多时候不是业务中的日常事务，更多是额外增加的优化工作，优先级不高。如果没有明确负责人和约定的完成时间，可能项目一忙起来就都忘了。没有监督人在接近完成时间时及时催促提醒，也很容易导致超时甚至不了了之。

  • 负责人推动一到两个版本

  • 形成规范

  • 加入常规流程