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

标题: 项目管理之道 《项目计划、进度与控制》读书感言 [打印本页]

作者: liquanfei    时间: 2007-7-25 15:02
标题: 项目管理之道 《项目计划、进度与控制》读书感言

项目管理之道fficeffice" />

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

 

 “这本书最适合您,您可以向我提出书中涉及的任何问题,它们全在我的脑子里,您可以试试,看我能不能不查书就回答出来。”

                                   

“不管您是公司的高层领导、还是公司的中坚领导、PDT代表、设计师、一般员工等,只要您关注公司的项目管理进程、关注公司今后的发展,我相信,您会认真读完本文章,因为,我是用心、真心,发自内心写出来的。”

 

“如果大家都熟读此书、并在实际工作中灵活应用,我相信,不仅我们个人,而且整个公司的效率都会得到提升。”

 

如果单从书名上来看,《项目计划、进度与控制》一书应该说没有什么特别之处,它不仅非常直接地表明这是一本关于项目管理的书,而且直接点明了项目管理的核心内容,从市场推广的角度来看,确实了无新意。当我们在书城里偶然看到该书的时候,相信也不会有多少人关注它,是啊,生活在现今时代的人们,即使是对那些宣传和包装得天花乱坠的书都无暇一一顾及,怎又能对一本看上去平平实实的书感兴趣呢?说实在的,我也是在一堆项目管理的书籍中偶然看到该书,当初买它的时候也没有更多的时间研究它,因为自己目前正在从事项目管理的工作,而且也在研究项目管理的课题,在过去的一段时间里,不管黑猫白猫,只要是项目管理的书就是好猫,于是很偶然的,该书挤进了我的书架。

如今,该书已经与《培思的力量》、《极限项目管理》一起成为我案头必备的三本我自认为三大经典项目管理书籍之一,至今,所购买的项目管理书籍不下几十本,但唯独这三本,我是看了又看,《项目计划、进度与控制》在很大程度上已经成为我的项目管理字典,在日常的项目管理过程中,经常能从该书中找到答案和共鸣。很清楚地记得该书是在今年529日买的,因为正好是六一前夕,在过去的4个月中,该书基本上一直被放在我的办公桌上,几乎不曾离开。当看完第一遍的时候,正值我们策划组织了项目管理IPD知识竞赛,于是当即决定将该书纳入了奖品的范畴。

目前,公司内已经有十几位同事手里拥有该书,而且各PDT都至少有一本以上,在今年7月,当各PDT完成了《真正的执行》的阅读后,随即启动了阅读《项目计划、进度与控制》的活动。

《项目计划、进度与控制》系美国顶级项目管理专家詹姆斯·刘易斯的最新力作,该书已是第三版,其第一版的出版时间已是在十年之前,可以想见,该书在很大程度上可以说是詹姆斯·刘易斯在项目管理方面的经验沉淀。

阅读《项目计划、进度与控制》相信对任何一个人都是一个挑战,因为该书厚达370页,40多万字,没有一定的心理准备是不敢打开本书的,不用说把它读完,更不用说对该书进行研究了。不过,我想,如果您是真的对项目管理感兴趣的话,一旦您有勇气打开,我敢担保您不会把它束之高阁的,事实上,我了解一下,有不少同事看了本书后,都觉得这是一本好书。对于这样一本项目管理巨著,如果真的要写感言的话,估计会超越本书的厚度,现在,我还不知道我有多少的空闲时间来写这篇感言,感觉压力很大,也不知道写到多少字的时候就不得不搁笔,这几天国庆节,没有打算安排加班,因为在过去的100多天,为赶十一新品的开发进度,在精神上可以说是没有一刻放松过,想趁这几天的假期,好好地放松一下,不过,人在家中,精神却还在沉浸在十一产品的开发过程中,庆幸的是,在这100多天的时间里,《项目计划、进度与控制》一直与我陪伴,一路走来,《项目计划、进度与控制》为我解忧。当十一产品已全部按照既定日程奔赴战场的时候,我想,该是总结的时候了。突然,脑海中冒出一个想法:能否结合十一新品的开发过程,写一篇《项目计划、进度与控制》的读书感言呢?这样岂不一箭双雕?如果您能看到这里,那我想告诉您的是,接下来您多看到的既是对多媒体事业部05年度十一财季新品开发过程的总结,也是我在阅读、使用《项目计划、进度与控制》一书4个多月来的感言。事实上,在本篇文章也可以作为我们公司在通往项目管理路上一个阶段性的回顾。

《项目计划、进度与控制》全书共七篇,我想把总结和感言也分为七篇来进行回顾和感悟。看到这里,或许您会着急,该直接进入该书的主要内容了吧,别着急,在进入该书主要内容之前,还有精彩的呢?我现在看书和以前看书有点不同,以前在看书的时候,和大多数人一样,我会直接进入书的目录或者直接从第一篇开始,但现在我开始阅读序言之类的了,因为在序言中,往往会对该书作一个总结,该书的一些精彩之处也往往会在序言中被点出来,这一习惯也体现在我买书的时候。本书与其他书不同之处在于:在开始之前,居然有策划人语、致中国读者、译者前言、英文版前言等,我把这四篇前言也仔细阅读了一下,还真发现了一些比较经典的论述。在策划人语中,有这么一段话,相信对现在的我们有很深的体会:

21世纪是充满竞争和变化的时代,企业面临前所未有的挑战。组织中的许多关键任务需要由临时的或跨部门的团队来承担,这些任务都由严格的时间、经费和质量的要求;为了更快地推动技术进步、更好地满足甚至引导客户需求,更灵活地应对不确定的变化,就必须改革僵化的传统组织结构,使其扁平化、矩阵化、更具灵活性,并以客户需求为导向,从而提高企业的竞争力。在现代企业中,中层经理将迅速减少,取而代之的是项目经理,这些现代组织的“新贵”拥有很大的权力,掌握关键性资源,并承担极为重要的责任;企业中所有的员工都可能同时存在于一个或者多个项目中,他们更重视团队精神、效率,更富于责任感和创新精神。

以上这段话,更多的是引起了我的共鸣,我想不仅是我,相信经历了一年多项目管理洗礼的设计师们,对这段话也会有一定的感受。现在我们大家都同时存在于一个或者多个项目中,公司越来越多的事情是通过临时的或者跨部门的团队来承担的,我们也可以从这段话中,明白在一年多前,公司领导为什么要成立产品线管理办,为什么要成立PDT团队,为什么会有PACPMT的组织架构,目的也就在于:应对目前的竞争环境以及向现代企业迈进。从组织的角度上看,现代企业与传统企业最大的不同在于:传统企业是职能型的组织架构,而现代企业则更多是扁平化的矩阵式组织架构,我们目前的PDT团队就是典型的矩阵式组织架构,PDT代表来自于事业部各部门。PDT团队中,各代表更重视团队精神和效率,经过一年多的工作来看,PDT团队的绩效有目共睹,出色地完成了过去三个财季的新品开发任务,其影响力正逐步扩大。目前PDT团队承担越来越大的责任,虽然在权力、关键资源方面的到位方面还不是很理想,但实事求是地说,我们还缺乏真正意义上的项目经理,即使是目前仅有的几个,我想,他们离所谓的“新贵”还有一定的距离。

接下来,还有一段话,非常之有意思:

    项目管理是由管理项目的需要发展而来,它的核心是工作任务的“可控性”。项目管理的理论和知识直接来源于实践者们长期经验的积累。运用直观、简便的项目管理工具和方法,就可以科学地管理项目工期、预算、质量和成本,总结项目经验成果并预防项目风险,从而达到控制成本、减少浪费。提高效率和增加客户满意度的目的。因此,项目管理非常贴近于实际,即使没有系统学过管理理论的理工科学生,也可以很快地掌握项目管理知识工具,并将其很好地应用于实际工作。项目管理更是一种文化,项目团队中每位成员的高度责任心和合作精神都是决定项目成败的关键。中国人喜好独善其身,却不善于分工协作,最终达成团队的成功。为此,常有许多企业反映,不少大学生在实际工作中,虽然个人能力很强,但缺乏整体协同和团队意识,在项目中难以与人沟通合作等等。因而,在组织中倡导项目管理文化,对组织的成功将产生重要的促进作用。

在这段话中,策划人点出了项目管理的核心是工作任务的“可控制性”,这一精确的定义对我们理解项目管理非常之重要。

另外,项目管理知识是实践的产物,它不是纯理论。这非常便于我们接受项目管理思想。我经常对我的朋友、同事们说,在项目项目管理方面,我是有点“照本宣科”,不过,因为项目管理知识基本上都来自实践,因此,这与平时我们所说的“照本宣科”有本质的不同,就这点,我会在后面加以相应的阐述。

还有非常值得一提的是项目管理更是一种文化。对于这点,我有很多的感想,我个人认为,在一个公司里面推行项目管理,应该首先推行的就是项目管理文化,不推行项目管理文化,推行项目管理一定会面临非常大的阻力,成功的可能性非常之小;同时,项目管理文化也是目前很多企业最缺乏的,可以这样说,目前很多企业不缺乏项目管理的书,也不缺乏项目管理的思想,也不缺项目管理工具,但是项目就是管理不好,我认为最大的原因在于缺乏项目管理文化。在策划人的这段话中,有一句话“中国人喜好独善其身,却不善于分工协作”可能有点极端,不少人看了可能有点不舒服,但同时大家也不得不相信,策划人说了一句大实话,与这句类似的表述有:“中国人一个人是一条龙,三个人是一条虫”。在一个项目中,决定成功的不是一个人,而是一个团队,决定其最后结果的不是最优秀成员的表现,而是最差成员的表现,这就是大家所熟悉的“短木板理论”。每一位成员的责任心和合作精神对于项目的成败起着决定性的作用,而合作精神则是项目管理文化中最核心的内容。团队如果不合作,即使团队成员都是顶级的项目管理专家,都拿了美国的PMP证书,其结果只有一个,那就是失败。

对一个团队的评估,一般都用团队表现和团队业绩两条曲线来评估,而我认为团队表现重于团队业绩,因为团队表现是团队业绩的基础,也是持续获得团队业绩的保证。这里面的团队表现,更大程度上暗示的就是团队合作。曾经有一位PDT副经理在接手一个PDT团队时,就非常着急地想从业务上着手,我对他说,先请几个核心成员吃吃饭吧,结果他照做了,效果不错。团队关系的好坏决定项目组内部的分工协同效果,而一些社交活动则是建立团队关系的重要一环。这个做法,后来在《项目计划、进度与控制》书中得到了共鸣:在该书第283页中,有这样一句话:“通过一项纯社交活动开始您的项目―一次宴会、野餐或垒球赛。”
      
在过去的近一年的时间,我们将PDT团队的合作精神建设作为推进项目管理文化最重要的工作之一,这个工作还将持续进行,项目管理文化建设不会是一个项目,因为这不会有结束的那一天,只要我们在做项目管理,就一定要进行项目文化建设。在成立PDT团队时,我们向公司领导申请了团队活动经费,在04年时,公司给了我们1.8万元的团队建设经费,在很大程度上促进了PDT的团队建设。不过我们在申请05年度的活动经费时遇到了些困难,好在我们不断坚持,打了近乎三次报告,终于申请下来了5万元的活动经费,这给我们05年度的项目管理文化建设提供了资金保证。

经过看上去更多是吃吃喝喝、游山玩水的活动,但实际上加强了PDT团队成员间的相互了解和熟悉,不仅是局限在认识,而且相互间的工作内容也有一定的了解,从而在项目中奠定换位思考的基础,在很大程度上减少了冲突。此外,我们还通过PDT篮球赛、项目管理知识竞赛、读书活动等促进项目管理文化的建设。正因为尝到了项目管理文化建设的甜头,在06年度,我们还将申请团队活动经费。

  不仅是策划人的话有点意思,就是译者的话也同样有意思。翻译《项目计划、进度与控制》这本书的叫赤向东,曾经在南太担任R&D经理。他在译者前言中有这么一段感言:

我们公司的产品开发流程十分复杂,熟悉它的运作是需要相当一段时间的。但我发现,自从读了此书后,对流程的理解比以前更深刻了,并且明白了为什么要那么做。回想我以前在南太任R&D经理时,几乎用了一年时间也没有完全搞清开发流程,原因就是缺乏系统的项目管理理论。

不管哪个公司,我相信,几乎所有的研发人员都会认为研发流程复杂,不管其流程是否真的复杂。每个设计人员都想走捷径,任何的流程对他们来讲都是束缚。在十年前,我听到公司的设计人员说,公司的流程太复杂了;今天,我还是听到他们同样的抱怨。其实,当研究比我们先进的同行企业时,我们会发现,他们的流程其实比我们的复杂多了。因此,我坚信:过于简单的流程是创造不出优秀产品的。不过流程也不是越复杂越好,合适的就是最好的,但问题是再简单的流程对设计师们来说,他们都觉得太复杂。希望这位由设计师出身的项目管理老师说的“并且明白为什么要那么做”能让我们的设计师们也明白为什么要那么做的话,哎呀,不行,那样的话,我们可要失业了。

 

   这本书把英文版前言也翻译了过来,读该前言,可大致了解这本书的特点。前言中有这样一段话:“我绝对不喜欢读那些高深难懂的著作。所以我们的人生目标就是把那些难于理解的理论转化成通俗易懂的、一小块一小块的、适合于消化的东西。这一点已经成为我的标志或品牌。”

确实,以上可以说是《项目计划、进度与控制》最大的特点,这就是我前面为什么说,只要您有打开本书的勇气,就一定不会放下它的原因所在。本书虽然厚,文字也密,但绝对不会让人感觉枯燥。

在英文版的前言中,作者还总结了该书另外一个重要的特点:该书更多是教我们项目管理的一些原理,而不仅仅局限于怎样处理具体的问题。“这是本书的出发点。我把项目管理的每一步原理教给你们,您们掌握了它,就可以处理您们各自不同的情况,甚至你们的所有项目。我保证,它一定是有效的。也许第1次不成功,但是您要想一想,使用一条原则有多种途径,如果你试试不同的途径,你会发现有的途径是最有效的。”

在前言中,作者指出目前一些人的错误认识:“在近20年的授课生涯中,我总是试图传授给学员们一些原理,以便帮助他们处理问题。可是我发现,有些人根本不想听原理,他们想知道怎样处理正在发生的具体问题。”、“人们期望项目管理是一个“填空过程”。“给我一些表格,让我填满,然后我就能做计划,做进度表和控制过程了。”他们这样说。但很遗憾,这是不可能的。这就像有人相信进度表软件能让人变成速溶项目经理一样,而事实并非如此。如果你不知道藏在进度表后面的原则,那么你做出的进度表也只能十分精确的对错误进行计划。软件只是一个工具,即使给我一把锯子,我也不是一个工匠。”作者所指出的这些错误思想,在我们的团队中也广泛存在,在推进项目管理的过程中,有些设计师甚至我们的PDT副经理都不同程度存在些项目管理急功近利的思想,试图把项目管理简单化,机械化。不少人认为,只要把计划模板给大家,我们的项目管理难题就基本上解决了,事实上,在几个月以前,我也是这么认为的。我们用了差不多2年的时间制作出了新产品的开发计划,我把这个模板推荐给了我们的六个PDT团队试用,当时认为,有了这个进度计划模板,我们的所有项目就可以受控了。而结果并不是当初我想象的结果,绝大多数项目组没法按照进度表模板进行项目的计划,我们的进度计划模板并没有产生速溶项目经理。还好,看了《项目计划、进度与控制》这本书,在这个问题上,它帮助我重新制定相应的计划。在6月份的时候,我们集中精力将进度表的重点放在了十一财季重点机型上,由PDT副经理亲自和研发项目经理一起制定项目计划,而我们的PDT副经理以及研发项目经理,基本上都接受过专业的项目管理培训,而且也都能熟练地使用项目管理软件。这样我们就避免了“当一人对项目管理一无所知时,给他一个强大的进度表软件,只会使他精确地记下错误!”(P178)。因为这本书,庆幸的是,我没有要求所有的项目都按照进度表模板来填,否则,我们会有大部分的项目精确地记录下错误。因为我们没有那么多懂项目管理的人员。

作者说:“我希望您能觉得本书是最实用的、最切合实际的项目管理书籍。”现在,我已经有了这样的感觉。

接下来,我想带着大家感受一下本书。
作者: liquanfei    时间: 2007-7-27 07:44
有没有谷友看过本书的呢?
作者: swordliang    时间: 2007-7-27 10:00
粗略的翻过,因为自己浮躁的心态而没有认真去读,但是这是做项目管理的人必读的一本书
作者: jinngle    时间: 2007-7-27 10:19

买了个中文版的,没看完,正在啃英文版的,作者已经写的很通俗易懂啦!


作者: 瘦土豆    时间: 2007-7-27 10:20
既然大家推荐,那我得买一本,好好看看,给自己充电!
作者: jinngle    时间: 2007-7-27 10:21
不过对我帮助不大,真正项目实施的时候才会领悟吧,知识这东西,也只有变成自己的才有用,否则也只有大条条,不过练练英语还可以,嘿嘿~
作者: swordliang    时间: 2007-7-27 10:31

因为我不知道PDT是什么意思,就查了一下,希望没有错,请楼主帮着核实一下!

PDTroduct Development Team的缩写,产品开发团队的意思。

PDT是一个虚拟的组织,其成员在产品开发期间一起工作,由项目经理组织,可以是项目经理负责的项目单列式组织结构。


作者: rockking    时间: 2007-7-27 11:07

写的很好,学习学习!


作者: liquanfei    时间: 2007-7-27 11:31
是的。PDT就是产品开发团队的意思。一般在推行IPD的企业中都会采用这样的称呼。
作者: liquanfei    时间: 2007-7-27 11:33
是的。PDT就是产品开发团队的意思。一般在推行IPD的企业中都会采用这样的称呼。
作者: 阿懒    时间: 2007-7-27 12:15

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


作者: swordliang    时间: 2007-7-27 12:40
QUOTE:
以下是引用阿懒在2007-7-27 12:15:04的发言:

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

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

作者: swordliang    时间: 2007-7-27 12:41
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    时间: 2007-7-27 14:38

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


作者: liquanfei    时间: 2007-7-27 15:30
字数没有超过16000也贴不上来,怎么回事呢?
作者: swordliang    时间: 2007-7-27 16:04
QUOTE:
以下是引用liquanfei在2007-7-27 15:30:24的发言:
字数没有超过16000也贴不上来,怎么回事呢?

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

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



作者: 人月神话    时间: 2007-7-27 22:30
项目管理核心是可控性。项目计划本身就是预测,因此可控性包括了可预测性和可控制性。
作者: liquanfei    时间: 2007-7-30 08:05

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


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

作者: liquanfei    时间: 2007-7-30 08:10

按照项目管理的思想,在产品开发前,就必须明确项目的三角形,在这个过程中,项目经理需要和领导之间进行博弈,即争取相应的资源,不能一味地如同领导所要求的:“最快的进度、最少的成本、最好的质量”,虽然我们大家都知道这是不可能的,但一般领导都这样要求。在过去一年多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年的时间。那时,我根本不知道还有其它方法的存在,我也完成了任务――而且他们还很满意。
问题是,我们没有意识到,其实我们的工作还可以做得更好。规范的项目管理(在流程上进行改变)真的能让您做到既快又省吗?
我想是的。
这段话,我觉得非常有必要抄下来,事实上,在写这篇文章的时候,我已决定要抄很多的内容,因为里面有太多非常精辟的论断。如果不把这些精华抄下来的话,我不会原谅自己。


作者: liquanfei    时间: 2007-7-30 08:13
按照项目管理的思想,在产品开发前,就必须明确项目的三角形,在这个过程中,项目经理需要和领导之间进行博弈,即争取相应的资源,不能一味地如同领导所要求的:“最快的进度、最少的成本、最好的质量”,虽然我们大家都知道这是不可能的,但一般领导都这样要求。在过去一年多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年的时间。那时,我根本不知道还有其它方法的存在,我也完成了任务――而且他们还很满意。
问题是,我们没有意识到,其实我们的工作还可以做得更好。规范的项目管理(在流程上进行改变)真的能让您做到既快又省吗?
我想是的。
这段话,我觉得非常有必要抄下来,事实上,在写这篇文章的时候,我已决定要抄很多的内容,因为里面有太多非常精辟的论断。如果不把这些精华抄下来的话,我不会原谅自己。

作者: liquanfei    时间: 2007-7-30 08:14
上传总出问题,应该改善一下。
作者: liquanfei    时间: 2007-7-30 08:17
这段话,可以说是我们目前多媒体事业部大部分人心态的真实写照。十一新品战役完后,我就对很多人说,虽然我们完成了十一财季的新品开发任务,但千万别认为我们的项目管理就做得很好,我们确实是完成了任务――而且领导们还算满意,但是,我们应该清醒地意识到,其实我们的工作还可以做 得更好。
在前面,在写到关于PCTS的时候,我写了一句,如果您不继续往下读的话,会是一个陷阱。这是因为,在现实生活中,领导经常给我们的任务是:在不改变PCT的情况下,扩大S。在我们看来,这是领导在难为我们,但实际上领导也是出于无奈。在没有看《项目计划、进度与控制》这本书之前,我也没有答案。我们受到传统思维的限制,于是认为PCT定下来之后,S就已经被确定下来。事实上这样的结果我们是基于平面的基础之上,但如果将三角形放在球面上,则会得到不同的结果。我们甚至将从球心到PCT围成的区域作为S,这样一理解,整个思维就会豁然开朗了。简单地改变球的半径,S就会改变。那么球的半径代表什么呢?作者说,我想它应当是用来衡量工作流程的好坏。作者这样比喻的目的只有一个,那就是告诉我们:通过改变项目的流程,我们可以赚到更多的钱,可以减少返工、提高生产效率、缩短时间等。个人觉得其实在项目管理三角形的背后,不仅仅是流程会改变S的大小,人才、工具也会改变S的大小。在PTC基本相同的情况下,A公司的S和B公司的S一定会有所不同。这似乎有点超越项目管理的范畴(不过由于项目管理的博大精深,也可以纳入。有争议)。
在前面,作者对项目管理的定义是:项目管理就是组织实施、安排、控制的过程。在P21页,本书强调了组织实施的真正含义:组织实施(FACILITATION)非常重要,项目经理不是独自为团体制定计划,而是让那些实际操作业务的人参与制定计划。为什么是这样的呢?有两个原因。首先,只有他们自己最清楚自己要做什么,要花多长时间。其次,他们最有可能想到一切必要的事情,而如果让您独自定计划,有些事情您是根本考虑不到的。而且,他们知道您的计划可能有纰漏,而您又独自制定并“强加于人”,他们很可能不把这个计划当回事。所以,如果您想要一个正确的、且为您的团队所接受的计划,就让他们参与到计划制定中来吧。
看完这段,我相信6个PDT团队的所有成员一定会有所共鸣。在过去的一年多时间里,对于书中所提出的必须由实际操作业务的人参与制定计划这一原则(P22)深深的体会。可以这样说,我们花了很长一段时间来组织实施项目团队来实施他们的计划。虽然说至今我们的项目团队在逐步形成这一习惯,但由于长期以来我们的项目开发人员都习惯于自己不做计划、然后又不认同别人所给自己的计划,于是当产品进度延期时,我们有太多的理由需要申述。由项目团队来制定自己的计划这一工作我们还将推进下去,直到我们的所有项目组都能自己制定适合的计划为止,到那时,我们才可以说我们在组织实施计划的工作。
从本书的P25到P30页,作者提出了项目管理系统的概念,并指出:成功的项目管理离不开一个良好的项目管理系统。项目管理系统包括七个部分,它们分别是:人的因素、文化、方法、组织、计划、信息、控制。作者把人、文化、方法等纳入了项目管理系统的范畴,这样一解释的话,我似乎又打通一个关节。
关于项目管理系统的七个方面,不作更多的解释,因为要解释的话,无非是把该书从P25页一直抄到P30页。虽然前面说准备好抄书,但大篇大篇地抄似乎又有点不太妥。在这里,只抄几个原则:
原则:项目很少因工具而失败,却常常因人而失败(P26)。流程不能提升人的业务能力,但它会暴露我们的业务能力缺陷。我们目前推行的集成产品开发流程正在暴露我们在业务方面的各种缺陷,这个缺陷以前也存在,只不过没有被暴露出来而已。因此,在接下来的工作 中,对于暴露出来的各种问题,各业务单元要以开放的心态去面对,事实上,谁最先面对自己的问题,谁就可能最先获得业务能力的提升。
原则:如果没有计划,就不会有控制。对于计划的重要性,相信大家都非常之熟悉,但像本书中这样来描述,其实是非常之让人感觉痛快的感觉。我们以前没有计划,但大家心里可能会说,没有计划没关系,我们在做控制的工作呢。从本原则中,没有计划,就没有控制,那我们自己认为的控制到底是什么工作呢?大家可以深思一下,可能我们经常所听到的如下对白,大家都是非常认真的实事求是的:
“最近在忙啥呢?”很随意的一句问话。
“没忙什么,瞎忙。”天啦,谁说中国人不谦虚,又有谁敢说中国人不诚实呢?别人随意的一句问话,我们就会实事求是地、谦虚地回答。是的,我们很多人在工作中都在瞎忙!这可是我们自己所说的。
接下来作者介绍以他自己的名字命名的刘易斯项目管理方法。在此处作者也提出了两个原则:
原则:这个思考过程适合于任何项目,无论它的规模或者种类如何。我们的项目一年下来大大小小几百个,但无论项目大小都得有项目管理的思考过程,但项目的规模不同则使用的工具也不同。对于特别小的项目而言,做一个关键路径进度表几乎是在浪费时间,但有的项目缺了这样的工具则是几乎不可想象的。不过,也有人会进入误区,认为我的项目太小了,不需要规范的项目管理技术,这些规范的项目管理技术只适合于大型的项目。针对这种情况,《项目计划、进度与控制》书中P33页有这样一句话:我想,很多情况下这是因为他们把这个过程思考与准备文件混为一谈了。书中还举了一个例子:如果我正在准备一顿饭,我仍然需要经过这些思考程序,但我完全没有必要为此准备一大堆文字报告。于是,作者又提出一个原则
原则:思考过程不同于制作书面文件。
该方法在本书的P34-P35页有一个流程图,不过可别想着照搬,人家可是申请了专利的(P33页)。看到这里,我不由得佩服老美的专利意识,不知情的人甚至会说,就这么点破玩艺也申请专利,缺钱了是不是啊。不管怎么说,现在是提倡专利意识,不申请那就自认倒霉吧,也别后悔四大发明没有申请专利,如果真的申请得到保护的话,或许中国在几千年前就发财了,比现在的英国这样的财主还富呢。写到这里,也得提醒我们自己,关于研发流程方面的IPD、PACE应该都是有专利的,如果要学的话一定得慎重。即使用了,也得站在专利的角度绕道,否则一旦当我们学会了,别人来找我们收钱的话,那可能比收一个产品的专利还多。
刘易斯的项目管理方法包括5个步骤。定义、战略计划、实施计划、执行与控制、总结教训。这5个步骤相信对公司的每一位都不会太过陌生,即使没有学过项目管理的人,对这样的5个步骤也不会觉得很新颖的。因为这是我们大家在做很多事情的时候的一个思维过程,只不过用语稍微专业一点罢了。事实上也仅此而已,但刘易斯把他申请了专利。
关于这5个步骤的简单介绍,请大家参阅本书P36-P37。

作者: 雨的快乐    时间: 2007-7-30 09:50

现在好像是到第九版了,家人有第九版的英文电子版吗?我在做项目管理工作,现在正在看这本书!


作者: liquanfei    时间: 2007-8-2 08:08

第2章:让您的组织相信项目管理
一个组织不支持进行项目管理,甚至反对员工为项目管理所做的努力,原因一般有两个:一是观念问题,另外一个则是因为项目管理可能会带来的痛苦。非常值得庆幸的是,公司推行项目管理是至上而下,不存在这个问题。在本章中,有几个原则非常值得我们熟悉:
原则:地图不等于边界;就是说,观念未必就符合现实(P41)。
原则:所有的行为都是为了满足个体的需要
原则:一个人可能只掌握了一种满足自己需求的方法
原则:观念决定我们的行为――行为总是与观念保持一致的
原则:观念成为自我实现的预言;换句话说,我们相信什么,什么就会变成现实。
原则:只有改变人的观念,才能改变人的行为。
原则:如果您相信所有的行为都是由基因决定的,那么个体就无法控制其不良行为。
原则:您无法在一个不相信项目管理的组织中推行项目管理

原则:观察人们所做的事,就知道人们相信什么。
原则:好的东西总是容易让人上瘾。
没有好计划,却产生好结果,是因为好运气,而非好的管理
                                                                     ―――David Jaquith
原则:人们总是倾向于回避痛苦,追求快乐。
原则:在组织内成功地推行项目管理需要文化上的改变
原则:我们都需要身在高位的朋友为我们的组织引入改革

第3章:项目经理的作用
说句心里话,对项目经理这样的称呼已经麻木。这有点像中国家电市场的概念炒作,已经到了严重透支的地步。大到一个工程负责人小到一个很小项目的硬件设计师也叫项目经理,我敢说,在公司被非正式称呼或者名片上有项目经理头衔的不下百人。如果这些人都是真的项目经理的话,则是公司之大幸,居然培养出了这么多的项目管理人才。
可以说,每个人都想成为经理,经理人拥有好的社会地位。在很多场合,经理人等同于成功者,在项目组内部,能够成为项目经理那简直就是一种荣幸。使人们想成为项目经理的另外一个原因,就是来自于人们的控制欲。人们希望控制别人,而不是被控制。


作者: zbgj001    时间: 2007-8-2 11:47
提示: 作者被禁止或删除 内容自动屏蔽
作者: liquanfei    时间: 2007-8-2 12:09

如果是从事项目管理工作的,最好看看。


作者: tigerwhp    时间: 2007-8-2 20:22
以前有粗略看过一遍,但是当初还没有真正理解项目管理,印象不是很深。前几天刚好翻了一下,觉得很有必要再看看。
作者: liquanfei    时间: 2007-8-8 15:07

走进第二篇:项目定义

 

5章:无头小鸡项目(以及如何避免)

要承认,我们也会有不少这样的项目,在项目一开始时,其实就已经决定了它失败的结局。在本书中,作者用无头小鸡来形容这样的项目。当鸡头被砍掉的时候,它的身体还会留着血跑动一会,然后才倒下去。原因在于信息从大脑 传递到身体的各个部分还需要一段时间。产生这样的项目其实我们大家都很清楚,一般更多的人都归咎于规划,再具体点说就是产品的定义没有做好。在这里,作者提出了一个原则:项目往往失败于开始,而非结尾。(P79)而出现这样的问题,最重要的在于团队人员不知道到底在做什么!当开始一个项目时,我们一般是部分领导说要开发一个新产品,然后组成了一个项目组。一群人开始按照既定的流程着手该新产品的开发。其实,在这个团队中,有很多人是不知道为什么要开发这个新产品的,但遗憾的是他们都不愿意说出来。有一个原则:社交活动中,许多人即使不明白别人的意思,通常也不会说出来。(P81)原则:错误的意见统一是没有处理好不同意见的结果,因为没有人知道不同意见依然存在。(P82

要想避免无头小鸡这样的项目,最好的办法就是让小组成员积极地参与到项目定义中去,包括项目面临什么问题、需要执行什么任务、希望得到什么结果等等(P82)。关于小组成员参与项目定义,我们目前仍旧局限在部分项目,大部分的项目主要是市场部或销售公司个别产品经理,而他们实际上没有完全融入到产品的开发过程中。而在几年前,新产品的定义基本上由大领导来决定的,因此,在就怎样做好产品的定义方面,我们还有一段路需要摸索,在这个摸索过程中,还会不断有无头小鸡式的项目出现。

让一个团队知道在做什么,对于项目经理来说非常重要。因为项目经理的首要目标就是让团队对任务取得共识。(P85)这句话说起来轻松,执行起来可不是那么回事。记得在6月份备战十一财季新品时,让各PDT形成十一财季产品清单前后花了差不多三周的时候,其结果也不是非常之理想,在备战 过程中出现了不少变更。因为PDT要经过市场代表、销售代表、开发代表的初步意见后,再征询市场部门、销售部门以及相关业务单元领导的意见,在形成一致意见的情况下再提交新产品进度委员会交由事业部领导批准,其过程可以说是一个力量悬殊的博弈。不过值得我们高兴的是我们听取了各方面的意见尤其在最先征询了项目组成员的意见,虽然后面与相关部门领导的博弈中处于下风,但也可以提前让团队成员知道一些项目的真实情况以及可能面对的困难。

有了十一财季新品的开发任务目标统一的经验,在准备春节财季的产品清单时候,我们发现虽然也会花差不多两周的时间,但相比之下,效率提高了不少,我们觉得,花这个时间去统一整个团队的思想和认识是非常必要的。

让团队成员参与到任务的制定,不仅仅是让成员理解项目的任务、前景以及困难,更重要的是通过一系列这样的任务,形成团队的愿景。(愿景:最终看起来是什么样子。P86)当人们失去愿景时,他们已经死亡。(P86)说到这里,我不由得想起当初产品线管理办形成自己的愿景时的场景。记得去年78月份的时候,大部分可以说是稀里糊涂地就被调进了产品线管理办,因此,形成产品线管理办的愿景显得非常之必要。于是在内部大讨论之后形成了“成为多媒体产品管理中心”的愿景。现在看来,那是一场非常有必要的意见大统一。现在,随着项目管理在产品研发方面的不断深入,我们很多人都越来越感受到一种强烈的使命感:将项目管理在多媒体事业部向前推进!因为这些将成为公司宝贵的无形资产,也是公司今后持续发展的坚实保证。当有了这种使命感之后,我们感觉很轻松,即使遇到再大的困难,即使有再大的不满,在强烈的使命感面前,这些都不算什么。


作者: liquanfei    时间: 2007-8-8 15:09

走进第二篇:项目定义

 

第5章:无头小鸡项目(以及如何避免)

要承认,我们也会有不少这样的项目,在项目一开始时,其实就已经决定了它失败的结局。在本书中,作者用无头小鸡来形容这样的项目。当鸡头被砍掉的时候,它的身体还会留着血跑动一会,然后才倒下去。原因在于信息从大脑 传递到身体的各个部分还需要一段时间。产生这样的项目其实我们大家都很清楚,一般更多的人都归咎于规划,再具体点说就是产品的定义没有做好。在这里,作者提出了一个原则:项目往往失败于开始,而非结尾。(P79)而出现这样的问题,最重要的在于团队人员不知道到底在做什么!当开始一个项目时,我们一般是部分领导说要开发一个新产品,然后组成了一个项目组。一群人开始按照既定的流程着手该新产品的开发。其实,在这个团队中,有很多人是不知道为什么要开发这个新产品的,但遗憾的是他们都不愿意说出来。有一个原则:社交活动中,许多人即使不明白别人的意思,通常也不会说出来。(P81)原则:错误的意见统一是没有处理好不同意见的结果,因为没有人知道不同意见依然存在。(P82)

要想避免无头小鸡这样的项目,最好的办法就是让小组成员积极地参与到项目定义中去,包括项目面临什么问题、需要执行什么任务、希望得到什么结果等等(P82)。关于小组成员参与项目定义,我们目前仍旧局限在部分项目,大部分的项目主要是市场部或销售公司个别产品经理,而他们实际上没有完全融入到产品的开发过程中。而在几年前,新产品的定义基本上由大领导来决定的,因此,在就怎样做好产品的定义方面,我们还有一段路需要摸索,在这个摸索过程中,还会不断有无头小鸡式的项目出现。

让一个团队知道在做什么,对于项目经理来说非常重要。因为项目经理的首要目标就是让团队对任务取得共识。(P85)这句话说起来轻松,执行起来可不是那么回事。记得在6月份备战十一财季新品时,让各PDT形成十一财季产品清单前后花了差不多三周的时候,其结果也不是非常之理想,在备战 过程中出现了不少变更。因为PDT要经过市场代表、销售代表、开发代表的初步意见后,再征询市场部门、销售部门以及相关业务单元领导的意见,在形成一致意见的情况下再提交新产品进度委员会交由事业部领导批准,其过程可以说是一个力量悬殊的博弈。不过值得我们高兴的是我们听取了各方面的意见尤其在最先征询了项目组成员的意见,虽然后面与相关部门领导的博弈中处于下风,但也可以提前让团队成员知道一些项目的真实情况以及可能面对的困难。

有了十一财季新品的开发任务目标统一的经验,在准备春节财季的产品清单时候,我们发现虽然也会花差不多两周的时间,但相比之下,效率提高了不少,我们觉得,花这个时间去统一整个团队的思想和认识是非常必要的。

让团队成员参与到任务的制定,不仅仅是让成员理解项目的任务、前景以及困难,更重要的是通过一系列这样的任务,形成团队的愿景。(愿景:最终看起来是什么样子。P86)当人们失去愿景时,他们已经死亡。(P86)说到这里,我不由得想起当初产品线管理办形成自己的愿景时的场景。记得去年7、8月份的时候,大部分可以说是稀里糊涂地就被调进了产品线管理办,因此,形成产品线管理办的愿景显得非常之必要。于是在内部大讨论之后形成了“成为多媒体产品管理中心”的愿景。现在看来,那是一场非常有必要的意见大统一。现在,随着项目管理在产品研发方面的不断深入,我们很多人都越来越感受到一种强烈的使命感:将项目管理在多媒体事业部向前推进!因为这些将成为公司宝贵的无形资产,也是公司今后持续发展的坚实保证。当有了这种使命感之后,我们感觉很轻松,即使遇到再大的困难,即使有再大的不满,在强烈的使命感面前,这些都不算什么。


作者: liquanfei    时间: 2007-8-22 09:47

 

走进第三篇:项目计划(P111

本篇包括第6章:项目战略:好的实施计划首先要有正确的战略;第7章:制定实施计划;第8章:项目风险管理;第9章:制作项目进度表等四章的内容。由于几乎所有的项目管理书都将项目计划、执行、控制等作为其重点讲述的内容,因此对于各方都非常重视的这一重点内容,在此仅介绍本书一些对我们的很大启发的内容。

首先,刘易斯项目管理方法提出了项目战略的概念,这在其他的项目管理书上很少提及的。所谓项目战略,作者解释为:战略就是完成一个项目的总的方法,有时又称为游戏计划。(P114)项目战略其实在我们的产品开发中已经在应用,只不过我们不太注意罢了,如技术方案的外包、模具开发的外包等都属于项目战略,甚至请外国设计公司为我们公司设计造型等也可以纳入项目战略的范畴。

此外,在本书的P114提到了技术策略这一概念,在我们进行产品开发时,技术策略显得非常重要,而且也是我们容易忽视的。在选择技术策略时,一条总的原则是,如果对项目的完成时间要求很严格,就不能使用没有把握的技术(P114)。就在刚刚结束的新品战役中,我们就违反了这一规则!一些非常重要、进度非常迫切的项目就使用了一些不太有把握的技术,虽然有这个或那个的理由,但这始终是违背了技术策略的选择原则。违背原则办事情是要付出代价的,今天不付,明天可能就要付;这次运气好没有付,但常走夜路必撞鬼,这是一个值得我们高度重视的!

在第七章制定实施计划中,本书也有不少精辟的论断。如P134页中有一句话:最大的激励就是时间底线(Nolan Bushnell),意思是当给团队一个时间底线时,他们会爆发出您意想不到的能量。看了这里,大家多少明白了,在我们应对一些不可思议的进度计划时,PDT团队受到了最大的激励--时间底线,所以在几个财季的部分新品的进度上创造了奇迹。这本书给了我们答案。

我们在做计划时,常犯一些错误。作者归纳了一下有五个。

错误1:不让具体执行工作的人参与制定计划

原则:计划的首要原则就是让具体做事的人参与到计划制定中来。P136

错误2:准备-开火-瞄准

原则:时间底线越严格,计划就越重要P137

错误3:大刷子计划P138 大刷子意指比较粗的计划

原则;把棒球场估计作为目标时不认真的。P138

错误4:微观计划

原则:计划细节永远不要超出您的可控范围P141

错误5:制定计划不考虑风险

原则:忽视潜在的风险并不等于“能行”,相反,它时鲁莽的项目管理方法

原则:事情变糟的可能行总是要比变好的可能性大。P142

在本书的第9章,P183页,建议所有的领导们都仔细阅读和体会一下。在这里,重点讲解了关于资源配置的问题。长期以来资源配置是我们的一个难点,同时也可以说是一个盲点。我们在做计划时基本上没有去考虑资源配置问题,也没有专门进行相关的研究。我们一年到底要开发多少项目,开发这么多的项目到底需要多少人?如果这个问题如果回答不上来,那基本上可以说我们目前基本上还没有考虑资源配置的问题。目前很多业务单元都说人手紧缺,但到底需要多少人才刚好呢、各业务单元所要求的人员数量是否合理呢?我想,这些问题是到时间回答的时候了。

几乎是每天,都会听到设计师对我说,哎呀,最近太忙了。我相信他们都说的是实话,因为从项目组成员来看,不少项目都集中在几个设计师身上,他们同时做着太多的项目,而更严重的是各级领导给予他们太大的压力。在P185页,作者提出了一个启动时间的概念。所谓启动时间,指的是当人们同时从事着不止一个项目时,就要不断地在项目之间转来转去。这种复合任务地问题在于,每一次转换时人们都需要“调整适应”;用平常的话说,就是人们需要时间来确认自己上一次做到什么地方,现在做到哪里等等。这种附加时间在制造业中被称为“启动时间”。而时间专家的结果表明,从一个项目转到另外一个项目大致需要10-15分钟的启动时间。

在给同样一批设计师安排太多的项目时,我们有必要考虑启动时间。这样的情况我们在前面的三个财季都遇到了,而且还比较严重。

紧接着,作者在P186页抛出了一个更有意思的概念:排队等候理论。并认为:进入一个系统要等待的时间取决于系统已经承载的负荷。一个工厂的平均负荷不能超过85%,而大多数的工厂则是过分地实行“只要肌肉策略”,给做项目的人120%的负荷,作者认为这是非常之愚蠢的,当您没有多余储备时,便无法应对突发事件、困难、甚至机会。正如墨菲法则指出的任何项目都要出现某些问题一样,当您犯了排队等候错误时,项目肯定要延期。

不知道我们的制造系统是否存在这个问题?

P188-189页,关于就怎样处理启动时间的问题作了一个详细的回答。作者的建议是减少它!怎样减少呢?通过项目的优先考虑。总的原则是,任何人都不应当同时做2个或3个以上的项目。理想的情况是,一个人只做一个项目直到完成它,然后转入下一个项目。

看到这里,或许有的领导会说,这简直不可能,正如作者所说的,太理想化。但作者用他自身的经历给予了回答:这真的可能吗?肯定的。作者说他以前在一家公司工作,该公司新产品总是出不来,忙碌了一年多,什么新产品都没有出来,大家都在非常努力地力争完成新产品,于是领导告诉大家希望年底看到结果。接下来,该公司开足马力完成正处于各阶段的产品,打算在年底推出10-12种新产品。

但是,到了年底推出这么多的新产品,会发生什么情况?什么也不会发生。制造部门无法在这么短的时间里面制造出来,即使能制造出来,销售部门也很难把他们销售出去。

看到这里,有人会说,这是不是在写我们公司的实际情况啊,不是,我肯定地告诉大家,以上内容在本书的P188页,大家可以自己看。作者所讲的内容简直就在描述我们现在的情况。03年的时候,我们的新产品开发进度老是一延再延,销售部门成天嗷嗷叫,我们有太多的新产品在同时开发,但就是不见有新产品出来,我们所有的人都很忙,忙的结果是出不来产品,或许我们大家都弄不明白,今天,或许大家有点醒悟:我们用了太多的时间在“启动”上了。为了解决这个情况,公司专门成立了产品线管理办,对研发流程进行优化,04年我们一个重要的动作就是产品的ABC排序,公司领导给予了大力支持,我们将这个排序告诉所有相关人,公司相关部门中坚领导基本上人手一份我们的产品排序清单,当初我们也仅仅是一个尝试,不知道结果如何,但今天,我们已基本验证:ABC的排序工作是非常之成功的,今后还得继续下去。

不过,看上去是一个简单的产品ABC排序,但过程总不是那么顺利,或许是销售部门以前“饿”怕了的缘故,于是总是希望新产品的重要性全部排为A,这样的话产品就能一下子全部出来了,大家也知道,如果全部都是A的话,ABC还有什么意义呢?记得当初我们的一个参考ABC比例是343,但从目前来看,基本上没有一条产品是达到此标准的,A的比例基本上全部超过40%,有的产品线如海外在最先排序的时候基本上是70%以上的都是A,当然也有其特殊性。不过不管怎么说,ABC的比例基本上让我们尝到了甜头,只要是A的项目,基本上都能按时或提前完成。其实如果按照规划管理的角度来看ABC分类,这是一个非常简单和原始的管道管理思想,并不是什么高深的学问!以前在给部门人员讲解管道管理时候,我很喜欢举深南大道交通的例子。首先深南大道的宽度一定是有限的-三车道或四车道,再宽也不能是无穷大的,假设有100辆车要通过深南大道,要想在最短的时间让这100辆车通过,相信大家都会得出一个简单的结论:排队通过,不相信会有人说,我们让这100辆车同时并排通过。而事实上,在进行产品开发的时候,我们很多人都希望这100个产品同时开发完成,大家都忽视了我们各个系统的能力是受到限制的。在实际的运作中,到底哪些车先通过呢,其实很简单,把他们先通过的必要性和理由稍微整理一下即可。假设这100辆车中,有中央首长的、有地方首长的、有急救车、有消防车、平民百姓的车等等,把他们进行一个排序不会是太困难的事情,可以让急救车、消防车、中央领导的车、地方领导的车、平民百姓的车等这样一排序,整个深南大道的交通就会井井有条,从而不至于塞车,该通过的车不能在第一时间通过。

在进行ABC排序时或管道管理时,在与相关部门、领导进行博弈的过程中,让人很容易想起中国的一个词:舍得。是啊,我们做任何事情,先有舍才能有得,舍在前,得在后,有些东西我们必须要有舍得精神,才能得到更多。不舍便没有得。

        可能还会人不服气:我们就有无穷多的资源,我们是一家大公司,小公司不能做,我们能够做出来。好,即使我们的研发能够在年底把产品都开发出来,也假设我们的制造部门都能制造出来,也假设销售部门都能把这些产品卖掉,我们得到的是年底12月份的销售额,但假如从年初到年底都有新产品出来,那我们会得到稳定的新产品流,而新产品流所 带来的销售额则远远大于12月一个月的销售额。具体的图表参考P188P189

         这个问题非常值得我们深思。我们目前也遇到了这个问题:新产品过度集中某23个月 ,虽然我们的新产品流比以前已有较大的改善,而且我们大家都意识到了这个问题,但要实现稳定的新产品流,还需要我们大家的持续不断的努力。


作者: fatboy21cn    时间: 2007-9-22 23:28

怎么没有找到原版电子书籍下载?能否再次提供,谢谢

[em01]
作者: swordliang    时间: 2007-9-23 19:38

终于搞到一本中文版的,跟英文版一样通俗易懂

精读一下!


作者: 我客松    时间: 2007-9-25 15:49
呵呵,太高兴了,好久没上家园来看看,今天一眼就看见了“项目管理之道 《项目计划、进度与控制》读书感言 ”亲切的字眼,说起这本书,真是有表达不完的爱慕之情,它是我读过的第一本有关项目管理的著作,由此激发了我对项目管理这门学科的热爱,也促使了我对英语原版书籍的热爱,我从阿獭大侠那里下载了这本书的外文版,然而迫不及待地打印成书(尽管花了五十元整,但是比起外文原版书籍来说是相当的便宜了,并有收藏价值),结合学校图书馆的中文版,先看一遍通俗易懂的中文版,然后带着印象去看一遍英文版,觉得相当的有意思,看完两遍后,奇怪的是,我大学英语四六级一次性就全通过了,真是神奇,由此我自创了学习英语的方法:最好先从翻译过来的通俗易懂的各种中文版本题材入手,再在网上找到该题材的英文原版,带着中文印象感兴趣地读英文原版,这种进步简直就是惊人的,但前提是你最好自己先对中文版的内容感兴趣。今年三月,带着对项目管理的热爱(我专业是工程管理),我也在昆明蓝血项目管理有限公司(培训师:汪小金博士)参加美国项目管理协会最新推出的CAPM(助理项目管理师,是PMP旗下专门钟对大学生量身打造的认证,其与PMP考试的差别在于,它只考PMBOK上面的知识,而不涉及到任何经验性的情景题),并且一次性通过了考试,拿到了CAPM证书,前不久也翻译了一本关于CAPM的模拟题库。。。。而所有这些,都归功于刘易斯先生的《项目计划、进度与控制》一书,并且也在网上找到了几本有关项目管理的原版著作,如《fundamentals of project management>>by James P.Lewis.现在手头上没有带,下次一定上传与家人分享。我在家园发表的东东不多,今后一定努力上传一些,讨论一些,发表一些。我的联系方式QQ:441408572
作者: 我客松    时间: 2007-9-25 15:51
呵呵,太高兴了,好久没上家园来看看,今天一眼就看见了“项目管理之道 《项目计划、进度与控制》读书感言 ”亲切的字眼,说起这本书,真是有表达不完的爱慕之情,它是我读过的第一本有关项目管理的著作,由此激发了我对项目管理这门学科的热爱,也促使了我对英语原版书籍的热爱,我从阿獭大侠那里下载了这本书的外文版,然而迫不及待地打印成书(尽管花了五十元整,但是比起外文原版书籍来说是相当的便宜了,并有收藏价值),结合学校图书馆的中文版,先看一遍通俗易懂的中文版,然后带着印象去看一遍英文版,觉得相当的有意思,看完两遍后,奇怪的是,我大学英语四六级一次性就全通过了,真是神奇,由此我自创了学习英语的方法:最好先从翻译过来的通俗易懂的各种中文版本题材入手,再在网上找到该题材的英文原版,带着中文印象感兴趣地读英文原版,这种进步简直就是惊人的,但前提是你最好自己先对中文版的内容感兴趣。今年三月,带着对项目管理的热爱(我专业是工程管理),我也在昆明蓝血项目管理有限公司(培训师:汪小金博士)参加美国项目管理协会最新推出的CAPM(助理项目管理师,是PMP旗下专门钟对大学生量身打造的认证,其与PMP考试的差别在于,它只考PMBOK上面的知识,而不涉及到任何经验性的情景题),并且一次性通过了考试,拿到了CAPM证书,前不久也翻译了一本关于CAPM的模拟题库。。。。而所有这些,都归功于刘易斯先生的《项目计划、进度与控制》一书,并且也在网上找到了几本有关项目管理的原版著作,如《fundamentals of project management>>by James P.Lewis.现在手头上没有带,下次一定上传与家人分享。我在家园发表的东东不多,今后一定努力上传一些,讨论一些,发表一些。我的联系方式QQ:441408572
作者: 阿懒    时间: 2007-9-25 17:07
QUOTE:
以下是引用我客松在2007-9-25 15:49:38的发言:
呵呵,太高兴了,好久没上家园来看看,今天一眼就看见了“项目管理之道 《项目计划、进度与控制》读书感言 ”亲切的字眼,说起这本书,真是有表达不完的爱慕之情,它是我读过的第一本有关项目管理的著作,由此激发了我对项目管理这门学科的热爱,也促使了我对英语原版书籍的热爱,我从阿獭大侠那里下载了这本书的外文版,然而迫不及待地打印成书(尽管花了五十元整,但是比起外文原版书籍来说是相当的便宜了,并有收藏价值),结合学校图书馆的中文版,先看一遍通俗易懂的中文版,然后带着印象去看一遍英文版,觉得相当的有意思,看完两遍后,奇怪的是,我大学英语四六级一次性就全通过了,真是神奇,由此我自创了学习英语的方法:最好先从翻译过来的通俗易懂的各种中文版本题材入手,再在网上找到该题材的英文原版,带着中文印象感兴趣地读英文原版,这种进步简直就是惊人的,但前提是你最好自己先对中文版的内容感兴趣。今年三月,带着对项目管理的热爱(我专业是工程管理),我也在昆明蓝血项目管理有限公司(培训师:汪小金博士)参加美国项目管理协会最新推出的CAPM(助理项目管理师,是PMP旗下专门钟对大学生量身打造的认证,其与PMP考试的差别在于,它只考PMBOK上面的知识,而不涉及到任何经验性的情景题),并且一次性通过了考试,拿到了CAPM证书,前不久也翻译了一本关于CAPM的模拟题库。。。。而所有这些,都归功于刘易斯先生的《项目计划、进度与控制》一书,并且也在网上找到了几本有关项目管理的原版著作,如《fundamentals of project management>>by James P.Lewis.现在手头上没有带,下次一定上传与家人分享。我在家园发表的东东不多,今后一定努力上传一些,讨论一些,发表一些。我的联系方式QQ:441408572

恭喜恭喜。
欢迎多多分享交流。


作者: swordliang    时间: 2007-9-27 09:28
QUOTE:
以下是引用我客松在2007-9-25 15:49:38的发言:
呵呵,太高兴了,好久没上家园来看看,今天一眼就看见了“项目管理之道 《项目计划、进度与控制》读书感言 ”亲切的字眼,说起这本书,真是有表达不完的爱慕之情,它是我读过的第一本有关项目管理的著作,由此激发了我对项目管理这门学科的热爱,也促使了我对英语原版书籍的热爱,我从阿獭大侠那里下载了这本书的外文版,然而迫不及待地打印成书(尽管花了五十元整,但是比起外文原版书籍来说是相当的便宜了,并有收藏价值),结合学校图书馆的中文版,先看一遍通俗易懂的中文版,然后带着印象去看一遍英文版,觉得相当的有意思,看完两遍后,奇怪的是,我大学英语四六级一次性就全通过了,真是神奇,由此我自创了学习英语的方法:最好先从翻译过来的通俗易懂的各种中文版本题材入手,再在网上找到该题材的英文原版,带着中文印象感兴趣地读英文原版,这种进步简直就是惊人的,但前提是你最好自己先对中文版的内容感兴趣。今年三月,带着对项目管理的热爱(我专业是工程管理),我也在昆明蓝血项目管理有限公司(培训师:汪小金博士)参加美国项目管理协会最新推出的CAPM(助理项目管理师,是PMP旗下专门钟对大学生量身打造的认证,其与PMP考试的差别在于,它只考PMBOK上面的知识,而不涉及到任何经验性的情景题),并且一次性通过了考试,拿到了CAPM证书,前不久也翻译了一本关于CAPM的模拟题库。。。。而所有这些,都归功于刘易斯先生的《项目计划、进度与控制》一书,并且也在网上找到了几本有关项目管理的原版著作,如《fundamentals of project management>>by James P.Lewis.现在手头上没有带,下次一定上传与家人分享。我在家园发表的东东不多,今后一定努力上传一些,讨论一些,发表一些。我的联系方式QQ:441408572

祝贺你有如此的收获

谢谢你的分享

欢迎多交流多分享


作者: eastiger    时间: 2007-10-10 21:44
书呢???
作者: 腾格里    时间: 2007-11-13 15:43

我现在正遇到沟通管理的问题,有谁知道如何与农民有效沟通?


作者: qicer1997    时间: 2008-4-3 22:55
   我们非常渴望能有中文版本上传,请各位大侠分享
作者: Superhawk    时间: 2008-4-5 21:00

去书店看了看,缺货啊

当当也没得卖,555


作者: bobo012    时间: 2008-4-5 23:51
怎么没人发话了啊?
作者: 阿懒    时间: 2008-4-6 08:46
QUOTE:
以下是引用liquanfei在2007-7-30 8:14:53的发言:
上传总出问题,应该改善一下。


1.上传要到资源中心,压缩之后上传。
2.大小如超过4.5MB,需要分卷压缩。
3.更详细的说明请参考 栖息谷导游手册(http://www.21manager.com/home/dy.html)


作者: jlgreat    时间: 2008-4-10 22:35
非常好,很想看看这本书
作者: 腾格里    时间: 2008-5-28 12:56

在哪里可以买到?我已经找了很久。


作者: asionyaya    时间: 2008-7-28 16:47
其实,我更想了解如何做好项目的资料整理。由于自己不是做项目的人,却很想了解项目执行的过程和总结情况。如果哪位知道,给我一些意见。项目资料整理的步骤和注意事项,谢谢!
作者: lywwei    时间: 2009-10-19 22:12
有意思
作者: lywwei    时间: 2009-10-19 22:17
写得好
作者: anvang    时间: 2009-11-6 13:09

正在看


作者: helanxue08    时间: 2009-11-9 18:07

谢谢分享

 


作者: luoliu    时间: 2010-1-25 19:25
 这是一本好书,我一口气用了三个晚上把它读完(这在以前重来没有过),但象楼主这样做笔记还没有,我想再好好读读,然后做个读书笔记,消化为自己的东西
作者: yelifujiam    时间: 2010-2-4 11:15
谢谢楼主感言,让我有更多的动力去研读本书,学习学习再学习
作者: 54mygod    时间: 2010-7-18 00:16
很好,值得学习!!
作者: wfjdpx    时间: 2010-9-25 22:50
《项目计划、进度与控制》是本好书,我看了,但没有楼主认真,值得学习,书和楼主都值得学习!!!
作者: wfjdpx    时间: 2010-9-25 22:55
QUOTE:
以下是引用luoliu在2010-1-25 19:25:06的发言:
 这是一本好书,我一口气用了三个晚上把它读完(这在以前重来没有过),但象楼主这样做笔记还没有,我想再好好读读,然后做个读书笔记,消化为自己的东西

兄弟,你硬是有点凶哈,三个晚上能看完!!!!!严重怀疑


作者: lcj0321    时间: 2016-9-6 10:27
liquanfei 发表于 2007-7-30 08:07
第1章:项目管理概述几乎任何一本项目管理的书都会从介绍项目、项目管理的概念开始,本书虽然也如此,但却 ...

书里说的项目管理是“工具、人和系统”的综合,而不是像楼主说的“工具、人和过程”。英文版里面也说的是“tools,people,systems”。请问系统与过程的含义一样吗?我现在也有些困惑。可以一起讨论一下。
作者: youxinchn    时间: 2016-11-27 10:34
嗯,是刘易斯的那本么?我也正在看呢,感谢楼主的推荐。




欢迎光临 栖息谷-管理人的网上家园 (https://bbs.21manager.com.cn/) Powered by Discuz! X3.2