跟着高手学复盘_落地实践
一、复盘概述
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 成员分工
image2.4 复盘定向
确定复盘内容,边界,流程等
-
确定复盘主题 ,集中讨论解决问题
-
复盘结果对团队有什么帮助
-
创造一个什么样团队氛围等
2.5 会议流程
-
回顾目标
-
结果比对
-
叙述过程
-
自我剖析
-
众人设问
-
总结规律
- 通过现象找本质
-
案例佐证
-
复盘归档
-
对复盘的过程和结论简历档案,形成有据可查的资料
-
将复盘得到的认知知识化,方便传播和查阅
-
保留真实的,准确的信息
-
2.6 ToDo部分
摘自恒捷大佬的评论
-
结论本身比较虚。比如很多时候有些代码里的隐藏问题,会得出一个 “加强代码 review ” 这种结论。但实际这个结论实际操作很难,怎么算加强,多看几次?谁去加强,leader 还是开发自己?连怎么确认是否有落地都难,那落地就更难了。
-
“分页不传参数的 BUG 多次出现” ,有时候产生的结论是 “以后每次分页记得传参数” 。说实话,这类 bug 容易出现,是不是说明这个地方写起来不符合人性所以容易遗漏?那是不是应该改进写法,比如这个传参数内置到分页库里,而不是开发每次手动加?
- 复盘结论可量化,解决方案可实施
-
-
结论具体了,但没有负责人和约定的完成时间,或者就算有也没有人监督。复盘产生的结论很多时候不是业务中的日常事务,更多是额外增加的优化工作,优先级不高。如果没有明确负责人和约定的完成时间,可能项目一忙起来就都忘了。没有监督人在接近完成时间时及时催促提醒,也很容易导致超时甚至不了了之。
-
负责人推动一到两个版本
-
形成规范
-
加入常规流程
-