什么是复盘
传统释义
围棋术语，指下完一盘棋后，双方棋手把对弈过程重新摆一遍，看哪里下得好，哪里下得不好，哪些关键节点有不同甚至更好的下法，以检查对局中招法的优劣与得失，并从中寻找提高自己水平的方法。
管理释义
一句话概括：“做过的事情，再从头过一遍”
对于我们经历过的事情，“从头”指的是‘从目的“开始审视和思考，从中发现问题、分析原因、总结经验
本质
考查“目标”和“结果”的Gap，根据差异，回顾、反思、探究、提升
为什么要复盘
对事
战略上及时校准方向、调适路线
战术上攻克具体难题、及时总结方法、不断提升经营水平
对人
规避重复问题：分析问题，探索可能的解决方案以避免同样的错误再次发生
提升能力：积累经验，总结规律，并抽象成方法论
核心价值
巩固成功与改正错误
什么时候复盘
及时复盘
高风险和高阻塞等任务行动结束后，花很短的时间再过一次整个过程，及时制定改进方案并落实。
阶段性复盘
大项目的执行过程中，阶段性复盘，思考原定的目标是什么，目前达成的结果是什么，阶段性地对目标或策略进行调整。
全面复盘
在项目或战略结束后，全面总结目的、目标以及达成的结果，过程中哪些地方做得不好，哪些地方做得好，以及收获的经验教训和规律。
如何复盘
四步复盘法
1. 回顾目标
回顾当初的目的或期望的结果是什么
抓手
- 需求是如何从提出到立项的？
- 想要实现的目标和收益是什么？
- 最初的计划是怎样的？
- 预期的风险和应对措施是怎样的？
注意点
- 分清目的与目标的不同，正确的目的保证目标的方向；清晰而适配的目标能更好地分解和保障目的实现。
- 确定目的之外，最好能确定出可量化的目标或具有里程碑性质的标志。无量化或可考核的目标，很难保证目的实现，也难与结果对照评估。
- 事前所提目的、目标不清晰，复盘时追补清晰，便于本次对照，提高下次定目标的准确度。可参考SMART原则制定目标
2. 评估结果
对照原来设定的目标找出过程中的亮点和不足
抓手
- 最初的目标和收益有没有实现？
- 最初制定的计划执行情况如何？（如进度计划、成本计划、资源计划等）
- 预期风险是否发生？应对措施是否有效？
- 发生了哪些意料之外的事情？有何影响？
注意点
- 首先要与原定的目标相比较，客观分析意料外的重要亮点或不足。
- 亮点与不足同样重要，不能弱化亮点
- 多引入外部典型事实样本，让我们的结果评估视野更广阔、结论更客观。
3. 分析原因
寻找成功的关键原因和失败的根本原因
抓手
- 叙述过程：实事求是的过程叙述，让复盘参与者知悉背景、对齐信息
- 自我剖析：自己对做过的事情进行反思和分析，看看有哪些问题，有哪些成绩，并试着去找出原因，发现规律。
- 众人设问：突破事件本身的局限，突破个人见识的局限。设问要多探索可能性，考察每一种可能性的条件，以及其边界。
注意点
- 成功时，主要看客观原因，多列举客观因素，精选自身真正的优势。
- 失败时，主要看主观原因。多从自身深挖原因，狠挑不足以补足短板
4. 总结经验
总结体会、体验、反思、规律，以及接下来的行动计划
抓手
- 我们从过程中学到了什么新
- 如果有人要进行类似的项目，我会给到什么建议?
- 接下来我们该做些什么?需要实施哪些新举措？继续哪些动作？叫停哪些动作？
注意点
-
总结规律
复盘结论的落脚点是否在偶发性的因素上？
当复盘的结论落脚在偶发性因素上，那一定是错误的。如果复盘没有进入到逻辑层面，没有经受住逻辑的验证，则这样的复盘结论，一定是不可信的。复盘结论是指向人还是指向事？
复盘的结论如果是指向人，则很可能说明复盘没有真正到位。因为复盘得出的是规律性的认识，而人是具体的，各不相同。指向事，则复盘到规律的可能性更高。复盘的结论不是指向人，而是从事物的本质去理解分析，这是验证复盘结论是否可靠的标准之一。复盘结论的得出，是否有过3次以上连续的 why 或者 why not 的追问？
如果次数不够，也很可能意味着复盘没有找到真正的原因。探寻问题背后的问题，找出答案之后的答案，这就是追问的目的。是否是经过交叉验证得出的结论？
“孤证不能定案”是法律上的术语，用来比喻复盘得出的结论通过其他事情交叉验证，也可以为结论的有效性提供一定的保障。
案例佐证
除了从因果关系上去验证规律外，为了验证规律的可信度，还应该用其他案例进行佐证。这是从规律的适用性出发的一次实验。案例佐证面临着案例选择的问题，所选的案例应该是同类型的、同行业的，不能选取跟所复盘的事件无关的案例。归档复盘
复盘进行归档，这其实也是知识管理的一种。归档将复盘得到的认识知识化或者形成方法论，更加方便传播和查阅，这让没有参与复盘的人也能掌握复盘得出的规律和观念，让新人可以在自己的工作中进行学习和参考，少走弯路。
复盘模版
项目复盘示例
项目目标复盘
项目进度复盘
- 是否按照原计划交付时间交付？
- 原计划的需求点实现了多少？哪些需求点没有按计划实现？每一个需求点延后原因分别是什么？
- 哪些里程碑有延迟，延迟原因是什么？
项目结果复盘
- 项目中出现了哪些意外？为什么会出现这些意外？
- 用户对新增功能点的接受程度和项目规划中的是否一致？
需求阶段复盘
需求定义复盘：
- 是否提供完整的需求输出，包括：原型、MRD、PRD、UML等
- 设计师、交互师、开发人员分别对需求是否明确：如果出现需求不明确的情况，将会严重影响项目的进度和质量
- 是否对典型用户和使用场景有清晰的描述？
需求变更复盘
- 需求变更次数：敏捷开发已经将需求变更的影响降到最低，但是较少的需求变更仍然是项目进展顺利的前提之一
- 哪些需求变更影响了项目实际进度
- 每次变更的原因：领导干预？前期考虑欠缺？需求无法实现？分析每一次的变更原因，可以在后期项目中进行合理的避免。
- 每个项目成员是否都清晰的知道每一次的变更：只有每位项目成员清楚的了解每次需求变更，并做好充分的沟通，才能保证项目的进度和质量。
- 项目成员是否能接收需求变更：这就要求每次需求变更，都要和相关人员做好沟通。
设计阶段复盘
- 是否确定视觉设计的最终审核人？
- UI设计产出是否符合统一标准？
- 设计工作是否影响开发工作的进度？影响原因是什么？
- 产品设计工作在什么时候，由谁来完成的？
开发阶段复盘
工期评估复盘
- 开发实施前，是否有充分的时间做工期预估：工期评估一方面是让项目成员能够对项目的整体进度有所准备，也是对项目需求进行详细梳理的过程。
- 工期预估与实际开发时间是否有差异，及差异原因分析
开发文档复盘
- 是否有提供开发文档？
- 开发文档是否符合规范
突发状况复盘
- 是否出现需求无法实现的状况？原因是什么？
- 是否出现团队成员变动情况？如何应对成员变动？后期如何避免？
- 是否出现功能模块与需求不符的情况？出现原因是什么？
Code Review复盘
- 是如何进行的：包括如何分工，如何复查等。
- Code Review结果是什么？
- 是否严格执行了代码规范？对不规范的代码如何处理？
测试阶段复盘
测试计划复盘
- 是否有完整、准确的测试用例？
- 是否有一个测试计划？这样的计划是否有效？
- 团队是如何测试并跟踪产品开发效果的？
测试工具复盘
- 使用了哪些测试工具来帮助测试？是否可以持续使用？
- 测试的时间、人力和软件/硬件资源是否足够?
测试结果复盘
- 哪个功能模块产生的Bug最多，为什么？
- 哪些BUG出现回滚，原因是什么？
上线阶段复盘
验收复盘
- 是否进行了正式的上线验收？
- 在正式发布的过程中是否有出现状况？后续如何避免？
- 上线前是否和运营、文案进行充分的沟通？
- 是否检查了数据埋点，数据埋点是否满足运营要求？
上线后效果复盘
- 在上线之后是否出现重大bug? 为什么测试阶段没有发现？
- 产品上线后的问题反馈渠道是否顺畅？
- 产品上线后收集到哪些问题反馈？都是什么类型？如何改进？
