在这样的情况下，如果将这个Bug继续划定在某个项目之下，那么他最多只能为一个项目提供帮助，防止该项目再次出现类似的问题。因此我们各项目组间可能经常能看到这样的对话：

　　A：Hi，我们这边发现一个问题，具体是…………这样的，你们有相关经验吗？

　　B：哈哈，这个我们前段时间才遇上过，解决方法是…………那样的。

　　A：谢谢，谢谢！！

　　确实，这样的场景很多，甚至能贯以“项目之间善于交流”的美名，但是如果认真地去思考，这样的场景真的有必要吗？如果有一个自动化的平台，会将这些通用的Bug都公布出来，每个人各取所需进行关注、记录，又怎么会出现这样的对话呢？

　　交流，哪怕是使用最好的方式进行最有效的沟通，始终是有一定的成本的。同时，交流通常是1v1的关系，即便频繁的接触、沟通，一个知识也很难以广播的形式让尽可能多地需要他的人接收到。

　　正因如此，我才认为一个Bug系统的职责远不止记录、处理、关闭Bug，而应该作为一个知识的集散地，在团队的发展中起更大的作用。

　　通用性Bug处理平台

　　前面也提到，对于通用型Bug，平台应该有能力对其进行分发、通告，在这里再详细地总结一下，一个较为完善的Bug平台，在处理通用型Bug方面应该至少有以下的特色：

　　Bug的tag

　　无论系统内置使用怎么样的方式来对Bug进行分类，其分类的维度总会有照顾不周之处。因此在Bug平台中应该引入tag的概念，让每一个Bug都能够有一个或多个tag，使用tag这种通用的方式来标识一个Bug的属性，也进一步方便了灵活的分类。

　　Bug的订阅

　　在Bug有了tag之后，所有拥有相应权限的人都可以订阅其指定的tag的通用型Bug。当一个Bug被提升为通用型Bug时，Bug平台会找到所有订阅了这个Bug拥有的tag的用户，并通过邮件等形式向其发送该Bug报告。而随后Bug的每一个处理环节都会有邮件等形式的广播。

　　Bug的共享

　　在Bug可以被订阅和广播的同时，通用型Bug应该允许每一个有权限（并且此类权限应该放得很宽松）的用户来参与讨论、修补，每一个人都可以提交解决方案，再由相应的QA进行验证后给予实行。这样的效率远大于一个项目的开发人员独自苦苦挣扎，因为很可能有某个人曾经遇上过这个问题，对他来说提供解决方案仅仅是举手之劳。

　　Bug的生命周期

　　当前多数的Bug平台将Bug的状态分为几个阶段，一般是Open -> Resolved -> Closed这样的过程，但这其实远远没有涵盖一个Bug处理过程中应该有的环节。

　　当然作为一个简单、现实为上的Bug系统，其主要环节有以上三者足矣，但是如果需要将Bug平台扩展成一个知识库，就不得不添加更多的环节，以期得到更多的信息：

　　1、Open，Bug的发现阶段，此时创建一个Bug，通常这个动作由QA进行。任何可重现、不可重现、小频率重现的问题都可以进入到这个阶段。

　　2、Reproduce Step Confirmed，Bug的重现步骤被确定，通常由QA提交。在这个阶段的Bug通常是稳定的，至少通过QA提供的重现步骤能大概率地被重现出来。