产品经理在结束一个项目的时候，都需要做对应的复盘总结。那么产品经理该如何做好复盘呢？

一、什么是复盘

1.1 来源

复盘最开始来源于围棋术语，本意是对弈者下完一盘棋之后，重新将对弈过程摆一遍，看看哪些地方下的好，哪些地方下的不好，甚至有更好的下法。

在美国，最早采用复盘的是美国军队，它们将其称为“行动后反思”（after action review，AAR）。

美军对AAR的定义是：“对一个事件的专业讨论，以绩效表现为核心，重点放在帮助参与者自己发现发生了什么，为什么发生，如何保持优势，以及改正缺点”。

1.2 定义

复盘，就是在一件事情做完了以后，做成功了，或者没做成功，尤其是没做成功的，坐下来把当时的这个事情，我们预先怎么定的目标、中间出了什么问题、为什么没有做到，把整个过程再理一遍。理一遍之后，吸取之前的经验，下次再做的时候，自然这次的经验教训就吸收了。

1.3 项目复盘

项目复盘就是针对一个项目，不管是 0 到 1 或者是 1 到 100 的版本迭代，把每个阶段中的具体工作进行分解，分析每一项工作的进展是否顺利，问题点在哪、以及如何更好的优化。

二、复盘和总结的区别

总结只是复盘的一部分，复盘有比总结更为丰富的内涵。总结，是对事件过程进行梳理，它是对已经发生的行为和结果进行描述、分析和归纳，主要关注一些关键点和里程碑。

复盘，是在头脑中对做过的事情重新过一遍，是指从头到尾的审视。复盘除了有总结所包含的动作外，它还对未发生的行为进行虚拟探究，探索其他行为的可能性和可行性，以找到新的方法和出路。

正因为复盘比总结多一个推演的步骤，使得我们可以对各种可能性及其不同后果进行审视和设计，看看为什么会成功，为什么会失败；成功的地方是否有更成功的措施，失败的地方是否可以找到不同的路径。

所以可以说，总结是平面行为，复盘是立体行为。而复盘也并不是要求我们真的把每一次的事情都重新做一遍，更多的是一种思维上对事件的重现。

三、为什么要复盘

3.1 为职业生涯和个人成长铺路

产品经理天然的路线就是走向管理，而作为走向管理的第一步，就是要会总结得失。

每一个项目从开始到结束，过程中或多或少都会出现计划之外的突发状况，复盘就是是绝佳的反思的机会，产品上的得与失，通过一条一条的罗列，不断深入思考，从而提升自己的能力。

当然，即使不走向管理岗，复盘的意义亦难以替代。

比如说，现在市场上要求越来越专业化的产品经理类型，数据产品经理、策略产品经理、商业化产品经理等，好的项目复盘习惯，依旧是积累总结项目得失、优化下一步产品策略的最佳方式。

另外，产品经理核心的能力之一，就是总结能力，将收集到的需求建议、竞品优势等进行归纳整理，结合项目自身的差异点才能形成自己的需求思路。复盘能够帮助你快速反思自己的不足，及时纠正。

3.2 从0到1建立制度或制度迭代

将问题找出其成功或失败的关键点。

知其然，而知其所以然，要有意义的失败，避免无意义的成功。

同时将处理办法整理成一套可供执行的程序，以便下次遇到相同问题时采用，当然，视情况而定，不可拘泥死板。科学制度的制定/迭代过程也是如此。

3.3 结合PDCA模式，总结经验，提升项目管理能力

四、什么时候做复盘？

有两种方式：

a. 按照事件划分：小事及时复盘、大事阶段性复盘、事后全面复盘

比如： 产品小需求在需求上线后或者上线几天的一定周期内复盘； 相对比较大的，跨时间周期比较长的需求或者项目，则在其进行到某个关键节点的时候及时复盘。

b. 按照场景划分：个人复盘、团队复盘、业务复盘

比如：个人的每日复盘、团队的每周复盘、每月复盘等等。

五、复盘的四个步骤

复盘首先要做的是事实陈述，一个有效的AAR（任务后检视方法After Action Review）必须建立在“铁的事实”的基础上。

如果现实难以陈述清楚并取得一致，将导致复盘进展缓慢或无法深入下去，一旦事实确定下来了，就开始诊断、分析存在差异的原因，找出导致成功或失败的根本原因后进行规律总结。

明白为什么会成功、哪些关键行为起了作用、这些行为有没有适用条件，对于提高后续行动的成功率有没有价值。因此，一个完整的复盘就出现了，包括如下四个步骤：

5.1 目标回顾

当初行动的意图或目的是什么？

事件/行动想要达到的目标是什么？

我们计划怎么做？

预先制定的计划是什么？

事先设想要发生的事情是什么？

5.2 结果陈述

实际上发生了什么事？

在什么情况下？

是怎么发生的？

与目标相比，哪些地方做的好？

哪些未达到预期？

5.3 过程分析

实际状况与预期有无差异？

如果有，为什么会发生这些差异？

哪些因素造成了我们没有达到预期目标？

失败的根本原因是什么？

如果没有失败，成功的关键因素是什么？

5.4 规律总结

从过程中学到了什么新东西？

如果有人要进行同样的行动，我会给他们什么建议？

接下来我们该做些什么？

哪些是我们可直接行动的？

举个例子：比如我们做了一场优惠卷活动，在会后复盘的时候我们就得看任何一个优惠券他的：发放价值、实际价值、发放优惠卷的数量、领取优惠卷的数量、有效领取数量、使用优惠卷的数量、过期数量；

六、如何做产品复盘

每个项目基本都会包含几个核心阶段：目标、需求、设计、开发、测试、上线，把每个阶段中的具体工作进行分解，才能分析出每一项工作的进展是否顺利，问题点在哪、以及如何更好的优化。

复盘最重要的两个环节：过往演绎和复盘优化。明确产生偏差的原因，并提出针对性意见。各个阶段复盘流程主要有以下这几个环节：

6.1 规划阶段复盘

原目标是否如期实现？是否存在偏差？

哪些需求点没有按计划实现？

每一个需求点延后原因分别是什么？

实现过程出现了哪些意外？

为什么会出现这些意外？

6.2 需求阶段复盘

是否提供完整的需求输出？（包括BRD、MRD、PRD、原型、UML等）

PD、UI、RD分别对需求是否明确？（如果不明确将会严重影响项目的进度和质量）需求是否对典型用户和使用场景有清晰的描述？

6.3 设计阶段复盘

是否进行设计评审？

人员构成是否充分？

UI设计产出是否符合统一标准？

设计工作是否影响开发工作的进度？

影响原因是什么？

产品设计工作在什么时候，由谁来完成的？质量如何？

6.4 开发阶段复盘

工期评估复盘：

开发实施前，是否有充分的时间做工期预估？（工期评估一方面是让项目成员能够对项目的整体进度有所准备，也是对项目需求进行详细梳理的过程）

工期预估与实际开发时间是否有差异？

差异原因是什么？

开发文档复盘：

是否有撰写开发文档？

文档是否符合开发规范？

风险控制复盘：

是否出现需求无法实现的状况？

原因是什么？

是否出现团队成员变动情况？

有无应对措施？

后期如何避免？

是否出现功能模块与需求不符的情况？

原因是什么？

6.5 测试阶段复盘

测试计划复盘：

是否有完整、准确的测试用例？

是否有测试计划？

计划执行情况如何？

团队是如何测试并跟踪产品开发效果的？

测试工具复盘：

使用了哪些工具来帮助测试？

是否可以持续使用？

测试的时间、人力和软件/硬件资源是否足够？

测试结果复盘：

哪个功能模块产的bug最多？

原因是什么？

处理策略是什么？

哪些bug出现回滚？

原因是什么？（回滚：即程序版本回退。出现较大bug，程序从1.1回退到1.0，迭代之后全是bug，修复成本高）

6.6 上线阶段复盘

上线验收复盘：

是否进行了正式的上线验收评审？

在正式发布的过程中是否有出现状况？

对策是什么？

上线前是否和运营、文案进行充分沟通？

效果如何？

是否检查了数据埋点，数据埋点是否满足运营要求？

上线后效果复盘：

上线后是否出现重大bug？

为什么测试阶段没有发现？

是否提供上线后问题的反馈渠道？

产品上线后收集到哪些问题反馈？

如何改进？

七、复盘常见的那些坑

1. 为了证明自己是对的

复盘的目的在于让团队从行动中学习，如果仅仅为了证明自己是对的，那么在复盘过程中就会刻意强化对自己有利的材料而忽视其他材料，这就像戴上了有色眼镜，完全忘记了复盘的真正目的。这也是为什么现在越来越多的复盘会变成了甩锅会，尤其是作为产品，复盘应该不忘初心。

2. 流于形式走过场

虽然复盘有固定的流程、步骤，但做复盘决不能照抄照搬或套用模板，也不能为了完成任务而应付了事，走走过场。复盘是为了学习和改进，是自己和团队受益的事，如果只做表面功夫，则既浪费时间也没有收获。

3. 追究责任，开批斗会

在开复盘会议时，通常容易演变成“挑毛病”大会，追究其责任并进行批评教育，这会严重破坏复盘所需的学习气氛，也会让团队失去信心。

4. 推卸责任，归罪于外

与挑错、批评相对应，人们很容易推卸责任，找出各种借口和理由为自己辩护，试图证明自己是对的，至少没有过错。这样将更加破坏学习的氛围，甚至滋长团队内部的不信任、矛盾与冲突。

5. 快速下结论

在做复盘的过程中，需要找出实际与目标之间产生差异的根本原因，并挖掘出经验教训，这需要时间的思考及审慎地分析。快速下结论通常只看到了问题的表象，还没有找到真正的问题，或是只总结出了一次偶然性的因果关系，却误以为发现了规律。

希望今天的内容对你有用～