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

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年的时间。那时，我根本不知道还有其它方法的存在，我也完成了任务――而且他们还很满意。
问题是，我们没有意识到，其实我们的工作还可以做得更好。规范的项目管理（在流程上进行改变）真的能让您做到既快又省吗？
我想是的。
这段话，我觉得非常有必要抄下来，事实上，在写这篇文章的时候，我已决定要抄很多的内容，因为里面有太多非常精辟的论断。如果不把这些精华抄下来的话，我不会原谅自己。

liquanfei

上传总出问题，应该改善一下。

liquanfei

这段话，可以说是我们目前多媒体事业部大部分人心态的真实写照。十一新品战役完后，我就对很多人说，虽然我们完成了十一财季的新品开发任务，但千万别认为我们的项目管理就做得很好，我们确实是完成了任务――而且领导们还算满意，但是，我们应该清醒地意识到，其实我们的工作还可以做 得更好。
在前面，在写到关于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。

雨的快乐

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

liquanfei

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

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

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

zbgj001

很不粗的书吗，那我有时间也看看！

liquanfei

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

tigerwhp

以前有粗略看过一遍，但是当初还没有真正理解项目管理，印象不是很深。前几天刚好翻了一下，觉得很有必要再看看。

liquanfei

走进第二篇：项目定义

 

第5章：无头小鸡项目（以及如何避免）

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

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

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

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

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

liquanfei

走进第二篇：项目定义

 

第5章：无头小鸡项目（以及如何避免）

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

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

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

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

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