作为产品经理，每天都可以从各种渠道收集到各式各样的BUG。因此，我们就成了名副其实的BUG接收器。既然成为了BUG接收器，那么BUG怎么接收，怎么处理，怎么验收就成了我们每天都要考虑的内容。下面我们就从BUG的接收、处理和验收，来讲述BUG的一生。
一、BUG的接收
首先，建立小组的BUGlist，用于提交收集到的BUG。在日常工作中我们发现BUG的渠道非常多，我们自己刷产品、测试人员测试、营销团队推广产品、用户反馈等。有的时候甚至是BOSS在和投资人讨论融资的时候，这个时候发现的BUG简直就是一颗炸弹，测试人员首当其冲。这些BUG都会统一提交到各个产品的手中，然后产品就会用自己的语言来描述BUG的情况和应该展示的情况，其中必要的截图和“应该是”等强调性词语的出现是很关键的。现在就可以提交这些内容到BUGlist，从提交的那一刻起，直到这个BUG彻底被消灭，期间所有的问题都将交由提交者来负责。
二、BUG的处理
BUG在处理过程中，要根据所开发产品的类型进行区分。主要分为WabApp和App。
WabApp
见于WabApp的灵活性，影响流程的BUG必须马上通知技术进行解决，如果不影响流程的类似于UI错误、文字错误、交互不佳等BUG我们可以等积累到一定数量后统一给技术进行交付。
App
对于App来说，有上线前的BUG和上线后的BUG的区别。上线前的版本，BUG主要出现在测试版的App上，因为可以随时修改的特征，我们可以像WapApp开发一样，及时处理严重的BUG，统一处理轻微BUG。对于上线后的BUG，在提交到BUGlist后，对测试版进行测试，如果测试版也出现了同样的问题，说明是测试人员检测上的疏忽，如果BUG没有严重到需要重新发版，那么就可以统一处理。如果BUG严重到需要重新发版，那么迅速交付开发并进行测试，修改后立即上传版本迭代。
三、BUG的验收
BUG的验收就是场景的复现，这个环节需要BUG的负责人亲自确认。在复现的过程中，可能要跑很多前置流程，可能要到后台进行调试，可能需要等待到特定时间、可能需要真实的支付、可能需要多次重复实验，不管验收过程有多么复杂，对于BUG的负责人来说，就必须亲自确认BUG已经修复，并且不再出现。这是一种工作态度，这也是责任心的表现。不能自欺欺人，用借口欺骗自己：“这个BUG应该已经好了。技术说BUG修复了就应该没问题了”。这样的疏忽，这样的借口都很有会给公司造成重大的隐患。是否为一个BUG的生老病死负责，也能判断一个产品人员是否有责任心。
BUG在完成以上三个环节以后，便结束了他的一生，但是这仅仅只是开始，快看下一个BUG已经在路上了，产品人，快去迎接他吧。
