1、在Bug管理过程中，Bug的发现即代表诞生，而Bug的关闭则代表结束。注意，这与Bug的真实产生与结束是有区别的。一个Bug显然在发现之前就已经存在，但这种定义方式，对Bug管理是有效且足够的。如果我们一个人在一个时间段能够处理一个Bug，如上流程是很简单的，单线程的操作不会遇到什么问题。但在一个App项目的测试或者运营阶段，我们实际面对的是同一时间段；多Bug出现，而且由不同职责的多个同事协同解决Bug。
2、在这个情况下，我们会遇到很多琐碎而且麻烦的问题，比如：谁来提交Bug？确认Bug？修改Bug？关闭Bug？哪些Bug先解决？哪些Bug后解决？哪些Bug不需要解决？如何能够让团队成员对Bug信息同步？如何能够减少解决Bug的时间？这些问题无疑给管理带来了很多的难题。
4、我们公司之前也使用过bug管理系统，如果不考虑用户体验要素，这套系统基本上能够满足正常流程：纪录、审查、跟踪、分配、修改、验证、关闭、整理、分析、汇总以及删除。不过有一点麻烦：这个bug管理系统并不是团队每个成员经常登录的系统，这就导致遇到bug时，需要经过“找出收藏的网址→登陆→依照指标输入详情→阶段性查看最新进展”，如果遇到这个bug是用户向你反馈而后你输入到bug系统时，你还需要等几天后给出反馈。这冗长的环节和时间等待，让我有点失去耐心，等到后来遇到用户反馈的bug我往往直接找技术反馈、处理而绕过bug管理系统。这样做肯定会影响到技术人员的开发效率，打断其思路，是非常不好的工作习惯。
