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

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

评论

52 楼 daquan198163 2010-08-02  

呵呵，沟通的本质也不在工具……

51 楼 wwccss 2010-08-02  

呵呵，这个帖子都很久了。我觉得这篇文章的观点很有误导性。管理的本质上思想，确实和工具没有关系。但管理都离不开工具的。就像我们平时所用的ppt, 脑图，excel, email, im软件，等等，这些都是工具。很难想象一个项目经理，没有这些工具，他可以进行项目管理。或者回到scrum的做法，使用纸笔，使用白板，但这也是工具。呵呵。

工具书管理思想的载体，好的工具对管理好项目是很有帮助的。

50 楼 吐故纳新 2010-08-02  

感觉在讨论先有鸡还是先有蛋的问题~

49 楼 akandfxs 2010-07-23  

jwnest 写道

akandfxs 写道

    听着总觉得向治大国若煮小鲜。虽然道理是这样，但主要太强调理念了，理念也是需要工具支撑的。没有好的工具，这些理念只是空中楼阁。就像一个国家，基本的统计数据都没有一个靠谱的，面对各种gdp的宣传，被涨工资之类的广告，有什么可信度而言呢？
    作为程序员，我是比较喜欢数字说话的，作为管理者，我是比较喜欢通过管理工具累计的数字描述团队的状态。比如本周bug数是不是比上周增多了，本月的bug率增加，原因是什么？可能是新老交替的正常现象，也可能是日程安排太紧，需要缓一缓。如果没有团队用起来成本比较低的管理工具，比如jira，是很难得到那些数字然后反思的。

假如上周有10个bug，但都是一些ui上小问题，可能半个小时就改好了。这周呢，只有2个bug，但都影响很大，要10天才能改好。如果通过bug数，你能得到什么样的信息呢？

当然这只是比较极端的一个例子，我想说的是，工具对项目管理当然是有帮助的，但不是核心，不要有种幻想，说引入某种工具以后，之前很烂的项目就能够马上变成井井有条。工具很多的起到一种锦上添花的作用，但雪中送炭基本上希望不大。见过很多的PM，工具用的很好，report写的很好，但也就仅此而已，项目本身是一塌糊涂。

    我觉得管理工具往往都不是雪中送碳的，管理工具往往同整个team的习惯经验结合的很紧密，管理层的经验习惯影响也很大。我觉得管理工具没有必要追求也不应该追求雪中送炭，锦上添花的效果。就像主食，而不是补药。就像南方人习惯吃米饭，北方人习惯吃面条，管理工具亦如是。能够锦上添花的可能是某个ppt的模板，：）。当然我也同意主食不是人活着的本质，但这已经和习惯思想联系的很紧密了，所以，对大多数人和团队来说，适合的管理工具就像可口的主食一样，还是先着眼于现实选好用好管理工具。
    对于10个bug，或者2个bug，其实bug本来按严重程度就有分级，还有核心模块和外围模块之类的分类，所以，此类指标只是bug管理细化和落实的问题。当然，如果这方面做的不好，可能会导致bug率毫无价值。对于管理工具提供的假数字，或者说很多很多数字，可以得出很多结论但可能其中自相矛盾，我觉得还是在目标导向的前提下努力获取真实的管理数字。而不是因为假数字太多，一开始就放弃了用数据说话。利用好管理工具，用真实的数字响亮的说真话，这个过程，是一个很好的体现管理思想的过程。

48 楼 一蓑烟雨任平生 2010-07-22  

项目管理有其方法论，方法论由流程、指南、工具、checklist、案例等等构成，工具软件是工具的一种，可以了么？这些概念都不清楚，做项目管理，唉，绕吧。

47 楼 jwnest 2010-07-22  

akandfxs 写道

    听着总觉得向治大国若煮小鲜。虽然道理是这样，但主要太强调理念了，理念也是需要工具支撑的。没有好的工具，这些理念只是空中楼阁。就像一个国家，基本的统计数据都没有一个靠谱的，面对各种gdp的宣传，被涨工资之类的广告，有什么可信度而言呢？
    作为程序员，我是比较喜欢数字说话的，作为管理者，我是比较喜欢通过管理工具累计的数字描述团队的状态。比如本周bug数是不是比上周增多了，本月的bug率增加，原因是什么？可能是新老交替的正常现象，也可能是日程安排太紧，需要缓一缓。如果没有团队用起来成本比较低的管理工具，比如jira，是很难得到那些数字然后反思的。

假如上周有10个bug，但都是一些ui上小问题，可能半个小时就改好了。这周呢，只有2个bug，但都影响很大，要10天才能改好。如果通过bug数，你能得到什么样的信息呢？

当然这只是比较极端的一个例子，我想说的是，工具对项目管理当然是有帮助的，但不是核心，不要有种幻想，说引入某种工具以后，之前很烂的项目就能够马上变成井井有条。工具很多的起到一种锦上添花的作用，但雪中送炭基本上希望不大。见过很多的PM，工具用的很好，report写的很好，但也就仅此而已，项目本身是一塌糊涂。

46 楼 zwchen 2010-07-21  

akandfxs 写道

    听着总觉得向治大国若煮小鲜。虽然道理是这样，但主要太强调理念了，理念也是需要工具支撑的。没有好的工具，这些理念只是空中楼阁。就像一个国家，基本的统计数据都没有一个靠谱的，面对各种gdp的宣传，被涨工资之类的广告，有什么可信度而言呢？
    作为程序员，我是比较喜欢数字说话的，作为管理者，我是比较喜欢通过管理工具累计的数字描述团队的状态。比如本周bug数是不是比上周增多了，本月的bug率增加，原因是什么？可能是新老交替的正常现象，也可能是日程安排太紧，需要缓一缓。如果没有团队用起来成本比较低的管理工具，比如jira，是很难得到那些数字然后反思的。

daquan198163 写道

以此类推：配置管理，本质和配置管理工具无关。
然后呢，如果不采用工具，配置管理肯定没法做

1、我说的是本质，管理辅助工具不是用来解决本质问题。
2、我没有强调工具，不是说工具不重要。
3、我的看法，人的问题，往往是更具本质性。

我发现这篇文章，观点和要点和我差不多：项目管理的本质

45 楼 zwchen 2010-07-21  

当管理者主动放弃罢免权、惩罚权，并且在资源有限的情况下，如果能够把大家主动性、责任心调动起来，顺利完成项目，这才是真正的管理者。
很多大公司，有的是人财物和成熟流程，我并不认为这些公司的管理者都接受过严峻的管理挑战，意识到管理的核心问题。

44 楼 daquan198163 2010-07-21  

以此类推：配置管理，本质和配置管理工具无关。
然后呢，如果不采用工具，配置管理肯定没法做

43 楼 akandfxs 2010-07-21  

    听着总觉得向治大国若煮小鲜。虽然道理是这样，但主要太强调理念了，理念也是需要工具支撑的。没有好的工具，这些理念只是空中楼阁。就像一个国家，基本的统计数据都没有一个靠谱的，面对各种gdp的宣传，被涨工资之类的广告，有什么可信度而言呢？
    作为程序员，我是比较喜欢数字说话的，作为管理者，我是比较喜欢通过管理工具累计的数字描述团队的状态。比如本周bug数是不是比上周增多了，本月的bug率增加，原因是什么？可能是新老交替的正常现象，也可能是日程安排太紧，需要缓一缓。如果没有团队用起来成本比较低的管理工具，比如jira，是很难得到那些数字然后反思的。

42 楼 zwchen 2010-07-20  

caidehui 写道

首先要说，管理本身是需要工具的。其次要说好的工具应该融入管理的基本原则、管理的辅助工具；再次要说就是工具永远都是辅助的。

管理涉及到：计划、组织、人员、领导、控制五个方面，因此每个方面都需要下功夫才行。

认同！
上面的五方面，是管理学领域的经典分类，但主要是管理者的视角，如果站在被管理者的角度，该是怎样呢？因为管理的目标，最终是被管理者去达成。

现在在系统地学习管理理论(附件)，最近在看一本《西方管理思想史》。
如果将实践再回归到理论，也许更牢。

有人说，你现在的失败，就是由于你曾经的成功造成的。也许，这是因为没有发现成功经验背后的规律、本质。

41 楼 caidehui 2010-07-20  

首先要说，管理本身是需要工具的。其次要说好的工具应该融入管理的基本原则、管理的辅助工具；再次要说就是工具永远都是辅助的。

管理涉及到：计划、组织、人员、领导、控制五个方面，因此每个方面都需要下功夫才行。

40 楼 zwchen 2010-07-20  

<div class="quote_title">cutesource 写道</div>
<div class="quote_div">
<p>我也同意项目管理和工具无关，最根本在于管人和风险控制</p>
<p>以前总结过一些管理心得和大家一起共享：</p>
<h1 class="title_txt"><span style="font-size: small;"><a href="http://blog.csdn.net/cutesource/archive/2010/04/03/5448351.aspx">PM
工作中常见问题及解决方法<br>做
好PM的几个关键事项</a></span></h1>
</div>
<p><br>仔细读了一下你推荐的两篇文章，尤其第二篇感触挺深。</p>
<p>不过，有个建议。</p>
<p>你是按checklist方式来分段，我建议你按PMP大纲的方式来组织，这样读者更易理解和记忆，比如你整篇文章的要点：</p>
<p>1、风险控制(项目关键点、风险点、突发事件)</p>
<p>2、沟通(团队间共识、换位思考、众议、倾听)</p>
<p>3、时间管理(计划、进度控制)</p>
<p>4、整体思考(大局观)</p>
<p> </p>
<p>对于偏创造性的工作，如中高端软件开发、艺术设计等，提升效率的最好方法，就是提供自由的工作环境，激发其工作热情，建立团队凝聚力，这对管理者情商和性格有挑战。</p>
<p>至于管理技能，这和智商有关，只要管理者肯学习，如实践和阅读，虚心请教团队成员，项目风险并不那么可怕，因为一线的开发人员，往往比你提前觉察到。<br><br>危机，往往根源于管理者堵了信息双向流通的管道。</p>
<p> </p>
<p> </p>

39 楼 cutesource 2010-07-20  

<p>我也同意项目管理和工具无关，最根本在于管人和风险控制</p>
<p>以前总结过一些管理心得和大家一起共享：</p>
<h1 class="title_txt"><span style="font-size: medium;"><a href="http://blog.csdn.net/cutesource/archive/2010/06/22/5685537.aspx">PM
工作中常见问题及解决方法</a></span></h1>
<h1 class="title_txt"><span style="font-size: medium;"><a href="http://blog.csdn.net/cutesource/archive/2010/04/03/5448351.aspx">做
好PM的几个关键事项</a></span></h1>

38 楼 snow8261 2010-07-19  

提供的bug_issue的模板还是不错的

37 楼 zwchen 2010-07-18  

tuti 写道

zwchen 
建议把标题和原文的词句，说得更明确点。我看误会的人还不少。
比如说这贴的标题，可多加几个字，如“项目管理的的本质和所用的项目管理软件无关”。

已经按你的建议修改了。

当初，我担心标题不够简洁，想写成“项目管理，本质和项管软件无关”，但“项管软件”这个词没人使用，所以去掉了。
单独看标题，想想，确实容易让人误解。

36 楼 lobbychmd 2010-07-18  

看标题，我还以为说的是项目经理可以不懂软件那个意思。。。

35 楼 fantasy 2010-07-18  

tuti 写道

zwchen 
建议把标题和原文的词句，说得更明确点。我看误会的人还不少。

比如说这贴的标题，可多加几个字，如“项目管理的的本质和所用的项目管理软件无关”。

的确看着标题我也误会了，建议修改下标题。

34 楼 tuti 2010-07-18  

zwchen 
建议把标题和原文的词句，说得更明确点。我看误会的人还不少。

比如说这贴的标题，可多加几个字，如“项目管理的的本质和所用的项目管理软件无关”。

33 楼 zwchen 2010-07-18  

tuti 写道

zwchen 写道

tuti 写道

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

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

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

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

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

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

其实，原文中，我并没有将项目管理和管理工具的关系说透，不过一蓑烟雨任平生同学比我见解更深刻(他的观点我总是逐字推敲)，我心里也就踏实多了。