产品经理在结束一个项目的时候，都需要做对应的复盘总结。那么产品经理该如何做好复盘呢？
复盘最开始来源于围棋术语，本意是对弈者下完一盘棋之后，重新将对弈过程摆一遍，看看哪些地方下的好，哪些地方下的不好，甚至有更好的下法。
在美国，最早采用复盘的是美国军队，它们将其称为“行动后反思”（after action review，AAR）。
美军对AAR的定义是：“对一个事件的专业讨论，以绩效表现为核心，重点放在帮助参与者自己发现发生了什么，为什么发生，如何保持优势，以及改正缺点”。
复盘，就是在一件事情做完了以后，做成功了，或者没做成功，尤其是没做成功的，坐下来把当时的这个事情，我们预先怎么定的目标、中间出了什么问题、为什么没有做到，把整个过程再理一遍。理一遍之后，吸取之前的经验，下次再做的时候，自然这次的经验教训就吸收了。
项目复盘就是针对一个项目，不管是 0 到 1 或者是 1 到 100 的版本迭代，把每个阶段中的具体工作进行分解，分析每一项工作的进展是否顺利，问题点在哪、以及如何更好的优化。
总结只是复盘的一部分，复盘有比总结更为丰富的内涵。总结，是对事件过程进行梳理，它是对已经发生的行为和结果进行描述、分析和归纳，主要关注一些关键点和里程碑。
复盘，是在头脑中对做过的事情重新过一遍，是指从头到尾的审视。复盘除了有总结所包含的动作外，它还对未发生的行为进行虚拟探究，探索其他行为的可能性和可行性，以找到新的方法和出路。
正因为复盘比总结多一个推演的步骤，使得我们可以对各种可能性及其不同后果进行审视和设计，看看为什么会成功，为什么会失败；成功的地方是否有更成功的措施，失败的地方是否可以找到不同的路径。
所以可以说，总结是平面行为，复盘是立体行为。而复盘也并不是要求我们真的把每一次的事情都重新做一遍，更多的是一种思维上对事件的重现。
产品经理天然的路线就是走向管理，而作为走向管理的第一步，就是要会总结得失。
每一个项目从开始到结束，过程中或多或少都会出现计划之外的突发状况，复盘就是是绝佳的反思的机会，产品上的得与失，通过一条一条的罗列，不断深入思考，从而提升自己的能力。
当然，即使不走向管理岗，复盘的意义亦难以替代。
比如说，现在市场上要求越来越专业化的产品经理类型，数据产品经理、策略产品经理、商业化产品经理等，好的项目复盘习惯，依旧是积累总结项目得失、优化下一步产品策略的最佳方式。
另外，产品经理核心的能力之一，就是总结能力，将收集到的需求建议、竞品优势等进行归纳整理，结合项目自身的差异点才能形成自己的需求思路。复盘能够帮助你快速反思自己的不足，及时纠正。
将问题找出其成功或失败的关键点。
知其然，而知其所以然，要有意义的失败，避免无意义的成功。
同时将处理办法整理成一套可供执行的程序，以便下次遇到相同问题时采用，当然，视情况而定，不可拘泥死板。科学制度的制定/迭代过程也是如此。
有两种方式：
a. 按照事件划分：小事及时复盘、大事阶段性复盘、事后全面复盘
比如： 产品小需求在需求上线后或者上线几天的一定周期内复盘； 相对比较大的，跨时间周期比较长的需求或者项目，则在其进行到某个关键节点的时候及时复盘。
b. 按照场景划分：个人复盘、团队复盘、业务复盘
比如：个人的每日复盘、团队的每周复盘、每月复盘等等。
复盘首先要做的是事实陈述，一个有效的AAR（任务后检视方法After Action Review）必须建立在“铁的事实”的基础上。
如果现实难以陈述清楚并取得一致，将导致复盘进展缓慢或无法深入下去，一旦事实确定下来了，就开始诊断、分析存在差异的原因，找出导致成功或失败的根本原因后进行规律总结。
明白为什么会成功、哪些关键行为起了作用、这些行为有没有适用条件，对于提高后续行动的成功率有没有价值。因此，一个完整的复盘就出现了，包括如下四个步骤：
当初行动的意图或目的是什么？
事件/行动想要达到的目标是什么？
我们计划怎么做？
预先制定的计划是什么？
事先设想要发生的事情是什么？
实际上发生了什么事？
在什么情况下？
是怎么发生的？
与目标相比，哪些地方做的好？
哪些未达到预期？
实际状况与预期有无差异？
如果有，为什么会发生这些差异？
哪些因素造成了我们没有达到预期目标？
失败的根本原因是什么？
如果没有失败，成功的关键因素是什么？
从过程中学到了什么新东西？
如果有人要进行同样的行动，我会给他们什么建议？
接下来我们该做些什么？
哪些是我们可直接行动的？
举个例子：比如我们做了一场优惠卷活动，在会后复盘的时候我们就得看任何一个优惠券他的：发放价值、实际价值、发放优惠卷的数量、领取优惠卷的数量、有效领取数量、使用优惠卷的数量、过期数量；
每个项目基本都会包含几个核心阶段：目标、需求、设计、开发、测试、上线，把每个阶段中的具体工作进行分解，才能分析出每一项工作的进展是否顺利，问题点在哪、以及如何更好的优化。
复盘最重要的两个环节：过往演绎和复盘优化。明确产生偏差的原因，并提出针对性意见。各个阶段复盘流程主要有以下这几个环节：
原目标是否如期实现？是否存在偏差？
哪些需求点没有按计划实现？
每一个需求点延后原因分别是什么？
实现过程出现了哪些意外？
为什么会出现这些意外？
是否提供完整的需求输出？（包括BRD、MRD、PRD、原型、UML等）
PD、UI、RD分别对需求是否明确？（如果不明确将会严重影响项目的进度和质量）需求是否对典型用户和使用场景有清晰的描述？
是否进行设计评审？
人员构成是否充分？
UI设计产出是否符合统一标准？
设计工作是否影响开发工作的进度？
影响原因是什么？
产品设计工作在什么时候，由谁来完成的？质量如何？
工期评估复盘：
开发实施前，是否有充分的时间做工期预估？（工期评估一方面是让项目成员能够对项目的整体进度有所准备，也是对项目需求进行详细梳理的过程）
工期预估与实际开发时间是否有差异？
差异原因是什么？
开发文档复盘：
是否有撰写开发文档？
文档是否符合开发规范？
风险控制复盘：
是否出现需求无法实现的状况？
原因是什么？
是否出现团队成员变动情况？
有无应对措施？
后期如何避免？
是否出现功能模块与需求不符的情况？
原因是什么？
测试计划复盘：
是否有完整、准确的测试用例？
是否有测试计划？
计划执行情况如何？
团队是如何测试并跟踪产品开发效果的？
测试工具复盘：
使用了哪些工具来帮助测试？
是否可以持续使用？
测试的时间、人力和软件/硬件资源是否足够？
测试结果复盘：
哪个功能模块产的bug最多？
原因是什么？
处理策略是什么？
哪些bug出现回滚？
原因是什么？（回滚：即程序版本回退。出现较大bug，程序从1.1回退到1.0，迭代之后全是bug，修复成本高）
上线验收复盘：
是否进行了正式的上线验收评审？
在正式发布的过程中是否有出现状况？
对策是什么？
上线前是否和运营、文案进行充分沟通？
效果如何？
是否检查了数据埋点，数据埋点是否满足运营要求？
上线后效果复盘：
上线后是否出现重大bug？
为什么测试阶段没有发现？
是否提供上线后问题的反馈渠道？
产品上线后收集到哪些问题反馈？
如何改进？
复盘的目的在于让团队从行动中学习，如果仅仅为了证明自己是对的，那么在复盘过程中就会刻意强化对自己有利的材料而忽视其他材料，这就像戴上了有色眼镜，完全忘记了复盘的真正目的。这也是为什么现在越来越多的复盘会变成了甩锅会，尤其是作为产品，复盘应该不忘初心。
虽然复盘有固定的流程、步骤，但做复盘决不能照抄照搬或套用模板，也不能为了完成任务而应付了事，走走过场。复盘是为了学习和改进，是自己和团队受益的事，如果只做表面功夫，则既浪费时间也没有收获。
在开复盘会议时，通常容易演变成“挑毛病”大会，追究其责任并进行批评教育，这会严重破坏复盘所需的学习气氛，也会让团队失去信心。
与挑错、批评相对应，人们很容易推卸责任，找出各种借口和理由为自己辩护，试图证明自己是对的，至少没有过错。这样将更加破坏学习的氛围，甚至滋长团队内部的不信任、矛盾与冲突。
在做复盘的过程中，需要找出实际与目标之间产生差异的根本原因，并挖掘出经验教训，这需要时间的思考及审慎地分析。快速下结论通常只看到了问题的表象，还没有找到真正的问题，或是只总结出了一次偶然性的因果关系，却误以为发现了规律。
希望今天的内容对你有用～
本文由 @产品陀螺 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。