项目管理之道 《项目计划、进度与控制》读书感言

阿懒

这本书确实非常经典，用非常通俗易懂的语言讲明白了很多项目管理和一般管理的通用原则、方法。
我曾经上传过此书的英文电子版，感兴趣的家人可以搜索下载。

swordliang

QUOTE:

以下是引用阿懒在2007-7-27 12:15:04的发言：

这本书确实非常经典，用非常通俗易懂的语言讲明白了很多项目管理和一般管理的通用原则、方法。
我曾经上传过此书的英文电子版，感兴趣的家人可以搜索下载。

QUOTE:

【阿懒资料】詹姆斯·刘易斯《项目计划、进度与控制》英文版
    
作者：阿懒   浏览：2912   回复：14  →   资源中心
      2005-9-30 21:16:38阿懒   浏览：2912   回复：14  →   资源中心
      2005-9-30 21:16:38

[此贴子已经被作者于2007-7-27 13:43:46编辑过]

swordliang

QUOTE:

以下是引用阿懒在2007-7-27 12:15:04的发言：

这本书确实非常经典，用非常通俗易懂的语言讲明白了很多项目管理和一般管理的通用原则、方法。
我曾经上传过此书的英文电子版，感兴趣的家人可以搜索下载。

QUOTE:

【阿懒资料】詹姆斯·刘易斯《项目计划、进度与控制》英文版
作者：阿懒   浏览：2912   回复：14  →   资源中心 2005-9-30 21:16:38

  

阿懒   浏览：2912   回复：14  →   资源中心 2005-9-30 21:16:38

  

  

  

liquanfei

很高兴不少人也都喜欢这本书。对于从事项目管理的人来讲，有这本书基本上就够用了。

liquanfei

字数没有超过16000也贴不上来，怎么回事呢？

swordliang

QUOTE:

以下是引用liquanfei在2007-7-27 15:30:24的发言：
字数没有超过16000也贴不上来，怎么回事呢？

刚才我咨询过工作人员了，是这样，你直接复制粘贴可能会因为网页代码太多而导致字数超过16420

你可以先拷贝到电脑附件中的记事本中或者点击按钮，目的是清除代码，然后再用留言栏上面的格式按钮设置格式就好了

人月神话

项目管理核心是可控性。项目计划本身就是预测，因此可控性包括了可预测性和可控制性。

liquanfei

你说得不错。项目管理的核心在于可控性，让一切尽在掌握。

liquanfei

第1章：项目管理概述
几乎任何一本项目管理的书都会从介绍项目、项目管理的概念开始，本书虽然也如此，但却用了一个非常有意思的关于阿沙海布塞德为埃及第19世法老拉姆斯大帝建造陵寝的例子来说明他的一个观点：教科书中关于项目的定义常常与现实不符。
事实上，在过去的几年时间里，看了不少关于项目管理的书，也听了不少项目管理讲座，接触了不少关于项目的概念：
项目－项目是一项为了创造某一唯一的产品或服务的时限性工作。（PMI）
项目就是以一套独特而相互联系的任务为前提，有明确的开始与结束，充分地利用资源而实现一个特定的目标所做的努力。(03年赛百威讲师给出的定义，着实让当初对项目管理基本上没什么了解的我冥思苦想了很久很久。不过提炼出的几个特点还比较容易理解：相互关联的活动、明确的目标、独特、确定的开始和结束)。
在更多的教科书给出如下定义：
它是一项一次性的工作，具有具体的开始时间、明确的结束时间、明确的规模和预算，它实际上是一个多任务复合体。
当然，对于项目管理概念的解释绝对不仅仅限于以上几个。
因为关于项目的概念很多，每接触一个，就得与原有的概念进行一个比对，说实在的，大多数的关于项目的定义都是翻译过来的，在国外，项目管理的流派其实也是不少的，不过最权威的算是美国项目管理协会（PMI）了。从最初的对项目的概念的几乎抠字眼，到今天我已基本上不再去理会概念。因为我发现，对项目的概念越关注，反而对其的理解却越来越迷糊了。去年讲项目管理的时候，一般在开始的时候也会给大家介绍一下项目的概念，也会举出几个典型的项目的例子。但从今年开始，我已不再重点讲解概念方面的内容，基本上只作一些简单的介绍。尤其是看了本书关于项目的概念方面的介绍，对项目概念的理解一下子豁然开朗了：原来教科书上的关于项目的定义与现实往往不相符！这是关于项目概念的一个非常大胆的观点，我几乎有了类似练武之人打通关节般的兴奋。更觉得没有必要去研究哪些是项目，哪些不是项目了。阿沙海布塞德为埃及第19世法老拉姆斯大帝建造陵寝到底是项目呢还是工程呢，我已没有兴趣去琢磨它，以前，我一定会琢磨半天的。
在《项目计划、进度与控制》书中，作者勉强下的定义是：项目（Project）是指一种一次性的复合任务，具有明确的开始时间、明确的结束时间、明确的规模和预算，通常还有一个临时性的项目组。同时作者指出：这个定义中唯一适用于各种项目的内容是：项目是一次性的工作，它本质上是一个多任务复合体。就这一点，我非常之赞同，同时可能我自己也受到作者的勇气所鼓舞，我也敢说：目前所有的关于项目管理的概念仅供参考，切勿深究。否则，您会认为：基本上不存在项目。即使是一个目前典型的新产品开发项目，由于在开发过程中，其规模不断扩大，您会说，这不是一个项目了。而项目概念的“明确”二字，实际上其本身也并不明确，我在想，是否应该在其前面应该再加一个“可”字呢？
书中介绍了作者比较喜欢的约瑟夫·朱兰关于项目的定义：项目就是定好时间解决问题。我个人也挺喜欢这个定义的，感觉很简单容易理解。对概念的纠缠，让我想起鲁迅，当别人下了关于人的定义后，他来了个：“一只被拔了毛的鸡也是人。”一个定义的最终形成，需要长时间的不断修正，从这个角度上看，项目的概念到目前为止，可以说还没有完全定型。
项目的概念就介绍到此，接下来是关于项目管理的概念。作者对项目管理的定义是：项目管理就是组织实施对实现项目目标所必需的一切活动的计划、安排与控制。作者也明确指出：项目管理并非只是列进度表、不仅是一些工具、不仅是一个工作岗位或者一个职位头衔。实际上在过去的很长一段时间，相信很多的代表对项目管理的理解都局限在列出进度表，然后按照进度表进行项目的进度跟踪即可，现实也体现这一点：可能在较长的一段时间里，我们还得忍受我们不少项目管理人员只是列出进度表，然后按照进度表进行项目的进度跟踪的实际情况。不过这虽然不太对，但至少在列进度表，这与传统的做法相比还是有很大的进步。其次项目管理对很多的人来说，无非是按照填写一些计划模板，如果按照模板填写完毕，我们就已经完成了项目管理的工作，这些想法和思想在日常工作中我们是经常听到、体会到以及感觉到的，对于目前我们的工作倒还比较匹配，但如果不尽快改变思想，相信不会利于今后的项目管理工作的。当然还有一部分人会认为，我们已经有了产品线管理办，已经成立了PDT团队，以及很早以前就有项目经理，这应该说我们的项目管理已经做得不错了。其实不然，有了项目管理的工作岗位、头衔甚至说成立项目管理部门，也不能说我们的项目管理就已经做得很好了。
在对项目管理的论述中，作者就项目管理的概念进行了浓缩，精辟地指出：项目管理包括工具、人和过程。在与项目管理打交道的两年多的时间里，觉得这个论述非常之具有专业水平，而且也比较容易让人理解和接受。项目需要一个团队来完成，在完成项目的过程中需要利用一些项目管理的工具，如进度表软件、计算机、项目日志、计划等。我们目前有不会少人容易忽视过程这一重要环节。在日常的工作中，我们不少领导都强调结果导向，过度强调结果导向的结果就是使大家忽视过程。而遗憾的是，我们的结果导向往往使我们离结果更远，因为过程决定任务的成败！（P9）以前我对公司内部弥漫的这种风潮虽然在内心深处不太接受，现在，终于在这本书中找到了答案，当初看到这句话的时候，一度兴奋不已。后来思索了一下，其实这与领导的要求并不矛盾，领导要求的结果导向，需要我们实际操作的人重视过程，这样与结果导向是不矛盾的。现在，当领导强调结果导向时，建议大家把它理解为重视过程。
学过项目管理课程的同事都知道项目的三重约束：进度、成本、质量。在PMI的课程也将项目管理的三重约束也定义为：TQC。这个三重约束基本上已经深入我们脑海。长期以来，我也是这样教别人的。不过在《项目计划、进度与控制》书中，作者对项目的三重约束提出了挑战，提出了四重约束，增加了规模这一约束。而且作者将质量（Q）改换为性能（P）。其实在理解以前的三重约束时有些困惑：Q除了代表质量，还应该代表数量？而质量这个概念对很很多人都是不能去深刻理解的。事实上，虽然我们不少人都学过项目管理，但我敢打赌，没有几个人能对这个质量作深入的解释以及怎么运用到日常的项目管理过程中。在我们的脑海中，质量是质量部门的事情，在我们公司中，那是技术质量管理部的事，我们的产品按照他们的要求检测通过即可。而这些需要检测的要求、性能指标等根本不用我们去了解，因为自然有专业人士告诉我们到底我们开发的产品合不合格的，要让我们在产品开发前提出或者明确一些质量要求，我们会认为：有这个必要吗？相信大家基本上都有这个想法，目前我们的项目可以说基本上没有在开始前明确系统的质量要求。目前的做法有两个明显的问题：一是质量要求在项目开始时没有明确要求（很大的原因是不知道怎么明确）；二是质量问题往往是质量部门检测后发现了问题再去修改。
进度、质量、成本这个简单的三角形，无论是从理解上还是具体执行上似乎都不是一件什么难事，但事实上这个三角形还不是那么容易组成的。如果单独拆开来看，估计除了前面提到的质量稍微有点难度外，其他的关于进度、成本等绝对不是一件很难做的事。在过去的一年多时间里，公司领导对进度的要求、成本的要求其实都在产品开发前期都明确提出来了，为了确保各新产品的进度，我们有专门的新产品进度协调进度委员会，以确保新品的进度。在成本方面，由于集成产品研发的推进，我们在很多产品的开发初期都明确了产品的成本要求，虽然在初期的时候有些让人感觉罗嗦，但现在可以说大家对成本的核算已经轻车驾熟了。不过对于质量的要求，领导一般对PDT说：“除了进度外，要加强质量”，话外之意，我们一般理解为不要出质量问题。

liquanfei

按照项目管理的思想，在产品开发前，就必须明确项目的三角形，在这个过程中，项目经理需要和领导之间进行博弈，即争取相应的资源，不能一味地如同领导所要求的：“最快的进度、最少的成本、最好的质量”，虽然我们大家都知道这是不可能的，但一般领导都这样要求。在过去一年多PDT的时间里，尤其在备战十一财季新品开发的过程中，我们在处理三角形关系方面还没有做好。一是PDT在与领导之间的博弈中基本上没有讨价还价的余地。一般领导要求怎么做，PDT就怎么做。尤其体现在进度方面，不少在规划中应该在06年元旦量产的产品被要求在十一前上市，当然领导从业务的角度要求也是无可厚非的，销售方面也确实有十足的理由要求PDT提前1个月甚至3个月出来，在不能增加资源、更不能牺牲质量的前提下大幅度加快产品的上市速度，这对PDT来说确实是一项不小的挑战。不过，经过十一这一战，我有深深的体会，在这种环境之下，员工的无私奉献可以加快产品的进度。
有一天，当我和一位同事在聊到这个话题时，突然有一个重要的发现：我们很多项目在开发前并不是没有一个三角形，而是这个三角形的三条边不在同一时空！这一发现一下子让我明白了我们在现实中遇到的问题。之所以说我们的项目三角形不在同一时空，举十一财季新品开发的例子。公司领导首先对我们的进度提出了要求，大部分项目的进度都比规划的上市时间提前甚至大幅度提前，PDT胆战心惊地接受了进度任务，其次在开发的过程中，我们发现人员不足，但实际上这时候是没有人给加进来的，即使有人，加进来也不一定有用（为一个已经延期的项目增加人力，只会使它更延期P14），于是唯一的办法就是调动大家的加班意识来进行处理。我们的某些设计师手上同时有好几个而且是非常重要的项目在同时开发。不仅如此，在产品开发的过程中，我们还被要求产品的低成本控制等因素，甚至还得忍受一些变更。因此，在产品开发过程中，不仅没有资源的增加，甚至增加一些功能等，变相地减少了成本的投入。最后一点是关于质量的。看上去领导没有要求质量，但实际上没有领导会说：“质量差点也行”，也不可能这样说。尤其是目前公司的产品质量基本上大一统的情况，不管高档的、低档的、不管LCD的、也不是CRT的、各种标准基本上都是一样的。现在可能好些了，平板类的和CRT类的技术标准有些差异化。在这种情况下，不管我们在开发的是什么档次的产品都必须通过公司几乎统一的质量检测标准。在产品还没有开发出来之前，我们几乎很少谈产品的质量，但一旦产品已经量产后，产品的质量要求就被提出来了。领导会再三向我们强调产品的质量。
于是，我们发现，项目被要求的进度、成本、质量相继被提出来了，值得注意的是，不是在同一时间提出来的，是分为产品开发前、开发中、开发后提出来的。这样的一个变通会让一个近乎无理的要求变得有理。这样也使得PDT更难以与领导讨价还价了。所以在项目开始前明确项目的三角关系绝对不是一件简单的事。
我们将话题又扯回关于三重约束中除了成本和进度之外到底是P好呢还是Q好。其实这两个都不错，从某种意义上讲是一致的，关键在于怎样才能便于人理解。质量这个概念已被广泛应用，广泛到甚至越来越让人觉得含糊，而一旦真的说到质量的时候，大家又容易陷进狭隘的质量概念中。人们一般用两种方法来定义产品的质量。一种定义是，质量就是符合技术规范；另一种是，质量就是要满足消费者的需求。在目前我们大脑里，说到质量，相信大家都会仅仅理解为符合技术规范。有意思的是，我们来看看《项目计划、进度与控制》书中对P(性能)有这样的描述：
过去的两年里，我知道有很多人都搞不清“性能”的含义，所以，这里我要解释一下。项目的目的是为了形成某种成果。建筑项目为人们建造居住的房屋、行走的路、供社区人民饮水的水坝。产品开发项目是为了给人们提供产品；软件项目也是一样。
对这两类成果有两类性能要求，它们是相互关联的两个方面。一是功能 的要求，用来表明它能干什么；二是技术要求，用来表明它的特征，诸如大小、重量、颜色、速度、马力、推力、或任何其他方面的表现。
细心的您或许发现，性能的含义里面相互关联的两方面和两种关于质量的定义几乎一致，即：功能的要求和技术要求。功能要求站在满足消费者需求的角度，而技术要求则站在技术规范的角度。这样一来，P就不仅完全包含了不同的质量定义，而且比Q更明确和具体。
在这里，我觉得有必要引入另外一个关于质量的课题：过程质量。在现实的产品开发过程中，重视过程质量会大大加快产品的进度。这样的结论对三角形关系是一个动摇。不过关键看怎么去理解，如果理解为P的话，则不会有多大的影响，但如果将理解为Q，而且又将项目质量要求的Q和过程质量分不清楚谁是谁的情况下，那是够思索一阵子的。在产品的开发过程中，每一个环节都将自己的工作保证质量一次性做正确的话，则会在很大程度上确保产品快速、保证质量地完成。
接着谈第四重约束的话题。《项目计划、进度与控制》书中，提出了将“规模”作为项目的第四重约束，并指出：项目的规模约束也是与其他三重约束紧密相联的。您可以在这四者重任选三个，但第四个便无法保证。事实上，规模的变更比其他因素都更容易导致项目超期和预算超支。这里有必要把规模的定义明确一下：项目包含的范围或大小。在过去的一年多时间里，PDT团队迎接一个又一个的财季新品开发战役中，对于公司来讲，成本、质量基本上不变化的，而进度基本上要求一再提速，虽然这对PDT团队来讲要求是非常高的，但如果仅仅是类似的变化，倒也不是太大的问题，PDT团队在这样的环境中已经得到了充分的历练。但往往单个项目规模的变更乃至项目数量的变更是让PDT往往措手不及的。如一个项目在进行当初出现突然的降成本要求，在降成本要求中出现的一些的如换平台、换屏的问题，在十一期间也出现了，PDP3218、PDP3288都遇到了类似的问题，在这里，可以将其归属于项目规模增加；此外，如果将十一所有新品的开发作为一个项目的话，则要求出来的新品数量的增加可以说是比较典型的项目规模变更，这在十一新品开发战役中也遇到了。一些如LCD-TM4211之类的打算在元旦上市的机型都被提前列入了十一财季上市的清单。
其实对项目范围的变更理解对于很多人来讲都很模糊的，感觉不是太具体。这也难怪，因为项目范围是由P、C、T所决定的，只有当P、C、T都定下来之后才会有确定的规模，从另外一个角度来说，P、C、T三个因素中任何一个的变化都会引起项目规模的变化，从这个角度来说理解作者所说的项目规模的变更比其他因素都更容易导致项目超期和预算超期，是因为项目规模的变更必须引起三角形的任何一个或者两条甚至是三条边的变化。如果您仅仅读到这里，这里的论述可能会是一个陷阱。
将S、P、C、T比喻成一个三角形，这个比喻的重要性，在于想说明我不能随意选择边长和面积；如果我确定了其中三个，第四个便随之能被确定。但是，如果你试图同时确定四个因素的话，那它们只能在偶然的情况下匹配。
可是，在项目管理中，项目发起人或其他管理者通常想同时确定四个因素。P12
这是一个多么一针见血的总结啊。就此，作者给出了一个原则：你只能决定这些约束中的三个，第四个将由事物本身的联系决定。（P12）针对这一原则，我认为PAC和PDT之间要想达成今后的良性循环，建议：PAC决定约束中的三个，然后剩下的一个约束由PDT来决定。PAC具有优先选择权。
关于时间－成本权衡曲线，作者作了一个描述，由于在目前阶段我们不能拥有随机增加人手来保证项目的机制，因此对我们的参考意义不太大，但如果今后要想向更规范的项目管理迈进，则建议还是有必要了解一下。
我们每天都在做项目，我们中的部分人或许已经做了很多年，在这个过程中我们都面临一个压力：既快又省地完成任务。时间成本权衡曲线告诉我们，如果您低于曲线的最低点，压缩项目时间会导致更高的成本。然而，项目对我们的要求是同时降低时间和成本！我们是不是被愚弄了？也许是。（P15）其实在我们公司压缩时间倒也不会增加成本，因为我们根本就没有临时对一个项目增加人的打算，一是没有这个机制，另外也没有这个习惯。我们唯一能做的就是提高协作和加班。
有一句心理学的名言：“如果你总是做你一直在做的事，你就会得到你一直得到的结果。”还有一句话：“异想天开的人总是做着一直在做的事，却期望得到不同的结果。”这就是说，如果你一直在做的事没有什么成效的话，你就必须改变你做事的方式。事实上，这种改变正是规范的项目管理所要带给你的。
长期以来，很多人都在使用不规范的、非正式的项目管理方法，我把它叫做“随意的”项目管理。我很了解它，因为我也那样干了大约10年的时间。那时，我根本不知道还有其它方法的存在，我也完成了任务――而且他们还很满意。
问题是，我们没有意识到，其实我们的工作还可以做得更好。规范的项目管理（在流程上进行改变）真的能让您做到既快又省吗？
我想是的。
这段话，我觉得非常有必要抄下来，事实上，在写这篇文章的时候，我已决定要抄很多的内容，因为里面有太多非常精辟的论断。如果不把这些精华抄下来的话，我不会原谅自己。