产品如何复盘迭代

① 一个完整的项目复盘到底要怎么做

复盘，是运营必不可少的能力，小到一次买菜的经历，大到百亿千亿的投资项目，都可以通过复盘来总结规律、提升水平。

一个完整的复盘。包括如下四个步骤：目标回顾、结果陈述、过程分析、规律总结。

彼此坦诚剖析，既不推卸责任，也不妄自菲薄，而是尽可能地呈现一个完整真实的项目流程。每个参与者都有平等的发言权，都能真实地表达想法。

要有专人控制时间和记录要点，开会最忌讳的就是不着边际地开得又臭又长，控制每个部分的时间很重要，另外记录要点也是一种会议成果的输出，有利于总结经验并开展下一步行动。

② 互联网产品复盘方法论

互联网项目经常复盘，对产品的迭代进步，至关重要。不废话，直接来干货。

1.获取信息：关键点法 【在需要复盘的事件中，首先确定需要复盘的关键点• 其次围绕关键点来进行思考和推演】，以下是具体方法步骤

信息：当时现场的外部环境——“有什么”。比如开会时有谁在场，开会的材料有什么，天气怎么样，有没有什么背景信息。

思维：当时现场每个人自己“是什么”的状态。比如自己当时是如何思考的，或者当时大家是如何思考的，或者当时的环境有没有一些社会的潜规则或者大家的共识等等。

情绪：当时现场的人员，情绪怎么样。比如开会的人之间是什么样的相互关系，整体的气氛怎么样，大家的心理状态怎么样？

2>复盘问题参考清单：
1.现在情况如何? 【• 现在做到什么程度？• 当时定的目标是多少?• 现在的结果和目标对比处于什么状态？• 有没有当时没预计到的结果出现?• 有没有当时预计过但实际没出现的情况？】

2.当初是怎么决定的？ 【• 当初决定的时候，是大家达成共识的吗？• 有没有听取其他人的意见？• 有没有让其他人畅所欲言？• 我们当时是如何确定执行目标的?• 支撑我们当初设置目标的依据有变化吗？】

3.执行过程是怎么样的? 【• 是不是完全按照我们的计划执行的?• 为什么××部门没有参加？• 为什么××活动没有做？• 我们做对了什么？• 我们做错了什么？】

3>如何判断复盘结论是否到位？
复盘结论的落脚点是否在偶发性的因素上？
复盘结论是指向人还是指向事？
复盘结论是否能支持多次why或者why not 追问？
是否是经过交叉验证得出的结论？

4>产品决策：

在公司，产品任何一个任务和决策，都要从多方面考虑是否可以执行：公司战略/系统协作/产品功能。
具体逻辑：公司规划/业务规模现状/产品迭代计划/风险评估/用户影响/成本考虑。

③ 产品经理要怎么做一个复盘总结

很多公司（包括我所在的公司），要求员工要按时提交：每日工作总结、每周工作总结、月度述职报告、季度述职报告、半年度述职报告、年度述职报告。所以，我们每个人，每天都在做着复盘。有些是我们意识到，但更多的是我们无法意识到的复盘。

一、 首先，什么是复盘

一个项目，不管是0到1或者是版本迭代，基本都会包含以下几个核心阶段（见下图）。产品复盘就是把每个阶段中的具体工作进行分解，分析每一项工作的进展是否顺利，问题点在哪、以及如何更好的优化。

二、 其次，为什么要复盘

之前的文章中，我表述了一个观点，“产品经理天然的路线就是走向管理”。而作为走向管理的第一步，就是要会总结得失。每一个项目从开始到结束，过程中或多或少都会出现计划之外的突发状况。而复盘就是是绝佳的反思的机会，产品上的得与失，通过一条一条的罗列，不断深入思考，提升自己的总结能力。

产品经理核心的能力之一，就是总结能力，将收集到的需求建议、竞品优势等进行归纳整理，结合项目自身的差异点才能形成自己的需求思路。

三、 最后，怎么做复盘

前文已经说过，复盘就是对具体工作进行分解，分析问题点和如何改进，以下就任务分解之后的复盘点，进行阐述。

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 产品上线后收集到哪些问题反馈？都是什么类型？如何改进？

每次的项目复盘，都是对自己的一次拷问和锤炼，迭代型产品每逢3个版本进行一次复盘，一般情况下，发版的节奏是一个月一个版本，因此可以按照3个月的节奏进行复盘。

最后，每次的复盘结果都要形成文字记录，这将是你成长路上的重要积累！

④ 产品设计之如何做好功能迭代

功能迭代是每个产品同学日常工作的一部分。下边就来梳理一下如何做好一次功能的迭代。

功能迭代定义：在原有功能基础上，再不改变现有功能主逻辑的前提下，针对该功能已知的问题，进行优化和补全。

功能迭代原动力当然是需求，来源方式分类如下：

方式1： 来自用户、客户、业务的反馈。

方式2： 来自数据分析。需要监测用户的每条使用路径是否通畅，对于其中不通的地方加以进一步查找原因和分析。

具体实际中发生的场景如下：

场景1：之前产品设计时未考虑到的场景，多为异常流程。 举个栗子：某同学在设计客户端超时自动锁屏功能时，用户使用账号、密码来解锁。但是未考虑通过微信扫码登录的用户，不会强制设置密码，换言之，微信扫码登录的用户是可以没有密码的，那么这类用户无法通过账号、密码方式来解锁了。

场景2：与该功能强耦合的功能更新了，但该功能未随之更新。 举个栗子：随着产品发展，陆续支持同钉钉、AD、ADFS、OA系统等同步创建用户功能，并且支持扫码登录、统一身份认证等登录方式。之前设计的超时自动锁屏功能，就需要跟随用户登录方式支持更多的解锁方式，而不是简单的使用账号、密码来解锁。

场景3：业务发展或用户使用习惯带来的更多的功能使用场景。 举个栗子：随着产品发展，用户越来越多，用户使用的支付方式也越来越多，微信、支付宝、银联等，那么支付功能就要支持更多的支付方式来扩大支付功能的使用场景。

需要防止的误区：功能上线后，如果评价不好或没人使用，一定要优先复盘该功能的核心场景而不是急着继续拓展功能。举个栗子：公司新开发了一个功能可以统计用户发出去文件阅读时长等数据，上线后无人问津，这个时候需要退回到核心场景，用户是否真的需要文件分发后的数据反馈？而不是急着去做评论、点赞等拓展功能。

Step 1：；分析清楚功能现状与逻辑

找到用户：产品对应用户模型中的哪几类用户会用到这个页面/功能？

流程：这几类用户使用流程是怎样的？

逻辑：产品功能的底层逻辑（业务流程）是怎样的？

Step 2：现在功能出现了什么问题？

现象：哪些用户出了什么问题？

原因：为什么会出问题呢？

影响面：出现问题的pinl和受影响的用户量是怎么样的？

Step 3：如何解决这些问题？

关键点：在业务流程中，找到最关键因素。

多种方案：有没有更多方案？还是只有一种方案？

难度评估：开发难度与效果的选择。可以用四象限法来评估，难度最小，效果最好的。逐步迭代方式。

Step 4：结果如何评定？

考核指标：用什么指标来评估产品的表现？

数据对比：前后的数据对比是如何的？

PS：做功能迭代的时候，往往是迫于一个第三方的压力，产品内心其实并不认同，那么通过数据对比产品可以验证自己的想法的正确性，从而对于第三方不适宜要求进行反击。