迭代上线后如何做版本review

看到各类文章告诉产品新人竞品调研如何做，需求评审如何做，怎样写一份合格的PRD...好像没怎么看到过来人聊一聊版本review应该如何做。虽然我也是一个产品新人，但是从最近几次的版本review中还是积累了一点点经验。就以我们的产品（面向海外市场的视频相关App）为例，分享一些我自己的体会吧。

产品在经历了需求收集、竞品分析，需求评审，资源协调，bug调试，终于在最后一刻上线了，你以为终于可以长出一口气了？对于快速迭代的scrum开发团队来说，产品经理有很大一部分工作是在产品上线以后才开始的，包括观察线上版本的数据是否出现异常，版本的功能、feature是否符合预期，是否需要进一步调整和优化等，都需要产品经理来继续跟进。

版本review到底如何做呢？

- 形式

版本review的形式其实并没有限制，可以是产品经理自己review数据，发现异常上报相关人员，也可以是以PPT的形式向团队成员进行汇报等。

- 时间

什么时间做版本review？其实版本review在这个版本上线之前就需要开始准备了。包括版本review涉及的内容，需要收集的数据都需要在版本上线之前就考虑清楚。

版本review到底review些什么？

不同公司不同产品需要review的内容可能不尽相同，针对不同类型的更新，需要review的内容可能也会略有不同。总结了一下，版本迭代中更新的功能主要可以分为以下几类：

1. 新功能

2. 功能完善/bug fix

3. 运营活动

对于运营活动类的功能更新，一般情况下我们会针对活动做专门的活动策划，活动预期以及活动效果的review，这里就不展开说了。今天主要说说针对前两类更新的review。

新功能

对于第一类新功能，我们在功能设计的时候就需要考虑清楚如何评价新功能是否达到了我们的预期效果。需要在哪些地方埋点来收集数据，如何通过收集到的数据来评价新功能是否达到了预期的效果。另外，通过数据的观察，新功能有哪些地方需要再做优化也可以放在版本review来做。

功能完善/bug fix

对于功能完善类的更新，在review的过程中更多的是要考虑以下几个问题。

1. 这次功能完善是针对什么问题进行调整的？

2. 我们需要和之前的版本对比哪些数据？

3. 数据发生了什么样的变化能够说明我们这次的调整是符合预期的。比如我们为了解决某个页面的流失率对功能做了优化和调整，那么对于调整后的版本，这个页面的流失率是不是明显降低就是我们衡量功能完善是否达到预期的标准之一。

4. 数据的变化是因为我们功能的调整引起的还是另有原因？

除了上面提到的功能相关的review，我们也会对一些App的表现和常规的数据进行review。这部分内容视公司和产品而定，可能有些数据不光是在产品review上就行收集和回顾，而是每天都需要关注和review。这里只说一说我在版本review过程中会关注的几个方面吧。

1. App的整体性能，主要包括App是否稳定，crash率是否维持在正常的水平内

2. App的安装卸载比例，安装卸载比例会和产品的质量和体验相关，如果安装卸载比例出现明显变化可能就需要考虑是不是因为版本的更新导致的。当然了，影响安装卸载比例的因素也有很多，比如APP内内容的更新和运营活动的上下线可能都会导致安装卸载比例的变化。

3. 应用商店下载页面的转化率和下载量变化

Tips

版本的数据变化可能会受到各种因素的影响，在版本review的过程中不要孤立的看数据的变化。

这里举个例子来说吧，我们在某个版本中对收藏功能做了一些调整，数据显示在调整后收藏操作的数据明显提升。如果只从这个事件操作数量的上升来看，我们这个更新确实达到了预期的效果，但是后来仔细分析发现，在这个版本上线期间，我们更新了一个成人内容的相关频道（并没有成人内容的视频展示，只是一些相关的介绍和信息），这个内容上的调整导致了大部分用户的收藏行为。对于这类情况，我们在review的时候需要考虑排除其他因素的影响或者避免在同一时间段内引入影响同一个功能的多个变量。

就像刚才说到的，数据的变化会受到各种因素的影响。为了及时了解和分析影响数据变化的因素，产品经理需要在版本上线后及时观察数据的变化，而不是为了review而review。