新版本上线前期，产品经理要做那几点事？

原计划上线在上周二的时间，因为BUG与需求的变动时间。我们延期到了本周五的时间。

在新版本提测与第二次提测，我们到底遇到了什么？

今天整理出了下面4点给大家，关于产品经理

在这次新版本上线前的测试工作，我们在UI还原中有几点坑

icon不清晰、图标不清晰问题，如下。你可以看到细节上出现模糊的情况，导致了页面不精致。

交互还原的问题

交互牵涉到用户在产品中操作行为的塑型问题，以跳转、弹窗、加载为例，搞清楚当前页面需要进入下一个页面还是只是一个提示。

以我们测试环境的「应用排行榜」为例

在点击hot交互行为后，出现点赞变形、以及应用没有默认图片导致图片无法加载。

排行榜的交互效果利用前端开放交互效果，我们采取了轮播的方式去表达不同行业应用的排行榜。

采取哪种交互效果，是要考虑开发成本和用户加载成本。

UI中的文案还原导致需求变动的问题

这一点比较有意思的是，大部分的产品经理给到设计过程中的页面可能并不能确定文案。更多的是确定产品信息框架、功能featurelist和业务价值。

如下

改为申请，允许用户提交自己的应用进入设计推荐体验。

但文案改动后，却导致了需求变动。从之前的撰写一份体验报告到变成一个弹窗。需求反而变得更简单了。

由于在测试版本经过2次发版，你可以对比一个好的测试版本只有通过可用、有数据填充的方式才算好版本。

在第一版本由于功能入口缺失，导致无法测试。

在第一版本中由于封面图默认缺失，我们无法判断是系统没有处理封面产生的还是用户没有上传封面。

所以测试版本发出，一定要给到的是可测试版本。而不是连测试数据都没有的版本，因为你根本无法判断是没有去填充数据还是数据本身就无法产生。

除了数据外，还有经过冒烟测试后不出现大的逻辑问题或功能性问题。比如点击支付却跳转到发布文章，点击发布文章缺发布失败。

影响了主功能、以及主要逻辑有问题的都不应该在测试环境出现或降低。辨别功能与需求的区别应该如下：

在测试发版本后，由于在产品使用中也会出现功能不完善、逻辑复杂等问题。

所以建立需求池，建立短期、以及未来需要产品规划的需求。在开发同时建立撰写优化需求。

需求池的管理我之前有一个分享：

一个都不能少，我的需求池协同管理

这里举例：

我们以社区的信息流迭代，减少广告位。新版本由于对内容更加聚焦，要求用户互动与产生有趣的内容问答。

产品使用的功能冲突产生需求变动问题

这一点以社区的2个功能：推荐应用、应用问答。在线上环境的推荐应用是为了满足用户找到有趣的应用去”主动“分享应用的问题。

但在新版的测试环境中我们将应用问答提出，推荐应用是否应该继续存在的合理性提出了质疑。用户会更愿意主动分享应用还是去以回答的方式推荐某个应用呢？

所以在测试环境上线后，我们抛弃了应用推荐的模式。而是以在问题场景中做应用推荐。

如果团队是靠着产品驱动的，运营依托于产品，产品的延期导致了几乎无法启动。延期造成的是企业或团队增长或变现放缓。

但如果是以社群、运营驱动的产品，则延期是可以考虑的，毕竟产品线的维护与迭代本质不影响企业或团队的增长。

同时要考虑版本中的附加值，这里我们称之为新业务或新功能。若存在这样的附加值，则延期一个迭代周期是比较合理的做法。