7、有问题可以尽管提，即使不是软件有错。这样也是很有益的

　　自己认为某个情况可能是错误，即使最后发现不是错误，而且被打回，那也是好事，因为其他人也会有类似的想法，自己以后可能又会有同样的想法。列出来可以避免大家的重复劳动。

　　值得指出的是，软件本身就提供了“打回”的选项

　　8、在有Bug系统的情况下，大家尽量使用，以避免浪费效率

　　在讨论的问题已经被记录的情况下，交流时只要说个号码即可，节省了时间

　　如果A跟B布置了一项软件修改任务，最好由A记录。如A没有记录，那B就该记录，否则其他人都不会知道，会耽误其他人更新对软件的了解，而且可能会重复提交问题。

　　比如，本人在这里说的原则，都跟大家介绍过很多遍，但没有记录下来，结果屡屡发现有人会完全忘记，以致Bug系统的效率难以发挥。今天才在这里做个记录，终于避免了无谓的重复劳动 ：-）

　　9、不要把每个Bug都置为 严重、重要、紧急

　　Bug是要一个个解决的，总会有轻重缓急的区分，每一个对公司的重要性也不同。如果都置为严重、重要、紧急，那每个Bug都没有区别了，而真正严重、重要、紧急的就体现不出来了。

　　Bug管理软件的设计者设计这些选项是很有道理的。

　　==========================

　　下面结合一些实际，再扩充几点（稍杂乱）：

　　10、我们完成一个项目的诸多任务的管理，同样可以通过Bug管理系统来管理

　　只要把问题的类型设置为Task，同样可以进行管理，其实它们的状态变化、管理方式都是一样的

　　11、善于利用各种查询、排序功能，找出跟自己相关的、紧急的任务

　　Bug管理系统有丰富的查询、排序功能。

　　与某个项目关系不太紧密的人员，实际上只要查看一下跟自己相关的任务即可，比如只查分配给自己的，并按更新时间排序，最近看过的就不用再看了；而被分配较多Task的人员（当然也是关系紧密的人员），可以按优先级排序，来帮助自己安排工作计划。

　　除了查找显式指定优先级的任务之外，每个人还可专门查询指定解决期限的问题，来帮助自己安排工作计划。

　　主管也可以看到当前的任务分配是否均衡，以进行适当的调整

　　12、Bug系统只是个交流平台，诸多事项其实都是可以掌握的

　　Bug系统其实只是个交流平台，使用者都是人，里面的诸多事项其实都是可以掌握、可以商量的。

　　提出Bug，尤其是分配Bug的人，可能并不知道被分派的人是否很忙，于是规定了一个期限，但这个期限在考虑实际情况后，也是可以修改的。

　　有了这样的平台，大家可以一边讨论，一边修改每项任务的优先级、完成期限，一边通过查询、排序来查看当前的安排是否合适。