已经有好几个月没有更新文章了，昨天晚上登录了一下后台，发现粉丝数还在往上增，很是过意不去，回头要专门总结下为什么我这么懒，连一周一更都做不到。

下半年我又把星图物联网平台和祥云物联网平台的产品工作捡起来了，两个平台的迭代也慢慢进入了正规。在推进产品的过程中，我发现了一个比较有意思的问题，也是所有产品在开发过程中都会遇到的一个共性问题：怎么给开发/测试提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、生产上线、反馈提出人，是一个BUG的完整闭环过程。谁提的BUG，解决后要通知到他，告诉他BUG已经解决。而很多时候我们只做到了生产上线就完了，没有给提出人一个很好的反馈，对于提出人来说不知道BUG什么时候能解决、是否已经解决。而BUG的闭环是一个流程的管理过程，合理、规范的流程能起到一个好的作用，相反只会让这个过程变得越来越无序和不可控。
而BUG闭环中的一个隐性问题就是已解决BUG的复现，产生的原因就不说了，当一个已经解决的BUG在下一个版本再次复现时，给整个团队包括产品、开发、测试带来的影响是非常恶劣的，是用户对团队能力的质疑甚至是否定。所以对于已解决BUG再次复现这个问题我一直持一个很坚决的态度，允许出现BUG，但不允许同一个BUG出现两次，如果出现，那么BUG的闭环过程一定是哪里出现了问题。

BUG管理工具

前两天给子公司的软件提BUG的时候，发现他们和我们目前的方法一样，通过Word文档来管理BUG，这应该是“最通用”的BUG管理工具。我相信一个好的管理工具能更加方便、高效的解决问题，那么你们都在用什么BUG管理工具呢？