产品经理应该如何减少上线后的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

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！