对于产品经理来说，只要产品按时在线，任何努力都是值得的。

如果说产品和开能还能对两件事情达成共识的话，那么除了喜欢苍老师之外，另一件一定是痛恨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）投稿发布，转载请注明来源于人人都是产品经理并附带本文链接