原计划上线在上周二的时间，因为BUG与需求的变动时间。我们延期到了本周五的时间。在新版本提测与第二次提测，我们到底遇到了什么？
今天整理出了下面4点给大家，关于产品经理。
第一点：关于U交互与UI的还原
在这次新版本上线前的测试工作，我们在UI还原中有几点坑
icon不清晰、图标不清晰问题，如下。你可以看到细节上出现模糊的情况，导致了页面不精致。
交互还原的问题
交互牵涉到用户在产品中操作行为的塑型问题，以跳转、弹窗、加载为例，搞清楚当前页面需要进入下一个页面还是只是一个提示。
以我们测试环境的「应用排行榜」为例。
在点击hot交互行为后，出现点赞变形、以及应用没有默认图片导致图片无法加载。
排行榜的交互效果利用前端开放交互效果，我们采取了轮播的方式去表达不同行业应用的排行榜。
采取哪种交互效果，是要考虑开发成本和用户加载成本。
UI中的文案还原导致需求变动的问题
这一点比较有意思的是，大部分的产品经理给到设计过程中的页面可能并不能确定文案。更多的是确定产品信息框架、功能featurelist和业务价值。
如下：
改为申请，允许用户提交自己的应用进入设计推荐体验。
但文案改动后，却导致了需求变动。从之前的撰写一份体验报告到变成一个弹窗。需求反而变得更简单了。
第二点：有数据才算一个标准的测试版本
由于在测试版本经过2次发版，你可以对比一个好的测试版本只有通过可用、有数据填充的方式才算好版本。
在第一版本由于功能入口缺失，导致无法测试。
在第一版本中由于封面图默认缺失，我们无法判断是系统没有处理封面产生的还是用户没有上传封面。
所以测试版本发出，一定要给到的是可测试版本。而不是连测试数据都没有的版本，因为你根本无法判断是没有去填充数据还是数据本身就无法产生。
除了数据外，还有经过冒烟测试后不出现大的逻辑问题或功能性问题。比如点击支付却跳转到发布文章，点击发布文章缺发布失败。
影响了主功能、以及主要逻辑有问题的都不应该在测试环境出现或降低。辨别功能与需求的区别应该如下：
需求-功能-bug
需求在功能实现前，bug在功能实现后。
需求描述需要实现的功能
bug描述功能实现未满足需求的所在。
比较特殊的还有需求bug。即需求本身存在问题，在按照需求实现之前就能确定功能会存在缺陷，此时就是需求本身存在bug
第三点：测试中的需求变动和迭代优化，耐着性子
在测试发版本后，由于在产品使用中也会出现功能不完善、逻辑复杂等问题。
所以建立需求池，建立短期、以及未来需要产品规划的需求。在开发同时建立撰写优化需求。
需求池的管理我之前有一个分享：
一个都不能少，我的需求池协同管理
这里举例：
我们以社区的信息流迭代，减少广告位。新版本由于对内容更加聚焦，要求用户互动与产生有趣的内容问答。
产品使用的功能冲突产生需求变动问题
这一点以社区的2个功能：推荐应用、应用问答。在线上环境的推荐应用是为了满足用户找到有趣的应用去”主动“分享应用的问题。
但在新版的测试环境中我们将应用问答提出，推荐应用是否应该继续存在的合理性提出了质疑。
所以在测试环境上线后，我们抛弃了应用推荐的模式。而是以在问题场景中做应用推荐。
第四点：要不要延期改BUG加需求？
如果团队是靠着产品驱动的，运营依托于产品，产品的延期导致了几乎无法启动。延期造成的是企业或团队增长或变现放缓。
但如果是以社群、运营驱动的产品，则延期是可以考虑的，毕竟产品线的维护与迭代本质不影响企业或团队的增长。
同时要考虑版本中的附加值，这里我们称之为新业务或新功能。若存在这样的附加值，则延期一个迭代周期是比较合理的做法。
