BUG过街,人人喊打

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

对产品经理来说,只要产品能够按时上线,任何付出都是值得的。
——每日心得

如果说产品和开能还能对两件事情达成共识的话,那么除了喜欢苍老师之外,另一件一定是痛恨BUG。但凡是IT相关的,必然对BUG耳熟能详。不过话又说回来,早发现BUG好于晚发现,自己发现好过用户发现。同时,BUG的修复和完善也是产品日臻完美的必由之路,真是令人讨厌的BUG呢。

BUG定义

bug的愿意是臭虫,可见人类对其厌恶之意。现在主要用来描述软件中隐藏着的一些未被发现的缺陷或问题,也算是性相匹配。

bug一般产生在开发过程中,每当开发完成部分开发工作时,测试、产品或设计师需要对开发的阶段输出(测试包)做出评估和测试,由此产生的问题就会属于bug。一些bug可以立即修复,但部分bug可能需要较长的开发周期,于是,在下一个测试包输出阶段,就会产生新的bug。一般情况下,bug需要按照优先级程度来排期解决。

BUG分类

工作中我一般会用三个级别来定义bug级别:严重,一般和轻微。

严重bug:功能无法使用,或者因为部分漏洞导致用户受到了损伤。比如大家在平时使用手机常会遇到的软件闪退,死机等等,均属于严重的bug。

严重bug是不能接受的,产品上线前必须保证没有严重的bug问题(或在一个较低的范围以内)。

一搬bug:问题明显,但不会影响用户的正常使用或者造成损害,一般是功能的实现不彻底或者冗余导致。比如常见的点击按钮第一下无法应,需要再次点击才能激活按钮。或者明显网络环境正常,但账号登陆需要较长的等待时间。
产品上线前期,一般bug总会占据bug问题的大部分,一般bug需要在产品更新迭代的过程中不断修复消灭。

轻微bug:细节问题,用户在正常使用状态下不会感知,比如图标尺寸,字体颜色等问题。

轻微bug一般属于需求的实现不彻底或者等同于新需求。在前期的界面开发中,产品经理尽量能够拉上设计师,对开发的相关界面问题做按帧层面的核对,保证开发的实现完全按照设计稿,避免在后期因为界面的调整而浪费精力和消耗士气。

BUG处理

下图是bug处理的一个简图,bug主要由测试提出,由产品评估,有开发解决,缺一不可。

重点说下严重bug的问题处理:一般来说,如果产品想要稳定发版,所有的严重bug都必须解决。但是,实际情况并非如此。
对严重bug,需要分两种情况来讨论:

一是受外界影响的不可控的问题。

比如用户手机死机问题,死机问题一定是手机产品经理认为优先级别最高的问题。由于用户使用手机环境的复杂程度,开发很难完全规避死机的情况。

对于这类问题,就需要规定一个阈值,当手机崩溃率高于这个范围就属于异常,必须处理;低于阈值,会被认为是合理,不必花费太多精力来修复。一般情况下,软件的崩溃率需控制在万分之五以下。比如手机qq一天启动了100W次,那么允许qq每天有100W*5/1W=500次的崩溃情况出现。如果高于这个值就属于异常情况,问题必须处理。

二是内部的核心的可控的逻辑。

比如类似支付宝这种涉及金钱交易的金融软件,产品逻辑相当复杂,可能会有一些闪退崩溃的bug,这些事可以接受的。但是对于内部主要的支付相关逻辑,必须是完美的毫无漏洞的。否则在执行过程中,有任何问题导致了用户金钱损失,都属于重大事故问题。

产品要谨记的是,对一款产品来说,因为软件外部环境以人员交接内部逻辑调整等等原因,bug会一直存在的。bug的修复只是产品迭代的一部分,不能把解决bug作为产品规划发展的方向,行为上的勤奋不能掩盖战略上的懒惰,产品经理的主要目的在产品体验和商业模式中找到平衡点,达到吸引用户和实现商业目的双重目的。

#专栏作家#

无邪,微信公众账号:devillnote,人人都是产品经理专栏作家,迅雷产品经理。关注移动互联网,聚焦产品策划、运营和用户分析。文章不追热点,以产品经理相关为主。

转载请保留上述作者信息并附带本文链接

您的赞赏,是对我创作的最大鼓励。

评论( 5

登录后参与评论
  1. 错别字太多了。。。。。。。。。

    回复
  2. 关于崩溃那个说的不全面。如果QQ因为某个原因一直崩溃,那就完蛋了。所以还需要自我恢复机制。比如我的微博再升级iOS8之后就崩溃了。重启,居然好了。虽然不知道发生了什么。

    回复
    1. 回复

      感谢你的反馈。不过如果软件进入崩溃死循环,一般是个例,如果大面积出现崩溃,并且无法自我修复,说明软件的服务器崩了,客户端和服务器的容错性还需要提升。

    2. 回复

      回复@刺猬一坨:我说的那种一般是数据损坏引起的,比如找张图片改扩展名为doc,双击。

  3. @我的印象笔记

    回复
加载中