功能开发测试完,然后就能上线了么?

最近一个功能在上线的时候遇到了点小问题,痛定思痛,决定复盘一下,避免以后出现类似的问题。

 

常规的产品设计流程是需求分析→方案设计→UI设计→开发→测试→上线,然而开发测试完之后,就真的能上线了么?

 

为了回答这个问题,本文围绕着上线环节,总结了一系列问题的清单,大家可以先看看问题,再明确下自己开发测试完的东西是否真的能上线了…

是否满足上线标准

 

首先要确认的是经过验收的功能是否能达到上线标准,核心功能与核心流程是否完善,交互体验如何,视觉还原度如何?

 

除了主要的功能,还需要注意一些小细节,比如文案、iOS与Android的交互统一性等,有些东西还是会产生一些负面影响的,常见的诸如登录与登陆、弹窗上的错别字等…

 

一个功能在开发过程中往往会经过产品、UI、开发这3个职位的协作,中间很有可能会出现信息传递不到位或者出现理解偏差的情况,而测试小伙伴大多关注的是功能层面,所以这些细节最终还需要产品确认一下。

 

其次就是回归测试结束了么,有时候因为代码冲突或者其他种种原因,很有可能导致新的问题出现,所以回归测试是必要环节,要确保大部分主要功能都回归过。

 

然后是Bug list是否都已经清空了,还是说还有一些Bug,有Bug的情况下能不能上线,还是需要把Bug都修复掉再上线?这些需要结合实际情况, Bug本身的严重程度和影响范围再作出最终决策。

 

最后可能需要和技术leader确认下是否所有的功能都已经提交代码、合并分支了,之前的确是遇到过开发忘记提交代码或者出现代码被覆盖的情况…

 

上线策略是怎样的

有时候可能不仅仅只是简单的上个线而已,可能会涉及到AB测试或者灰度发布的情况。

 

如果是AB测试的话,需要提前明确要测试哪个变量,测试组和对照组如何选择,AB测试多久,在什么时候下掉AB测试。

 

灰度发布也是类似的道理,要明确灰度选择的标准是什么,是随机还是按照行为、渠道等条件筛选,上线之后要明确在什么时间、达到什么样的标准之后就可以放大流量或者放弃发布。

 

因为AB测试和灰度发布都会涉及到客户端和服务端,需要相关同事的支撑,所以这些东西需要提前明确下来,然后提前告知队友大概在什么时间需要什么支持,不要临近上线了再去找相关方…

 

数据与埋点准备好了么

这是个大坑,要先确保上线之前想要的客户端数据都有埋点,而且需要保证数据的准确性,等上线之后才发现没有埋点或者埋点有问题,就要再过一两个版本才有数据了。

 

如果上线之后需要搭建数据看板,就需要提前和相关人员沟通清楚需要的属性,比如客户端、版本号、新老用户等字段,不然等最后数据看板搭建好了才发现没有这些字段,就又需要重新走一遍流程了…

上线时间选择好了么

上线时间点的选择在一定程度上会影响着功能的上线,而且这里面还有很多不可控的因素。

 

就客观条件来看,具体的时间点、上线日期这些都是需要考虑的,有的发布可能需要避开一些高峰时间点,而有些发布可能需要赶高峰时间点。

 

此外也可能会有一些突发事件,比如某某的服务器挂掉了,支付系统要升级什么的,如果你的功能恰好依赖对方的服务,那就可能会出问题。

 

除了外部的一些因素,内部的很多因素也是需要考虑的,比如内部依赖的其他系统是否会升级,运维人员是否会请假,是否需要新服务器,这些都可能是坑…

 

关于上线时间节点,一方面需要尽可能的保证上线时间点是可行且安全的,另一方面需要能保证相关方可以及时联系上,万一出现什么问题能及时进行调整。

 

是否需要冷启动

这个问题在上线前就应该考虑清楚,而且应该是已经解决掉了的,不然产品其实是达不到上线标准的。

 

需要冷启动的产品类型比如资讯类、社交社区类、平台类的产品等…

 

以资讯类产品为例,产品上线的时候肯定不能只是空空如也的模块,除此之外什么都没有,这个时候需要先保证用户进来的时候是有内容可以消费的。

 

那第一批内容是什么,从哪里来,如何排序,如何展现,这些都是需要解决的问题。

 

常见的解决方案无非是爬虫+人工干预,没有内容自己想办法生产一批,没有用户自己先用一些机器人数据来伪装成用户,再加上运营人员的干预,借此来完成冷启动过程。

 

上线物料准备好了么

很多时候功能不仅仅只是面向用户的,还可能会涉及到其他很多支撑体系,比如客服、销售、运营、渠道等…

 

这个时候就需要准备很多对内或者对外的物料,比如:

  • 面向用户的FAQ;

  • 面向客服、销售、运营的说明文档、操作手册;

  • 面向市场的投放素材;

  • 面向应用市场的描述、截图、图标…

 

如果涉及到上述物料的话,记得提前准备好,不然是没办法按时上线的。

 

通知相关人员了么

上面提到了功能在上线的时候,除了面向用户还需要有内部一系列的支撑,这个时候就需要提前和相关部门的相关人员进行沟通,比如:

  • 涉及到法务问题需提前和法务进行沟通;

  • 涉及到财务问题需提前和财务进行沟通;

  • 涉及到运营推广需要提前和运营小伙伴沟通;

  • 涉及到客服…

  • 涉及到销售…

  • 等等…

 

一句话总结就是需要提前通知到所有可能的干系人,提前预约好相关的资源。

 

是否有上线预案

上线成功,没有出现什么问题固然很好。问题是万一上线失败了,有没有什么紧急的预案或者Plan B…

 

比如万一需要版本回滚的话,需要回滚到什么版本,涉及到的用户范围有多广,影响的范围会有多大?

 

万一遇到一些紧急的问题,客户端发包周期又比较长,有没有什么东西是可以走服务端配置,能及时进行处理或者告知到用户的。

 

如果出现用户大规模涌入,服务器能否承受的了这么大的压力,又或者是可能会出现大规模的审核任务、用户投诉,那审核人员和客服人员能否承接住。

 

平常的功能上线可能不需要考虑这些问题,如果上线的是比较重大的功能,覆盖用户范围又比较广,而且可能会产生重大影响的,就要提前考虑下这些问题了。

 

其他一些问题

 

不知道怎么归类的,都放到了其他里面。

 

有的时候需要上线的服务会依赖于其他部门的其他服务,这个时候在上线前就需要确保这些依赖的服务都已经上线,不要等到了生产环境才发现有些依赖服务还没上线。

 

有时候也会涉及到数据备份或者数据迁移的问题,这些操作需要在上线之前就保证能够完成。

 

除此之外,还有一件很头疼的事情,那就是版本兼容。不同用户的新版本接受程度是不一样的,这就会遇到某些版本的客户端不支持某功能的问题。

 

一种处理方式是旧版本直接不支持该功能,提示引导用户去下载,不要face一点可以无限弹窗的引导用户去下载,再不要face一点可以强制用户升级,不升级没办法使用。

 

另一种处理方式是用比较平和的方式引导用户更新版本,比如微信之前的两次引导,一次是5.0的版本为了推游戏使用的启动页打飞机功能,一次是小程序准备推出游戏时的跳一跳功能,通过这两个功能让用户争相自发的完成了版本升级。

 

后续待办

对于项目而言,上线之后就结束了,对于产品而言,上线只是新的开始。可能后续还有一些其他的版本规划,也可能暂时只是在摸索,重点在收集用户反馈和行为数据。

 

不管怎样,如果涉及到后续事项或者其他部门支撑的,也都需要提前通知到相关方。

 

小结

 

最后简单的总结下本文,主要是围绕着上线前的一系列问题展开的自问自答,主要问题有:

  • 是否满足上线标准;

  • 上线策略是怎样的;

  • 数据与埋点准备好了么;

  • 上线时间选择好了么;

  • 是否需要冷启动;

  • 上线物料准备好了么;

  • 通知相关人员了么;

  • 是否有上线预案;

  • 其他一些问题;

  • 后续待办;

 

总结来看,这些问题其实都是围绕着人、物、事展开的,具体就是:

  • 人:各路小伙伴,通知到位;

  • 物:各种物料、文档准备到位;

  • 事:各种事项一一确认,提前明确后续需要谁在什么时间提供什么支持。

 

如果上线的功能很重要,又很复杂的话,可以提前列一个上线清单,然后一个个的去跟进,这样就可以避免漏掉一些任务,大概率能保证成功上线了。

 

以上,就是本文的全部内容,愿你有所收获。欢迎斧正、指点、拍砖…

 

产品学习|交流分享

公众号ID:产品经理从0到1


来源:产品经理从0到1,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/61501

发表评论

电子邮件地址不会被公开。 必填项已用*标注

侵权联系
分享本页
返回顶部