概括的四大步骤适用于以个人为主体的复盘分析，分析的对象可以是自己、产品或项目。本文主要介绍的方法论是概括的四大步骤，enjoy~

1. 复盘分析的方法论

复盘分析的核心思路，就是戴明环（PDCA）的应用，由此来分析过去某一段时间内产品和项目的工作情况以及成果总结，更重要的是获得可验证的规律/经验。

概括的四大步骤适用于以个人为主体的复盘分析，分析的对象可以是自己、产品或项目。

细分的八大步骤适用于以团队为主体的复盘分析，形式通常是会议，分析的对象可以是产品或项目。

本文主要介绍的方法论是概括的四大步骤（因为使用范围和对象更广，实际应用的频率也会高，Sue过往的工作经验中，有勇气有意识开复盘分析会议的公司和领导不算常见，会有互撕耍锅的情况发生）。

1.1 回顾目标

P-plan，所设定的计划/目标是怎么样的？

大到项目立项，小到版本迭代，我们任何一项工作的开展，都不能忘了初衷和目的。

在工作开展的过程中，应当始终朝着所设定的目标去努力实现。但理想与现实往往都有偏差，有各种各样的因素存在，也有各种各样的情况会出现，最终导致不同结果的发生。

所以复盘分析的第一步，是回顾目标。走到了今天，不妨回过头去看看当初的目标。

1.2 评估结果

D-do，做了什么？执行的情况如何？

结果是既成的事实了。结果的好与差，多好或多差，它需要有一个参照标准来对比的。

我们第一步回顾的目标就是参照物了。

通过对比，会找到目标和实际结果的差距。类似两个数字之间的比大小，情况可分为三种：

• “大于”，结果大于目标，就是指完成的情况比设定的目标要好；
• “等于”，结果等于目标，就是指完成的情况刚好达到设定的目标；
• “小于”，结果小于目标，就是指完成的情况比设定的目标要差。

除了上面的三种情况，还有两种情况需要注意的：

• 一是，目标里面的事项没有做，那结果可视为0，这种情况也属于结果不如目标，但需要单独讨论，是因为差距的原因是根本没有行动，那为什么设定了目标且始终没有行动呢？
• 二是，结果里面的事项是没在目标内的，通俗的说法就是，明明是数字比大小，你却把结果改成了字母，那跟目标（数字）的对比，就不能是单纯的大小了。这说明差距是我们做了目标计划之外的事情，为什么会出现这样的情况呢？

需要强调，关注的重点不是差距的大小，而是出现差距的地方，可以是试着去思考：为什么会出现这样的差距？

1.3 分析原因

check，检查分清对错好坏，找到原因和问题。

通过第二步的对比，找到了差距，那这些差距造成的原因是什么，我们失败了吗？失败的根本原因是什么？如果没有失败，那我们成功的关键因素是什么……这些都需要深入去思考。

对发生过的事情，尤其是特殊时间节点的举措，一一罗列然后进行反思，分析得出的原因要包括主观和客观两个方面的，都要尽量穷尽，且尽量触达最深刻的“根因”。

1.4 总结规律

action，总结经验、吸取教训，得到规律，行动验证，不断循环。

这是复盘分析最重要的一步。上面所有的步骤都是为了得出一般性的规律，形成符合真相的认识。总结规律得出的结论是否正确，最好的方式是检验。

复盘得出的结论是否可靠，必须在复盘的当时做出判断，一般来说可以通过 4 原则来评判：

（1）复盘结论的落脚点是否在偶发性的因素上？

当复盘的结论落脚在偶发性因素上，那一定是错误的。如果复盘没有进入到逻辑层面，没有经受住逻辑的验证，则这样的复盘结论，一定是不可信的。

（2）复盘结论是指向人还是指向事？

复盘的结论如果是指向人，则很可能说明复盘没有真正到位。因为复盘得出的是规律性的认识，而人是具体的，各不相同。

指向事，则复盘到规律的可能性更高。当然，这里的“事”不仅仅是指某件具体的事，而是人之外的事物。不要随意外部归因，比如：“如果出租车司机都开这么慢，那我以后都会迟到”等等，这会将事件引导到阴谋论上。

复盘的结论不是指向人，而是从事物的本质去理解分析，这是验证复盘结论是否可靠的标准之一。

（3）复盘结论的得出，是否有过3次以上连续的 why 或者 why not 的追问？

复盘得出的结论，至少应该有过三次以上的连续的 why 或者 why not 的询问。如果次数不够，也很可能意味着复盘没有找到真正的原因。

探寻问题背后的问题，找出答案之后的答案，这就是追问的目的。

（4）是否是经过交叉验证得出的结论？

“孤证不能定案”是法律上的术语，用来比喻复盘得出的结论通过其他事情交叉验证，也可以为结论的有效性提供一定的保障。

2. 复盘分析的应用和技巧

2.1 对项目的复盘分析

项目复盘的时间：最好在项目结束后的一个星期。这个时间节点，项目刚结束不久，参与项目的人员对项目各情况的印象还比较清楚，比较容易回忆。

项目复盘的参与人员：最好参与过项目的人都能参与进来，在项目开展过程承担关键角色的人员是必须要参与的，例如项目经理、产品经理、研发经理、运营经理等等。

项目复盘的提前准备：通知需参与会议的相关人员，让各自准备相关的材料、邀请一位复盘会议的引导者。

材料包含但不仅限：

1. 文档：版本迭代记录、用户反馈记录等；
2. 数据：过程中的数据、最终的数据等。

项目复盘的阶段流程：

套用上面分享的四大步骤，对项目复盘分析的工作可分成以下3个步骤：

（1）对项目做整体的回顾

这一步将四大步骤中的（1）回顾目标和（2）评估结果进行了合并，从“起点”（目标）到“终点”（结果），对项目进行整体的回顾。

为了避免一上来就“唯结果论”，相互抢功或耍锅，开场应该相对轻松点，可以让大家先来聊聊对项目的理解：

• 项目服务的对象是否符合项目定位的客户/用户？
• 项目开展的过程中我们遇到了哪些机遇？什么挑战？
• 项目取得的成果是否符合我们的期望值？好在哪？差在哪？
• ……

（2）对关键事件进行回顾

项目的起止，有时间线，那自然就会对应有故事线。

过程中发生的各个关键事件，是影响项目运营和项目结果的重要因素，我们应当一一列举并分析。这时候让参与会议的人员提前准备，就很有意义了。

从项目立项开始画一条时间线，在时间线上标注出各个关键的节点，让所有人对应时间点，把自己印象深刻的、对项目当时有影响的事情写在便条上，然后贴上去。

便条需要讲清楚几点：当时发生了什么事，是怎么发生的，造成了什么问题，最后是怎么解决的。

（3）产出团队和个人收获

付出必然会有收获的（这不是一句毒鸡汤）。这里想说的收获，更多的是对人对事的收获。

还是那句话，项目的结果是既成的事实。结果有可能是不如预期的，有可能是刚好达到设想的，也有可能超出预期的，这始终不是关注的重点。

复盘的意义在于总结，找到对项目有贡献的人，肯定和学习ta；总结对项目有利的经验，校验然后放大它。

对人的部分，可以把项目关键角色的人头像贴出来或名字写出来，让大家把跟这个人合作的经历、感受和评价写下来，肯定ta过往对项目的贡献。

对经验的部分，可以从沟通、人员、流程和实践等方面进行收获总结。

2.2 对产品的复盘分析

对产品的复盘，更准确的说法，应该是对版本的复盘。

产品复盘的周期：这需要具体依据产品的版本迭代速度而定。一般是3个版本迭代完就应该进行一次产品复盘。

产品复盘的参与人员：参与版本设计、研发和运营的相关人员，例如产品经理、美术、研发、测试、运营、客服、商务等。

产品复盘的提前准备：通知需参与会议的相关人员，让各自准备相关的材料、邀请一位复盘会议的引导者。

材料包含但不仅限：

1. 文档：版本迭代记录、需求管理表、需求文档、设计图稿、开发文档、测试用例、用户反馈记录等；
2. 数据：版本迭代前一个周期的数据、版本迭代后一个周期的数据。

产品复盘的阶段流程：

同样套用上面分享的四大步骤，对产品复盘分析的工作可分成以下4个步骤：

（1）回顾版本目标

依据准备好的版本迭代记录和需求管理表，先来回顾一下复盘版本的迭代内容，这些内容都是围绕什么重点/目标展开的，属于新增功能还是优化已有功能，这些功能点是服务于哪些人群的，他们的群体特征是什么样的，主要是想满足他们什么样的需求？表层需求是什么？底层需求又是什么？如何验证版本的效果？

所以这就要求我们接到需求后，要对需求进行足够的分析，在设计产品和规划版本的时候，要提前想好验证产品设计的方式，罗列出希望改善的数据/指标。它有可能是营收类指标比如订单金额，也可能是功能使用率的漏斗模型指标，或者用户好感度相关的指标等等。

（2）评估版本结果

用数据说话。将版本发布前后的两个周期进行对比，数据/指标上有哪些变化？版本面向用户的意见反馈怎么样？他们喜欢和认可新版本发布的内容吗？认为还有未被满足的需求吗？或者是还有期待被服务得更好的场景？

（3）分析关键环节

这一步，可以按产品开发生产线的各个节点划分为关键环节，依次可以划分为：需求——设计——开发——测试——上线。

A. 需求

这个环节，主要复盘的内容有以下几项：

1. 需求对接：需求方的需求表述是否清楚？产品经理的需求分析是否准确？
2. 需求定义：需求文档的输出是否完整清晰？设计师、交互师、开发、测试对需求是否了解？

产品经理需求方的对接：

需求变更：需求变更的次数是否频繁？存在需求变更影响到了版本进度？需求变更的原因是什么？需求变更后是否有对文档进行及时的更新？是否做好沟通工作，把需求变更的事宜清楚地传递给相关人员？

B. 设计

这个环节，主要复盘的内容有以下几项：

1. 设计确认：是否有确定视觉设计的最终审核人？
2. 设计标准：UI设计产出是否符合统一标准？
3. 工期进度：产品设计工作在什么时候，由谁来完成的？设计工作是否影响开发工作的进度？影响原因是什么？

C. 开发

这个环节，主要复盘的内容有以下几项：

1. 工期进度：开发实施前，是否有充分的时间做工期预估？工期预估与实际开发时间是否有差异，及差异原因分析。
2. 开发文档：是否有撰写开发文档？开发文档是否符合规范?
3. 突发状况：是否出现需求无法实现的状况？原因是什么？

是否出现团队成员变动情况？如何应对成员变动？后期如何避免？是否出现功能模块与需求不符的情况？出现原因是什么？

D.测试

这个环节，主要复盘的内容有以下几项：

1. 测试计划：是否有完整、准确的测试用例？是否有一个测试计划？这样的计划是否有效？团队是如何测试并跟踪产品开发效果的？
2. 测试工具：使用了哪些测试工具来帮助测试？是否可以持续使用？测试的时间、人力和软件/硬件资源是否足够?
3. 测试结果：哪个功能模块产生的Bug最多，为什么？哪些BUG出现回滚，原因是什么？

E. 上线

这个环节，主要复盘的内容有以下几项：

1. 版本验收：是否进行了正式的上线验收？在正式发布的过程中是否有出现状况？后续如何避免？是否检查了数据埋点，数据埋点是否满足要求？
2. 上线通知：是否有通知到相关人员？上线前是否和运营、文案进行充分的沟通？
3. 发版效果：在上线之后是否出现重大bug? 为什么测试阶段没有发现？产品上线后的问题反馈渠道是否流程？产品上线后收集到哪些问题反馈？都是什么类型？如何改进？

（4）总结版本经验

顺着产品开发生产线的各个关键节点逐一去反思总结存在的问题，得出版本迭代的经验：有哪些错误我们要去改正的？哪些情况可以去避免的？有哪些避免的措施可以做？哪些好的经验和配合我们要继续保持的？

2.3 对个人的复盘分析

同样套用上面分享的四大步骤，对个人复盘分析的工作可分成以下4个步骤：

（大白话的复盘思路就是：我是谁？做了什么？做得怎么样？还能不能更好？）

（1）自我定位

不要用类似“我是xxx项目xx产品的产品经理”这种简单的表述作为你的自我定位，这更准确的说法是“职位/title”，不能算“自我定位”。

试着去描述你在团队/项目中，承担着什么样的角色，这个角色存在的价值是什么？除了在企业的角度上看你作为产品经理的价值，更重要的是在你的理解下，你的价值是什么？你不可替代或难以替代的地方是什么？甚至都可以是你在承担这个角色时的人物性格、人格魅力的自我剖析。

假设Sue作为一名数据型的产品经理，除了负责数据采集、加工、分析；负责整个项目的数据平台搭建，还有应该做到充分理解平台项目业务，为业务增长和用户体验提供数据服务支持，很好地对数据进行应用与实践，优化产品策略和提高业务收入，实现数据驱动、数据赋能的价值。

（2）个人产出

根据自我定位的职责和价值，和你实际的产出进行对比，找出差距。

你在项目发展中，做了什么事情？这些事情对项目的推进有什么作用？

你在版本迭代中，做了什么事情？这些事情对产品的发展有什么影响？

你在整个团队中，贡献的价值是什么？有多大？

简单的说就是：你做了什么？结果怎么样？有哪些亮点？哪些不足？

（3）深入分析

对差距存在的原因进行反思和分析，取得成绩（亮点）的原因是什么？造成问题（不足）的原因是什么？

这里可提供几个参考角度：

1. 依据差距去追查原因：对比往期结果、对比同行分析
2. 分析原因时明辨内外：是自己的努力带来的？外在环境造成的？
3. 厘清线索判定是否可控：可控？不可控？半可控？

 （4）总结成长

可以从以下几个方面，进行思考和总结，帮助自己更好的成长。

A. 工作流程

• 需求方面：需求对接、需求管理、需求设计、需求评审。
• 版本管理方面：周期确认、周期跟进、验收确认、跟进反馈。

B. 产品技能

1. 流程梳理能力：业务流程、页面流程、涉及多角色的跨职能流程；
2. 文档撰写能力：交互设计、页面布局设计、文字表述能力。

C. 工作习惯

1. 是否养成记录工作日志的习惯？
2. 是否养成定期体验产品的习惯？
3. 是否养成关注行业动向的习惯？

产品经理是个综合性要求很强的职位，除了上面简单提到的几个方面外，还有很多需要不断学习的地方：类似企业经营、团队管理、运营推广等等。

以上，是Sue最近做自己所在项目的复盘分析以及个人的工作总结时，对“复盘分析”有了一些新的总结与思考，整理后与大家分享，希望有小伙伴一起交流学习。

项目具体的复盘分析不便分享，跟大家分享一下梳理的学习脑图（https://kdocs.cn/l/sRcLmnp5U?f=131）

本文由 @素小白 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议