《项目计划、进度与控制》读书感言2

liquanfei 发表于 2007-7-27 14:43:25

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

liquanfei 发表于 2007-7-27 14:51:37

内容很多，可能看上去会比较累。不过我相信我过去的几年实战经历对某些谷友是有帮助的。

swordliang 发表于 2007-7-27 15:32:38

字数看上去虽然多点，但是楼主的叙述方式，看起来还是觉得很舒服！非常感谢楼主的分享，我们都积极地学习中！

jinngle 发表于 2007-7-27 20:41:35

的确，引起了我对书中论述的很多回忆，当时候看这本书的时候，就是因为他有很多耳目一新的观念，才深深喜欢上了，很期待楼主的下回分解！

amanda917 发表于 2007-7-27 23:52:35

以前看过相关一些书，觉得挺枯燥但是只有你亲身经历过，才发现其实真的很重要，项目管理

amanda917 发表于 2007-7-27 23:55:37

标准容易定，你如何整合资源和优化组合，保证质量能按时完成我觉得这是项目管理中很重要的一部分

tyq99119 发表于 2007-7-28 13:55:25

学习中……

lonelyanuo 发表于 2007-7-29 01:20:25

回复：（tyq99119）学习中……

项目管理只有实践过后才有深刻的总结，期待楼主的续篇！

liquanfei 发表于 2007-7-30 12:09:44

后续会接着发在第一篇的后面。

腾格里 发表于 2008-1-10 16:43:03

哪里有下载？

页: [1] 2

栖息谷-管理人的网上家园's Archiver

《项目计划、进度与控制》读书感言2

回复：（tyq99119）学习中……