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

管理软件，本质上是对业务的一种抽象及描述，它让业务流程能够自动化。如果业务流程本来就没有梳理清楚，就来开发或实施，结局往往就像国内很多流产的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，这些国产开源软件的开拓者，让人敬佩，也让人担忧。理想是美好的，但我不希望它影响你的生活，特别是你的家庭。

评论

32 楼 zwchen 2010-07-18  

关于管理中的人性，我引用我的新浪微博中的几条：

引用

今天和一位核心开发人员，沟通了一个多小时，他始终坚持自己的数据库字段命名风格，而不顾项目整体规范，最后我妥协了。作为一个创业型团队的负责人，也许员工的积极性和热情最为可贵，先解决团队生存问题吧。

引用

团队管理应该以员工需求为出发点，将员工需求和目标转化为组织目标。只有尊重了员工需求，才可能调动员工积极型、让员工主动参与。

引用

创业者，谁都逃不出企业生命周期的规律，在企业发展的不同阶段，采用不同的管理策略，如联想的贸工技。千万不要拿成熟大公司的管理来应对处于婴儿期的小公司，浅层次的如考勤、报销制度，小公司特别需要活力、凝聚力。《餐巾纸上的创业课》是本有趣味和深度的书。

31 楼 tuti 2010-07-18  

zwchen 写道

tuti 写道

“软件项目的项目管理，本质和软件无关”
这不是扯淡吗？

以此类推： 家庭装潢的项目管理本质和家庭装潢无关
           汽车研发的项目管理本质和汽车研发无关

“项目管理，本质和软件无关”，此软件不是指我们开发的软件，如OA系统，而是指项目管理工具(软件)，如MS Project。

你说的类推，我也认为是不合理的。具体的项目管理和其业务是高度相关的，一个做建筑工程的项目经理，很难搞定软件的项目管理。

原来zwchen是这个意思。不过这个还需要说吗？ 任何人都知道项目管理所用的软件不是项目管理的本质。
话说回来，其实我看了好几遍，都没看太懂zwchen开篇这贴是中心意思是什么。
好像是想和大家分享软件开发项目管理的本质是什么，来论证管理工具软件不是项目管理本质。

我看了下“禅道”，基本是Scrum的套路（虽然说是不局限于Scrum）。
其实我最近也在关注这个事情，因为我们项目也是Scrum的套路，目前是以Execl+ Jtrac作为项目管理软件。
如果不够用的话，到是要考虑"禅道"了。

30 楼 gigix 2010-07-18  

zwchen 写道

比如开发企业信息系统，要建立数据库：
如果是大项目，可能有专门的DBA负责建库，不需要和谁一个个字段确认。
如果是中小项目，可能是PM或PL负责建库，也不需要其他人确认。最混乱的情况是，各模块开发人员自己建表。
如果是偏产品，小团队，比如我建立过一个流程，对我们很实用：

引用

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

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

这个例子举得特别好，特别有道理
有空的程序员可以去看一本印度阿三写的叫《数据库重构》的闲书，去打听一个北欧佬琢磨的叫Database Migration的玩意

是，项目管理和软件无关，我真的特别想赞同你。
只不过得加上后半句：软件也跟这种项目管理无关

29 楼 zwchen 2010-07-17  

amwiacel 写道

   我有一个问题，就是对于大型的企业业务系统，当大部分成员都不熟悉业务的情况下，是否还是与他们沟通，即人的管理呢？我以前就是这么做的，经理做总体的计划，明细的计划由各各成员去写，可是，最后发现，他们实现的业务功能80%以上不适合。我的观点是，具体的的计划也由经理来做，成员只要按要求实现就是了，就比如在战场上一样，上级要你冲就冲，往左就左，不得违抗！
   PS:我们没什么详细设计文档，只要企业业务文档和需求文档。

你说的人的管理，和我表达的人的管理，不是一个概念。
我指的的人的管理，是尊重人性，比如我们都希望被领导信任、希望领导听取我们的看法；希望领导尊重我们的生活，比如加班应该得到团队的认同，否则不加。

我相信人性都是向善的、友好的；但我也认为人还是有消极的一面，比如不愿意直面困难，如做计划，所以我每周一一定会制定目标和计划，不过制定目标和计划后，一定会和团队商量，问他们还有没改进的地方，得到他们的认同。

所以，对于新手，让他们去梳理业务，不是很现实。不过你可以给他们讲解，每个具体的业务点，让他们参与，这样，他们会感觉到被尊重。他们往往在细节上会给你一些新的看法，主动思考的热情被激化出来了，去代码实现时，自然会很卖力。

命令式单向沟通，会让员工产生抱怨情绪，因为你没有给他承担责任的机会。
为什么很多管理者喜欢命令式单向沟通(某某谁把这个做了，委婉点加个请字)? 可能只是因为他喜欢支配的感觉(权力欲)，但却意识不到。可怕的人性！

当一个管理者把心思放在如何将目标达成，而不是如何让团队按自己的意思执行，他会发现他的团队越来越愿意参与进来。

28 楼 zwchen 2010-07-17  

tuti 写道

“软件项目的项目管理，本质和软件无关”
这不是扯淡吗？

以此类推： 家庭装潢的项目管理本质和家庭装潢无关
           汽车研发的项目管理本质和汽车研发无关

“项目管理，本质和软件无关”，此软件不是指我们开发的软件，如OA系统，而是指项目管理工具(软件)，如MS Project。

你说的类推，我也认为是不合理的。具体的项目管理和其业务是高度相关的，一个做建筑工程的项目经理，很难搞定软件的项目管理。

27 楼 fantasy 2010-07-17  

  任何项目管理工具的推行和使用都需要成本，不同的项目规模和项目多少使用的项目管理软件应该不一样，工具以满足项目管理需要的前提下，尽量轻便，杜绝资源浪费。
  项目少或者项目规模不大的，可以使用Excel进行缺陷管理，方便快捷，培训成本少。（建议楼主的Excel第一个sheel加上各个字段的说明，并不是每一个人写好这张表格的，如优先级如何界定，什么样的BUG为优先级高，修改建议如何写，可以写一个例子，提出日期精确到时还是天，问题的理解如何写等）
  项目多或者项目规模大，建议使用成熟的缺陷管理软件，便于缺陷统计（问题集中在哪，是人的问题，流程的问题还是业务逻辑的问题），集中处理（减少处理成本），缺陷总结（便于后面的人处理问题）。
  很多情况下缺陷问题的解决是能共享到其他项目复用的，比如A项目提出一个缺陷，只需要在系统中搜索下，便能迅速解决问题。
  但是我认为对于像缺陷这种本来不应该存在的问题，需要通过软件来进行管理，本身就是一个风险，应该尽量消除。

26 楼 tuti 2010-07-17  

“软件项目的项目管理，本质和软件无关”
这不是扯淡吗？

以此类推： 家庭装潢的项目管理本质和家庭装潢无关
           汽车研发的项目管理本质和汽车研发无关
           。。。
只要基于常识想想，一种特定领域的项目管理，怎么可能跟具体领域的特殊性无关呢？
一个软件项目管理的策略，组织，流程，方法，技术等等怎么可能去跟家庭装修项目管理一样呢？

要说抽象的项目管理和具体领域无关，那是PMP看多了。

真有心了解这个问题，可以去看一下 温伯格《成为技术的领导者》。
http://book.douban.com/subject/1132623/

25 楼 amwiacel 2010-07-17  

   我有一个问题，就是对于大型的企业业务系统，当大部分成员都不熟悉业务的情况下，是否还是与他们沟通，即人的管理呢？我以前就是这么做的，经理做总体的计划，明细的计划由各各成员去写，可是，最后发现，他们实现的业务功能80%以上不适合。我的观点是，具体的的计划也由经理来做，成员只要按要求实现就是了，就比如在战场上一样，上级要你冲就冲，往左就左，不得违抗！
   PS:我们没什么详细设计文档，只要企业业务文档和需求文档。

24 楼 zwchen 2010-07-16  

zgsheng 写道

一蓑烟雨任平生 写道

说实在话，大部分情况下用软件还不如不用软件。

大家都回家洗洗睡吧.....明天早上起来去找个别的工作吧.

完整的表述：

引用

需求管理和质量管理之类的，说实在话，大部分情况下用软件还不如不用软件。

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

只有知道自己要做什么，怎么来做，人力解决不了的时候才上软件，这个原则是我们给客户上系统时反复强调的，而且工作过程和方法也是基于此原则来展开。对客户这样说，对自己也更要这么要求。
手工能管理好，才能上软件，就是这个意思。根据我这么多年的项目经验，通过导入一个软件来做管理改善的项目，没有看到一个成功的。
管理软件的导入，必须伴随着业务的改善，软件可能固化了一个流程，但是怎么来判断是否合适，怎么来做变更，需要对自身的流程有一个清晰的认识，可惜这块被各种各样的方法论给盖住了，哪有不劳而获的事情。

禅道这样的软件，我觉得它的价值就是能够基于功能点，逐次的将各阶段的工作任务串联起来，能够知道各阶段的任务完成情况，仅此而已，我用excel能做，但是关联起来手工处理难度较大。需求管理和质量管理之类的，说实在话，大部分情况下用软件还不如不用软件。

22 楼 seeckt 2010-07-15  

引用

你和陈兄讨论的一个假设是说项目团队里面要有一个比较好的管理人员。但实际的情况是好的管理人员凤毛麟角。

没有比较好的管理人员，一般好的管理人员也会有吧
没有一般好的管理人员，那么总要拔一些有管理思路萌芽的人员出来
通常管理水平总是领先于工具水平的，如果工具能对管理水平提示有较大帮助
就会有个推论：
因为各种管理工具都可以用（买）到，各个公司的管理水平将趋于一致

实际这是不太可能的，管理水平主要取决于团队，不光是管理者，还有被管理者
而团队会根据自身的水平选择符合自己LEVEL的管理工具

比如缺陷描述的例子：
重现步骤：XXX提交，报错
期望：正常运行
实际：报错

这样的缺陷描述，用了什么缺陷软件也没多大用，首先应该培训团队，提升团队

但工具能避免人重复地犯无必要的错误却是真的
如果没有缺陷管理工具，推荐使用版本管理软件，将错误列表提交到版本管理软件中
这样不至于邮件或者QQ中来回传导致缺陷遗漏和缺陷状态更新不及时
否则总是有人拿过期的信息进行跟踪

这是个常有的错误，日常也有这样的例子：
旧手机即将停用前通知所有的好友新手机号，等手机启用后就有些人总是打旧号，造成沟通失败或者沟通成本上升
通过电信开通相关手机业务相当于用工具对某个环节进行改进

21 楼 wwccss 2010-07-15  

我觉得好的管理人员，心应该是很细腻的，呵呵。或者讲，中间管理层的人员，主要的职责是执行，需要考虑比较周到，方方面面的事情要把握好，平衡好。高层的管理人员我想更多的是战略，宏观方面的把握。

之前听过一次项目管理的培训，老师讲到，最高境界的管理，是无为而治。如果真的到了那个境界，应该是随心所欲不逾矩了。

20 楼 zwchen 2010-07-15  

wwccss 写道

引用

手工能管理好任务，才有上工具的必要

这个观点不赞同。你和陈兄讨论的一个假设是说项目团队里面要有一个比较好的管理人员。但实际的情况是好的管理人员凤毛麟角。有一个工具支持，让团队快速成长，我想不出这有什么不对。

手工管理好，一般是这个管理者有好的习惯，这时上工具，往往是提升效率。
比如，对于一个喜欢条理、整洁的人，以前没用过钱包，你送他一个，他会感觉，这东西正是他想要的。
而对于另外一些人，你看到他口袋里乱糟糟的，如银行卡、纸币、发票还有名片，于是好心买一个送给他，他却怎么都不用，还告诉你，朋友已经送我好几个了。

工具有一种规范作用，如果它和人的习惯差别太大，那么，适应是个很痛苦的过程(这些话在原文都说过)。


另外，对一蓑兄说的管理毫无艺术可言，自己的一点补充：
管理，如果技术都不熟练，根本就谈不上艺术，就像游泳，一游就呛水，还谈什么优美的泳姿。

如果说管理有种艺术，就是对平衡和人性的把握，因为两者都无法量化或规范化，更多是一种感觉，而艺术也是一种感觉。

19 楼 zwchen 2010-07-15  

wwccss 写道

这个观点我赞同。我并没有表达使用了项目管理软件，就一定能成功这种观点，所以呢，不要断章取义，曲解别人的观点。

我的观点，好的流程是需要好的工具来支撑的。诚如陈兄所言，那为什么有那么多的公司在使用项目管理软件？如果事情真如陈兄所言，使用个excel，word就可以了，那微软为什么还要开发project？还要开发自己内部的项目管理系统？我觉得陈兄看问题容易剑走偏锋，走进自己的圈子出不来。难道excel不是工具吗？真的按照陈兄的观点，excel, word你也应该删除的。

后来我们换成了在线的项目管理工具。难道我们团队的那些牛人们都不如你远见卓识？

excel我并没有排除它可以作为一个管理工具，但它有他的适用范围。比如你的团队扩大到十人，二十人，更多，上百人。想想看，用excel来进行项目管理或者bug跟踪，天哪，都不敢想象。

误解啊误解！

1、我不是说项目管理工具没用，而是说项目管理本身更核心，是基础、是前提。项目中往往存在比管理工具更棘手、对项目风险更大的因素。

2、在大型协作团队中，Excel等方式管理确实很低效，我更倾向于在线工具，如我们以前用过的dotproject(当时40人左右团队，20多人用)。当然，大型团队未必就是大型协作。

关于工具这块，我可以这么说，project和bug管理，几乎所有有点名气的工具，无论是在线还是桌面版，我都安装评测过，持续过三四年，我这人喜欢折腾。现在在用的，就是桌面版的ConceptDraw PROJECT，小型团队很实用。

3、我后面的回帖和我的原帖整体看法是一致的，而且你们的回帖我都是认同的，只是补充了一些，比如倚天剑的比方，并不是针对你，而是说很多人的误区，包括几年前的自己。

18 楼 wwccss 2010-07-15  

引用

手工能管理好任务，才有上工具的必要

这个观点不赞同。你和陈兄讨论的一个假设是说项目团队里面要有一个比较好的管理人员。但实际的情况是好的管理人员凤毛麟角。有一个工具支持，让团队快速成长，我想不出这有什么不对。

引用

流程在工具中越弱化越好，项目的核心还是业务

这个赞同。我们在设计软件的时候，也是按照这个原则去设计。也许大家真得应该看看我们的软件，呵呵。我们已经接到过好几个朋友的反馈，说禅道的管理方式和他们现在的管理方式惊人的一致。感觉就像是为他们量身定做的似的。

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

技术“牛人”未必能管理得好自己的任务和时间，因为怎么做好任务管理，怎么开会，这个也是一种技能，scrum能解决的也就是这个问题。

手工能管理好任务，才有上工具的必要，流程在工具中越弱化越好，项目的核心还是业务，把时间留给这块再多也不过分，管理要尽量简化。
如果仅仅只管bug，上不上bug管理工具没关系，只是一个结果而已，上百人的项目用excel不是管不了，没那么邪乎。

题外话，跟本帖内容无关：软件开发的很多管理方法跟传统行业比还幼稚的很，而且这个行业非常的封闭固执。多问一些为什么，会发现大部分是咨询公司的忽悠，故意将技术方法和管理方法混在一起，简单的东西复杂化，比如管理方法，复杂的东西简单化，比如技术方法。

16 楼 wwccss 2010-07-15  

引用

我也是一蓑兄那种观点，项目成败与否，和工具关系不大，尤其是不成熟的团队和管理者。我很重需求管理和质量管理，但不是管理它们的工具。
项目管理的目标，是怎么让项目成功，而不是如何把工具用熟，而很多人就喜欢盯着工具，以为自己握着一把倚天剑。

这个观点我赞同。我并没有表达使用了项目管理软件，就一定能成功这种观点，所以呢，不要断章取义，曲解别人的观点。

我的观点，好的流程是需要好的工具来支撑的。诚如陈兄所言，那为什么有那么多的公司在使用项目管理软件？如果事情真如陈兄所言，使用个excel，word就可以了，那微软为什么还要开发project？还要开发自己内部的项目管理系统？我觉得陈兄看问题容易剑走偏锋，走进自己的圈子出不来。难道excel不是工具吗？真的按照陈兄的观点，excel, word你也应该删除的。

引用

我建议，等你们几个客户项目结束后，去调研一下，让他们评估一下你们的软件，对生产率有多大的提升；另外，让他们假设一下，如果用Excel等做Bug管理和计划管理，和你们工具比，有哪些区别。

关于excel，我可以跟你讲一下我们之前在中国雅虎时的项目管理方式。就是使用excel的模板来进行scrum管理，大家每天晨会之前来签出，修改自己的任务估计，然后签入，其他人再进行修改。实际使用下来，存在的问题。
比如一个人签出之后，忘记签入，别人就不能修改。
一个人误操作之后，恢复很难。
修改历史很难跟踪。
文件的打开和保存速度很慢。
……
后来我们换成了在线的项目管理工具。难道我们团队的那些牛人们都不如你远见卓识？

excel我并没有排除它可以作为一个管理工具，但它有他的适用范围。比如你的团队扩大到十人，二十人，更多，上百人。想想看，用excel来进行项目管理或者bug跟踪，天哪，都不敢想象。

陈兄的文采很好，经验也很丰富，但感觉你的思路眼界有些狭窄，看问题偏激。你之前在的中大型团队的管理方式你照搬之后，很惨痛。有没有想过原因？或者讲，把你现在的管理方式，直接套用到中大型团队，会怎么样？

没有防止四海而皆准的管理方式，每个公司都有自己的秉性。你不能因为你现在的公司的实践成功的地方，就认为你的管理方式就可以推广的其他的公司。你也不能因为你现在公司的实践失败的地方，就认为这种管理方式不对。

15 楼 daquan198163 2010-07-15  

我觉得项目中的中间文档非常不适合采用word之类传统重量级的文档格式，因为它无法多人协作撰写、没有全文检索、甚至打开一个文档都要多浪费几秒时间和任务栏空间。

也许这才是最好的项目文档表现形式

当然，对于操作手册之类的交付文档，还是可以用word来写的，但也不是最好的选择。

14 楼 zwchen 2010-07-15  

wwccss 写道

我觉得陈兄的很多观点基于自己现在的管理现状而定。我觉得你现在的环境，应该是很特殊的一个。你本身懂技术，懂管理，又有特殊的地位，所以，你推行很多管理方式，很容易。或者讲，还是你个人的成功。如果换个团队，或者你在公司里面没有任何的背景，再来，估计就会出很多的问题。

我们做的东西，不是一个大而全的东西，而是一个满足项目管理核心流程的东西，而且我们已经做出来了，并且有很多的用户在用。这其中包括阿里学院，金山逍遥网，还有腾讯蓝房网等大公司。这也证明了用户有这样的需求。

需求管理和质量管理对于项目的核心价值，我想是非常重要的。我不赞同你的观点。就像前面说的，你现在的公司有很特殊的地方，你的经验，很难推广到其他的团队。

呵呵，我真的建议陈兄了解一下scrum.

来现在的公司之前，我在中大型的项目开发和产品研发团队呆过几年，那时候只是一位管理的旁观者，后来一直在思考项目管理和通用管理的适用性。我曾经将原来项目中的过程管理方法照搬，遭遇过惨痛的失败。

我也是一蓑兄那种观点，项目成败与否，和工具关系不大，尤其是不成熟的团队和管理者。我很重需求管理和质量管理，但不是管理它们的工具。
项目管理的目标，是怎么让项目成功，而不是如何把工具用熟，而很多人就喜欢盯着工具，以为自己握着一把倚天剑。

scrum和xp我四年前就买过几本书来研究，可能不是不深入。一切方法，都是拿效果说话。应用敏捷过程，我更看重的是它的一些理念，实操方面，按自己情况来。如

引用

个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作   重于 合同谈判
响应变化   重于 遵循计划

我建议，等你们几个客户项目结束后，去调研一下，让他们评估一下你们的软件，对生产率有多大的提升；另外，让他们假设一下，如果用Excel等做Bug管理和计划管理，和你们工具比，有哪些区别。

13 楼 wwccss 2010-07-15  

我觉得陈兄的很多观点基于自己现在的管理现状而定。我觉得你现在的环境，应该是很特殊的一个。你本身懂技术，懂管理，又有特殊的地位，所以，你推行很多管理方式，很容易。或者讲，还是你个人的成功。如果换个团队，或者你在公司里面没有任何的背景，再来，估计就会出很多的问题。

我们做的东西，不是一个大而全的东西，而是一个满足项目管理核心流程的东西，而且我们已经做出来了，并且有很多的用户在用。这其中包括阿里学院，金山逍遥网，还有腾讯蓝房网等大公司。这也证明了用户有这样的需求。

需求管理和质量管理对于项目的核心价值，我想是非常重要的。我不赞同你的观点。就像前面说的，你现在的公司有很特殊的地方，你的经验，很难推广到其他的团队。

呵呵，我真的建议陈兄了解一下scrum.