写在前面 /今天就通过这篇文章，和大家分享一下什么是“复盘”，以及如何做好“复盘”。
很多公司（包括我所在的公司），要求员工要按时提交：每日工作总结、每周工作总结、月度述职报告、季度述职报告、半年度述职报告、年度述职报告。所以，我们每个人，每天都在做着复盘。有些是我们意识到的，但更多的是我们无法意识到的复盘。
复盘属于后置任务，通常会由于“版本节奏快”被忽略，缺少复盘在产品上表现为反复，可能是前端设计上的，也可能是产品功能甚至架构上的，还有可能是算法上的调整……各种层级的反复，绝大部分是缺少复盘造成的。
一、 什么是复盘
一个项目，不管是0到1或者是版本迭代，基本都会包含以下几个核心阶段（见下图）。产品复盘就是把每个阶段中的具体工作进行分解，分析每一项工作的进展是否顺利，问题点在哪、以及如何更好的优化。
二、 为什么要复盘
在之前的文章中，我表述了一个观点，“产品经理天然的路线就是走向管理”。而作为走向管理的第一步，就是要会总结得失。就好比每个人年末都会回头想想这一年干了什么，有哪些经验教训一样，产品复盘就是把某个时间节点前的需求回头梳理一遍，看看这段时间需求池的实现进展如何，有哪些insight，或者是哪个产品模块你又产生了新的见解。每一个项目从开始到结束，过程中或多或少都会出现计划之外的突发状况。而复盘就是是绝佳的反思的机会，产品上的得与失，通过一条一条的罗列，不断深入思考，提升自己的总结能力。
产品经理核心的能力之一，就是总结能力，将收集到的需求建议、竞品优势等进行归纳整理，结合项目自身的差异点才能形成自己的需求思路。
复盘的目的是获得洞察（insight）。比如新增了某个功能，原本的目的是帮助用户实现A需求，但是经过一段时间发现功能使用率很低，为什么呢？使用成本高？假设该功能在明显的位置，又容易打开，这种情况下，就要考虑用户这个需求是真需求吗？有没有其他的方式让用户实现同样的需求？
这里想要特别强调下 “洞察”对于产品经理的重要性。俞军老师在《为什么多数产品经理都不合格》中提到，A类产品人才的核心能力是洞察力。不管做多么细微的事，一定要学会用脑，多想想为什么这么做。这个观点对我的冲击和帮助都很大：做好一件事是一种能力，但是知道为什么这样做是更重要的一种能力。
三、 怎么做复盘
前文已经说过，复盘就是对具体工作进行分解，分析问题点和如何改进，以下就任务分解之后的复盘点，进行阐述。我们来看看复盘的正确姿态：
建立需求池
要求：每一版的需求按照固定的格式提报，在新版本发版后，及时标注需求的实现情况。分清楚已完成/延迟发版/不能支持的需求，可以用不同颜色或者你偏好的方式标注。
学会给需求划分类型
要求：可以按照前端、后台、算法划分需求，或者按照你熟悉的模块进行区分。分类型管理。
确认好固定节点建立复盘习惯
比如，每逢3个版本进行一次复盘，一般情况下，发版的节奏是一个月一个版本，因此可以按照3个月的节奏进行复盘。基于前两点的准备，你最少可以明白这三个月做了多少个需求？都是什么类型的需求？
要结合产品数据和用户反馈综合分析
要求：数据尽量取到小流量数据，全量数据还有发版稳定后一周左右的数据，按照时间序列分析下看看有没有一些变化。不要迷信数据和反馈，因为小流量的切分策略啊、平台本身的数据波动啊、等等这些，都是影响的因素。
下面我们来具体看看复盘的模式：
1 项目目标复盘
1.1 项目进度复盘
1.1.1 是否按照原计划交付时间交付？
1.1.2 原计划的需求点实现了多少？哪些需求点没有按计划实现？每一个需求点延后原因分别是什么？
1.1.3 哪些里程碑有延迟，延迟原因是什么？
1.2 项目结果复盘
1.2.1 项目中出现了哪些意外？为什么会出现这些意外？
1.2.2 用户对新增功能点的接受程度和项目规划中的是否一致？
2 需求阶段复盘
2.1 需求定义复盘：
2.1.1 是否提供完整的需求输出，包括：原型、MRD、PRD、UML等
2.1.2 设计师、交互师、开发人员分别对需求是否明确：如果出现需求不明确的情况，将会严重影响项目的进度和质量。
2.1.3 是否对典型用户和使用场景有清晰的描述？
2.2 需求变更复盘
2.2.1 需求变更次数：敏捷开发已经将需求变更的影响降到最低，但是较少的需求变更仍然是项目进展顺利的前提之一。
2.2.2 哪些需求变更影响了项目实际进度
2.2.3 每次变更的原因：领导干预？前期考虑欠缺？需求无法实现？分析每一次的变更原因，可以在后期项目中进行合理的避免。
2.2.4 每个项目成员是否都清晰的知道每一次的变更：只有每位项目成员清楚的了解每次需求变更，并做好充分的沟通，才能保证项目的进度和质量。
2.2.5 项目成员是否能接收需求变更：这就要求每次需求变更，都要和相关人员做好沟通。
3 设计阶段复盘
3.1 是否确定视觉设计的最终审核人？
3.2 UI设计产出是否符合统一标准？
3.3 设计工作是否影响开发工作的进度？影响原因是什么？
3.4 产品设计工作在什么时候，由谁来完成的？
4 开发阶段复盘
4.1 工期评估复盘
4.1.1 开发实施前，是否有充分的时间做工期预估：工期评估一方面是让项目成员能够对项目的整体进度有所准备，也是对项目需求进行详细梳理的过程。
4.1.2 工期预估与实际开发时间是否有差异，及差异原因分析
4.2 开发文档复盘
4.2.1 是否有提供开发文档？
4.2.2 开发文档是否符合规范
4.3 突发状况复盘
4.3.1 是否出现需求无法实现的状况？原因是什么？
4.3.2 是否出现团队成员变动情况？如何应对成员变动？后期如何避免？
4.3.3 是否出现功能模块与需求不符的情况？出现原因是什么？
4.4 Code Review复盘
4.4.1 是如何进行的：包括如何分工，如何复查等。
4.4.2 Code Review结果是什么？
4.4.3 是否严格执行了代码规范？对不规范的代码如何处理？
5 测试阶段复盘
5.1 测试计划复盘
5.1.1 是否有完整、准确的测试用例？
5.1.2 是否有一个测试计划？这样的计划是否有效？
5.1.3 团队是如何测试并跟踪产品开发效果的？
5.2 测试工具复盘
5.2.1 使用了哪些测试工具来帮助测试？是否可以持续使用？
5.2.2 测试的时间、人力和软件/硬件资源是否足够?
5.3 测试结果复盘
5.3.1 哪个功能模块产生的Bug最多，为什么？
5.3.2 哪些BUG出现回滚，原因是什么？
6 上线阶段复盘
6.1 验收复盘
6.1.1 是否进行了正式的上线验收？
6.1.2 在正式发布的过程中是否有出现状况？后续如何避免？
6.1.3 上线前是否和运营、文案进行充分的沟通？
6.1.4 是否检查了数据埋点，数据埋点是否满足运营要求？
6.2 上线后效果复盘
6.2.1 在上线之后是否出现重大bug? 为什么测试阶段没有发现？
6.2.2 产品上线后的问题反馈渠道是否流程？
6.2.3 产品上线后收集到哪些问题反馈？都是什么类型？如何改进？
最后，每次的复盘结果都要形成文字记录，这将是你成长路上的重要积累！
本文参考文章：
杨福伟《产品经理能力进阶：做好复盘》www.woshipm.com/pmd/849428.html
时雨《资深产品经理如何做需求管理（三）：学会复盘》http://www.woshipm.com/pmd/691420.html
转载文章仅供大家学习，不作任何商业用途。
