产品经理应该如何减少上线后的BUG?

1 评论 4553 浏览 5 收藏 12 分钟

编辑导语:作为一名产品经理,在产品上线之前对Bug的测试是至关重要的,轻则影响某一环节,严重的将造成不可逆的流失。因此,产品经理应该如何减少上线后的Bug?作者总结了几个方法以及如何复盘归档,分享给你。

一、bug带来的影响

  • 某游戏因人物属性设置出现bug,导致外挂横行,战力体系崩溃,最终核心用户流失;
  • 某电商平台的优惠券功能出现bug,一夜之间造成千万元级别的损失;
  • 某超大体量的APP最新版本被设置成了3天后过期,但实际上应用市场上已无可更新的版本,差点造成3天后数千万用户无法使用该APP;

版本上线时,我们最担心的一件事情就是出现重大bug,特别对于已拥有大量活跃用户的产品来说,一旦新版本出现严重的问题,可能造成难以挽回的损失。

出现问题后,公司对事故的起因进行调查和追责时,无论因谁而起,我们身为产品的负责人都会难辞其咎,成为主要的责任人或之一,我们将之调侃为背锅。

如果只是偶尔背一次还好,大部分人能够顶得住压力,但如果总是容易出现各种问题,这个时候可能就需要我们反思根本问题出现在哪,其中是否有我们自身的原因?我们在工作中有什么方法可以有效降低bug发生的概率?

刚进入职场的时候,我们应该都经历过背锅这个过程,只是有的人领悟能力强,很快就会找到方法,早早跨过这道坎,而有的人经常做背锅侠,要经历一两年才能找到解决的方法。

惨就惨在,我就属于后面那种,有1年多的时间里,我经常会遇到版本上线后出现的各类问题,不过,幸运的是我从过去的工作中,总结出了几点方法,之后就很少出现上线后出现重大的bug,职场之路也更加顺利,这里想把方法记录一下同时也分享出来,帮助更多的人找到这扇门的钥匙。

二、bug的避免方法

常见的bug大概可以分为3种类型:需求设计的缺陷、功能缺陷、性能缺陷,我们分别来寻找应对方法:

1. 需求设计的缺陷

如果因为我们对需求的调研不充分、理解不深,又或者是设计功能的时候思考不全面,从而导致做出来的逻辑出现漏洞,上线后出现问题,那么这类缺陷的直接责任人就是产品经理。

出现了此情况,说明产品经理没有做好最基本的本职工作,给团队其他成员带来了额外的工作量,这种情况是我们最应该避免和反思的。

产品经理每增加一个功能,都意味着需要投入相应的开发、测试人员进去。如果功能开发完成后发现需求存在缺陷,再回过头来修改,那么至少需要1个开发去返工。

这对于项目的资源是一种损耗,同时也会引来团队其他成员的不满,这种不满进而会导致其他人对产品经理信任度的降低,当产品经理失去了团队成员的信任时,往后的工作将会举步维艰。

如何避免?

(1)提高需求设计的质量

高质量的需求输出物是规避bug的基本保障,做到这点需要有2个要素:

一方面,我们要具备设计出所需功能的能力,这个可以通过竞品调研或大量的项目经验,去积累产品设计的案例库,体验的多了,做到这一点就不会有太大问题。

另一方面,需要我们对功能的逻辑规则描述得足够详尽完整,理论上来说,流程图、原型、需求文档做得越细致,那么bug的数量就会越少。

不过实际工作中经常因为项目的时间有限,很难花大量的时间在原型和文档上面,这种情况下,可以把主要的时间花在核心功能逻辑的思考和描述上面,核心的部分思考越全面、描述越细致越那么需求的质量就会越高。

(2)重视需求调研和确认

前面提到了需求设计的质量,还有比这更为重要的,就是需求的调研和确认。若这一步没做好,则可能造成后面的努力都付之一炬,因为所走的方向错了,最终做出来的功能就会无法满足用户需求,最终造成需求设计上的重大缺陷。

因此,前期需要进行充分的调研,明白用户真实的需求是什么。对于B端的需求来说,通常能够接触到需求方,那么做需求的过程中有不确定的点,可以及时与其进行确认,并邀请其参与到需求评审中来,确认能满足需求后再进入开发阶段。

2. 功能缺陷

还有一类最常见的bug,是开发过程中,因为技术人员自身的原因而产生了bug,我们在这里定义为“功能缺陷”。

这类问题出现后有的产品人会说,这不是产品经理导致的,与我没关系,既然是开发造成的问题就由开发人员去承担。我见到过很多产品人都在工作中有上面这种观念,我个人不是很认同这种思维。

的确,这个观念听起来很合理,谁引起的就由谁去承担,但,在问题出现之前我们真的已经尽好自己的职责了吗?

要知道,雪崩发生之后没有一片雪花是无辜的,我们是一个团队,项目上线后出现了技术bug,会有主要责任人,但通常不是某一个人的责任,而是多个人共同造成的结果,如果密切协作,这类bug大多数情况下都能避免。

如何避免?
除了测试人员要尽到自己的岗位职责外,我们产品其实也能起到很大的作用,只需把控好一个关键节点——就是上线前做好测试环境的验收。

产品经理进行上线前的验收,能够分别从实际业务使用场景和功能实现逻辑的角度去测试,如果时间允许,可以使用测试用例去细致地测,例如功能与产品需求不相符、功能有漏洞这类问题,很多都能及时发现,并提前解决。

3. 性能缺陷

这类bug是最难察觉的,通常情况下测试人员不会特意去测试性能,因为大多数产品的功能并不需要太高的性能,但对于使用频率高或有实时性要求的功能来说,就必须要考虑性能了。

例如大体量电商平台的下单流程,短信、邮件平台的发送流程,这类存在高并发业务的产品功能,都需要考虑性能,一旦性能未达到要求,就会直接影响这些产品的营收,有时会是致命的缺陷。

如何避免?
产品经理在设计功能时,需要根据实际的业务场景去判断这个功能对性能的要求是否高,假如出现高并发、高延迟后对产品的影响有多大。

如果判断出该功能对性能有要求,且性能缺陷对产品的使用会产生很大的影响,那么就需要在需求文档中将性能需求写进去,注明对响应的实时性、功能的并发量有什么要求。

三、bug的复盘归档

前面列举了常见的3类bug,并给出了规避的方法,这些可以让缺陷变得可控,降低bug发生的概率,但是并不能保证上线后就一定不会再出现bug了,因为现实情况并不总是理想化的,实际的工作中存在太多的变量。

万一还是出现了严重的bug,怎么办呢?

每次出现问题后,我们都应该对bug进行复盘:分析bug出现的原因→将问题进行归类→给出解决方案→进行存档

归类后有助于我们举一反三,未来做其他类似的功能时,就能避免类似的问题再次发生了。

例如做电商的订单支付时,出现订单重复支付的情况,原因是服务器因网络延迟没有及时收到第一笔支付成功的回调结果,然后通过限制x秒内不能再次发起支付、系统每3分钟查1次支付结果、自动退款逻辑这3个方法解决了这个问题。

那么在以后做任何涉及到支付的功能时,其实都可以参考上面这3种规避的方法了,这就是bug归类的作用。

存档的作用在于防遗忘和自查,每次记录bug时,如果发现这类bug已经出现过1次了,那么这个时候就能引起反思,以保障下次不会再出这类问题。

四、结语

bug不仅会给产品本身造成影响,也会带来额外的工作量给我们增添烦恼,比解决问题更重要的是能够预测出问题的发生,并提前进行规避,希望通过以上的几点方法能让我们都成为一名“bug终结者”。

如果每次从自己手上的做出来的功能都很少出现问题,那么leader其实会觉察到这是一个靠谱的人,特别在产品初期,将有助于我们实现职场的进阶。

 

本文由 @汪仔9090 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 标准的软件研发流程中,每一步都在帮助产品经理发现问题、解决问题。
    常规流程:需求分析(产品自我检查)——产品需求评审(开发、测试角度发现产品方案问题)——测试案例评审(测试角度覆盖整体案例,包括新功能测试,回归测试,间接影响功能测试)——开发编码(实际编码过程中,极有可能出现在实现需求时,发现产品经理的需求存在需求遗漏或不严谨,需要与产品沟通后,让产品经理发起需求变更流程。)——测试(大量问题在此处发现并修复)——代码评审(技术角度发现代码逻辑BUG)——产品经理验收(上线前验收极其重要)——测试回归(主流程功能回归,确保主流程无问题)——发布——产品生产验证(发布后尽量覆盖验证场景,确保及时发现问题,能够协调修复或者暂缓对外)——业务生产验证(业务产品运营就需求内容进行生产验证)
    每一步都是为了避免生产带BUG上线。如果功能较大,发布后可进行灰度,灰度能够保证验证场景更加全面。最终无问题后全部对外。如果中途出现需求变更,也应该按照变更流程实施,确保变更内容通过需求评审、案例评审。

    综上:减少上线后有BUG不是产品经理一个人的责任,而是整个链路上,所有角色功能努力的结果。因此,如果上线上发布后出现BUG,那每个人都有责任。要用集体、整体的眼光来看待这个问题。只有大家通力合作,才能避免BUG到线上。

    回复