要想从头搞砸一个项目，最简单的方式就是不动脑子，直接开始。多做一点儿组织和规划的工作，就能为项目多保留一些成功的希望。项目经理必须知道项目的关键驱动因素是什么、项目要怎么样才算“完成”，而且还得把这些结论写到章程中，让整个项目团队都能了如指掌。
1.1　定义项目和项目经理
项目到底是什么？我们首先要有一个一致的定义。
项目：一个独特的任务或是系统化的流程，其目的是创建新的产品或服务，产品和服务交付完成标志着项目的结束。项目都有风险，并且受制于有限的资源。①
①　(C) 2007 R. 麦克斯?怀德曼，。经许可后转载。
项目经理负责管理风险和资源。交付日期迫在眉睫，技术目标难以达成，产品质量漏洞百出，项目资金即将告罄，人手面临匮乏困境----没有项目管理，贯穿于项目中的这些风险如何应对？
因为各自的关注点不同，每个项目都是独一无二的。项目经理要根据每个项目不同的实际情况，进行管理和规划。在启动之前，着手收集信息，了解项目要实现哪些目标。
我们的目标是什么？
----克里斯，项目经理
我是一个大公司的项目经理，主要负责软件和硬件的集成项目。我的同事妮姬负责主办各种活动。我的团队搭建电脑系统，而妮姬的团队负责活动组织----虽然彼此的产出根本不沾边儿，可我们都是项目经理。
我们面对的风险完全不同，对外交付的东西也根本不一样。我要的是软件、硬件以及一些文档，而妮姬需要展览摊位、食品、以及其他有助于活动成功的必备之物。
我们的工作有一个共同之处：开始时要知道项目的目标，这样就可以马上知道我们接下来要做什么了。知道要做什么、“完成”意味着什么，这对我和妮姬的团队很有帮助。
每个项目都是独一无二的。项目团队规模不同，各自的能力也有所区别。有些项目的客户是内部的，有些则是外部的。有些项目面临很紧迫的时间压力，有些项目则可能要面对其他威胁和风险。产品是每个项目的核心，让我们再就产品的定义达成共识。
产品：项目产生的一系列可交付物。
作为一名成功的项目经理，或者想成为成功项目经理的你，应该花些时间来发现当前项目的独特之处。这样，你就有可能成功地启动、管理和结束这个项目。
我们现在已经有了项目和产品的定义，接下来该搞清楚项目经理的职责了。怀德曼说，一个项目经理“被赋予管理项目的权力和责任，并带领项目团队，通过项目管理来达成项目的目标”。②这个正式定义还挺不错的。不妨看看下面这几句大实话，比较而言，也许它给人的感觉更加模糊，但同时也更准确。
②　(C) 2007 R. 麦克斯?怀德曼，。（经许可后转载）。
项目经理：负责向团队清晰说明完成的含义，并带领团队完成项目的人。完成，是指产品符合组织对这个产品的要求，也能满足客户使用这个产品的需要。
其中，完成的说法是暗含风险的。我可以确定任何项目的产品一定伴随着风险，我们会在后面讨论如何对这些风险进行识别和分类。在采取任何进一步行动之前，项目经理必须理解项目的关键驱动因素是什么。
无论规模大小----是项目就有风险
----埃里克，资深项目经理
我曾参与过延续数年、团队达数百人的大项目；也参与过一些小项目，我们的团队只有两三个人，客户也只有两到三个人配合，整个项目持续时间三个月。关于项目，我有一点非常确定：通往最终交付的道路上，总是有风险伴随在我们左右。
有时，风险因团队具体情况而不同。设想整理床铺这件简单的小事。对我来说，这只不过是待办事项清单上的一个条目而已。可我的孩子们却觉得，铺床就像是一个满是风险的项目，最主要的风险就是他们无法在睡觉之前把床铺好。
1.2　管理项目的关键驱动因素、约束和浮动因素
要完成一个项目，如果不能理解项目的背景，前进的路上必然充满艰险。
项目的背景是由所在组织的关键因素决定的。项目的驱动因素是什么？是否存在约束？有没有可能在驱动因素和约束之间进行折中？项目经理能否为自己争取更多的自由运作空间？
当前项目的驱动因素与上一个不同
----斯图尔特，项目经理
我现在正在管理我个人的第二个项目。第一个项目的交付物是公司旗舰产品的一个补丁版本，因而很容易就能知道我们的工作重点：添加几个功能特性，并修复多个缺陷。
但是这第二个项目----哎，可完全不一样了。这个项目会被用作目标市场的探路石。我们需要很多新功能，这些功能还得没啥大问题。工作重点不是解决缺陷，因为交付日期马上就要到了，得赶紧让产品投入市场。老板跟我说可以多给我几个人，但是不会有外包公司参与，因为要控制成本。
能够识别出哪些事情在推动项目让我获益匪浅。我发现优先级最高的就是功能，其次是交付日期，接下来是人。只要能发布，公司对于缺陷和成本卡得就不是那么死了。
也许大家都听说过项目的“铁三角”：成本和时间是这个三角形的两条边，第三条边一般是质量或范围（见图1-1）。其实铁三角过于简单了。斯图尔特的两个项目的驱动因素就存在很大差异。
图1-1　传统的铁三角
像斯图尔特这样成功的项目经理会权衡许多因素，而不仅限于铁三角。以为只要让客户从铁三角中选择他最看重的两条边，然后就可以交付他想要的结果，这根本是痴人说梦。要是这么简单的话，那任何人都能当项目经理了。
首先，要写下客户的期望----从客户的角度来看，项目的驱动因素是什么［Rot98］。这个列表中应该包括：客户想要什么（功能集合），他们期望何时收到交付物（发布时间），可交付物的质量如何（缺陷等级）［Gra92］。
接下来，写下项目的约束。环境是什么样子的？能否灵活安排团队的位置？必须遵守什么样的流程？手下的人有哪些？他们能做什么？预算有多少？这些约束是可以改变的（一般只有项目出问题的时候才能改变）。约束决定了项目的规模（还有持续时间和质量）。
对比客户的期望列表和项目的约束列表。你脑海里蹦出来的项目成功的必要因素有哪些？选择其一，比如发布时间，这就是识别出来的项目的关键驱动因素。
列表上还剩下什么？应该还能看到功能集合、低缺陷率、发布成本等条目。在这些条目里，需要对哪些进行管理才能保证项目的成功？可以按重要性排列这些关注点。客户和出资人会在这些方面上对项目形成限制。从中选择两到三项，我们称之为项目的约束。
再看看剩下的条目。有些条目很重要，不过它们有很大的调整余地，我们称之为浮动因素。一个项目至少要有三个浮动因素。
最后看看还没选择的条目，是不是还有哪个比已经选择的更重要呢？如果有，那就再调整一下；如果没有，这个项目的关键驱动因素、约束、浮动因素就都识别出来了。
我曾经见过有三个约束的项目，团队必须付出超乎寻常的努力，才能保证项目成功。以我的经验，如果项目有一个关键驱动因素、两个约束、三个浮动因素，那它的成功几率还是不小的。浮动因素越多，项目就越容易管理。
理想状况下，关键驱动因素应该只有一个，约束应该只有一个，而浮动因素可以有四个。大部分情况下，我们管理的都是不那么理想化的项目，所以如果项目有一个关键驱动因素、两个约束、三个浮动因素，这也是可以成功的。过多的关键驱动因素或约束，会让项目过于受限。这种情况下也许能够成功，但是项目经理和团队就得选择促成项目成功的组织形式和实践----不过还是要有点心理准备，因为可能无法获得百分之百的成功。
如果存在过多的关键驱动因素和约束，而且项目经理除了启动项目之外别无选择，这时所能做的就是选定一个关键驱动因素，并尽可能频繁地向出资人提交项目的产出，帮助他们决定自己真正想要的东西。在启动项目的时候，为了得到项目的成功条件，可以问一些与上下文无关的问题（请看1.5节）。还要定义出发布条件（请看2.3节），这样就知道到什么程度算做完了。
提示：要是约束太多了，你就自己作决定吧
受到过多限制的项目难以逃避失败的厄运。过多的关键驱动因素，意味着没有人知道成功的条件是什么。过多的约束，意味着组织中没人愿意去判断孰轻孰重。
有必要的话，让管理层决定项目的关键驱动因素、约束和浮动因素。如果这不可行，那项目经理就自己作决定吧；项目和组织会因此而受益。
想创建出不受约束限制的项目需求是不现实的。假设有一个可以承重5斤的书包，如果你硬要往里面塞10斤的书，不外乎两种结果：要么书包带断掉，要么书包底破掉。管理项目也是如此，要根据约束来管理需求。要想同时应付过多的需求，那不管用什么办法，人手、时间、预算还有工具这些资源可能就是不够用，发布出的产品也很难具备高层想要的全部功能，同时可能有很多缺陷。
1.3　与客户或出资人讨论项目约束
要主动理解出资人想要的东西。下面这段谈话就是我在最近的项目中与出资人的对话。
JR：哎，克莱德。咱们看看到底是什么在驱动这个项目吧。
克莱德：可别！别再整我了。上个项目的时候，你就让我做过一次了啊。
JR：没错。还记得吗？你当时想添加新功能。你希望在产品发布之前塞进去尽可能多的功能，我可以加，因为当时组织项目的方式还允许。那确实挺不好弄的，不过还是有可能做到。
克莱德：啊，对，我忘了。不过这个项目不一样啊。
JR：哦？跟我说说。
克莱德：你瞧，管人是你的事情，项目的运作情况你也得管。不过你不需要资金，我也不担心成本问题，因为唯一的成本就是工资。
JR：还有软件呢。
克莱德：你还真挑啊。好吧，如果需要什么软件，跟我说。不过老实讲，基本上工资就是这次的全部成本----我也不用管，我最关心的是项目要多久才能完成。
JR：那需要哪些功能呢？对它们的质量有什么要求？这是给财务部门用的一个小程序，你也知道他们总是要求完美。要是我不能保证给他们的东西毫无问题，莱斯丽会跟上面吹风的。
克莱德：没错，不过我会帮你扛着的。我就是希望给他们够用的功能就行了，这样你跟你的团队就能很快搞定，比如在十周之内。
JR：如果到了第八周，我们还没有开发完所有的功能，而且还有很多bug要改。你会怎么想？
克莱德：JR，别啊。我需要全部的功能。你们开发团队曾经完成过类似的工作，我相信这次也一定行。
JR：克莱德，如果我能理解你到底想要什么，你知道，我们开发团队会尽力而为的。
克莱德：好吧。千万不能有不完整的功能。你尽管开始，把它做完，而且要让莱斯丽喜欢它。否则，她非把我头砍下来不可。文斯已经启动了一个大型的项目计划，过段时间，我想让你们开发团队加入到那边去。他说已经准备好在十个星期后接收更多的人了。这样，你也有足够的时间来给莱斯丽一点儿用得上的东西。
1.4　决定项目的关键驱动因素
在与克莱德的对话中，我让他说明他最看重的是什么。克莱德说一个大型计划会在十个星期之后启动，很明显，日期就是这个项目的关键驱动因素。
在项目早期，似乎一切皆有可能，特别是没有估算任何工作的时候。出资人可能会说：“我们想要这5个功能，在8月1日之前完成，还不能有严重的问题。我们还想让你把成本控制在一百万美元之下。给你这6个人。OK？”
可别轻易说OK。
估算了工作量之后，就能知道用这么多钱、这么长时间，这6个人能不能做完项目。要是可以，蛮好。不过很可能没有办法按照出资人对时间、金钱、人力的要求，在规定的工作环境中，提供符合他们质量要求的产品。此时，出资人需要做出艰难的决策，要考虑组织中的项目驱动因素，比如发布日期、功能集合、成本、人员分配及其分配时间、将要采用的技术和实践，等等。
要是出资人不愿意判断项目的驱动因素是什么，这个责任就落到项目经理肩上了。如果项目经理不做决定，团队自己会决定。但是他们会各拿各的主意，而且这些主意也不一定会符合出资人的想法。实际上，每个人----不管他或她在项目中的角色是什么----都会根据自己的想法进行判断。有的人会优先考虑发布日期的限制，从而把减少缺陷的想法抛在脑后。有的人会根据日程安排，仅仅实现一个功能----一个包含完整回归测试套件的功能，其余的功能却都没做完。有的人会优先考虑实现功能集合，开发出尽可能多的程序桩（stub），当测试人员发现问题时再去填充，直到时间用完为止。每个人都会做自己认为正确的事，而不是从出资人（或项目经理）的角度出发，因此做出的决策彼此不同。
通过制定优先级列表可以解决这个问题，其过程跟做数独游戏有些类似，即将所有可能的驱动因素列在左边，右边空出来等着填数字。
使用矩阵表明项目的优先级
下面是克莱德的排序矩阵。
项目驱动因素　　　排序
发布成本　　　　　　5
发布日期　　　　　　1
功能集合　　　　　　2
减少缺陷　　　　　　3
人员配备　　　　　　4
工作环境　　　　　　6
在这个项目中，发布日期是最主要的驱动因素。如果产品今年不能发布，这个项目就没有什么存在的意义了。但是完备的功能也很重要----功能不齐全，即使及时发布，整个项目也没有价值。而且，由于公司业务属于受政府管制的行业，产品的缺陷率必须很低。接下来是人员配备，因为只要这些人能在十个星期之后参与下个项目计划就可以了。项目的成本控制不太重要，因为项目的价值会很高。工作环境排在最后，为了保证及时交付，我可以灵活调整某些事情。
即使已经有了排好顺序的优先级，我们还是没有多少灵活性。不过了解了项目的关键驱动因素，我就可以定义出项目的成功条件，并选择适合项目的生命周期了。项目团队可以制定出发布条件，并根据驱动因素合理地安排各自的工作。嗯，最后，我们按照当初的要求，成功地交付了项目。
1.5　应对喜欢过多干预项目的出资人
在绝大多数情况下，关于成功标准的谈话不会进行得那么顺利。读者也可以看到，我必须促使克莱德做出选择。类似情况很常见。
有些项目对于功能集合、减少缺陷、时间安排这三者的要求都是最高的，而且优先级相同。我敢说，读者一定以项目经理或团队成员的身份参与过类似项目。你不能再给团队添加更多人手了，而且项目的预算不可改变。项目流程必须按照公司的强制要求执行，还得使用公司规定的办公室和家具，其他一些工作环境问题也让项目难以推进。除非没有技术或时间上的风险，否则没人能够使这样的项目取得成功。不过还是有一些方法，能够理清这些看来已经没有活动余地的约束条件。
在1.4节中可以看到项目的驱动因素矩阵。如果出资人愿意排定优先级，那这种方式再好不过了。有些勉强的出资人可能因此而变得更加坚定。项目经理有时要先草拟一个优先级列表，拿给出资人看。比如，几个出资人对于优先级的排序可能无法达成一致意见。要是出资人不愿意拿主意，项目经理就只好自己做决定，然后再给出资人看。她可能会愿意去修正列表，或者直接签名通过这个列表，自己就不再建新的了。
要想明确项目真正的驱动因素，有两种不同的途径可供选择：预测未来；使用与上下文无关的问题。
1.5.1　预测未来
让出资人设想这样的情况：现在离项目预定交付时间只剩三个星期，却还有功能尚未实现。（可以着重讨论该出资人需要的一两个功能。）除了没做完的功能之外，还有很多严重的缺陷等着修复。这样看来，要想在预定的发布日期之前开发完所有的功能并修复所有的缺陷，很明显是不可能了。这个时候，出资人该怎么办？
如果出资人这么说：“把你的脑袋砍下来给我吧。”那就该考虑“三十六计走为上”了。请看7.7节。
不过出资人很可能会这样说：“把这个该死的项目做完吧。你还需要几个人？”接着，你可以问他：“是先做完所有的功能，还是先修复所有的缺陷？”他一般会说：“这两个功能和这些问题都得解决掉。”再问他：“以项目目前的优先级顺序，是吗？”项目经理要经常帮助出资人搞清楚：哪些约束是真正的约束，哪些是出资人自己一厢情愿的想法。
在对话中使用与上下文无关的问题，有助于识别出项目的驱动因素、约束以及活动余地。
1.5.2　使用与上下文无关的问题识别项目真正的驱动因素
明确了驱动因素之后，项目经理就可以发掘项目的需求了。与上下文无关的问题有助于抽取出这些需求。通过这些比较抽象的问题，可以诱导其他人说出他们对于项目的假设。不妨从下面这些问题开始。
项目要怎么样才算成功？
为什么想得到这样的结果？
这种解决方案对你来说价值何在？
这个系统要解决什么样的问题？
这个系统可能会造成什么样的问题？
要注意，少用“为什么”之类的问题。“为什么”问得越少，对于业务需要反而能了解得越多（而且问问题的人也不会像个令人厌烦的三岁小孩子。）同时，“为什么”这类问题很容易让对方产生戒心。也得注意避免“怎么做”之类的问题，出资人会觉得你在让他们设计系统。
在问问题时，要让人感觉到你真心希望了解这个项目，而不要让别人抱有戒心。这些问题可以为项目经理和出资人将来的合作打下良好的基础，而不是形成龃龉的关系。
这些问题可以找出系统的价值所在。在向出资人提问时，要营造平等的气氛。在纸上做笔记，而不是用电脑，这样你和出资人之间就不存在障碍了。将这些问题作为谈话的开端。在刚开始时，从出资人处收集到的关于项目价值的信息越多，你就能更深入地了解如何设计这个项目。
项目要怎么样才算成功？
----贾斯汀，项目经理
几个月前，我开始管理这个会持续两三年的项目。这两天，老板跑过来跟我说他想加入一个新的功能。一个我在说：“酷啊，这个新功能一定会很棒的！”而另一个我说：“噢不，我们介入这个项目已经两个月了。要是我给老板留下可以随意加入新功能的印象，如果不调整我们团队的工作方式，那我一定会有麻烦的。”于是，我问老板这个问题：“对你来说，项目要怎么样才算成功？”
使我大吃一惊的是，老板认为这个项目要能完全随需应变才算成功。他十分确定：不到最后一刻，需求不会停止变化----也许要到我们发布前一周才能最后明确。我以前可从来没有管理过类似的项目！不过既然现在知道了，我就能着手筹划应对之策了。
1.6　编写项目章程，共享现有决策
项目章程会明确记录项目的需求和约束，还可以帮助项目经理思考如何进行项目规划。整个团队和出资人都可以查看项目章程，以此确保他们对项目有关的决策可以达成一致。
在启动项目时，编写项目章程可以让大家知道应该完成什么目标，以及项目干系人提出的约束条件。即使不知道完成项目需要的细枝末节，编写章程也有助于发现潜在的问题。项目章程可以帮助项目经理和团队理解风险、成功标准，而大家也可以藉此考虑组织和操控项目的方式。
如果你在管理一个敏捷项目（使用敏捷生命周期的项目，请查看附录A.4节），项目章程会很简短，只要包括项目远景（参与项目的人可以做出正确的决策）和发布日期（这样就不会为了给产品“镀金”而错过项目的结束时间）就够了。
下面是我的项目章程模板。
项目章程是有意要设计成这么简短的，目的是帮助团队赶紧启动。它不会包含团队对于这个项目“完成”的定义，也不会介绍团队如何组织项目，但是已经足够让大家着手开展工作了。
1.6.1　远景
每个项目背后总有一个缘由（或者两个、三个）。发起这个项目的缘由何在？项目的价值何在？要用描述远景的句子来说明项目的价值。越早向大家阐明项目的价值，团队就越有可能告诉你接手这个项目是否明智。也许他们会告诉你，囿于目前的约束、资源和他们的能力，这个项目就不可能完成。要是不能明确阐明项目的远景何在，很可能这个项目就是“不可能完成的任务”了（因为没有远景的项目无法结束）。实用的项目远景对团队来说不可或缺。
1.6.2　需求
某些情况下，项目唯一的需求就是要在某个特定日期到达之时发布某些功能。更多时候，需求掺杂在下面这样的语句之中：“2月20日发布的主要版本中，我们需要这个又棒又炫的功能。”这些才是项目的驱动因素，产品功能列表不是。
1.6.3　目标
项目目标是希望通过项目要达成的目的，不过客户跟出资人可能并不赞同这些目标。（想了解更多关于目标的讨论，请查看2.3节）。
小乔爱问……
谁来撰写项目章程呢？
撰写章程，可以帮助团队早点形成凝聚力。要让尽量多的团队成员参与编写章程。
要是还没有为项目分配人员，那就先自己写章程吧。如果不是单***匹马，就跟大家一起写。在项目启动会议中（请查看10.3节），把章程跟大家过一遍，确保每个人都知道其中的内容及其缘由。
目标与需求不同［DeM97］。项目并不一定必须交付它的目标。遵循传统的阶段-关卡（phase-gate）式开发过程或瀑布式开发过程的项目，它的产品里面会有比较严重的技术债务（technical debt，请查看附录B）。通过重新设计解决技术债务、添加更多的自动化测试、设计冒烟测试等等，这些都是可能的项目目标。
客户有时会提出一些特定的要求：“如果目前的时间安排允许，并且不麻烦的话，我想要一个电子签名。”作为一个注重实效的项目经理，你可以说：“OK，我们会把它加到项目目标里面去。要是雪丽和简有时间的话，她们会去做的。”
1.6.4　成功标准
成功标准是围绕客户能基于完成的产品做什么给出的定义。成功的标准[0]并不涉及缺陷，而只关注能力。（请看［Rot02b］和［Wie05］）。
下面是一些成功标准实例。
要包括功能1、2、3，这样我们的产品就可以打入目标市场了。
要提升产品性能，再测出相关数值，这样我们就可以将其与竞争对手的产品进行对比，并编写新的市场营销材料了。
客户不需要访问我们的网站，就可以打开***包、加载软件。
在第一季度发布。
在你意识到之前，项目就已经开始了
项目通常在正式开工之前就已经启动了。也许有人已经开始了原型化的工作；也许有人已经预想了一些功能；也许管理层已经跟首席架构师探讨了项目在技术上的可行性。这些都是项目的组成部分，即使你不这么认为。
由于项目在你思考之前就已经开始了，所以大可不必因项目章程、项目规划和项目日程的反复修改而烦恼。作为一个注重实效的项目经理，在项目前期，虽然有些工作已经开始了，你还是应该张开双臂拥抱项目，接受眼前的一切。在项目中期，你应该不断评估项目进程和风险，从而掌控整个项目。项目收尾阶段，如果你是注重实效的，那就没什么好担心的了。
团队要控制成功标准。项目经理要确保成功标准中不会包含非项目人员才能完成的任务（比如“卖出50 000套软件”）。项目经理和团队不能控制别人做什么，只能控制自己和团队的行动。要确保成功标准在项目经理的掌控之中。
1.6.5　ROI
我接触过的客户中，很少有人会去度量ROI（即投资回报率）。毕竟，要操纵数字太容易了。不过，如果管理层要求的话，项目经理可以估算项目的回报，试着计算ROI。在项目完成后，可以看看是否达到了当初预计的数字。
1.7　理解质量对于项目的意义
要想理解质量对于出资人和客户的意义，必须先要理解项目的关键驱动因素、约束和浮动因素。出资人是为项目提供资金的人，客户是使用产品的人，他们不一定是同一群人----对质量的定义可能有差别。没错，这让项目经理的工作更不好做了。不过，知道了对于项目来说“质量”意味着什么，也就部分理解了“完成”的含义。
温伯格这样说：“质量，就是对于某人的价值。”［Wei92］这个定义也就意味着可以为项目产品添加新功能，并可查看一个功能吸引（或排斥）了多少个（以及什么样的）“某人”。在想到出资人和客户的时候，不妨考虑一下他们希望从项目中得到什么。这样一来，项目经理便可以根据实际情况调整发布时间、项目预算和人员配备；同时，项目经理也可以权衡：是否所有的“某人”都需要某个功能。如果项目经理和团队知道“某人”对于质量的定义，大家就可以朝着这个方向来努力；即使他们改变了主意，团队仍然可以取得成功。
根据项目产品所处的不同市场应用阶段［Moo91］，如图1-2所示，客户对于质量的定义也有所差别。
图1-2　摩尔的鸿沟
当产品处于市场应用的早期阶段时，顾客群的规模不大；但是技术狂热者们已经想先睹为快了，所以会面临比较大的发布压力。此时产品不必具有很多功能，而且也不必有很高的稳定性，但是它必须具备自己的独特之处，来吸引更多客户。
在产品进入市场的初期，无论客户群大小，人们都会有各自不同的需求。所有客户都希望马上得到新版本，而且要具备他们自己想要的功能。此时的产品用起来不能太费事，不过由于只有你的产品能够解决客户的问题，所以即使有点儿缺陷，它的销路还是会很不错。
一旦产品（或有替代产品）进入到大众市场之后，实用主义者们就会关心产品的缺陷能否得到及时修复。如果在之前的版本中累积了技术债务（请查看附录B），现在就到了还账的时候了。鉴于实用主义者拥有强大的购买力，管理层会迫于压力而决定频繁升级产品----即使有些客户不想***最新的版本。在加强产品稳定性的同时，每次发布的新版本中多少要加入一些新功能。
保守主义者也会购买你的产品，但往往是迫于某种压力作出的选择。如果产品不能完成承诺的功能，或者有太多缺陷，保守主义者们会抓住一切机会发起抨击。他们不需要新功能，只希望承诺的功能好用就行了。此时只要发布缺陷修复补丁，或是发布更加可靠、更高性能、更稳定的产品即可。
对于你的产品，盲从者和怀疑论者有可能买，也有可能不买。处于这个阶段的产品有时会被称为“现金牛”，因为此时产品为公司带来的收入要远远超过需要付出的成本。
尽管在产品生命周期的开始阶段发布的很多版本都会面临不小的压力，但在产品生命周期的后续阶级，规模日益增大的客户群对低缺陷率要求的压力会更大。
每个项目启动时都要有章程。
对项目章程的反复修改要有心理准备。章程不一定完美，它的意义在于帮助整个项目团队进行规划活动。
要知道“质量”的意义以及项目的驱动因素。这样随着项目的不断推进，项目经理和团队才可以作出正确的决策。
本文目前还没有评论……