复盘的背景
“复盘”这个词最早来自棋类术语，也成“复局”，指对局完毕后，复演该盘棋的记录，以检查对局中对弈者的优劣与得失关键，有效地加深对这盘对弈的印象，也可以找出双方攻守的漏洞。
复盘的定义
- 简单说就是回放过去，反思不足，总结经验，复用未来；
- 把过去好的留下来，整理成规范、体系，服务现在和未来；
复盘的价值
- 站在巨人的肩膀上；
- 少走弯路，少踩坑；
- 把经验转化为能力；
- 不重复交学费，降低学习/工作/试错的成本；
- 做更好的自己（革过去自己的命）；
- 站在今天看昨天，看昨天干得漂亮的活，今天漂亮的干活，让明天活得漂亮。
复盘的类型和特性（时间维度、用户属性）
- 日会-晨会（吾日三省吾身、及时反省和调整、适用个人）；
- 月复-月会（小型项目或团队、阶段性调整、适用个人或团队）；
- 季度复-季度会（中型项目或团队、阶段性调整、适用团队和公司）
- 年复-年会（大型项目或团队、阶段性调整、适用团队和公司）
- 公司和用户/加盟商/客户（粉丝）的交流会/年会/生日会（开放参与对象 | 让用户参与进来，倾听用户心声，挖掘潜在需求和痛点，吸收用户端的建议和创意，调整公司市场战略和产品战略）。
复盘的执行（如何把复盘做好）
- 复盘会议邀请（负责人 | 复盘目标、参与成员）
- 复盘内容准备（参与全员 | 过去做的事情，拿的目标结果（定性和定量的数据）、找到捷径的经验分享、挖/踩到坑的反思、未来的规划、个人成长）
- 复盘内容分享（全员）
- 复盘内容提问、回答、讨论（全员
- 复盘点评、整理（负责人 | 发现/优化团队长板）
- 复盘总结内容、笔记共享（全员 | 知识库、成长体系文档）
常见复盘角度
四部曲复盘法
第一步：回顾目标
- 当初行动的目的和意图是什么？
- 时间或行动想要达到的目标是什么？
- 预先制定的计划是什么？
- 事先设想要发生的事情是什么
第二步：评估结果
- 实际上发生了什么事？
- 在什么情况下？是怎么发生的？
- 与目标相比，哪些地方做的好？
- 哪些地方未达到预期？
第三步：分析原因
- 实际情况与预期有无差异？
- 如有，为什么会发生这些差异？
- 哪些因素导致未达到预期目标？
- 失败的根本原因是什么?
- 如无，成功的关键要素是什么？
第四步：总结经验
- 在过程中学到什么新东西？
- 有人进行同样行动，有啥建议？
- 接下来该做些什么？
- 哪些是可以直接行动的？
- 哪些是其它层级才能处理的？
- 是否要向上呈报？
复盘结论判断
- 是否排除了偶发因素？
- 是否具有普遍性？个例？
- 结论指向人还是指向事？
- 是否经过三次以上追问为什么？
- 是否有类似事件的复盘结果？
- 是否可以交叉验证？
行动
- 开始做什么？
- 继续做什么？
- 停止做什么？
常见项目复盘提纲
- 目标达成度
- 我们的产品要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 我们达到目标了么？（原计划的功能做到了几个？按照原计划交付时间交付了么？）
- 用户量，用户对重要功能的接受程度和我们实现的预想一致么？我们离目标更近了么？（需要上线后观察再回答）
- 计划执行情况
- 开发前，是否有充足的时间来做计划？
- 团队在计划阶段如何解决同事们对于计划的不同意见的？
- 你原计划的工作是否最后都做完了？如果由没做完的，为什么？
- 有没有发现你做了一些时候看来没必要或没多大价值的事？
- 是否每一项产品需求都有清晰定义和衡量的交付成果？
- 是否项目的整个计划都按计划进行？项目出了什么意外？有什么风险是当时没有预估到的？为什么没有预估到
- 在计划中有没有留下缓冲区，缓冲区有作用吗？
- 将来的计划会做什么修改？
- 资源协调情况
- 我们有足够的资源来完成这个项目吗？
- 项目所需时间和其他资源是如何估计的？精度如何？
- 测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（产品设计/文案/运营策略）是否低估了难度？
- 你有没有感到你做的事情可以让别人来做（更有效女）？
- 变更管理
- 是否存在需求变更？变更了几次？每次变更的原因是什么？
- 需求变更时，是否每个相关的员工都及时知道了变更的消息？
- 我们采用什么方法来决定每次变更，是“推迟”还是“必须实现”？
- 变更的出口条件（也就是什么叫“改好了”）有清晰的定义吗？
- 对于可能的变更是否提前制定应急计划？
- 员工是否能够有效地处理意料之外的工作变更？
- 从设计到开发
- 产品设计工作在什么时候，由谁来完成？是合适的时间、合适的人么？
- 产品设计工作有没有碰到模棱两可的情况，团队是如何解决的？
- 团队是否运用单元测试（Unit Test）,测试驱动开发（TDD）、UML、LINT或其他工具来帮助编码？这些工具有效么？
- 什么功能产生的BUG最多，为什么？
- 在发布之后发现了什么重要的BUG？为什么我们在设计/开发的时候没有想到这些情况？（需要上线后观察再回答）
- 代码走查（Code Review）是如何进行的？是否严格执行了代码规范？
- 从测试到发布
- 团队是否有一个测试计划？这样的计划是否有效？
- 是否进行了正式的验收测试？
- 团队是否有测试工具来帮助测试？效果如何？
- 团队是如何测试并跟踪产品开发效果的？从产品实际运行的结果来看，这些测试工具有用吗？应该有哪些改进？
- 在发布的过程中发现了哪些意外问题？如何解决的，后续如何避免？
- 团队协作
- 团队的每个角色是如何确定的，是不是人尽其才？
- 项目执行过程中是否有团队成员并更？变更是否带来问题？是如何解决的？
- 团队成员之间有互相帮助吗？
- 当出现需求描述、项目管理、合作方面的问题时，团队成员如何解决问题？
- 总结
- 关于以上问题，有什么经验教训？如果历史重来一遍，我们会做什么改进？
- 你觉得团队目前处于“萌芽/磨合/规范/创造”阶段的哪一个阶段？为什么？
- 你觉得团队在这个项目相比前一个项目有什么改进吗？
- 你觉得目前最需要改进的一个方面是什么？
按照流程的复盘
- 项目的出发点：需求目的是否准确，回头来看对问题的分析准不准确
- 项目的解决思路：当时为什么按照这个思路来设计，现在来看，是否有更好的解决思路
- 设计细节：规则和流程设计上有没有漏洞？有没有优化的空间让效果更好？当时为什么没有发现这些？
- 项目管理和执行：人员安排上有没有不足？数据需求是否确认好？沟通协调是否有不足？是否延期及原因；
- 数据表现分析：是否达到预期？没有的话是主观原因还是客观原因？下一步如何做？继续尝试还是放弃