管理层要求所有的Bug 都要通过Raid（Product Studio）来跟踪处理。这个看起来很简单的Bug 管理工具是每个员工和其他同事有效协作的重要保证
每个产品都细分模块（Area，SubArea），每个模块都有明确的需求定义者（PM）、开发工程师（Dev）和测试工程师（Tester）这三个角色。一个问题出现了，一定会落实到某个人的头上去跟踪处理，绝不能出现无主的Bug
PM 负责书写的Spec 是这个功能特征（Feature）的合同，以此Spec 来指导开发和测试。当Dev 和Tester 就某个Bug 发生争执的时候，PM 负责给出一个明确的说明
测试不仅仅是Tester 的事情，尽管那是他们的专职工作。研发团队中的所有人每发现产品的问题时候，都有义务把这个问题告知负责这个模块的测试人员去记录跟踪这个Bug，或者干脆自己新建一个Bug 来跟踪
你可以创建一个Bug 指派给自己，以跟踪某件事的处理。比如开发人员把源代码中的某处问题用Bug 记录下来，以后抽出时间来进行处理
团队中的所有人都可以创建、指派和更改Bug 的状态
当你创建一个Bug 的时候，描述一定要足够详细，让下面处理Bug 的人和其他关心这个Bug 的同事能够通过Bug 描述准确的重现这个问题，而不是猜测某些步骤或者跑过来当面问你
通常一个Bug 的处理过程是这样的：
1. Tester 发现一个问题，到Raid 中创建一个Bug，描述这个Bug 的详细信息，比如重现步骤（Repro Step）、错误结果（Result）、期望的改动（Expect）、运行版本等；然后把这个Bug 指派给负责该模块的Dev Lead
2. Dev Lead 判断后把这个Bug 指派给某个特定的Dev
3. Dev 处理掉这个Bug 并返还给原Tester，或者请求PM 给出一个澄清说明
管理层通过Raid 来跟踪整体进度，以及每个员工、团队在其中的贡献
有专人定期给相关同事发出Bug 的状态报告
每个人都可以方便的自助查询Bug 的分布处理情况。Bug 管理系统对所有的团队成员都是毫无保留的敞开大门（除了你不能删除Bug，另外所有的操作都被忠实的纪录下来）
随着时间的推移，管理层要逐步给出明确的Bug 解决指导方针：哪些Bug 是可以不理睬的（Won’t Fix），哪些是可以推迟到下个版本处理（Postponed）。比如在最终Build到来前的几周，也许非常严重的Bug，像数据丢失、程序崩溃之类的也都要推迟到下个版本再解决了。
当一线员工出现争执、无法达成一致意见的时候（尽管这种情况不多见），管理层要快速给出处理意见。