Bug管理的经验和实践
Bug管理的经验和实践
作者：Tuenhai 厚朴教育来源：Tuenhai 点击数：132 更新时间：2010-3-13
作者: Tuenhai.com MSN: king#tuenhai.com
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
原文在：http://bugfree.sourceforge.net/ （刘振飞 王春生）
一. 微软的研发管理分工明确
研发人员分工明确．主要的三个角色：ＰＭ（Program Manager)、Dev(Developer)、Tester三者分工明确，接口清晰，PM来定义需求、书写出每个功能（Feature)特性的设计文档（Spec),Dev写代码来实现这个Spec,Tester来测试Dev做出来的东西是否符合PM定义的Spec,三个角色并无必然的上下级关系，只是分工合作来完成某个功能。
有一次,tuenhai对项目的需求作了一些说明，PM竟然把我的说明作为需求，就匆匆进行开发……后来实在没有办法，tuenhai只得撤了他。从某种程度上讲，需求比coding更重要。高阶主管参与需求制定是有必要的，但项目经理绝不能因此偷懒，不写需求。定需求要求相关人员交流讨论多次，各方都满意后，才能进行下一步的开发。如果一个PM为了所谓的赶进度，省略需求，甚至省略文档，如此没有大局观的PM,实在是第一天就应该就地免职。
二. Raid 不仅仅是跟踪软件功能方面的Bug,其他各种问题如需求文档的改动，界面上的错别字，帮助文档的遣词造句问题，某项任务指派等等都可以通过一个Bug来跟踪。
现在公司初创，工作靠自觉，或口头分配，工作过程无记录，工作无法量化考核，这种情况想来就头疼。就一个Bug管理系统，就能提高不少的管理效率。
三. 国内公司对开发这一环节一直很重视，不过需求和测试较弱一点。如果没有很好地对项目或用户需求的真正把握，后面的所有工作都是白费工夫，事倍功半。
需求的重要，前面已有论述，至于测试，小的团队可能没有专职的测试人员，开发人员有时要兼测试工作。测试有一定的专业性，举一个小例子。开发人员有无测试代码在各个平台各个操作系统的兼容性？有可能开发人员压根不知道要进行这样的测试？没有进行严格的测试，产品怎么可以推向市场，由用户去帮我们测试吗？tuenhai没有正式做过开发或测试，但这些流程还是知道的。种种情况，令人忧心。
不单是开发，管理上的一些事情也要走类似“需求，开发，测试”的流程。如果把工作不甚严谨的人撤换掉，公司里可能就只剩几个人……
四. 如果你以前没有用过Bug管理系统，那么一开始的时候也许你会觉得这个工具浪费时间，因为一个测试人员要费神把发现Bug的详细步骤记录下来，有时还要贴一张示意图，这一切不如当面说来得直接。
但是使用一段时间，你们发现BugFree很有用，它忠实地记录着每个问题的处理过程，不断提醒你存在的问题，永远不会丢失和忘记，如果你参与过较大软件项目或产品的研发，就会理解它对软件可持续发展至关重要。
工作方法和过程比结果更重要。现在公司要以1000w的投入，二年后得到5亿的回报，在做这件大事的时候，如果不重视工作方法和工作过程，tuenhai怎么有信心去做好这件事情。1000w的投入，不是儿戏！公司里不少人因为信任我而加盟，如果我不把公司管理工作做好，又怎么对得起这些朋友的信任？
公司人虽然比较多，但清醒者有没有？有几个？
在公司初创期，虽然时间很紧，但不管怎么紧，首先是建立一个高效的管理系统。人有了，管理思想也不缺，但还要一个系统，一个工具来支撑。
第一步是招人，第二步是管理系统，第三步是做好各种实事。
web端Livid,Lexrus，碧轩，桌面端yewuyu，明日帝国，七猫都是高手，董事长pangshengdong长于商业策划，tuenhai 做事还算能抓住重点。作为初创且不出名的公司，拥有这样的人才布局，是相当不错的了。接下来还要引进分类广告的专才和资本运作高手（欢迎与tuenhai 联系 tuenhai.com msn:king#tuenhai.com)。
管理系统，我已经交Livid,Lexus,及BugFree的作者王春生来完成，预计一个月内，他们会给tuenhai一个完美的答卷。
管理系统搭建完成后，就要用这个系统高效组织管理。
五.做好Bug管理，应该是从高层领导到中间层管理人员再到基层人员，都从内心认同其重要性，然后根据自己公司的实际情况制定相关的管理体系和制度，切实执行并逐步形成自己的风格。要实用，不要随波逐流。
tuenhai:我对管理系统的建立是充分认识到其重要性，现在要让所有员工知道我的思考。不可能我一个人去做所有的事情。根据公司实际开发管理系统，更有针对性。可以考虑在BugFree基础上进行开发。或者在员工内部个人 Blog上进行功能扩展，加上工作相关功能。
六.当我决定做BugFree时，脑子里很清楚为什么要做，做成什么模样，应该怎么做，做出来后大家怎么用，每个环节都考虑清楚了。这样真正实现的时候就很快了
tuenhai:也就是需求要非常清晰。对于我们公司现在要做的管理系统，需求还不够清晰。相关人员都都提出自己的方案，然后讨论，脑力激荡。一周或两周的讨论，应该可以定出一个非常清晰的需求。需求定好，项目已经完成一半。
七. 一个好的Bug管理系统要具备以下特征：
1. 可以完备的记录、跟踪Bug的一生，从出生——创建新的Bug,不断成长——记录相关人员寻找产生Bug原因的讨论过程，发育成熟——找到一个处理办法，同时也允许Bug的复活（问题重现），继续其生长过程。
2. 方便的查询功能，快速找到你关心的Bug.
a)最近N个指派给我的Bug
b)最近N个由我创建的Bug
c)各处自定义条件的查询
3. 提供各种Bug的统计信息。比如每个人头上有多少个Bug,到目前为止Bug总数统计，最近一周的Bug曲线图等等。
4. 方便的项目和模块管理。可以有多个项目，每个项目有多个模块，方便增加、删除和修改。
5. 方便的用户管理。作为一个可独立使用的系统，需要能增加、删除用户。
八. 应该用Bug 管理指导原则（guidance）?来替换Bug管理规章制度（rules & regulations）这个词。
所以我认为Bug 管理就是去制定适合自己团队实际情况的Bug 处理流程和指导原则，制定者（管理层）应该起到真正指导的作用，他们要非常清楚下面这些问题的答案：
· 我们需要测试什么：哪些软件（网站）、哪些模块
· 测试人员的分工：什么人负责什么模块
· 测试工具和环境：巧妇难为无米之炊。你不能安排一个测试人员去测某个模块，而没有给他提供必要的软硬件环境
· 测试的进度安排：干这一行加班是不可避免的，但是需要有度，人不是机器，长期的劳累谁都扛不住。如果时间很紧，那只能去抓重点，要有所不为
· 发现一个问题时，如何用Bug 管理工具去创建一个Bug：标题如何写、严重程度、详细重现步骤、错误状况、期望结果、现场附件、这个Bug 去分配给谁
· 当一个Bug 被处理掉时，测试人员应该如何验证并关闭
· 当一个Bug 的解决方法有争议时，谁来仲裁
· 定期的Bug 提醒，比如当前每个人的Bug 情况
· Bug 状态报告：Bug 数目的变化趋势及我们应该采取的行动
· 阶段性的总结反馈：哪些地方我们做的好，哪些做的不好，为什么、如何改进
· … …
没有这样配套的Bug 处理流程和指导原则，再好的工具都将会是一个摆设、甚至是添乱的工具。就像一个乐队有非常出色的各种乐器，但乐队指挥是个外行（就像成龙电影《双龙会》一个镜头），那么演奏出来的一定会是混乱的乐章。
九. 已经陆续谈过微软的Bug 管理指导原则了，这里系统的总结一下：
·管理层要求所有的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，像数据丢失、程序崩溃之类的也都要推迟到下个版本再解决了。
·当一线员工出现争执、无法达成一致意见的时候（尽管这种情况不多见），管理层要快速给出处理意见等等。
十. 我所计划的Bug 管理指导原则是：
·产品（WAP、彩e 或彩信杂志、网站等）中碰到的所有问题都要用BugFree 来跟踪处理
·有一个专职的测试小组
·团队中每个同事发现一个问题时，都有义务去告知相关的人员或者直接创建一个Bug
·需求、开发、测试三个角色的定位要非常明确。特别的，提出需求的人要把需求认真考虑好、细化成文档，然后才能提交正式开发、测试
·发现一个Bug 时，测试人员提交给某个开发小组长，他来负责指派给具体的开发人员；产生争议的时候由需求定义者来出面说明；?矛盾?很大时我来协调和仲裁。Bug 的处理过程都要用BugFree 记录下来：
·每天系统自动通知头上有Bug 的人自己还有几个问题。我会检查这些Bug，看到不合适的地方就去添加我的意见
·每周系统自动通知所有人前一阶段Bug 的整体情况；同时测试小组要汇总上周的Bug测试情况，告诉团队中所有同事哪些模块容易出问题、主要有哪些类型的问题
上面这些我能够作为?硬性要求?的，只能是前两条：
任何人再向开发人员反映问题的时候，开发人员会告诉他们：创建一个Bug 来跟踪
刚刚成了一个测试小组
其余的只能融化在日常工作中，管理层不断在很多细节上要求、甚至亲自示范（比如我会使用不同的产品，发现问题上Bug），去教会大家测什么、如何测、发现问题怎么办、Bug 解决后怎么办。
十一. 关于“数字神经系统”
让一切可以数字化、文档化的 信息被记录下来，为公司的进一步发展和决策提供基础信息支持。该系统可以用八个字来概 括：数据、文档、自助、自动。其表现形式就是一个包括六个子系统的企业内部网：
(1). 员工管理系统 - 每个员工都有唯一的UserID，验证密码后方可登录数字神经系统，访 问公司内部信息，查看上下级关系、每个员工的个人公开信息等，此处学习 SharePoint、 Outlook和Exchange中的员工管理和展示；
(2). 信息管理系统 - 内部的信息发布展示平台，有点象 BBS一样，可发布公司正式通告、 员工也可自由匿名发帖；
(3). Email系统 - 现在Email的重要性对一个企业不言而喻，我们采用免费Qmail来搭建；
(4). 文档管理系统 - 一个集中管理公司所有文档(包括研发过程书写的各种文档)的地方， 学习SharePoint中的文档库；
(5). 源代码管理系统 - 集成优秀且免费的CVS；
(6). BugFree - 虽然网上有免费的Bug管理系统，但是我看后觉得都不好使，和我在微软用 的差别太大，科泰世纪公司的Bug管理系统倒也很像微软的，但是要花钱买。于是决定用PHP+MySQL借鉴微软的研发流程和Bug管理工具自己开发一个，以便对我们开发新网站、声讯软件、客户端软件和公司事务管理中出现的问题进行有效的跟踪处理。
有两种表现形式：
一是Blog的基础上作功能扩展，加上权限，加上评分。
上部导航是我的一些栏目，每月工作，每周工作，每日工作，工作心得；Bug管理，网文收藏，我的简历.还可以包括自定义栏目。
每月工作，每周工作，每日工作帖子作固顶。每个帖子分三部分组成：高阶主管参与的工作计划，工作总结，高阶主管评分。
每月工作，每周工作，每日工作，工作心得四个栏目本组人都可以看到。其他栏目全公司可以看到。
Bug管理用来创建Bug,指派任务，整合BugFree的功能。
右边是一些公共的东东，上部可以是公告区，显示公告或制度等。接着是项目文档，本组成员的Blog地址，我有权限看到的Blog文章等。
另一种表现形式是如同内容管理系统，栏目和Blog形式一样。
作者：Tuenhai 厚朴教育来源：Tuenhai 点击数：132 更新时间：2010-3-13
作者: Tuenhai.com MSN: king#tuenhai.com
版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明
原文在：http://bugfree.sourceforge.net/ （刘振飞 王春生）
一. 微软的研发管理分工明确
研发人员分工明确．主要的三个角色：ＰＭ（Program Manager)、Dev(Developer)、Tester三者分工明确，接口清晰，PM来定义需求、书写出每个功能（Feature)特性的设计文档（Spec),Dev写代码来实现这个Spec,Tester来测试Dev做出来的东西是否符合PM定义的Spec,三个角色并无必然的上下级关系，只是分工合作来完成某个功能。
有一次,tuenhai对项目的需求作了一些说明，PM竟然把我的说明作为需求，就匆匆进行开发……后来实在没有办法，tuenhai只得撤了他。从某种程度上讲，需求比coding更重要。高阶主管参与需求制定是有必要的，但项目经理绝不能因此偷懒，不写需求。定需求要求相关人员交流讨论多次，各方都满意后，才能进行下一步的开发。如果一个PM为了所谓的赶进度，省略需求，甚至省略文档，如此没有大局观的PM,实在是第一天就应该就地免职。
二. Raid 不仅仅是跟踪软件功能方面的Bug,其他各种问题如需求文档的改动，界面上的错别字，帮助文档的遣词造句问题，某项任务指派等等都可以通过一个Bug来跟踪。
现在公司初创，工作靠自觉，或口头分配，工作过程无记录，工作无法量化考核，这种情况想来就头疼。就一个Bug管理系统，就能提高不少的管理效率。
三. 国内公司对开发这一环节一直很重视，不过需求和测试较弱一点。如果没有很好地对项目或用户需求的真正把握，后面的所有工作都是白费工夫，事倍功半。
需求的重要，前面已有论述，至于测试，小的团队可能没有专职的测试人员，开发人员有时要兼测试工作。测试有一定的专业性，举一个小例子。开发人员有无测试代码在各个平台各个操作系统的兼容性？有可能开发人员压根不知道要进行这样的测试？没有进行严格的测试，产品怎么可以推向市场，由用户去帮我们测试吗？tuenhai没有正式做过开发或测试，但这些流程还是知道的。种种情况，令人忧心。
不单是开发，管理上的一些事情也要走类似“需求，开发，测试”的流程。如果把工作不甚严谨的人撤换掉，公司里可能就只剩几个人……
四. 如果你以前没有用过Bug管理系统，那么一开始的时候也许你会觉得这个工具浪费时间，因为一个测试人员要费神把发现Bug的详细步骤记录下来，有时还要贴一张示意图，这一切不如当面说来得直接。
但是使用一段时间，你们发现BugFree很有用，它忠实地记录着每个问题的处理过程，不断提醒你存在的问题，永远不会丢失和忘记，如果你参与过较大软件项目或产品的研发，就会理解它对软件可持续发展至关重要。
工作方法和过程比结果更重要。现在公司要以1000w的投入，二年后得到5亿的回报，在做这件大事的时候，如果不重视工作方法和工作过程，tuenhai怎么有信心去做好这件事情。1000w的投入，不是儿戏！公司里不少人因为信任我而加盟，如果我不把公司管理工作做好，又怎么对得起这些朋友的信任？
公司人虽然比较多，但清醒者有没有？有几个？
在公司初创期，虽然时间很紧，但不管怎么紧，首先是建立一个高效的管理系统。人有了，管理思想也不缺，但还要一个系统，一个工具来支撑。
第一步是招人，第二步是管理系统，第三步是做好各种实事。
web端Livid,Lexrus，碧轩，桌面端yewuyu，明日帝国，七猫都是高手，董事长pangshengdong长于商业策划，tuenhai 做事还算能抓住重点。作为初创且不出名的公司，拥有这样的人才布局，是相当不错的了。接下来还要引进分类广告的专才和资本运作高手（欢迎与tuenhai 联系 tuenhai.com msn:king#tuenhai.com)。
管理系统，我已经交Livid,Lexus,及BugFree的作者王春生来完成，预计一个月内，他们会给tuenhai一个完美的答卷。
管理系统搭建完成后，就要用这个系统高效组织管理。
五.做好Bug管理，应该是从高层领导到中间层管理人员再到基层人员，都从内心认同其重要性，然后根据自己公司的实际情况制定相关的管理体系和制度，切实执行并逐步形成自己的风格。要实用，不要随波逐流。
tuenhai:我对管理系统的建立是充分认识到其重要性，现在要让所有员工知道我的思考。不可能我一个人去做所有的事情。根据公司实际开发管理系统，更有针对性。可以考虑在BugFree基础上进行开发。或者在员工内部个人 Blog上进行功能扩展，加上工作相关功能。
六.当我决定做BugFree时，脑子里很清楚为什么要做，做成什么模样，应该怎么做，做出来后大家怎么用，每个环节都考虑清楚了。这样真正实现的时候就很快了
tuenhai:也就是需求要非常清晰。对于我们公司现在要做的管理系统，需求还不够清晰。相关人员都都提出自己的方案，然后讨论，脑力激荡。一周或两周的讨论，应该可以定出一个非常清晰的需求。需求定好，项目已经完成一半。
七. 一个好的Bug管理系统要具备以下特征：
1. 可以完备的记录、跟踪Bug的一生，从出生——创建新的Bug,不断成长——记录相关人员寻找产生Bug原因的讨论过程，发育成熟——找到一个处理办法，同时也允许Bug的复活（问题重现），继续其生长过程。
2. 方便的查询功能，快速找到你关心的Bug.
a)最近N个指派给我的Bug
b)最近N个由我创建的Bug
c)各处自定义条件的查询
3. 提供各种Bug的统计信息。比如每个人头上有多少个Bug,到目前为止Bug总数统计，最近一周的Bug曲线图等等。
4. 方便的项目和模块管理。可以有多个项目，每个项目有多个模块，方便增加、删除和修改。
5. 方便的用户管理。作为一个可独立使用的系统，需要能增加、删除用户。
八. 应该用Bug 管理指导原则（guidance）?来替换Bug管理规章制度（rules & regulations）这个词。
所以我认为Bug 管理就是去制定适合自己团队实际情况的Bug 处理流程和指导原则，制定者（管理层）应该起到真正指导的作用，他们要非常清楚下面这些问题的答案：
· 我们需要测试什么：哪些软件（网站）、哪些模块
· 测试人员的分工：什么人负责什么模块
· 测试工具和环境：巧妇难为无米之炊。你不能安排一个测试人员去测某个模块，而没有给他提供必要的软硬件环境
· 测试的进度安排：干这一行加班是不可避免的，但是需要有度，人不是机器，长期的劳累谁都扛不住。如果时间很紧，那只能去抓重点，要有所不为
· 发现一个问题时，如何用Bug 管理工具去创建一个Bug：标题如何写、严重程度、详细重现步骤、错误状况、期望结果、现场附件、这个Bug 去分配给谁
· 当一个Bug 被处理掉时，测试人员应该如何验证并关闭
· 当一个Bug 的解决方法有争议时，谁来仲裁
· 定期的Bug 提醒，比如当前每个人的Bug 情况
· Bug 状态报告：Bug 数目的变化趋势及我们应该采取的行动
· 阶段性的总结反馈：哪些地方我们做的好，哪些做的不好，为什么、如何改进
· … …
没有这样配套的Bug 处理流程和指导原则，再好的工具都将会是一个摆设、甚至是添乱的工具。就像一个乐队有非常出色的各种乐器，但乐队指挥是个外行（就像成龙电影《双龙会》一个镜头），那么演奏出来的一定会是混乱的乐章。
九. 已经陆续谈过微软的Bug 管理指导原则了，这里系统的总结一下：
·管理层要求所有的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，像数据丢失、程序崩溃之类的也都要推迟到下个版本再解决了。
·当一线员工出现争执、无法达成一致意见的时候（尽管这种情况不多见），管理层要快速给出处理意见等等。
十. 我所计划的Bug 管理指导原则是：
·产品（WAP、彩e 或彩信杂志、网站等）中碰到的所有问题都要用BugFree 来跟踪处理
·有一个专职的测试小组
·团队中每个同事发现一个问题时，都有义务去告知相关的人员或者直接创建一个Bug
·需求、开发、测试三个角色的定位要非常明确。特别的，提出需求的人要把需求认真考虑好、细化成文档，然后才能提交正式开发、测试
·发现一个Bug 时，测试人员提交给某个开发小组长，他来负责指派给具体的开发人员；产生争议的时候由需求定义者来出面说明；?矛盾?很大时我来协调和仲裁。Bug 的处理过程都要用BugFree 记录下来：
·每天系统自动通知头上有Bug 的人自己还有几个问题。我会检查这些Bug，看到不合适的地方就去添加我的意见
·每周系统自动通知所有人前一阶段Bug 的整体情况；同时测试小组要汇总上周的Bug测试情况，告诉团队中所有同事哪些模块容易出问题、主要有哪些类型的问题
上面这些我能够作为?硬性要求?的，只能是前两条：
任何人再向开发人员反映问题的时候，开发人员会告诉他们：创建一个Bug 来跟踪
刚刚成了一个测试小组
其余的只能融化在日常工作中，管理层不断在很多细节上要求、甚至亲自示范（比如我会使用不同的产品，发现问题上Bug），去教会大家测什么、如何测、发现问题怎么办、Bug 解决后怎么办。
十一. 关于“数字神经系统”
让一切可以数字化、文档化的 信息被记录下来，为公司的进一步发展和决策提供基础信息支持。该系统可以用八个字来概 括：数据、文档、自助、自动。其表现形式就是一个包括六个子系统的企业内部网：
(1). 员工管理系统 - 每个员工都有唯一的UserID，验证密码后方可登录数字神经系统，访 问公司内部信息，查看上下级关系、每个员工的个人公开信息等，此处学习 SharePoint、 Outlook和Exchange中的员工管理和展示；
(2). 信息管理系统 - 内部的信息发布展示平台，有点象 BBS一样，可发布公司正式通告、 员工也可自由匿名发帖；
(3). Email系统 - 现在Email的重要性对一个企业不言而喻，我们采用免费Qmail来搭建；
(4). 文档管理系统 - 一个集中管理公司所有文档(包括研发过程书写的各种文档)的地方， 学习SharePoint中的文档库；
(5). 源代码管理系统 - 集成优秀且免费的CVS；
(6). BugFree - 虽然网上有免费的Bug管理系统，但是我看后觉得都不好使，和我在微软用 的差别太大，科泰世纪公司的Bug管理系统倒也很像微软的，但是要花钱买。于是决定用PHP+MySQL借鉴微软的研发流程和Bug管理工具自己开发一个，以便对我们开发新网站、声讯软件、客户端软件和公司事务管理中出现的问题进行有效的跟踪处理。
有两种表现形式：
一是Blog的基础上作功能扩展，加上权限，加上评分。
上部导航是我的一些栏目，每月工作，每周工作，每日工作，工作心得；Bug管理，网文收藏，我的简历.还可以包括自定义栏目。
每月工作，每周工作，每日工作帖子作固顶。每个帖子分三部分组成：高阶主管参与的工作计划，工作总结，高阶主管评分。
每月工作，每周工作，每日工作，工作心得四个栏目本组人都可以看到。其他栏目全公司可以看到。
Bug管理用来创建Bug,指派任务，整合BugFree的功能。
右边是一些公共的东东，上部可以是公告区，显示公告或制度等。接着是项目文档，本组成员的Blog地址，我有权限看到的Blog文章等。
另一种表现形式是如同内容管理系统，栏目和Blog形式一样。