传统项目管理的时代已经过去。虽然在合适的情况下，我们仍然会继续使用和我们共同成长起来的传统线性模型，但是伴随行业的日渐成熟，我们已经发现了一套全新的应用模式，而传统项目管理(Traditional Project Management, TPM)模型却完全不能适合这种应用的需要。绝大多数当今的项目都不符合应用TPM模型的条件，其主要原因是很难在项目启动时就确定完整的需求。造成确定需求困难的因素有不断出现的变化、不明确的商业目标、竞争者的行为和一些其他因素。 　　所有的TPM模型都要求有完整的工作分解结构(Work Breakdown Structure, WBS)，而没有明确完整的需求就产生不了完整的WBS。大多数观察家认为在项目初期定义完整的需求是不可能的，除非是一些非常简单的项目。即便是您能做到这一点，我们也要说，世界不会因为您在管理一个项目而变得静止。变化的商业条件、竞争和技术都能够也的确制约着完整需求的出现，或者至少是会误导完整需求的出现。现代商业处于肆无忌惮变化和高速发展的环境之中。需求从不会真正明确，它们在整个项目周期过程中都会不断地变化。周期和递归模型逐渐成为时尚，然而，许多组织还在使用不合适的方法或模型进行项目管理。这多么愚蠢，又多么浪费时间和金钱啊！这种状况必须转变，不能顺应这种转变的公司势必会在竞争中衰败。Alan Deutschman的“要么改变，要么死亡(change or die)”的说法用在今天的项目管理界中再合适不过。 　　0.1 当代项目纵览 　　变化是永恒的，也是难以预料的。这并不使人感到意外。事实上，变化本身也正在加速变化。这也不会让人感到意外。昨天的做法属于昨天。今天是新的一天，面临着新的挑战。所有的项目管理者，无论是高级经理还是即将成为项目经理的人员，都需要思考如何有效地调整他们的项目管理方法，而不能只是照搬昨天旧的做法。 　　在通往高绩效的道路上充满了大量的不确定性。成功向来和勇气、创造性以及灵活性相伴。如果我们只是简单地依赖于照搬现成的方法，那么很有可能遭遇失败。在接下来的篇章中您会发现，我将要走出条条框框的束缚并可能带领您走出安乐窝。我将延展您的思维，以考虑如何进行有效的项目管理，从而交付预期的商业价值。 　　没有什么比管理这类既没有明确解决方案、又没有明确目标的项目所使用的方法更需要变化。这些项目经常出现，更经常的是，这些项目不适合您当前所采用的做法。我在环游世界的过程中收集到的数据表明，至少有70%的项目不适合使用与我们共同成长的传统的、线性的项目管理生命周期。一个挑战摆在了我们面前，这就是我们要使我们的项目管理流程和技巧与不断变化的项目需求、所处的商业环境和所服务的市场--或者是被认为与项目管理毫不相干的风险--相匹配。这就意味着我们必须变革自己的方法和模型，并开发出能够经得起变化的模型。本书的目的就是介绍一种新的项目管理方法，一种能够应对这些挑战的方法，我们将该方法称为适应性项目框架(Adaptive Project Framework, APF)。 　　APF的最初版本开始于我与客户的两次合作。这两次合作的项目都不是软件开发项目。一个是要求开发一个与系统开发生命周期(Systems-Development Life Cycle，SDLC)完全兼容的项目管理生命周期(Project-Management Life Cycle, PMLC)；另一个是为一个大型连锁超市设计一个射频识别应用程序。因此，一个涉及业务流程设计，另一个涉及新产品开发。这两种项目都可以应用APF。这一点使得APF与大多数只适用于软件开发项目的敏捷方法区别开来。对于这两个合作项目，我会将其作为本书用到的4个案例当中的两个来进一步讨论。 　　揭开技术革命的神秘面纱，问题便浮出水面。商人总是贪婪的，总有欲望需要满足。幸好到目前为止，还没有人质疑他们的这种权利。当然技术帮了他们的大忙，能让他们得到其想要得到的事物。然而我知道，欲望是客户表达对他们所面临的一些未阐明的或者不太明确的问题的解决方案。如果我们足够幸运，他们的欲望精确地反映出他们问题的解决方案，那么项目前进的方向就会非常明确。但欲望并非总是和需求一致。因此，如果您把焦点放在满足欲望上，您的注意力或许就找错了方向，从而招致失败。隐藏在欲望背后的是真正的需求，真正的需求往往没有明确表述出来。商人无法区分欲望和需求，事实上，欲望挡住了人们的视线，使人们看不到真正的需求。这不是孰先孰后的问题，而是对问题缺乏理解。这种状况从技术革命开始一直持续到今天。 　　如果前言中您想要记住什么的话，那么就记住图0-1所表示的信息，即客户想要的可能并不是客户真正需要的。如果您盲目地接受客户所说的内容，并在此基础上实施项目，那么您和您的客户可能最终会发现事情不妙而幡然醒悟。到那时，您已经构建了您的客户不会使用的项目。经常地，在构建解决方案的过程中，客户发现他们真正需要的事物不同于他们所表达的想要的事物。这就为期限拖延、范围蔓延、无休止的变化、返工、超出预算和进度延误等问题提供了温床。TPM不得不顺应类似这样的项目现状。大量的时间浪费在计划从不发生的事情上。超过65%的项目会失败。这种情况必须改变。 　　客户想要的可能并不是客户所需要的。项目经理的工作是使客户想要他们所需要的事物。 　　图0-1 欲望与需求 　　我们需要两个对象。首先我们需要一个流程，用来发现隐藏在欲望后面的需求。不断地提问“为什么”可以发现需求。使用根本原因分析法(Root Cause Analysis)几乎可以完全剥开欲望的层层面纱，从而获知真正的需求。第二，我们需要一个构建在变化之上的方法--一个在整个项目生命周期过程中都能促进认知和发现的方法。这个方法必须承认，无论我们如何试图阻止变化，变化还是会出现。项目实施必然需要认知和发现，而认知和发现会导致变化的出现，因此我们的方法必须有内置流程以适应这些变化。 　　这本书介绍的方法正是为了满足这些要求。该方法就是APF模型，其名称APF也是精心选择的结果。 　　0.1.1 自适应 　　自始至终，APF的目的是为了不断适应变化的项目形势。对解决方案的理解发生变化很可能会导致管理项目的方式或者使用的方法发生变化。周期早期产生的认知和发现可能也会导致采用的方法发生变化。例如，您在项目计划的前几个周期里使用APF方法，很快便发现了完整的解决方案。还应该继续使用APF吗？或许现在一些其他的敏捷项目管理(Agile Project Management, APM)模型会更为适合，或许您还会考虑选用一些TPM方法，例如增量方法。这个项目的新的特点决定了应该采用什么样的方法。 　　APF中没有什么是固定的。它的每个部分都是会变化的，并且能不断适应项目的特点。APF中的变化并非来自预先定义好的潜在变化列表。该方法中的变化是创造性地响应不断变化的形势的需要。很明显，APF要求客户和项目团队有意义地参与，双方是坦诚且相互信任的合作伙伴。做不到这一点便会招致失败。要想成功地运用APF，您的思维必须像大厨，而不是像厨师！厨师只会照着菜谱做菜，如果缺少了某种食材，可能就不知道如何继续。而大厨拥有适应不同情况的技巧和经验，他可以在现有的食材范围内创造菜谱。 　　我的女朋友提供了一个能说明我的意思的极佳示例。她总是爱做乳酪蛋糕。一个星期天的晚上，她问我是否需要做乳酪蛋糕，我不假思索地说：“做吧。”几分钟后，我听到在橱柜中到处翻找的声音，接着从厨房传来叹息声。香草精已经用完，而那是乳酪蛋糕食谱中一个必不可少的成分。当时已经很晚，不能再去超市购买。所以我建议她把面糊放在冰箱里，明天早上再去买香草精。几分钟后，我闻到了烤箱中乳酪蛋糕的味道。莫非她找到香草精了？不，没有。相反，她找到了一罐香草糖霜，而香草精是它的主要成分之一。她计算出乳酪蛋糕食谱中所需的香草精等同于多少香草糖霜，然后使用香草糖霜代替香草精。结果做出来的乳酪蛋糕非常棒！那么您会询问，这和项目管理有什么关系吗？我想表达的是，如果您所做的一切就是盲目照搬其他人的项目管理方法，那么您没有任何机会！而如果您创造一种适应当前条件的方法，那么您就有了收获成功的希望。 　　0.1.2 项目 　　每个项目都是独一无二的，它们从来不会在同样的环境下重复进行。那么为什么我们不使用独特的方法来管理它们呢？我并非主张管理方法要发生全面的变化，而是主张研究一种深思熟虑的方法--一种既能考虑到项目的反复无常、又能应对项目的反复无常的方法。在选择最佳项目管理方法时，我们要考虑项目、组织和环境的特点。下面列出的是我所见到的最常需要考虑的项目相关特点，在我们最终选定最佳方法时应该充分考虑到它们的影响。 　　●风险 　　●成本 　　●工期 　　●复杂性 　　●市场稳定性 　　●商业价值 　　●使用的技术 　　●商业环境 　　●客户参与 　　●目标和解决方案的清晰度 　　●影响到的部门数量 　　●组织环境 　　●团队技能和能力 　　●需求的完整性 　　●项目经理和团队成员 　　这些项目特点的不同组合就能导致处理项目的方法发生变化。例如，如果某个项目方法要求客户大量参与，而您凭借对这个客户的了解认为这是不可能的，所以您就不会选用该方法。这可能就意味着您必须妥协，选择一个不十分理想、缺乏客户有意义参与的方法 (Chaos Report 2007列表第一次把缺乏客户有意义参与列为项目失败的首要原因)。或者，您可以组织有客户参与的研讨会，根据研讨会的结果来决定最终选择什么样的项目管理方法。 　　假设您的组织环境的特点是频繁重组和角色与职责频繁调整。在这样的环境里，项目的启动事宜和项目重点将会发生改变。最适合的项目管理方法应该是增量释放交付产品或者在间隔较短的情况下交付产品，而不能在较长的项目周期结束时一次性交付产品。这样的策略将会降低资源浪费的风险和由于早期终止项目而带来的商业价值的损失。在第9章中会再次讨论这个问题。 　　0.1.3 架构 　　APF有几个变体。使用照搬食谱和创建食谱来做比较。TPM照搬食谱，APF遵循架构。TPM项目经理需要知道如何一步一步地遵照任务列表完成任务，而几乎不考虑为什么这样做。TPM项目经理在一定意义上来讲受所使用项目管理方法的束缚。APF创建食谱。APF项目经理需要了解他们面临的形势，并调整他们的工具包以满足形势的需要。APF允许项目经理随着形势的变化而做出调整。APF项目经理掌控着方法，而不是像TPM项目那样，是方法掌控着项目经理。 　　为了把APF放在适当的环境中，我把各种各样的项目管理方法想象成映射在一起的一个非常简单的项目景观图。这是下一节的主题。 　　项目管理环境不断变化。它包含以下7个相互依赖的变量： 　　(1) 项目实施环境的特点 　　(2) 项目本身的特点 　　(3) 业务流程生命周期 　　(4) 项目管理生命周期 　　(5) 项目团队的情况 　　(6) 客户团队的情况 　　(7) 支持所有工作的软/硬件技术 　　虽然这种复杂环境似乎有点令人窒息，但事实并非如此。我将和您一起探索这个多维环境的复杂性，并告诉您如何在这个变化的环境中获取并保持有效的项目管理。 　　多年来，管理大师一直在讲，一个有效的组织是能保持员工、流程和技术平衡的组织。员工是聪明的，这一点毫无疑问。多少次，您都会听到主管说：“只要把五个聪明的人放在一个房间里，他们就能解决您提出的任何问题。”这或许是对的。但是，我想没有人愿意把企业的未来的赌注都压在少数几个英雄的身上。技术发展的速度超过任何组织可以吸收的速度，所以技术不是障碍。最后是流程，本书也将注意力放在业务流程上。但让我们感兴趣的不只是您的日常的业务流程。我们要研究的是一个真正的能够确定流程的流程，而不是一个稳重且固定的方法--或者食谱，我喜欢这么称呼它。进一步跟随这个食谱比喻，我想要教会您如何创建食谱，而不只是盲目照搬预先确定下来的食谱。 　　0.1.4 人员、流程和技术之间的平衡 　　一些研究人员观察到成功的组织能够保持人员、流程和技术之间的平衡。据我所知，至今没有人能够建立一个评估工具以考量这个平衡度。几年前，我做过一个开发评估工具的项目，该工具用来测量组织中项目管理对人员、流程和技术的重视程度孰深孰浅。这个评估工具用来建立当前状态和理想的最终状态，并提出如何从当前状态转变到理想的最终状态的建议。这个模型如图0-2所示。 　　图0-2 组织中人员、流程和技术之间的平衡 　　这个三角形代表着决定项目管理平衡的3个维度：人员、流程和技术。从项目管理的角度来看，人员指的是项目团队，流程指为项目选用的项目管理策略(同样的模型适用于任何业务流程)。最后，技术指支持选定的项目管理流程的工具、模板、硬件和软件。 　　这个三角形分成了6个互不重叠的区域，每个区域使用字母S(人员)、P(流程)、T(技术)的组合来命名。这几个字母的组合顺序代表它们与顶点的远近顺序，距离最近的排在第一位。距离越近，说明该顶点所代表的维度对于组织来说就越重要。所以，SPT的组合是指人员对于组织来说最重要，其次是流程，最后是技术。这个示例的顺序也说明人员(项目团队)驱动着流程的选择(PMLC模型)，人员和流程共同驱动着技术的选择(支持着硬件和软件的使用)。 　　这3个参数的得分受线性约束。该模型中3个参数的总分是200，也可以是其他任何数值。这意味着3个参数是相互依存的，且每个数据点都限制在三角形的界限之内。 　　评估数据将根据这3个维度汇总得出，并使用一端是正方形(当前状态)、另一端是菱形(理想状态)的一条直线表示出来。这条直线的端点与三角形顶点的距离让我们可以相对考量出这3个维度对于组织的重要程度。端点距离某个顶点越近，该顶点所代表的变量对于组织越重要。在这个示例中，正方形的位置告诉我们组织目前比较重视技术，其次是流程，最后是人员。换句话说，科技设施是主宰，它决定着使用什么样的项目管理流程，然后再选择什么样的项目团队可以适应这样的技术和流程。菱形的位置告诉我们，理想的项目管理文化是大致同等重视流程和技术(流程略微比技术重要一点)，而最重视的是人员。换句话说，首先选定项目团队的成员，然后再为所要从事的项目选定最佳的项目管理策略，最后再选择最能支持所选项目管理策略的技术。尽管不是每一个组织都有相同的理想状态，但是SPT区域应该是大多数组织都更青睐的一个区域。不同的行业也有不同的侧重。例如，金融机构更倚重流程和技术，而零售行业或许更倚重人员和流程。 　　这条直线的长度与组织要达到它的理想的支持环境而需要做出变化的程度成正比。我研究的部分内容，就是希望制定出一些策略以帮助组织从当前状态转移到理想状态。如果您对SPT评估工具感兴趣，希望获得更多信息，那么请通过rkw@eiicorp.com与我取得联系。 　　在这本书中，我把项目的特点作为这个模型的切入点，这些特点推动着我们选择团队所需的技巧和能力，然后团队确定应该使用的项目管理工具、模板和流程，最后，团队和选定的工具、模板以及流程将确定最适合的技术以支持所有的工作。当然，这并不是一本可以盲从的食谱书。相反，它更是一个架构，教会您如何创建食谱。图0-3清楚地表达了我的想法。换句话说，我的目的之一是使您像一个卓越的项目经理那样思考问题，并最终成为一个卓越的项目经理。 　　图0-3 您愿意做大厨还是厨师 　　0.1.4 项目的特点 　　纵览项目管理的各种方法，使用比前面讨论的7个变量更为抽象的角度来思考问题。为了保持简单、直观，我把项目管理景观想象成一个简单的二维方格，如图0-4所示。第一个维度表示项目目标，包含两个值，即项目目标是具体明确(完全已知)或者不是具体明确(不完全已知)。第二个维度表示解决方案，或者是说您期望如何达到目标，它也包含两个值，即解决方案具体明确(完全已知)或者不是具体明确(不完全已知)。如果像图0-4中那样把这两个维度交叉在一起，我们就把项目分为了4个类别。需要注意的是，明确和不明确之间的边界只是一个概念上的边界。该边界不能量化，只是一个概念边界。这种分类虽然很简单，但它却能把以前的项目和以后的项目都包括进去。也就是说，每个项目都属于也仅属于这4个象限中的一个： 　　●TPM：传统项目管理(线性和增量PMLC模型) 　　●APM：敏捷项目管理(迭代和适应PMLC模型) 　　●xPM：极限项目管理(极限PMLC模型) 　　●MPx：Emertxe项目管理(极限PMLC模型) 　　图0-4 项目管理景观 　　TPM象限里的项目是目标和解决方案都非常具体明确的项目。它们属于简单项目，已在过去重复进行了许多次。所有这些项目或其绝大部分都有成熟的模板。因为组织对它们非常熟悉，所以也了解项目的需求。拥有完整的需求意味着能确定明确具体的解决方案和产生完整的WBS(Work Breakdown Structure，工作分解结构)。TPM模型将非常适合这些项目。 　　随着不确定性的增多，接下来就是APM象限中的项目。从目标明确具体且大部分解决方案已知(或许在选择如何提供一些特征时例外)到目标明确具体但解决方案几乎未知的项目都属于这个范畴。因为解决方案未知，所以这些项目的风险比TPM象限里项目的风险高得多。这些项目的成功完成对于组织至关重要。商业价值也必须足够高才值得冒险从事这样高风险的项目。显然，需求不能明确完整地确定下来，因为这样就意味着知道了完整的解决方案。也产生不了完整的WBS，所以不能使用TPM模型。所需要的就是内置认知并发现解决方案的特征的PMLC模型，这样完整的解决方案就会成为执行项目的一部分而得以发现。本书的重点就是研究属于APM象限的APF方法。 　　xPM象限中的项目的不确定性更高。对于这类项目，既没有明确的目标也没有明确的解决方案，它们需要随着项目的进行而同时认知和发现。它们通常是失败风险非常高的科研项目。最适合这类项目的PMLC模型必须能够容纳大量不确定性并包括调查周期，从而能够获得项目目标和支持这一目标的解决方案。即使这些工作都能成功进行，还要考虑商业价值的问题。现在有了明确具体的目标，但其解决方案能够提供足够的对组织有用的商业价值吗? 导致3M公司最终出品Post-it Note黄色贴纸软件的项目就是一个很好的示例。该项目生产的胶制产品不具备最初定义的商业价值，束置高阁了7年之后，才有人找到了一种使其有商业价值的应用方式。 　　发现那种商业价值的项目属于MPx象限。该象限的项目最初看上去可能给人无意义的感觉。有解决方案却在寻找问题的项目有意义吗？事实上是有意义的。沃尔玛对新引进的射频识别技术的最初调查就是一个很好的示例。在这个MPx项目中，沃尔玛被问到的问题是“您能找到射频识别技术(解决方案)的有商业价值的应用方式(项目目标)吗？”这听起来像是xPM象限的项目，只是顺序颠倒。这就是为什么将这些项目称为Emertxe项目的原因。Emertxe就是Extreme(极限)倒过来的写法。xPM和MPx象限主要都是科研项目。xPM象限的项目是给一个定义模糊的目标寻找解决方案，而MPx象限的项目是给有商业价值的技术(解决方案或它的一些变体)寻找应用(目标)。xPM和MPx象限的项目适用同样的PMLC模型。MPx项目既可能非常简单，也可能非常复杂。详情请参阅第8章。 　　随着项目的进展，项目所属的象限会发生改变。例如，在项目早期，目标可能很明确但解决方案不明确。这时该项目属于APM象限，可以从这个象限中选择最适合的项目管理流程。随着项目的进行，解决方案得以发现并变得非常明确，这时项目属于TPM象限，最适宜的方法也从APM象限转移到TPM象限中挑选。当您面对这样的决策时，需要考虑很多问题。第9章对此会进行讨论。 　　我认为APM代表着不断发展的一类项目。我曾游遍美国、欧洲和亚洲，期间曾询问很多项目经理，在他们的项目中各类项目都分别占有多大的比例。答案与我估计的几乎无异，他们认为20%的项目属于TPM象限，70%属于APM象限，剩下10%分别属于xPM和MPx象限。我相信公司所处的行业对这个比例有很大的影响，例如，建筑行业中TPM象限的项目比金融服务行业此类项目占有更大的比例。但是我没有任何数据来支持这个观点。 　　我的同事也从他们与客户合作的经验中证实了这些比例。也有很多传闻证据支持这些数据。因为许多APM项目都很新，所以我还没有得出一个确切的结论。在我们获得足够多的APM项目的经验并且从同事处获取了更多的数据之后，我们将会对项目的类别分布有更好的理解。 　　如果我们试图把本属于APM象限的项目放进TPM象限中，那么我们就要惹上麻烦。许多人也正在这么做，尽管他们知道所用的方法不正确。许多人还没有准备做出这个改变。使用错误的方法所导致的结果从平庸的成功到彻底的失败不等。几年来我一直主张项目所使用的方法必须最终由前面列出的7个变量来决定。一旦确定项目是TPM、APM或xPM，我们就需要充分考虑这7个变量，然后在其所属象限中选择最佳的具体的PMLC模型。 　　本书研究的重点是APM象限。为了讨论的需要，有时也会涉及其他象限。 　　即使在现在讨论APM象限的早期阶段，您也应该能够列出一些您希望看到的一个成功的APF PMLC模型所具有的特点。下面是我列出来的特点： 　　●APF要求具有新的思维方式--一个因变化而更加丰富的思维方式。 　　●APF不是一个一劳永逸的方法--它不断地适应变化。 　　●APF使用实时计划方法。 　　●APF从TPM和xPM方法中选取适应的工具、模板和流程。 　　●APF基于边发现边学习的原则。 　　●APF能够确保“一旦您构建它们，它们就会到来。” 　　●APF追求每次都做得正确。 　　●APF以客户为中心并以客户为驱动。 　　●APF拥有一组不变的核心价值观。 　　●APF交付最大的商业价值。 　　●APF肃清所有不增值的工作。 　　●APF方法比TPM方法所用成本低、实施时间少。 　　●APF使得客户有意义地、完全地作为主要决策人参与到项目中。 　　●APF基于客户和团队之间共同的合作伙伴关系。 　　●APF方法非常有效--100%的情况下！从没有例外！ 　　我引起您的注意力了吗？好！请继续阅读，找出APF方法如何大大提高您公司的项目绩效并带来根本影响！ 　　0.1.5 业务流程生命周期 　　APF必须与其他流程相结合。包括软件和系统开发生命周期、产品开发生命周期、流程改进生命周期和问题解决生命周期。可能还包括其他流程。APF应该集成进这些业务流程中，而不是把这些业务流程集成进APF。 　　0.1.6 项目管理生命周期 　　作为一个项目管理方法，APM必须适应项目。如果它强迫项目按照它的规则和惯例进行，则APM方法不会有效。当前有几种APM方法可供项目选用，软件行业包含以下几种开发模型： 　　●适应性项目架构(Adaptive Project Framework, APF)(即本书所讨论的方法) 　　●适应性软件开发(Adaptive Software Development, ASD) 　　●特征驱动开发(Feature Driven Development, FDD) 　　●动态系统开发方法(Dynamic Systems Development Method, DSDM) 　　●演变开发瀑布模型 　　●Prince2 　　●Scrum 　　●Rational统一过程(Rational Unified Process, RUP) 　　●微软解决方案架构(Microsoft Solution Framework, MSF) 　　●Crystal 　　●xP 　　●其他 　　除了APF之外，对于其他APM模型的详细讨论超出了本书的范围。有关TPM、APM、xPM和MPx的详细内容，请参阅Effective Project Management:Traditional, Agile,Extreme, Fifth Edition一书。 　　0.1.7 项目团队的情况 　　项目管理方法要与团队技能和能力相匹配，这对于项目的成功是必不可少的。例如，如果项目非常复杂，要求团队成员具有创造性和不受条条框框束缚的思维方式，那么选用喜欢遵章行事的专家团队就不会有效。如果您的团队是这个情况，而您的项目是APM或xPM项目，那么可能就不得不选用一种符合团队优势和偏好而对于项目却并非最适合的方法。 　　所有的APM方法都要求项目团队由一支不需要监督就能工作的高级专家队伍组成。APM项目没有项目经理新秀或新的团队成员的立足之地。许多APM项目团队成员必须搭配组成团队。虽然有一些变通方法可以不用搭配团队成员，但这样也会招致用人风险。我们将在第9章中对此进行讨论。 　　0.1.8 客户团队的情况 　　正如所选方法必须符合项目团队的情况一样，它也必须符合客户团队的情况。例如，如果与您合作的是喜欢处于领导位置的掌权型客户，他们就很可能会抵制使用使他们对发生的事情没有话语权的方法。如果他们的确有能力，那么就应该选用适合其特点的方法(例如Scrum)。您将一直伴其左右提供支持，防止他们迷失方向。 　　0.1.9 技术支持 　　我记得我的一位朋友兼同事过去常说的一句话是：“不要用大锤杀死蚊子(杀鸡焉用宰牛刀)。”当然她是在说技术的使用。我曾经做过的许多项目的最适用技术竟然是白板、即时贴和标记笔。使用适合的技术。大多数APM项目都能非常成功地使用低科技方法。不是因为有计算机存在就意味着必须使用最先进、最优秀的工具。执行APM项目时所关注的焦点应该是创造交付产品的商业价值，而不是通过什么工具去创造。 　　0.2 项目管理是有组织的常识 　　我喜欢简单、直观地阐述问题。项目管理被简单直观地定义为：项目管理是一套旨在回答下列6个问题的工具、模板和流程： 　　(1) 这个项目处于什么样的商业环境？ 　　(2) 您需要做什么？ 　　(3) 您将要做什么？ 　　(4) 您将如何做？ 　　(5) 您如何知道您成功了？ 　　(6) 您做得效果如何？ 　　我们看一下这些问题的答案。 　　0.2.1 这个项目处于什么样的商业环境 　　此处的环境是指一个需要解决方案的问题或者一个尚未开发的商机。如果是问题，并且解决方案具体明确，那么交付解决方案应该是相当简单的事情。如果解决方案并不是完全已知，那么选用的项目管理方法必须能够促进团队成员认知和发现解决方案。显然，这些项目的风险之所以高于TPM项目，是因为这些项目的结果不明确，或许在努力付出之后仍然不能发现其正确的解决方案。 　　如果项目是想利用尚未开发的商机，那么可以从几个方面来着手进行，在第1章中会对此有所讨论。 　　记住，您的项目或许正在与处于同样商业环境的其他项目以一个完全不同的角度竞争着资源。例如，您的项目处理的是问题的这个方面，而另一个项目处理的却是该问题的另一方面。如果您知道这些，那么固然好，因为您可以把这两个项目合二为一以节约成本。这样，您需要考虑更多的因素。高级经理需要对比找到解决方案或利用未开发商机的项目与其他项目相比哪个更重要。 　　0.2.2 您需要做什么 　　答案很明显，就是解决问题或者利用这个未开发的商业机会。一切都不错，但鉴于该项目所处的环境，这或许就没有那么容易。即使在解决方案已知的极少情况下，您仍然可能缺少做这个项目的技术资源；即使您拥有这些技术资源，在需要时它们也不一定能用。对于解决方案未知或部分未知的项目来说，您或许不能成功地找到迄今未知的解决方案。因此，任何情况下您都需要清楚地知道要做什么。 　　0.2.3 您将要做什么 　　这个问题能在您的项目目标和具体的目标声明中找到答案。或许您和其他人会提议该问题的部分解决方案或利用未开发的商业机会的方式。任何情况下，您的目标和目标声明都应该清楚地表述您的意图。 　　0.2.4 您将如何做 　　这个问题的答案将说明做这个项目时会使用什么方法，以及为实现上述目标和目标声明应该做出什么样的详细计划。 　　0.2.5 您如何知道成功 　　您的问题的解决方案或未开发商机的利用方法将向组织交付商业价值。这是项目成功的标准。也正是基于此，我们才会批准从事该项目。这个成功标准可以采用增加收入(Increased Revenue)、降低成本(Avoided Costs)或提高服务(Improved Services)等形式来表现。这3个商业价值缩写为IRACIS。无论成功标准以什么形式表现，都以数量词来表示，这样您对于是否取得预期的商业结果就不会有任何争议。作为实施后期审计的一部分，您需要把实际取得的商业价值和项目计划中估计的商业价值(即当初做这个项目的理由)作对比。 　　0.2.6 您做得效果如何 　　这个问题包括4个小问题：第一个也是最重要的一个问题是，您的成果是否达到了既定的成功标准？第二个问题是，项目团队表现如何？第三，项目管理方法是否适合该项目？第四，我们学到了什么经验教训以应用于未来的项目中？这些问题的答案全部是实施后期审计的一部分。 　　0.2.7 项目管理是有组织的常识 　　上述6个问题的答案说明项目管理不过是把一些常识性的内容组织在一起。如果不是这样，那么您为什么想这么做呢？因此， 您对这6个问题的答案能很好地测试出您的项目管理方法是否奏效。 　　0.3 编写本书的原因 　　高达65%的项目失败率(最新报告数据)令人难以接受。这尽管不是新问题，但似乎又没有什么方法可以提高项目成功率。项目经理仍然在沿用着旧的做法，把新项目强加到旧的方法中。多么浪费时间和资源！几年前，我严肃地反思了项目失败的原因，并自问能有什么方法加以改进。在很偶然的机会下，我与两个客户合作，他们的项目都是部分解决方案已知。我知道TPM方法不会奏效。我们所生活的商业环境发展快速、不断变化，为了获取解决方案，我们使用迭代方法，这两个项目成为我设计项目管理方法的源动力。结果就产生了APF。APF属于APM方法的一种。 　　0.4 本书的结构 　　本书包含前言和10章内容。第1章定义APF并讨论各种项目管理方法。接下来的5章(第2~6章)分别介绍APF生命周期的5个阶段。这5章内容结构一致，开始都是本阶段的概述，然后讨论工件、流程和交付产品，最后一小节内容是有关一个或多个案例的讨论，借以总结每章内容，另外还有几个讨论题以供教学使用。第7章描述APF的几个应用变体。第8章介绍APF和极限项目管理的关系。第9章收集了频繁问到的几个APF相关问题，并给出了答案。第10章回过头来在项目管理景观中对APF定位，并展望APF未来的发展方向。 　　0.5 案例研究 　　为了说明APF在软件开发领域之外的应用情况，本书列举了下列4个案例研究。这4个案例都是客户实际应用APF的示例。为了更好地说明APF的特点，我稍微做了修改。企业名称和客户名称都是匿名，以保护客户的隐私。对于案例的失败和成功之处，我尽力保留其原貌。对于人名和公司名称，如有雷同，纯属巧合。 　　0.5.1 第五大道小吃：小亭子设计 　　第五大道小吃一直在寻找一种能够吸引购物者兴趣的方法，从而给纽约的10家分店带来更多的客流量。公司视自己为精品，吸引的是高端顾客。该公司与其竞争对手相比，提供最完整的国际快餐食品和系列产品。小亭子还没有完全引入零售业，因此创建小亭子是一个很好的盈利机会。我和我的合作伙伴采用通过迭代发现解决方案并满足不断变化的项目需求的方法。该方法最终成为APF的最初版本，成功应用于新产品开发领域。在这个案例中，该公司建立了购物亭，在里面放置食品，接受订单，帮助客户看地图并提供其他指导性帮助。随着购物者接受并使用这种新的零售方式，其购物兴趣也在缓慢提高。商店经理的报告中表明，顾客开始把这种零售方式与他们的购物体验结合起来，购物活动也有所增加。 　　0.5.2 Kamikazi 软件系统：系统开发项目管理流程设计 　　Kamikazi软件系统公司是一家B2B和B2C网站软件开发公司，它以固定的成本/时间为客户设计个性化因特网和企业内部网址，赢得了一定的声誉。该公司的开发环境很明显属于高风险环境。最近的趋势表明，该公司在小规模项目上不挣钱；事实上，这一点是绝对错误的。Kamikazi通过项目审核发现，变更请求的数量在逐渐增加，而管理这些变更的流程却阻碍着公司的发展。于是该公司找到我们，希望我们能够帮助设计、开发和实施一个在其系统开发环境中有效的项目管理流程。 　　该公司的开发团队很少能够在预算或时限范围内完成客户的项目。尽管他们的项目管理已经达到了CMM(软件管理成熟度模型)三级的水平，但是高级经理却找不出问题并纠正它们。他们知道在对原有规格进行了一、两次毫无计划的修订之后，内部客户才会大体上满意所交付的产品。但因为这些修订不在预算范围内，因此高级经理对这些成果并不满意，也就没有任何喜悦可言，所以也不会举行任何庆祝活动。正因为如此，作为权宜之计，我们应用了APF的实时计划方法和迭代周期。下面是所取得的成果： 　　●更能满足预算和时间的限制。 　　●起初，客户代表不习惯范围变更，但因为他们参与制定了优先级决策和周期计划，因此他们对最终成果很满意。 　　●人们普遍认为，与使用旧的传统方法相比，该项目用时更少，客户接受度更高。 　　●让客户参与解决问题和处理冲突，使得团队与客户的交流更加富有成效。 　　0.5.3 比萨饼快递：订单输入和送货上门流程设计 　　比萨饼快递(Pizza Delivered Quickly, PDQ)是一家有着40年历史、在当地开有4家分店的家族连锁店。它既可以在店内就餐，也提供送货上门服务。PDQ的店面位于Woodville，这是一个有着20万人口的中西部城市。近来，PDQ的销量下降了30%，主要原因是送货上门业务减少。公司认为这主要是因为出现主要的竞争对手。该竞争对手也是一家全国比萨饼连锁店，拥有10家分店，一年半前在Woodville开业，其促销活动是保证下订单后的45分钟内送货上门。而PDQ广告承诺在1个小时内送货上门。PDQ目前的店内业务和一般业务都使用计算机操作，但却不太依赖软件系统接收、处理需要送货上门的客户订单。Pepe Ronee是PDQ公司的计算机服务主管，负责开发一个应用软件来确认最佳的“比萨饼工厂”处于什么位置，并创建一个软件系统，使该应用软件能够更有效地运作。该项目投产时，PDQ的总裁Dee Livery说要全力以赴地从事这个项目。并进一步强调说PDQ的未来取决于这个项目的成功与否。她希望其工作团队能在30分钟或更少的时间内交付准备上炉进行烤制的比萨饼，在45分钟或更少的时间内交付预焙的比萨饼。考虑到他们的计算机技术的应用现状，这是一项十分艰巨、但对于PDQ生存又至关重要的挑战。 　　0.5.4 Try&Buy百货商店：课程设计、开发和交付 　　Try&Buy百货商店是全球最大的折扣店之一。它的信息系统部(Information Systems Department, ISD)拥有1万名专家，其中大概有2000名是项目经理。这些系统开发人员按照顾客、产品、服务组织在一起，一共分为184个这样的组。每个顾客、产品、服务小组独立运作，拥有自己的流程、工具和模板。每个小组都有着强烈的责任感和自豪感。尽管跨组项目会有一些问题，但这样独立的组织结构的确使得ISD的每个顾客小组都拥有各自的专长。该公司之所以成功，很大程度上也要归因于这种独特的组织结构。然而，还是存在很多的问题。项目总是完成得很晚或很少完成，测试情况不佳，维护成本高。采用一种184个小组都要使用的项目管理方法的提议很快被否决，因为这并不实用，也会造成时间和金钱的浪费。ISD的高级经理感觉到需要对他们开展培训。 　　0.6 本书读者对象 　　一般来讲，这本书适合的专业人士虽然分属不同的团体，但他们却有一些相似之处。您是具有创造性的思想家。您在做项目时会问“为什么”，而不只是盲目地遵照任务列表工作。如果任务没什么意义，您会删除它们，或者会使用有意义的任务代替它们。您专注于交付客户满意的商业价值。您致力于和您的客户一起交付商业价值，而不是远离客户。这种协作付出是您所使用的方法的优势所在。您乐于接受新的有效项目管理的观点和理念。您具有团队合作精神，意识到只有和客户共同努力才会有成功的机会。如果您想提供绝对一流的服务并且感觉自己需要帮助的话，那么您已经找对地方。如果我描述的是您，那么请继续阅读。我会给您的工具包增添一些很有价值的内容。如果我描述的不是您，那么您需要严肃地反思一下。否则，这个世界将不再属于您。 　　0.6.1 项目经理 　　这些专业人士是本书最主要的受益者。如果他们碰到不适用传统方法的项目，那么APF或许是最好的选择。这本书将会给他们提供一个适用的模型。 　　0.6.2 软件开发人员 　　APF毕竟是一个敏捷软件开发管理流程。有关收集需求和如何处理结果方面，有很多值得学习的地方。有意义的客户参与和协作也是必需的。变化流程如果处理得当就会成为巨大的财富。本书对这些问题都会有所讨论。 　　0.6.3 产品开发人员 　　有关应用APM模型的书籍中很少提到APM应用于产品开发。APF主要为特定读者而设计。所有的案例研究描述的都是APF在非软件开发中的应用。 　　0.6.4 流程设计人员 　　APF最初的应用之一就是流程设计项目。Kamikazi 软件开发公司的案例就是通过系统开发流程项目追踪APF的开发和应用。有趣的是，这个案例研究使我们看到一个一心想要把方栓置于圆孔中的公司需要付出多大的代价。甚至在该流程完成了很长一段时间之后，该公司才意识到这正是他们一直在寻找但却没有看见的解决方案。回想起来，APF或许是该公司在网络泡沫破灭的时代幸存下来并繁荣至今的主要原因。 　　0.6.5 业务分析师 　　APF是流程设计和流程改进项目的一个强有力的工具。APF周期的探究本质上旨在发现可行的流程变化以进行可测量的改进。 　　0.6.6 流程改进专家 　　APF是流程改进项目的一个强有力的工具。上述评论同样适用于此。 　　0.6.7 研发专家 　　APF、xPM和MPx有很多相似之处。随着目标变得越来越模糊，选用的方法就应该从APF过渡到xPM或MPx。有趣的是，xPM和MPx的阶段结构是相同的。两者都是为了发现目标和发现实现不断变化的目标的解决方案。即使在完成时，剩下的问题依然是“应用xPM或MPx目标/解决方案所产生的商业价值是否是可接受的商业价值？” 　　0.6.8 问题解决者 　　有许多解决问题的模型，APF是其中之一。在典型的APF项目中，您想要给复杂问题找到一个完整的解决方案。 　　0.7 小结 　　APF使得项目管理方法向前迈进了一大步。要取得成功，需要您深入内心深处，尽全力唤起您的创造性潜能和创新性思维。APF要求客户也是如此。它不适合内心柔弱、因循守旧的人。APF需要把项目看做是一个独一无二的实体，该实体不断借鉴一些经过审核的工具、模板和流程，从而创造出最适合的项目管理方法。这里没有银弹，所以不要抱有幻想。这里也没有食谱，也不要试图寻找。但值得欣慰的事实是您即，将成为一名大厨，而不是一名普通厨师！如果您应用我提供的方法，那么将能够有效地管理任何项目，无论它有多么复杂和多么不确定。我已经对此尝试了很多次，因此我知道本书所主张的方法总是有效的！ 　　本书将带领您开始一个令人兴奋的、具有挑战性且回报颇丰的职业生涯。