1. 梳理复盘思路-避免闭门造车
切忌领了任务就去行动，行动前请做好自己的计划！盲目的做一件事，唯熟能生巧尔。不适合应对时刻变换着的需求，更不能从“工具人阶段”，成长为一个有独立思考能力的“产品负责人”。
接到复盘任务的第一时间，我并没有像往常一样拿着就开干。“复盘”这件事不同于其他明确的任务，按着流程做就好。背后可能是领导简单的想让我做这么一件事，也可能是想通过这件事本身，考验我对于这类事情的处理是否达到了预期，再或者想知道我是否有独当一面的能力可以升职加薪向下一阶段迈进。
所以，在和人人都是产品经理社区的校友、师长们交流之后，咱们开始了有条例有方法的去做复盘这件事，特此感谢期间答疑解惑的社区同学和老师们。
1.1 挖掘复盘的原因
复盘为了什么，给谁看，预期是什么？
杜绝瞎琢磨，合理的询问上级，快速落实需求的意图，统一思路！通过和leader的直接交流，我了解到复盘是一个临时决定（可能有原因没明说），一方面给领导看，另一方面给部门反思用。
- 复盘项目给领导过目，汇报工作，
- 复盘项目给部门开会，反思工作。
1.2 整理复盘的思路
想实现什么结果，需要准备什么材料，大致的流程？
给领导汇报，要精炼！本来用Excel表格一个个整理的项目细节，但是考虑到汇报时间和场景优先，咱们选择了采用PPT的形式，简单快捷的汇报“项目概述”、“复盘结果”和“后期规划”这三个点，汇报时间控制在30min内。
- 复盘项目给领导过目，汇报工作。
时间-30min内
地点-领导办公室
场景-拿着PPT宣讲
期望-领导听了很感动，认可了部门的工作（升职加薪）
给同事开会，要接地气！像电视剧里那种死板的开会是不符合我们团队氛围的，而且成员大多是研发同学，所以采用Excel表格罗列项目清单的形式来开会，简单直接的对接到具体细节和研发同学。主要分为四个步骤“肯定项目中的成果”、“指出项目中的不足”、“共同回顾项目历程”和“讨论出具体的的解决方案”。（开会不是拿着鸡毛当令箭，大家都喜欢先给块糖再轻轻打一下，所以先夸再指出问题同事给出解决方案，这样工作才容易开展下去，成为合格的团队管理人员。）
- 复盘项目给部门开会，反思工作。
时间-不限
地点-会议室
场景-按照项目清单，详细聊聊近期情况
期望-在分享项目过程中，总结出潜在的问题，让今后的项目执行过程的变得更好
2. 落实关键流程和产出
2.1 版本管理情况
按照版本去讲，研发容易会议，领导容易理解！一方面，项目周期长细节难以回忆，一年时间这是第一次做复盘，研发同学回忆不起来具体的点很正常；另一方面，领导不关心每个版本具体有啥，列出版本号和主要功能即可。
（1）上线版本（0-1）
这一步列出来上线版本（0-1）中主要的功能项。
- 有什么功能模块？
- 当时的预期是什么？
- 是否达到了预期？
- ……
（2）迭代版本（1-100）
- 有什么功能模块？
- 当时的预期是什么？
- 是否达到了预期？
- ……
值得一提的是，做复盘才知道，好的整理习惯是真的很重要。因为项目比较赶，好多信息没有及时更新到需求池、周报日报甚至SVN和GIT上也没有备注比较细节的需求点，对这次复盘的数据核对造成了一定影响。
可能会存在的文档：版本迭代记录、需求池、产品需求文档、测试用例等
如果你也有敏捷开发（赶进度）的情况，遇到了部分数据对不上的处境。可以去研发同学那里寻求帮助，比如：日报、周报，GIT、SVN，这些上面会有记录。
2.2 项目管理情况
前面的“版本管理情况”，是帮助大家会议的。接下来这个“项目管理情况”，是和部门开会的时候，重点拿出来，大家一起看到文档，所以要做的更细。
（1）预计时间和上线时间
这里的目的是反馈“进度情况”！上线时间总是会被拖延，讨论过很多次也没有解决实际问题，所以借着这次机会，咱们再好好聊聊这件事，集思广益，想想措施。（给领导汇报的时候，这个数据可以酌情改一下，领导一看全都延期了心里会不舒服，所以提前给上级过一下，让大家都舒服）
关于进度管理这块，我非常赞同“新浪网高级产品经理的观点”：
现在的敏捷开发真的是在规划阶段无法保证结果的‘质量’。
1.要把需求/功能进行拆分，确认是短平快项目还是长周期项目，明确优先级及‘关键组件’；
2.拆分后的需求进行排期（设计、开发、测试各个阶段），‘关键组件’及‘前置条件’；
3.如果是短平快的项目那就每天进行20分钟左右的站会，如果是长周期的项目那就进行周例会；
4.实时跟进项目进展，抓住‘关键组件’及‘前置条件’要素；
5.做好沟通、汇报工作，措辞需要精确，清楚，不要出现‘模棱两可’的答案。
（2）功能概述和详细信息
这里的目的是帮助部门同事，回忆跟进XX需求时的过程，一步步反思总结当时“遇到的困难”、“临时解决方案”和“更好的解决方案。”
同时，大家一起评估功能是否达到预期效果，回顾研发过程中遇到的问题、解决方案和建议，为以后处理好同类问题打下基础。
（3）任务类别和优先级
这一步，是总结用的。
任务类别可以看出咱们的研发精力到底主要投入在哪里，分类有“BUG修复”、“功能新增”、“功能迭代”、“界面优化”等。（毕竟总是修复BUG是很有问题的事，要明确咱们投入在哪里了）
优先级是一个见仁见智的东西。俗话说，找10个女人也不能一个月生下孩子。做项目也是，排10个最高优先级也不能一天实现。
对于优先级排布，有太多方法和结论。但是咱们深入想一下，为什么要排优先级。假设订好了一期需求，突然来了紧急需求，这时候就需要优先级！一般就按着优先级高的去做或者加班完成，但是真没有必要啊。
对于紧急需求，一般产品同学能想到“置换优先级低的需求（不紧急的需求）”或者“加班加点完成”。在和中科软的10年资深产品经理聊过后，我认为“紧急需求”的优先级是可以的拆分的，别因为紧急就不去分析他，咱们更要分析这个“紧急需求”，拆分他到底哪里优先级高，是否有替代方案。一级一级拆分下去，自然方案就出来了。可以大幅避免无意义的加班。
3. 关于复盘方法论
3.1 戴明环（PDCA）
戴明环（PDCA）法
P（Plan）计划：产品可靠的目标预测与订定、可靠的计划研拟与确定、可靠的组织与分工
D（Do） 执行：可靠的任务激励、命令与实施
C（Check）查核：产品可靠的评定与评估、可靠的作业管制与稽核
A（Adjust）修正：寻找改良方案使下次计划变得更加完美
出自维基百科-2018年6月19日修订
3.2 六何法（5W1H）
六何法（5W1H、6W）
何人（Who）
何事（What）
何时（When）
何地（Where）
何解（Why）
如何（hoW）
Tip：叫啥名字都可以，5W1H和6W的区别就是对“how”的定义不同罢了，有人偏爱“How”所以叫5W1H，有人偏爱“hoW”所以叫6W。
出自维基百科-2019年9月2日修订
3.2 你自己总结的方案
适合自己的方法才是最好的方法，不然就是邯郸学步，得不偿失。
以上，是“木深”最近做自己所在项目的复盘分析的工作总结时，对“复盘分析”有了一些新的总结与思考，整理后与大家分享，希望有小伙伴一起交流学习。