项目管理，本质和项目管理工具无关

管理软件，本质上是对业务的一种抽象及描述，它让业务流程能够自动化。如果业务流程本来就没有梳理清楚，就来开发或实施，结局往往就像国内很多流产的ERP。

管理软件，本质上是解决一种秩序和效率，也就是说，当业务的混乱度还没有达到一种临界点，需要一个所谓的软件来管理时，这时候上它，往往会带来更低的效率。就像一个深山老林的大爷，并不需要一个闹钟来提醒他何时起床(作息时间管理)。

项目管理有个前提，资源稀缺，如人力、时间、资金等。比如，有一个政_府官员，有一笔拨款，于是上了一个政绩项目，这类项目一般不缺资源，所以也不需要进度管理，做啥时候就啥时候，更不用项目管理软件。如果进度拉长可以增加预算，于是得到更多灰色收入，那么效率可能是一种负担。我不是危言耸听，你看中国有多少.gov的僵尸网站？

项目管理 vs 人的管理
其实，标题的意思是，项目管理过程中，关注于项目，还是关注于人。是人适应项目，还是项目适应人。

偏向于人的管理，即人本管理，我认为，对于像软件这种思考型行业更有效。因为思考型行业的管理，本质是人脑的管理，人心的管理。人脑的管理，就是将人的智商充分发掘出来，高效率地工作；人心的管理，就是让员工自动自发、培养其责任感和热情。管理是因为不协调才需要约束，如果大家自动自发、有责任感，还需要把管理挂在嘴边吗？
最好的管理，是员工感觉不到被管理。

任何外在的手段，无非是让其产生压力、恐惧，如被淘汰、降薪、加班，通过这种力来推动项目。但人的效率，只有在充分自由的环境下才能够发挥。引力(激励)比推力更有效。《人件》比任何项目管理工具书，更能从根本上解决问题。
项目的风险，往往来源于人的风险，如沟通不畅，上下不齐心。

信任本身就是一种约束，监督会加强团队的隔阂。
激励比控制更容易规范员工行为。

如果说在项目管理和人的管理间找到一种关系，那就是：设定目标，然后站在执行者的角度考虑问题。
项目管理的前提，是人的管理。人的问题解决后，再来谈管理项目。

项目管理，本质上是关注如何在有限的资源下，达到设定的目标。所以，它涉及到成本管理、进度管理和人力管理等资源方面，范围管理和质量管理等目标方面，以及达成目标所需要的沟通管理和采购管理。

成本管理 打个比方，计算器可以为我们DIY电脑时省钱吗？
人力管理和沟通管理 关键是处理人的关系，关注当事人的利益
范围管理 也许写在纸上大家也就明白了
质量管理 决定于流程和执行力度
采购管理 就看PM的商务沟通水平了

也许，项目管理软件，最后会简化到一个进度管理和任务分配工具，而进度管理，往往Excel甘特图更实用。

当然，我说的是中小型项目，大型、规范的项目和团队，可能就很依赖于项目管理软件来做进度。

完成项目，需要一种方法，这种方法可能就依赖工具，也许工具本身就提供一种方法。工具有一定的使用环境，就如同我以前一篇文章中，谈到的一段经历：

引用

Bug管理，这两年，我们经历了三个阶段。
先说说使用环境吧，因为这是决定一管理软件是否适合的最核心条件之一。
人员 有开发人员和不懂软件的业务人员 问题主要是业务员提出
距离 原来一年大家在一个办公室 后来IT部和业务部分，距离约1km
项目 旅游电子商务网站 包括前台和后台 这类网站重业务和用户体验 技术上没难度

最开始，使用的是Bug管理系统JIRA 用了约一年，基本上是推，业务人员不适应，最后我觉得反馈一个问题很烦琐，自己主动废弃了。
后来，使用Excel，当然这是为bug管理定制的Excel， 执行一个月就觉得不行，因为问题汇总、截图等不方便，简单问题这样汇报似乎也太累。
最后，使用Foxmail邮件 用得非常顺，特别是业务部和我们分开情况下。因为邮件有三个特性很受用：抄送人，延迟执行，贴图。
有些很小并且及时的问题，直接通过QQ完成。
反正，在我们这个小团队，最后一种方式，直到现在都觉得很适合我们。

其实，在Bug管理的背后，有一个非技术支撑：信任。我们的重点不在责任界定、责任追究等和权限有关的事情上，我们只关注目标：问题被及时发现、及时解决，以及解决过程中的低成本协作。

开始应用一款项目管理软件，都存在不习惯、甚至抵触的问题。最难的是改变人的思维习惯，其次才是行为习惯。前者需要有效的培训和辅导，培训的效果，取决于团队成员多大程度的认同而不是会用，后者可能需要痛苦的练习。
所以，不是说软件好，大家就会用。


项目管理 vs 过程管理
能够将这两个概念清晰区分的人，一般都有真正的项目管理经验。
前面说过，项目管理，本质上是关注如何在有限的资源下，达到设定的目标。项目管理，本身和具体开发的实物无关，比如甘特图几乎可以描述任何项目。这就是为什么有些项目还会有产品经理。
过程管理，本质上是实现具体实物所需的步骤或流程，而它和具体实物、以及项目团队关系很大。

我将两者拿出来比较，主要是因为，我觉得项目的成功与否，与采用的过程关系很大，而这在项目管理软件中很难体现。比如开发企业信息系统，要建立数据库：
如果是大项目，可能有专门的DBA负责建库，不需要和谁一个个字段确认。
如果是中小项目，可能是PM或PL负责建库，也不需要其他人确认。最混乱的情况是，各模块开发人员自己建表。
如果是偏产品，小团队，比如我建立过一个流程，对我们很实用：

引用

1、项目经理先和某开发人员沟通需求及业务字段
2、开发人员在一个规范的Excel表格中建表
3、告知经理，review一下字段命名及类型等，微调
4、开发人员在开发数据库中建表
5、建完后告知经理，再次review

这样，把本来建库的繁琐工作授权给开发人员，解放了经理，也提升了他，还保证了质量。过程其实非常敏捷。


项目管理软件及市场
开发管理软件，最核心是有一批精通业务的人，而不是技术。项目管理，本身也是一种业务。如果自己从来没有做过项目管理，或者只是作为旁观者，开发的项目管理软件，往往是一堆毫无价值的代码。

可能有人说，我也带过项目呀？如果你带的一批人，一开始都和你关系不错，直到项目结束，你可能并没有接触到真正棘手的管理。当你的项目组，都是一批有个性、工作性质不同的人，你这时候才会深刻体会到，沟通、协作有多大的挑战，如果再加上一个项目期限，我姑且抛开项目本身的业务复杂性。比如，技术牛人，往往很有个性，喜欢自己来一套，不遵守团队规范，并且不太喜欢主动反馈，因为自我感觉都OK。如果强推规范和流程，往往会埋没一位人才。

还有一种情况，就是大公司的“资深”项目经理，这类人往往受公司高层支撑，比较强势。如果遇到项目组某成员不服管，往往是，要么打入冷宫，要么驱逐出队，而不是站在员工角度，和他沟通。这种行为可以理解，因为找刺头沟通很烦，再说替换他毫不费力。这样的资深的项目经理，往往并没有多少管理经验(管理=管人+管事)，因为权力并不是领导力，权力并不会带来真正高效的的管理：员工主动性、责任心。再说，他并没有利用好资源。如果该队员是他带入的，这样做，是一种对己对人都不负责的行为。对于项目经理的他，选择即责任。

上面的两个例子，说的是管理经验的误解。
如果你真的理解项目管理，那么还有考虑一个问题：我的项目管理经验，或是我的项目管理软件，针对的是哪一类用户。难道它也适用桥梁工程的项目管理？即使是在软件项目管理领域，也有企业软件和互联网软件、嵌入式软件的差别。
在管理领域，软件越通用，往往越没用。

上面说到管理软件应用的临界点，其实，在管理软件市场，也存在一个临界点问题，也就是时机。就像有人说，创新，快一步就是先烈，刚好才是先驱。大家可能看到有很多开源软件活得很滋润，但一定要明白，那是欧美，很成熟的市场。很多行业，业务还没有从混沌走到秩序，管理软件可能都不是很重视，何况软件开发本身的管理。所以，打开这个市场很难。

当前，很多软件企业还停留想办法如何拉客户赚钱，而不是省钱。对于项目管理软件这类解决效率的工具，可能兴趣并不大。任何产品，只有给客户带来真正可见的价值，才容易推广，才可能在这个市场中持久生存。

其实，在任何产品得到市场认可前，都有一个观念更新的过程，也就是市场培育期。比如，保健品市场，什么90%的男性有不同程度的肾虚，当男性开始怀疑自己某方面功能，觉得真有那么回事时，什么丸什么丹就好卖了。再比如，IBM智慧的地球，成都机场有它的巨幅广告，可能别人想做中国十几年后的生意。

在项目管理软件领域，当前最需要做的，就是普及项目管理理念及方法，而不是编写软件安装、使用文档。

项目管理软件的细分 一个创业型公司，在资源有限情况下，做好一个一站式的项目管理软件，不是很现实。即使是IBM的Rational套装，我们当初也只是用其中一块ClearCase/ClearQuest，并且只是在需求阶段，在开发阶段，还是用CVS和Eclipse集成。项目管理那个甘特图软件，或是后期测试阶段的Bug Tracker，是两个完全不同的场景。如果还在软件里面集成沟通工具、绩效管理，简直就是造孽。

沟通最讲究的就是效率，在项目管理软件里面沟通不太现实，因为这种软件一天可能只打开两次，而沟通需要及时、方便。方便决定于习惯。为了一个项目而培养一种习惯很难。最大的问题是，要撬动所有人的习惯。你在工具上提个问，别人两天后才给你答复，估计热情一下就降下来了。

绩效管理，也就是填写甘特图的工时。它是一个和利益挂钩的东西，如果领导用它就是计算工钱，而不是改进工作效率，大家怎么可能有热情配合，不抵触都很难。

管理工具，越简单越好。告诉团队，翻过这座山(改变用户习惯)，我们就解放了；问题是，翻得过吗？

题后记
本人主要是看到JavaEye一篇帖子《禅道项目管理软件发布1.1版本》，有感而发。
对于像wwccss，这些国产开源软件的开拓者，让人敬佩，也让人担忧。理想是美好的，但我不希望它影响你的生活，特别是你的家庭。

评论

12 楼 一蓑烟雨任平生 2010-07-15  

项目管理没什么艺术可言，技能不到位，经验不够，靠制度和工具也没用。

公司理解的项目管理和项目组理解的项目管理是两个概念，前者侧重过程节点，后者侧重任务。项目经理要同时针对这两类管理要求进行工作，公司层面的项目管理，看中的大的节点和资源成本、以及风险，项目组层面的就是日常的任务看板。项目经理自己不要糊涂就行，把公司层面的项目管理要求，转嫁给项目组成员，那就惨了。

公司层面如果管理的目标很明确，就是要了解各个项目的阶段进展和人力资源情况，收集数据做改善分析用，可以上一个软件，比如MS PROJECT，或者自己做一个填报系统。
项目组层面本质是任务管理，我的意见是先解决项目经理自己的时间和任务管理能力，绝大部分项目经理自己的时间和任务管理都是混乱的，因为软件开发的一些个性，传统的开发方法侧重于过程和专业活动，而将日常的任务和沟通管理忽视。现在的很多开发方法论，要解决的就是任务的细化分解和时间管理，如何做计划、如何开会、如何将任务完成情况显现化，这些跟软件工具关系不大，白板或者EXCEL就足够了。项目经理个人在听那些方法论忽悠之前，还不如老老实实的买本GTD方面的书好好学习一下，怎么管理好自己的事务。

上工具主要解决的是项目各阶段任务与需求的可追溯，能直观的通过视图看到各个层面的任务完成情况，也就是各关联任务的看板，这块靠人工比较困难。

11 楼 zwchen 2010-07-15  

wwccss 写道

但我觉得现在的项目管理软件存在的问题，就是功能不完整。比较流行的项目管理软件，大都只有任务管理，没有需求管理和质量管理。使用起来还得整合多种工具。

你也知道，任何软件就是解决需求或问题的。如果你将“功能不完整”作为你的核心需求，我担心会走入一个误区。
你说的功能不完整，应该是将项目管理相关的活动(Activity)都集成进来，而这本质上是解决一个便利性问题。
1、能否做好一个大而全的工具，对于资源有限的团队，很难。
2、客户是否普遍有这样一个需求，很难说。

需求管理和质量管理，需要管理的，体现在成果物上，就是Word或Excel、UML、原型图等文档，需要的协作工具可能就是一个SVN。

在项目开发中，用企业wiki之类的工具来管理文档，貌似很规范，其实极其不方便(不敏捷)。
当年，我们用Rational SoDA来管理需求文档，最后我发现还没有纯Word来得直接，对我们的需求分析质量也没啥帮助。

如果说项目管理软件在计划管理、任务管理方面有作为的话，需求管理和质量管理我看不到对项目的核心价值。
需求管理，核心是深入业务，和客户多沟通
质量管理，核心是流程管理，过程决定质量

10 楼 wwccss 2010-07-15  

chenlixun 写道

管理是门艺术, 主要还是人的思想问题, 管理者具备良好的管理素质, 公司有健全的管理制度, 工具上的一点差别影响不大.

PS:可惜大多数公司建了制度,依赖工具,无视制度,结果可想而知.

我想现在国内绝大多数的公司制度并不健全，工具也没有，管理人员水平和素质也跟不上。且不要说小公司，就是很多的大公司，同样也存在很多的问题。

9 楼 chenlixun 2010-07-15  

管理是门艺术, 主要还是人的思想问题, 管理者具备良好的管理素质, 公司有健全的管理制度, 工具上的一点差别影响不大.

PS:可惜大多数公司建了制度,依赖工具,无视制度,结果可想而知.

8 楼 wwccss 2010-07-15  

呵呵，鹿鸣兄目前还不是我们团队的（以后也许会:)）。

我觉得bug管理软件，对于团队项目管理的提升作用不大。因为它只覆盖了项目管理的后半部分。所以陈兄所说的用什么bug管理工具，关系不大，比较赞同。因为没有本质的区别。

但我觉得现在的项目管理软件存在的问题，就是功能不完整。比较流行的项目管理软件，大都只有任务管理，没有需求管理和质量管理。使用起来还得整合多种工具。

我们现在也提供项目管理咨询服务，但这不是我们的主要方向。我们目前的计划是通过社区来实现团队的正常运作。

引用

就是太把自己当回事

呵呵，没有觉得伤人，很好的提醒。我们对自己的定位呢，比较清楚。属于有点理想主义，没有太多资源，可以写点代码，做点事情的那种。也算是人生的一种经历吧，不管结果怎么样，我们要坚持下去。

7 楼 鹿鸣 2010-07-15  

我是专职的软件测试人员，至少从我的职业来说，并不是很赞成你里面说的观点。
无论是XP还是scrum，或者其他的敏捷方法，我没有实践过，但是基本的理论等我都在关注，其实在我个人看来，与其说是软件管理，不如说是开发人员的自我管理。
在各种敏捷理论中，我感觉的一些问题是，一是仅仅说了开发人员需要如何做，二是需要客户的直接参与，三是都举的比较小的团队规模，通常不超过10人。
仅从我测试的角度说，在敏捷过程中，测试可以参与的地方不多。XP里面是开发人员在做测试方面的内容，InfoQ上的scrum实施有测试角色，但是定位也很模糊。
现实中我主要做系统测试工作，需要什么？需求和设计文档，我必须有很明确的东西，才可以进行相应的测试工作，比如测试方案、测试用例、测试执行。但是敏捷过程中，大部分的东西都在口头上和代码中，友好的面对测试的内容并不多。
还是感觉大多数的过程，都是给开发人员设计的，并没有考虑到其他角色的存在。比如QA、CM、QC等。当然了，这些角色也许在开发人员认为都是没有必要存在的，但是既然有这样的分工，就一定有其意义。
现在我觉得，大部分的软件工程理论都在实际中有太多的扭曲成分，还没有看到能让我觉得类似银弹的东西。

6 楼 zwchen 2010-07-15  

鹿鸣 写道

我们用的excel本身和你附件给的格式差不多啊。
对缺陷管理这里，我想还是比较有发言权的，51testing的缺陷管理版本人就是版主，也比较关注这些方面的问题。
这么多年，我一直用ClearQuest，其实就是因为CQ几乎隐藏了所有对开发人员无用的东西。
zwchen说的很对，开发人员用缺陷管理软件需要培训，这么多年来，我见到的培训最少的缺陷管理软件就是ClearQuest。
ClearQuest其实配置使用起来是最麻烦的，而且也过于古老，新的软件jira等我不否认比CQ好很多，比如可以把缺陷分配给多人处理。
但是使用软件需要成本，我个人认为，这个成本最好转移到测试人员而不是开发人员，就是测试配置完毕后，仅仅需要开发人员方便的使用，其他麻烦的事情，都在测试方面，因为主要需要使用此软件的是测试而不是开发，开发仅仅需要了解问题并解决，至于缺陷状态时什么，有多少严重问题，有多少缺陷，什么时候需要修改，开发人员的想法很可能是“关我何事”。
所以测试人员需要给开发人员设置方便。
包括TestDirector或jira这样的软件，给开发人员讲解比较麻烦，因为太多的内容不好隐藏，很多时候真的是需要培训才可以的。
ClearQuest则不然，功能相对强大自由，配置繁琐费时，客户端也比较麻烦，但是web端啥都没有，开发人员想折腾都不可能。
通常在ClearQuest上我都按照开发人员姓名或模块和状态（等待处理，再次出现）做查询，就告诉开发，你只要点击自己名字的查询，修改里面的缺陷即可，状态选择按照你的处理模式，已经修改、不是缺陷、暂不修改，别的你不用管也不用动，2分钟完事。
从培训和使用角度，我觉得对开发人员来说，ClearQuest是最简便的。

Excel也一样，我之所以不想用它，也是同样的思想，麻烦事测试做，开发只需要了解哪个问题需要修改。
所以每一轮，我都要检查几个人提交的缺陷是否重复，重复的合并。程序员已经修改的问题直接删除，只留下新问题和没有修改的，这样每轮都需要做很多整理工作。最后写总结，把这些中间过程的缺陷文档合并到一起，就觉得很多了（600+整理为148）。

也许很多人对同样的问题看法也不一样吧。

CQ客户端确实使用简单，但那东西安装比较麻烦，比如License Server；一般公司也买不起，用破解总感觉不放心，如果只是暂时用用倒无妨。

你说的这些细节我都比较认同。不过你说的是细节，也就是方便性提升。
我想，你用易用的Foxmail收信，或是任何一个简陋的邮件客户端，对你写信收信效率并不大。
能够引起震撼的软件，一般是颠覆型创新，而不是改进型创新。

我想表达的是，对于一个项目，其实用什么Bug管理工具，对风险成败，关系并不大。

对于你们以此创业的人，一定要站在宏观角度，来评估自己的产品对客户的价值。很多产品做死了，就是太把自己当回事(如果你觉得我这句话很伤人，我很担心下面就没法沟通)。

你们大概也在考虑做项目管理咨询服务，这我比较认同。都一个行业的，大伙还是希望你们走好。

5 楼 lobbychmd 2010-07-15  

LZ 要多研究下敏捷开发。。 另外 Rational 也没什么好迷信的，小创业团队做出来的工具不一定比它差

4 楼 鹿鸣 2010-07-15  

我们用的excel本身和你附件给的格式差不多啊。
对缺陷管理这里，我想还是比较有发言权的，51testing的缺陷管理版本人就是版主，也比较关注这些方面的问题。
这么多年，我一直用ClearQuest，其实就是因为CQ几乎隐藏了所有对开发人员无用的东西。
zwchen说的很对，开发人员用缺陷管理软件需要培训，这么多年来，我见到的培训最少的缺陷管理软件就是ClearQuest。
ClearQuest其实配置使用起来是最麻烦的，而且也过于古老，新的软件jira等我不否认比CQ好很多，比如可以把缺陷分配给多人处理。
但是使用软件需要成本，我个人认为，这个成本最好转移到测试人员而不是开发人员，就是测试配置完毕后，仅仅需要开发人员方便的使用，其他麻烦的事情，都在测试方面，因为主要需要使用此软件的是测试而不是开发，开发仅仅需要了解问题并解决，至于缺陷状态时什么，有多少严重问题，有多少缺陷，什么时候需要修改，开发人员的想法很可能是“关我何事”。
所以测试人员需要给开发人员设置方便。
包括TestDirector或jira这样的软件，给开发人员讲解比较麻烦，因为太多的内容不好隐藏，很多时候真的是需要培训才可以的。
ClearQuest则不然，功能相对强大自由，配置繁琐费时，客户端也比较麻烦，但是web端啥都没有，开发人员想折腾都不可能。
通常在ClearQuest上我都按照开发人员姓名或模块和状态（等待处理，再次出现）做查询，就告诉开发，你只要点击自己名字的查询，修改里面的缺陷即可，状态选择按照你的处理模式，已经修改、不是缺陷、暂不修改，别的你不用管也不用动，2分钟完事。
从培训和使用角度，我觉得对开发人员来说，ClearQuest是最简便的。

Excel也一样，我之所以不想用它，也是同样的思想，麻烦事测试做，开发只需要了解哪个问题需要修改。
所以每一轮，我都要检查几个人提交的缺陷是否重复，重复的合并。程序员已经修改的问题直接删除，只留下新问题和没有修改的，这样每轮都需要做很多整理工作。最后写总结，把这些中间过程的缺陷文档合并到一起，就觉得很多了（600+整理为148）。

也许很多人对同样的问题看法也不一样吧。

3 楼 wwccss 2010-07-15  

感谢zwchen专门写了这样长的文章来回复，让人感动，谢谢！

有点不太赞同chen兄的是，我觉得项目管理不能单纯靠人。工具的支持是很有必要的。有很多项目做得比较成功，是因为有一个好的项目经理。但如果换了一个项目经理，这个项目就可能over了。所以呢，我的观点，成功的项目管理，不能纯粹靠人。当项目涉及的人比较多的时候，工具的支持就更有必要了。尤其是中国的现状，大大小小的企业，合格的项目经理很少。众多的IT从业人员还是整天在加班来保障项目的完成。或者讲 ，一个好的项目管理工具，可以帮助团队理清项目管理过程，帮助团队成长。

我几年前曾经写过一篇博客，谈到系统和工具的区别。我认为系统是凌驾于人之上，人需要适应系统。而工具是被人来使用的。所以我在开发东西的时候，都喜欢做工具。这一点应该是受unix的设计哲学影响比较大。

项目管理和人的管理。我非常赞同人的管理。之前在alibaba的时候，我们所在的部门有专门的过程改进小组，他们设定了很多的流程。私下里我跟朋友聊，觉得这些流程其实就是对人的一种不信任而设置的。因为小部门很多，一个项目往往需要很多小部门配合才能完成。但小部门的考核又是独立的，不是按照项目来考核。所以大家都首先保障自己的利益，就会出很多问题。怎么解决，流程。当时搞的非常郁闷。

关于项目管理和过程管理，我给我们的软件目前的定位是满足项目管理的核心过程。其他有很多的过程，完全可以由团队自行商定和执行。不能企图通过一个软件来解决所有的问题。

禅道目前采用的管理方式是scrum。scrum我在alibaba学习和使用了三年，然后自己推广执行了大半年。scrum其实是一个非常简单的管理方式，它通过几个核心的实践解决了项目管理过程中的几个核心的东西，比如计划、沟通、反馈、迭代等。自己带过项目，做过开发，做过测试，知道项目管理过程中存在哪些问题。

目前禅道核心的东西三块：需求管理、任务管理和质量管理。涉及的人员主要是产品、开发和测试。其他的辅助的功能，有计划、发布、todo等管理，后面计划增加的有文档管理等功能。其他的一些个性化的功能会通过插件的方式来进行开发。

在国内做开源，如楼主所言，确实很难，大的环境不好。用户基础又很差。我们做开源软件，主要还是兴趣，再者觉得这是个很有价值的事情。我们也在摸索中国环境下开源的发展道路。呵呵，希望可以成为先驱，不能做先烈。:)

chen兄，不知道你用过禅道没有？有空的话，帮忙把把关，呵呵。先谢过了。

2 楼 zwchen 2010-07-15  

鹿鸣 写道

别的不多说，至少缺陷管理上到一定的规模，必须用软件。
个人觉得阈值是50左右，只要一次提交20以上，在修改、验证、再次出现、新缺陷等等，3轮后，你就彻底迷糊哪个缺陷到底处理了没有，特别是可能多人测试重复提交缺陷的时候。

前两天我们就做了一个这样的尝试，去其他地方测试，没有用我们的缺陷管理软件（CQ），直接用excel管理的，我们3个人，后来两个人，最后只有我自己一个人测试一个程序，大约6~7轮，实际缺陷148，但是中间包括整理、重复等缺陷600+，弄的我很晕。

1、我不否认Bug管理系统的价值，项目到了一定规模，用它有时可以提高问题反馈、跟踪、解决效率。

2、Bug管理系统也是一种管理软件，所以在上马它之前，一定要给员工培训其“业务”，比如Bug管理系统可以帮大家解决什么什么问题，有什么什么好处；另外，还有告诉它们实施过程中有什么阻力；然后再告诉他们使用流程。
往往不是Bug系统不够好，而是团队不够规范，比如大家提交问题时马虎、或喜欢口头反馈。

3、Excel可以做成很适用的Bug管理客户端，通过SVN来团队共享，见附件。

4、本文的主题是，如何客观看待项目管理软件，偏管理、偏商业、偏宏观；你说的是微观，是问题的另一个方面。
打个比方，你夸一个MM，你好聪明啊，她回答，难道我不够漂亮吗？

1 楼 鹿鸣 2010-07-15  

别的不多说，至少缺陷管理上到一定的规模，必须用软件。
个人觉得阈值是50左右，只要一次提交20以上，在修改、验证、再次出现、新缺陷等等，3轮后，你就彻底迷糊哪个缺陷到底处理了没有，特别是可能多人测试重复提交缺陷的时候。

前两天我们就做了一个这样的尝试，去其他地方测试，没有用我们的缺陷管理软件（CQ），直接用excel管理的，我们3个人，后来两个人，最后只有我自己一个人测试一个程序，大约6~7轮，实际缺陷148，但是中间包括整理、重复等缺陷600+，弄的我很晕。