适应性项目框架概述.doc
《适应性项目框架概述.doc》由会员分享，可在线阅读，更多相关《适应性项目框架概述.doc（46页珍藏版）》请在冰豆网上搜索。
第1章适应性项目框架概述
第1章
适应性项目框架概述
Itisamistaketolooktoofarahead.Onlyonelinkofthechainof
destinycanbehandledatatime.
——WinstonChurchill
Thereisnodataonthefuture.
——LaurelCutler，FCB/LeberKatzPartners公司副董事长1每章的开篇引言都选自LewisD.Eigen和JonathanP.Siegel所著的TheManager’sBookofQuotations（纽约：
AMACOM，1991）一书。
我们在通过项目管理创造更美好世界的旅途中到达了一个十字路口。
在继续前行之前，我希望您停下脚步，思考一下前面的路应该怎样走。
我希望与您分享的是我在过去40年与您同行的旅途中总结出来的结论，这并不是在主张颠覆项目管理世界，只是想让您停下来思考一下正在发生的事情，以及我们如何应对这些事情。
是时候注意一下不断变化的商业环境所发出的信号；是时候学习如何适应当今商业世界中快速而不断变化的、复杂而不确定的需求；是时候学会如何最佳地管理这些项目。
复兴项目经理的时代已经来临，创造一个新的项目管理流程模式的时机已经成熟。
这个新模式不应该是静态的，而应该是对团队、外部支持人员和客户（似乎总是不断改变想法的人）动态变化的模式——必须适应不断变化的项目特点、环境和文化的模式。
甚至这些新模式在从项目开始到结束的过程中也很容易发生变化。
因此，一个有效的项目管理方法必须是能够不断评估项目整体环境以及适应不断变化的条件和情况的方法。
复兴项目经理是一个打破常规的思想家——是把创新和勇气灌输给开发团队和客户团队的人员。
建议：
对最近才感受到缺少有效项目管理流程所带来的痛苦并极力把传统做法应用于非传统项目的企业，我要对它们说：
“不要浪费时间！
”
我认为有效的项目经理更像是大厨（chef），而不是普通厨师（cook）。
普通厨师只会按照食谱做菜，从未受训于烹饪食谱外的菜肴，只要按照食谱按部就班地进行，一切就会安然无恙。
而大厨接受的是创造食谱的训练，为了适应变化的情况和限制因素，他可以适应任何食谱。
我想现在您应该已经是一名普通厨师。
在这本书中，我将会带给您成为大厨所需要的工具！
1.1适应性项目框架的基础
让我们面对这个事实：
世界不会因为您在管理一个项目而变得静止。
因此，我们面临的挑战是要采纳并适应一种方法，以管理总是会遇到难以预料的变化的项目，以期望该方法在不妨碍项目、团队、客户、企业和市场的情况下能够进行自我调整。
1.1.1客户与顾客的区别
我们首先澄清一些词汇。
顾客是我们卖给其产品或服务的人；而客户是我们要与其合作解决问题或者共同利用未开发的或新的商业机遇的人。
客户一词适用于适应性框架的项目，也是整本书中一直使用的一个词汇。
1.1.2APF项目团队
APF项目团队由客户团队和开发团队组成。
对于某些APF项目，客户团队或许只是一个拥有决策权的个人。
而对于大型APF项目，客户团队或许会有几个成员，这样才能满足业务流程或者功能部门的需要。
客户团队的成员在整个项目周期可能会发生变化，但总有一个人负责决策，这个人会和开发团队的负责人一起共同管理整个项目。
开发团队由负责产生可交付成果的专业技术人员组成。
其团队人员在整个项目周期也很有可能发生变化，但项目中总会有一个核心开发小组保持不变。
开发团队中也会有一个人负责决策，这个人与客户团队经理一起共同管理整个项目。
这两个团队的经理共同分享成功和承担失败。
他们都必须拥有该项目的决策权。
如果客户经理事事都要获得公司管理层的准许，那么您的APF项目将会严重受损。
这种项目经理模式是APF独有的特点，也是一个关键的成功要素。
这种管理模式最重要的特点是双方平等赋权并共同承担项目责任。
APF项目团队是非常特别的团队，其成员大多是不需要监督便能工作的高级专业人员。
他们所从事的项目很复杂，且充满大量的不确定性。
所以，如果想要找到可接受的解决方案，他们就必须是创新型人才。
创新型人才往往很独立，有可能不具备良好的团队协作精神。
这对于项目经理来说是一种挑战。
伴随着创造性而来的是成员的相对独立以及不受组织限制因素和呆板流程的羁绊。
当需要特别指出时，我会分别用“开发团队”或“客户团队”这两个词，但当我使用“项目团队”这个词时，指的是由开发团队和客户团队共同组成的团队。
1.1.3初步认识APF
您已经知道，在这本具有开创意义的书中，您将要探索的项目策略我称之为适应性项目框架。
这绝对与您父辈们的项目管理不同，它是全新的。
我甚至都不用“管理”这个词来描述它。
它是一个框架，在这个框架里产生有效管理。
如果必须选一个词描述它，那么我更愿意用“领导”，而不是“管理”。
您将会发现，APF代表着项目思维方式和运行方式的转变。
有一点需要指出，那就是它减少了诸如计划、重新计划和从不执行的任务等所有的不增值的活动。
为什么要计划我们一无所知的未来呢？
您绝对不应该基于对未来的某个猜想来制订您的项目计划，这会浪费太多的时间和金钱！
此外，这也会严重影响项目风险。
在APF中，计划是随时制订的。
听起来自相矛盾，是吗？
这样的计划或者基于我们已知的信息制订，或者基于上次计划制订后我们已知的解决方案制订。
所以，APF计划是增量的。
APF需要创造性思维——这种思维方式因变化而蓬勃发展，而并非躲避变化。
所有APF项目共有的一个特点是在项目启动时不知道完整的解决方案；它随着项目的执行逐渐被发现和认知。
这个发现流程将需要一套新的工具，而这套工具在任何其他敏捷方法中都不存在。
这意味着APF项目管理流程必须自备一些对策以供认知和发现这套工具。
认知和发现的结果会转化为解决方案中的功能和特征。
因此，解决方案会累积增长直到项目结束。
这种解决方案的累积构成普遍存在于所有敏捷方法之中。
在APF中，认知和发现流程是结构化的。
而在其他敏捷方法中，它却是偶发的。
在一个APF项目中，开始会对解决方案有一个不完整的定义。
您对这个解决方案也许知道的很多，也许知之甚少。
对其知道得越少，找不到能够获得可接受商业价值的解决方案的风险就会越大。
所有APF项目的一个共同特点是，项目团队中客户成员和开发人员通过他们创造性的、协作性的工作以及他们的专业知识，最终都能在规定的时间和成本限制内找到最佳的解决方案。
提供认知和发现的机制就是向您的项目管理流程注入传统方法所不具备的内容——事实上，其他任何敏捷方法也不具备这些内容。
您必须与客户一起及时地验证在那个时间点确定的各种可能的解决方案。
将这些行动称为“检验泳道”，其内容会在第3章中进行详细讨论。
检验泳道创建认知和发现。
当该泳道成功确认出另外一部分解决方案时，该部分便在后来称之为“集成泳道”的周期中集成进解决方案。
这两个泳道定义出了APF中独特的、不存在于其他任何敏捷方法中的关系。
APF显然也不是一个万能方法。
该方法只是通过在每个周期中学习和发现更多的解决方案，从而适应不断变化的商业环境和项目状态。
APF基于形式服从功能的原则。
它从传统的线性和极限方法中汲取工具、模板和流程，使它们在适当的时机及时满足项目需要。
APF是基于做中学原则的一个框架，这一点能保证：
“一旦您构建该框架，它便是这些工具、模板和流程所需要的，这些工具、模板和流程也会随之而来。
”
不像极限管理项目那样只寻求最后一刻的正确（它应该如此），APF项目每时每刻都在寻求正确。
每个周期都会及时产生在那个时刻所了解到的解决方案的可行版本。
这与创建产品原型非常类似。
无论何时终止一个APF项目，当时的解决方案总能交付商业价值。
APF以客户为中心，以客户为驱动，立足于一套不变的核心价值观（本章后面讨论）。
APF相对于花费的时间和金钱，确保了最大商业价值。
APF是高效的：
它去掉了所有可能出现的不增值的工作。
APF是使客户成为有意义的决策者和完全的决策者的框架。
APF在请求者和提供者之间创建了合作伙伴关系，并确立了他们共同的责任。
APF是一个100%有效的框架，没有例外！
最后，APF项目是高风险项目。
这不是流程导致的，而是项目本身所固有的特性。
这些项目的成功完成对于企业来说至关重要，但其解决方案迄今为止却找不到。
这也许是因为问题根本无法解决，也许是因为没有人能成功地找到一个有待发现的解决方案。
如果通过有效项目管理能够发现这一解决方案的话，那么也只能通过使用APF才能做到。
1.2目标、解决方案、功能和特征
如前所述，APF是为目标明确并已编制成文档但解决方案仅仅部分已知的项目而设计的。
图1-1（在前言中也出现过）指明了APF在项目景观中的位置。
APF可以用于敏捷项目管理象限中的任何项目（明确的目标、不明确的解决方案），它是一个适应性项目管理生命周期模型。
该模型适用于多种情况——从最简单的仅仅一小部分解决方案未知的情况到最复杂的仅仅一小部分解决方案已知的情况。
或许该解决方案只是一个简单的配合决策的算法。
另一个极端情况是解决方案完全未知，因为问题是第一次出现，关于该问题知之甚少；也或许是因为该问题经常出现，但却一直捉摸不透它的解决方案。
APF也可以用于既没有明确的目标也没有可用的极限方法的项目。
图1-1项目管理景观
使用定义每个需求的功能和特征可以客观地表示出解决方案的已知程度。
这些功能和特征也正是需求分解结构（RBS）的组成模块，在第2章中会详细讨论。
RBS中的第一级是需求，第二级是功能，最低一级是特征，如图1-2所示。
图1-2需求分解结构
您或许已经注意到RBS和以可交付成果为基础的工作分解结构（WBS）之间存在相似之处。
本质上讲，RBS回答这个问题：
“我们将要交付什么？
”，WBS是RBS的拓展并回答这个问题：
“我们将如何交付？
”因此，RBS作为一个子集包含在WBS中。
从RBS开始，您可以继续分解，在分解结构的最低一层上创建以可交付成果为基础的WBS的形式。
当然还有其他几种WBS能够遵循的体系结构。
有关WBS体系结构的详细内容和如何建造完整的WBS，请参考本书作者的另一本著作EffectiveProjectManagement：
Traditional,Agile,ExtremeRobertWysocki博士，EffectiveProjectManagement：
Traditional,Agile,Extreme，FifthEdition（纽约：
JohnWiley&Sons，2009）。
。
如果客户团队和开发团队确信RBS能够完全描述项目的解决方案，那么传统项目管理（TPM）方法就是正确的选择，很有可能会选用一些传统的线性或者增量方法。
如果RBS不够完整，或者怀疑其不够完整，亦或者感觉项目期间有可能会出现变化，那么选用敏捷项目管理方法（APM，如APF）就会非常合适。
RBS中未知的部分可能是一个或多个特征（这会直接导致应用APF），或者是一个或多个功能（这会使得APF的应用更具挑战性）。
但是，假如RBS不够完整，可能您和客户团队却觉察不到。
大多数项目管理学者认为在项目启动阶段产生完整的RBS是不可能的。
如果您同意这个想法，那么为您的项目采用一些诸如APF的敏捷方法将会是明智的做法。
极端情况下，在项目进展过程中甚至能确认需求。
只要目标明确且编制成文档，APF方法会是正确的选择。
项目经理再也没有必要拼凑一些线性或者增量方法并期待着该方法能奏效。
APF甚至可以在已经使用了TPM的情况下使用。
随后我们将讨论这种情况。
APF之所以不同于其他方法，是因为它能确保有效——100%的情况下。
65%的项目失败的事实StandishGroup，ChaosReport2007：
TheLawsofCHAOS（波士顿：
StandishGroupInternational，2007）。
升级会员 