复盘是一个不断学习、总结、反思、改进和提升的过程。复盘不是批斗大会，而是在尊重客观事实的基础上，对过去某一阶段的整体回顾，一方面避免下一阶段重复犯一样的错，或少走弯路；另一方面从暴露的问题中发现规律，并再度地提醒自己。

复盘是对过去的事情做一次思维演练。作为产品负责人的时候，我一般会在项目上线后一周内，或系统平稳运行两周后，组织团队成员进行阶段性的项目复盘，主要是为了优化未来的行动策略，以便之后更好的做需求管理和项目管理。

以用户积分体系V1.0为案列，做一次项目复盘。复盘前，我会了解项目进度、计划排期、版本控制和团队协助等情况，并收集大家的问题反馈，做成规范性的项目复盘报告。

复盘中以对事不对人的的原则，通过假设和提问的方式，对问题进行答疑解惑、深层剖析，以便寻求优化方案，为未来的项目做支撑。直白点说，复盘就是让自己与过去做的事进行对话、探讨和审视。复盘常用的方法是GRAI复盘法，即Goal(回顾目标)、Result(评估结果)、Analysis(分析原因)、Insight(总结规律)。 

回顾目标

复盘是围绕目标进行的。复盘的时候，我们需要重新回顾一下最初的目标。当我们把产品规划、项目计划、战略目标、商业价值等设定为里程碑的时候，都要遵循“SMART原则”，即Specific(具体的)、Measurable(可衡量的)、Attainable(可达到的)、Relevant(有相关性的)、Time-bound(有限期的)。

比如我们最初目的是搭建会员激励积分体系，最初目标是确保用户积分体系V1.0按期上线。但在具体实施过程中，实际情况与预期目标会有一定的偏差的，我们可以通过复盘来规避这种偏差，做到有的放矢。 

评估结果

评估需对照原来设定的目标，找出这个过程中的亮点和不足，忠实地还原事实，看目标是否实现。此次亮点之处是：给出借成功的用户发放积分，通过兑换、抽奖的场景，让积分的获取与消耗形成闭环。不足之处是：1.产品整体体验不够友好，有些功能和交互还需优化；2.开发未做单元测试，直接提交SIT问题太多，影响测试进度；3.测试力度不足，数据流和并发验证有待改进。复盘出来的问题都可以重新审视，成功的可以学习经验，失败的可以吸取教训。

分析原因

分析原因是复盘中的核心环节。在分析原因时，以组别的形式，进行产品、设计、开发和测试自查，剖析当前存在的突出问题，问题带来的主要影响，以及对应的解决方案。比如产品可从需求管理的角度来分析原因，开发可从项目进度角度来分析原因，测试可从系统质量的角度来分析原因。

以产品自查为例，当前存在的问题是业务规则优化私下沟通，有些需求对称不到位。造成的影响是测试不清楚规则变动，功能漏测，开发理解不到位，做出来的产品和实际需求有偏差。共同探讨的解决方案是需求改动后群发并告知对应的变动点，需求对称到具体负责人，有问题找产品实时反馈。 

总结经验

复盘后我们要对心得体会和项目行动进行一个总结，并明确哪些要开始做的，哪些要继续做的，哪些要停止做的。此外，复盘需要一个持续跟进的过程，我们要建立问题知识库，在下一阶段复盘时，回顾之前的问题是否得到有效解决。

复盘要养成一种习惯，更要有有仪式感。比较遗憾的是，有些公司的复盘流于表面形式，纯粹的走马观花，有些是连复盘环节都省了。导致之前阶段出现过的错，在下一阶段继续范，有时候还会错得一塌糊涂。 

学习不一定进步，但项目复盘可以。作为产品经理，我们不能一味地低头苦干做产品（忽视复盘），要回头看看以往做过的产品（萃取价值），也要学会把项目复盘当干货来践行。