这篇文章将和大家分享需求管理系列的最后一篇，学会复盘。复盘的目的在于通过对过往产品策略的回顾，抽离出产品发展的路径，同时与预期路径进行比对，有助于产品经理明确产品目标，同时对偏离的策略进行矫正。

在之前关于需求管理的两篇文章中，我分别阐述了如何进行需求评估以及需求的完整生命周期。

从实际操作来看，这两个环节是显性的，就是说，不管你是刚入门的PM还是资深的PM，这两个模块是跳不过去的。但是往往很多时候症结是出现在极容易被忽略的环节上，这就是为什么这篇我要讲复盘的原因。

复盘这个模块属于后置任务，通常会由于“版本节奏快”被忽略，缺少复盘在产品上表现为反复，可能是前端设计上的，也可能是产品功能甚至架构上的，还有可能是算法上的调整，或者更简单直白的，经常听到周围小白用户评价某APP，怎么XX功能又回去了？各种层级的反复，绝大部分是缺少复盘造成的。

首先，为什么要复盘？

复盘就像是年终总结，就好比每个人年末都会回头想想这一年干了什么，有哪些经验教训一样，产品复盘就是把某个时间节点前的需求回头梳理一遍，看看这段时间需求池的实现进展如何，有哪些insight，或者是哪个产品模块你又产生了新的见解。

复盘是绝佳的反思的机会，产品上的得与失，建议要一条一条列出来，不断深入思考，如果有可能的话，可以与mentor交流下观点。

复盘的目的是获得洞察（insight）。比如新增了某个功能，原本的目的是帮助用户实现A需求，但是经过一段时间发现功能使用率很低，为什么呢？使用成本高？假设该功能在明显的位置，又容易打开，这种情况下，就要考虑用户这个需求是真需求吗？有没有其他的方式让用户实现同样的需求？

这里想要特别强调下 “洞察”对于产品经理的重要性。俞军老师在《为什么多数产品经理都不合格》中提到，A类产品人才的核心能力是洞察力。毕业前我曾在某老牌世界500强外企实习，当时我的director是业内知名的专家，她不断强调的就是insight，不管做多么细微的事，一定要学会用脑，多想想为什么这么做。这个观点对我的冲击和帮助都很大：做好一件事是一种能力，但是知道为什么这样做是更重要的一种能力。而现在我回头去想想到底怎么做产品时，我更认同洞察力才是能力的壁垒。尤其是对于每天都需要大量决策的产品经理来说，必须要不断增强自己的洞察力。

其次，复盘的正确姿态是什么？

接下来我们来看看如何以正确的姿态复盘产品得失。

第一，建立需求池。

要求：每一版的需求按照固定的格式提报，在新版本发版后，及时标注需求的实现情况。分清楚已完成/延迟发版/不能支持的需求，可以用不同颜色或者你偏好的方式标注。

第二，学会给需求划分类型。

要求：可以按照前端、后台、算法划分需求，或者按照你熟悉的模块进行区分。分类型管理。

第三，确认好固定节点建立复盘习惯。

比如，每逢3个版本进行一次复盘，一般情况下，发版的节奏是一个月一个版本，因此可以按照3个月的节奏进行复盘。基于前两点的准备，你最少可以明白这三个月做了多少个需求？都是什么类型的需求？

第四，要结合产品数据和用户反馈综合分析。

要求：数据尽量取到小流量数据，全量数据还有发版稳定后一周左右的数据，按照时间序列分析下看看有没有一些变化。不要迷信数据和反馈，因为小流量的切分策略啊、平台本身的数据波动啊、等等这些，都是影响的因素，不能断章取义的看数据。

最后，如何从复盘中建立insight？

复盘的结论最好用文字沉淀下来

产品经理有一项非常重要的能力就是总结能力。这项能力是需要培养和强化的，最好用可见的形式去约束自己，比如你复盘了几个月的产品路径，得出不少重要的结论，千万不要以为记在脑海里就够了，因为实践表明，你一定会忘记结论。为了避免遗忘和反复，你可以将结论以邮件形式同步给相关成员，或者专门建立一个文件夹存放，再或者写到小本本上，各种方法都可以。

再者，如何能和前辈或者同行进行讨论，会有助于加深理解

在工作中可以尝试与不同模块的同事进行沟通， 同行的交流是很重要的。行业相差太大，沟通的成本会比较高，最好找同一个大部门不同产品线的同事，可以讨论下案例，交换下心得，也许别人会有不同的看法，或者有可借鉴的功能、算法、架构。其实在大公司，可复用的资源是很多的，接口可以调用，方法也能共用，尤其是对于刚入行的产品经理来说，工作前几年建立的关系，往往是你职业生涯的圆心，不要过分纠结于工作范围，多看看别人怎么做。

以上就是需求三部曲的最后一篇文章，关于需求，如果有更多的见解，欢迎大家讨论。

相关阅读

资深产品经理是如何做需求管理的（一）：需求的优先级判定原则

资深产品经理如何做需求管理（二）：需求的生命周期

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