1、在Bug管理过程中，Bug的发现即代表诞生，而Bug的关闭则代表结束。注意，这与Bug的真实产生与结束是有区别的。一个Bug显然在发现之前就已经存在，但这种定义方式，对Bug管理是有效且足够的。如果我们一个人在一个时间段能够处理一个Bug，如上流程是很简单的，单线程的操作不会遇到什么问题。但在一个App项目的测试或者运营阶段，我们实际面对的是同一时间段；多Bug出现，而且由不同职责的多个同事协同解决Bug。
2、在这个情况下，我们会遇到很多琐碎而且麻烦的问题，比如：谁来提交Bug？确认Bug？修改Bug？关闭Bug？哪些Bug先解决？哪些Bug后解决？哪些Bug不需要解决？如何能够让团队成员对Bug信息同步？如何能够减少解决Bug的时间？这些问题无疑给管理带来了很多的难题。
3、传统的方式中，当一个用户或者测试人员发现Bug或者问题时，需要做以下事情：用纸或者电脑记录问题，通过邮件将信息反馈到产品负责人手中。这一流程通常需要10-20分钟；而使用有效的bug管理工具，可以实现遇到Bug后，在工具里填写完Bug反馈信息后，即可将问题信息等传递到产品负责人的Bug管理平台上，该流程仅需45秒以内。解决Bug：在解决Bug的流程中，最阻碍开发同学效率的是“Bug复现”问题；当信息不完备时，开发、产品，Bug反馈者通常需要3-5个来回，来确认，在全部精力投入的情况下，平均约耗时30分钟能够确认一个Bug场景。同样，我们选择好的管理工具，可以避免这30分钟的沟通与确认时间成本。
4、我们公司之前也使用过bug管理系统，如果不考虑用户体验要素，这套系统基本上能够满足正常流程：纪录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除。不过有一点麻烦：这个bug管理系统并不是团队每个成员经常登录的系统，这就导致遇到bug时，需要经过“找出收藏的网址→登陆→依照指标输入详情→阶段性查看最新进展”，如果遇到这个bug是用户向你反馈而后你输入到bug系统时，你还需要等几天后给出反馈。这冗长的环节和时间等待，让我有点失去耐心，等到后来遇到用户反馈的bug我往往直接找技术反馈、处理而绕过bug管理系统。这样做肯定会影响到技术人员的开发效率，打断其思路，是非常不好的工作习惯。
5、而我们公司现在直接在手机端的日事清内进行“bug管理”，提bug人员将bug输入到“收集”状态，由产品助理集中处理，视bug具体情况将bug拖拽到其他集中状态。如果拖拽到“确认”，在该bug下添加相应技术人员让其处理，技术人员会在日事清协作系统内收到通知并且bug同步到其收纳箱，方便技术人员集中处理，解决后由技术人员拖拽到“已解决”状态卡片，大大节省了沟通时间。
