本书作者根据自己27年来从事软件技术和管理方面的工作经验，结合系统工程和项目管理方面的知识，为读者推荐了很多切实可行的虚拟项目管理的思路和方法。特别是关于亚文化概念的论述、给管理者的建议、在网络时代进行现代软件开发所面临的问题以及一些常见问题的解答，一定能让读者获益匪浅。

无

今天，如果工作在一个以高新技术为主的软件密集型项目中，可能感到每天都不得不做一些几乎不可能完成的事情。从最基础部分做起的开发方式已经过时，快速集成已有的组件是当今最流行的软件开发模式。但是，当你认识到，你所在的组织并不具备决定项目成败的关键技术，而且这些技术是不容易实现的，那么如何集成由其他公司开发的包含了这些技术的产品呢？首先想到的是要寻找一个转包商，但接下来面临的是项目的进度问题，让人头疼的问题也就开始了。
　　这一切听起来熟悉吗？
　　现在，让我们想象一下。假设你正在从事的项目中所涉及的关键技术可以很快实现，分配到项目中的技术人员也很明确地了解你对他们的要求。设想在工程真正开始之前，你不用花大量宝贵的时间来仔细编写提供给转包商的详细的规格说明书。设想你的项目团队由合适的工程技术人员组成，他们具备项目所需的技能，并且整装待发，这个团队在合同生效的第一天起就开始正常、高效地运转。
　　在这个项目中，不会存在由于任务的错误传达而造成的冗长的集成工作。这次所有的转包商都是你自己团队的扩展成员，大家共同使用项目一致同意的工具，支持项目的基础设施、技术与管理的规程和战略。这个项目进展得如此顺利，以至于合同开始一年后，你几乎分辨不出自己的员工和转包商了。顺便提一下，项目团队中的一些成员并不是和你在同一地点一起工作，有一部分人在3 000英里之外。但是在这个项目中，地理位置在哪里并不重要，因为距离不是问题。
　　以上描述的情况怎么样？你是不是感到有些疑惑？是的，这种感觉是很正常的。这个项目确实被描述得有些不切实际，技术的发展以及组织获取商业机会的策略的变化都会对工程如何真正地进行产生显著的影响。这些变化不仅是由技术的发展来驱动的，也因为我们要改变客户的态度，使我们能够利用已有的解决方案来迎接新的挑战。
　　今天，客户不愿意等很多年后才能看到他们投资的成果。竞争的日益加剧要求我们必须具备快速解决问题的能力，并且在需要的时候，能够很快地改变以符合新的要求，这并不是那么容易实现的。虽然利用已有的解决方案来完成任务从理论上讲是非常合理的，但很少有公司具备必要的、全部的解决方案以及有能力的专家来应对当今多数复杂的挑战。
　　为了适应竞争的需要，许多高新技术组织开始转向战略合作模式，他们雇佣物理上分散的但是已集成的项目团队。就在几年之前这种模式看起来还是难以想象的，然而现代技术，例如电子邮件、互联网、网络会议、电话和视频会议等技术为分布式团队更加高效地工作提供了新的可能。

本书的内容
　　本书讨论的不是虚拟技术。它讨论的是技术管理问题，也就是如何通过雇佣其他组织的资源和人力来快速、低成本地建立复杂的软件密集型系统，这是软件项目管理革命性的进步。我们知道这种管理模式的潜力是巨大的。同时，从目前的工程组织机构在上世纪90年代中后期到21世纪初遇到的问题和积累的经验中，我们也认识到哪些方面严重影响了项目的进展。这
本书描述和验证了，在以高新技术为主、采用虚拟合作方式的软件密集型项目中所采用的关键的管理方法，同时也为组织在高速变化的环境中寻求高生产力提供了切实可行的方法。

本书的读者
　　本书是为那些忙碌的项目领导者以及项目工程人员（第一或第二层的工程管理人员，高级项目工程人员以及项目经理）编写的。他们了解项目管理的基本方法，但是面对今天基于虚拟合作方式的项目，他们不知道造成项目进展困难的根本原因是什么，以及如何解决这些问题。由多个组织参与并采用分布式开发的高科技软件项目会面临很多问题，这本书对关心这些问题的人会有所帮助。本书假设读者熟悉大型软件项目的传统的管理方法。

本书的组织
　　这本书分为七个部分：绪论，综述，传统集中式环境，故事，八步骤计划，总结和附录。
　　在绪论部分，我们提出了本书要讨论的观点，并对项目的特点进行了描述。我们很快发现这些对于很多类型的项目都是适用的。在绪论中，我们还将讨论：虚拟合作的工作方式对生产力的基本影响，以及为什么要对虚拟项目给予更多的关注，并且特别强调了这本书将如何帮助读者。
　　书中提出的建议旨在让读者了解在虚拟项目中会出现的情况，而不是要告诉读者应该怎样去做。在理解虚拟项目带来的新的困境之前，我们首先要真正接受这一事实，也就是项目管理方式的变化是必然的。这是故事部分的主要目的。
　　同时，考虑到项目领导者非常繁忙，他们中很少有人能有时间仔细浏览书中的所有细节，所以综述部分就被包含进来。这是本书最后写出的一个部分，它把本书中对于虚拟项目领导者来说最重要的关键点进行了概括，包括了在虚拟项目中最常见的11种问题和14种推荐的解决方法。
　　为了保证综述部分尽可能简练，我们没有提供所有的背景知识和基本原理，但读者可以根据我们提供的参考书目来了解更多的细节。综述部分提出了一个包含八个步骤的切实可行的计划，这个计划可以用来搭建和执行新的虚拟项目，或者改进已经出现问题的项目。
　　第1章主要描述了在传统的集中方式下如何完成项目，以及项目具有哪些基本特征和要素。这章的内容基于这样的假设：在完全理解新的分布式项目运作方式带来的变化之前，首先需要理解传统集中方式的成功之处。
　　接下来的五个章节通过对真实的项目经历的一系列故事来调查和阐述发生在虚拟项目中的变化，这些项目大都发生在1994年至2000年间。我们对这些项目进行了分析、研究、总结，并针对项目中常见的问题推荐了解决方法。
　　第7章综合了前面几章的结论，并对在综述部分中讨论的八步骤计划进行了非常深入的探讨。
　　在第8章“总结”中，我们回到了生产力的问题上，再次提醒读者我们在绪论部分讨论过的目标，并将关键点进行了总结。我们还将讨论，如何保证一个虚拟项目的正常进行，以及如何着手改进一个正在进行的项目。
　　在附录部分我们提供了一些相关的支持信息。第1章至第8章中重点描述的34个有关虚拟项目问题的小贴士和50个解决方法在附录L中进行了总结。我们建议忙碌的管理人员阅读附录J中提供的常见问题的解答。
　　由于这不是一本关于方法学的书籍，书中推荐的方法和当前的系统和软件思想是一致的。书中提供的解决方法参考了相关领域中公认的专家发表的作品。
　　如果你正面临一个高科技软件密集型项目，项目有多个组织参与，并且有多个工作地点（这种方式将被越来越多的公司采用），这本书将帮助你的项目向着正确的方向前进，并避免许多其他公司遇到过的常见错误再次发生在你的项目中。

关于生产力方面研究的书籍非常多。我们都希望比竞争者更快速、更低成本地生产出高质量的产品。但在当今世界中，高质量的标准是什么呢？它与生产力有什么关系？以往，在很多组织机构中，生产力都被看成是一个数字游戏,也就是说，把生产力与每人每小时能产出的产品数量联系在一起。　近年来，很多组织为提高生产力做出了坚持不懈的努力，他们致力于建立稳定的、可重复的内部工程过程。这些组织认为建立一个可重复的内部工作过程是不断提高生产力的关键。抛开这个从长远角度考虑的观点，我们需要重新认真地考虑，在当前的环境下如何真正提高生产力。例如，当你的竞争者已经具备了你的客户想要的产品，那么一味的提高单位时间内的产出数量还有什么意义吗？
　　今天，对于规模较小、相对稳定的组织机构而言，提高生产力的方法和途径已经与以往不同了。以前通过自己的努力而使自己立于不败之地的组织，现在正着力于与其他组织合作生产需要的产品。在这个过程中，多数组织认识到，仅仅依靠组织内部的资源已经不能满足激烈的市场竞争的需要。
　　因此，对于当今成功的组织而言，真正的高生产力已经不仅仅是指单位时间的产出量。这些组织正在寻求一种新的、创造性的方法，其目的是把以往的竞争者转变为密切合作的伙伴。

导致合作项目失败的因素
　　为了与日新月异的外部环境相适应，本书致力于讨论一种新的构造高科技软件密集型系统的方法，集成已经存在的产品，以及使用具备不同技能、知识和背景的工程技术人员开发新的产品。如何将这两种方法结合起来构建一个项目，是本书特别强调的重点。
　　Booz－Allen4的研究表明，以下四方面因素导致很多合作项目的失败：
　文化的差异
　领导层的冲突
　缺乏信任
　内在的竞争关系
　　通过对２０世纪90年代到21世纪初这段时间进行的一些合作工程项目的研究，我们发现，以上四方面因素是这些项目共有的特征。造成项目中出现种种问题的根本原因其实并不像想象得那样复杂，但是，由于没有采取及时、有效的措施来解决这些问题，最终导致了项目的失败。通过对合作项目的进一步研究，我们认识到，我们能够识别出导致项目失败的那些因素，并且可以通过采取行之有效的措施来解决这些问题。

背景
　　本书中涉及的观点和方法是通过对在1994年至1998年间开发的、具有分布式开发特征的项目的研究而提出的。最初，我们认为本书仅仅为那些采用相同开发模式的项目提供帮助，然而，通过对其他一些具备不同特征的分布式项目（1998年至2000年间）的研究，我们得出结论，本书中提出的很多方法的适用范围比最初预想得要大得多。
　　我们并不是推荐读者将本书中所有的方法都应用到他们的虚拟项目中去。如果你的项目包括多个办公地点、有多家公司参与、上百个项目团队成员分布在世界不同的地方，那么这本书将是非常有帮助的。对于那些规模较小的、正在为虚拟合作模式寻求有效策略的组织机构，本书同样是有帮助的。

什么是虚拟合作
　　在20世纪90年代中期，最初开始研究虚拟项目时，我们把虚拟合作定义为：
　　“综合关键技术来解决问题，但物理上不是在同一地点集中式工作。”
　　现在出现了一种新的分布式开发项目。我们也据此对虚拟合作的定义进行了修订。
　　在大多数传统的转包合同关系中，主承包商向分包商提供正式的规格说明书。通常，规格说明书对需要生产的产品进行了详细的描述。传统的分包商依照规格说明书的要求，利用自己的设备、使用自己的管理人员、自己的辅助基础设施、内部的生产过程和技术方法来生产产品。
　　只要规格说明书的要求能够得到满足，分包商就可以自由地利用自己的设备工作，因为他们希望使用自己的工具、方法和辅助基础设施。依照上面对虚拟合作的定义，这种主承包商和分包商的关系可以被称作虚拟合作。
　　本书中重点强调的是包括多个组织参与、有多个办公地点的虚拟项目。在这类项目中，组织之间的关系与传统的转包合同关系是不同的。
　　相对于传统的主-转承包关系的项目，我们更感兴趣的是那些使用虚拟团队的项目，它们拥有单一的、整合的项目团队，项目成员共同遵循符合一定标准（待讨论）的公共过程、支持服务和技术策略，他们的管理通过一个线形的管理链完成。这些虚拟合作的项目与传统项目的主要区别在于二者使用的管理方法不同。
　　面对一份复杂、详细的需求规格说明书，在项目的初始阶段、工程开发工作真正开始之前，我们经常会发现，我们的时间有限而且欠缺一些必需的知识。此外，客户往往在项目开始的第一天起就期待更多的东西。在很多高科技产品的竞技舞台上，对于客户的需求，很少有组织能够拥有现成的解决方案。为了适应市场竞争的需要，一种新的虚拟合作方式应运而生，我们这样定义它：
　　“建立一个跨多个物理工作地点、单一的整合团队，集成关键技术，以便快速应对新的、复杂的软件密集型项目的挑战。”

当今虚拟合作项目的特征
　　我们总结出了7个在当今很多虚拟合作项目中出现的关键特征。如果你正处在一个分布式软件项目的开发过程中，或者正处在一个新项目的投标阶段，那么把以下列出的7个特征与你的项目相比较，看本书是否会对你的项目有所帮助。这些特征包括：
　　多个组织参与
　软件密集型
　时间紧迫
　强调集成和重用
　采用先进的技术
　项目团队成员物理上是分散的
　工程人员具备不同的技术背景
下面将对这些特征逐一进行描述。
　多个组织参与。所有的虚拟项目都有多个组织参与，这些组织并不一定是指不同的公司。
　　有些项目是由公司内部多个不同部门之间合作完成的，它们处在不同的工作地点，有自己的组织结构和文化。我们认为多数虚拟项目都是大型项目，但并不是说每个项目参与的工程师都非常多。这里我们说的“大型”是指：项目中涉及多种技术、多个部门、多个工作地点或者是多个组织。事实上，在我们分析的项目中，有些项目在初始阶段团队规模很小（3~7人），并且随着项目的进展人数不断减少。采取这种方式进行项目开发能够有效地节约成本，因为项目中只包含关键的技术和必需的人员。这些项目的重要特征是有多个组织参与，因此项目中出现了不同的组织结构、文化和方法。很多在由单一组织或工作地点完成的项目中出现的问题，本书并未涉及。
　软件密集型。我们研究的所有项目都是以软件技术为主的。这是一个非常关键的特征，因为我们面临的问题包括软件产品的研发、产品与系统工程软件的关系、产品与那些由负责编写接口程序的项目成员编制的相关软件的关系。由于是针对软件密集型的项目，所以本书中提出和讨论的很多观点都是超越传统的软件边界概念的扩展。
　时间紧迫。今天，时间紧迫对于项目来说好像是非常正常的事，并不是什么例外。然而，我们还是要明确地指出这个特征。时间紧迫是我们放弃传统的大规模开发的方法，而转向强调集成和重用的开发方法的一个重要原因。传统的开发方法不能以足够快的速度将产品交付到用户手中，不能满足未来市场的需要。快速的开发能力是时间紧迫这一特征的另外一种表达方式。如果客户看不到项目在快速进展，那么项目将面临被终止的风险，或者在开发工作尚未正式启动之前项目投资就已经被缩减了。
　强调集成和重用。这个特征实际上是前一个特征——时间紧迫带来的结果。为了应对快速开发的挑战，我们必须采用强调集成和重用的项目开发方法。今天，无论是虚拟合作还是传统集中方式，很少有项目能够承担长期的开发过程，因此，必须要合理的使用已经存在的解决方案，并将其有效地集成到单一的系统中去。
　先进的技术。为了应对新的、复杂的挑战，大多数的虚拟项目有多个组织参与，包含多种技术。这是虚拟项目的一个重要特征，它引出了一个关键的论点：创造性设计方案。这一论点将在第2章中进行详细的讨论。
　项目团队成员物理上是分散的。工程工作的交互必然会受到物理位置的影响。新技术（例如：电子邮件、远程电话会议系统、网络会议、万维网）使团队成员在物理上分散工作成为可能。但是，物理上的分散还是会影响团队成员间的交流，因此引出了一系列非技术层面的问题。如何有效地管理和解决这些问题，我们将在第五章中进行详细的讨论。
　工程人员具备不同的技术背景。我们快速地将来自不同组织、有着不同背景和经历的人员组合到一起，这样做，显然可以使项目团队的知识能力大大扩充和提高，但同时项目内部发生冲突的可能性也大大增加了。这些冲突往往和物理距离问题混合在一起，在决定采取怎样的方法来解决冲突时，我们必须认真考虑物理距离的问题。有关这个问题的讨论贯穿了本书的始终，尤其在第2章和第7章中进行了详细的讨论。

为什么要关注虚拟合作
　　今天，计算机设备的价格不断降低，加上互联沟通能力的大大加强，造成市场对软件的需求空前增长。与此同时，越来越多的敏锐的客户也认识到，开发一个新的软件并不需要从基础研发做起。
　　不幸的是，很多已经存在的解决方案并不能直接被一个新的客户使用。为了满足客户的要求，我们必须对现有产品进行必要的改造。要完成改造工作，我们不仅需要掌握特定的技术，还要对该产品有相当程度的了解。很多软件组织发现他们缺乏这样的关键技术和人才，因此无法在激烈的市场竞争中立足。
　　使用分布式开发的模式为公司提供了更多的商业机会，这些机会在以往看来几乎是不可能得到的。这是因为我们拥有了更广博的技能和产品知识，以及更加丰富的人才资源库。公司的从属关系和物理的位置，这两个过去看来最主要的障碍，已经不再是阻碍我们发展的屏障了。
　　我们必须认识到，我们不是一定要与不同背景的人采取虚拟合作的方式一同工作，因为这无疑会增加管理工作的复杂程度。这一观点贯穿本书始终。然而，配备所有必须的人才和技术，有时对于一个组织来讲根本是不可能、不现实的。
　　以高新技术为主的软件密集型组织要想在当今高速变化的商业环境中生存，必须能够利用新的机会让自己站稳脚跟，而使用传统的开发模式根本无法创造这些新机会。为了满足未来的竞争需要和潜在的软件需求而拥有多个领域的所有关键技术，这种做法对于单一的组织来讲是不可行的。
　　理论上讲，今天，有先进技术的支持，利用虚拟合作的方式开发一个项目应该不是那么困难。不论工程师们是在他（她）的办公室工作还是在几千公里以外工作，管理者都应该可以同样有效地分派任务、监督工作。然而，现实并不是这样的。通常，各种各样不可预见的问题会在项目进行的过程中不断出现。这些问题连同已经被验证过的、相应的解决方案正是本书要讨论的重点。

为什么要编写这本书
　　以前，我曾经多次想过，应该把自己工作中的经历和遇到的问题编写成一本书。我希望本书的内容能够在介绍分布式开发模式的基础上再向前迈进一步。本书对于那些只是想对未来有个初步了解的读者是有帮助的，然而激励我编写这本书的主要原因是：我希望把自己在帮助客户建立和执行一个虚拟合作项目总结出的经验教训，作为帮助和指导奉献给读者。
　　其他人需要在艰难的实践过程中不断摸索才能总结出成功的经验和教训，有了这本书，你不必再去走他们走过的路。我希望本书中提出的观点和相应的解决方案，能够回答21世纪虚拟项目领导将要面对的众多问题。

本书将为解决哪些问题提供帮助
　　通过阅读本书，你将认识到虚拟合作的项目与传统的集中式项目有哪些不同，相信你会把这些知识与自己的实际工作经验相结合。你将了解到在虚拟合作的项目中，项目领导通常会遇到的很多常见的困难。尤其是，你会认识到：
　造成项目任务远程沟通困难甚至误解的主要原因，以及及时、有效的技术方法以便补救已经出现的问题。
　关键的规则以避免在使用沟通技术时（电子邮件、远程电话会议系统）通常会出现的问题。
　工作分解不同方法的优缺点。
　如何协调不同办公地点的工作，使那些具备不同过程成熟度的站点能够有效地协同工作。
　降低虚拟合作项目特殊工作过程成本的方法。
　协调不同工作地点基础设施的差异战略。
　一个八步骤的计划，用来系统地建立和执行一个虚拟合作的项目，有效避免11种常见问题的出现。

有关本书提出的建议的说明
　　必须说明的是，本书中提出的旨在帮助你的虚拟项目走向成功的各种建议，都是基于你的项目团队成员希望项目成功的假设。有时人的行为总是会受到个人利益的影响。如果你的团队成员中，有人故意想要破坏项目的正常运转，那么既使采用了我们推荐的方法，项目还是很可能会失败。另外需要说明的是，本书中多次用到的术语“虚拟”和“分布式”，二者含义相同。

未来会怎样
　　在虚拟项目中，多个远程的办公地点协同工作，这样的工作方式比传统的单一办公地点方式的工作效率要高。传统的转包合同项目，需要为每个团队成员支付相应层面的管理和服务支持成本，并且他们的工作是非常独立的，而虚拟合作的方式则能够使项目更加有效地运作。这为大幅度地提高生产力提供了可能。
　　我们预测，未来对真正生产力的衡量将与外部世界密不可分。我们发现，真正的生产力已经与我们和外部组织的关系联系得越来越紧密，而这些外部组织过去可能被看作是我们的竞争对手。这些新的合作关系并不那么容易建立，而且不容易和传统的内部工程过程相适应。为了理解这些问题（技术的和非技术层面的），我们首先必须认真分析传统的内部工程过程。
这正是第1章要讨论的题目。

(美)Paul E.McMahon：Paul E.McMahon: Paul E. McMahon为不同规模的工程组织提供技术和管理方面的服务。20世纪70年代初，他开始从事飞行仿真技术程序设计工作。在1997年开始PME系统的独立工作之前，McMahon先生一直在休斯和洛克希德·马丁公司担任高级技术和管理职务。作者根据他27年的工作经验为组织提供全方位的帮助，他结合系统工程和项目管理两方面的技术来寻求高质量的软件开发过程。他曾在Binghamton大学任教，发表过10余篇论文，经常出席行业研讨会，而且已经成为NASA有号召力的演讲者。可以通过电子邮箱pemcmahon@acm.org与作者联系。要获取更多相关的信息,请登录www.pensystems.com。

何瑞娟 等：暂无简介

今天，软件行业的竞争日益加剧。许多软件组织认识到，仅仅依靠组织内部的资源已经不能满足激烈的市场竞争的需要。为了在最短的时间内、以最低廉的成本为客户提供高质量的产品，越来越多的组织开始转向战略合作模式，也就是与其他组织合作，通过整合现有的产品，以及使用具备不同技能、知识和背景的工程技术人员开发新的产品等方式来完成软件项目的开发。虚拟项目管理的概念也就应运而生了。
　　由于有多个组织的参与，虚拟项目管理比传统的软件项目管理更为复杂和困难。本书的作者多年来一直从事软件技术和管理方面的工作，作者根据自己27年的工作经验，结合系统工程和项目管理两方面的知识，为我们推荐了很多切实可行的虚拟项目管理的思路和方法。相信本书一定会为虚拟项目的管理者们提供很大的帮助。

译 者
2003年11月

第1章　传统的集中式工程17
　1.1　工程人员怎样提高工作效率17
　1.2　非正式沟通的作用18
　1.3　组织的亚文化19
　1.4　组织的差异20
　　1.4.1　大型和小型的工程组织21
　　1.4.2　系统和软件22
　　1.4.3　支持职能23
　　1.4.4　〖JP5〗体系结构、用户接口和数据库〖JP〗23
　1.5　组织的进化和发展25
　　1.5.1　一个故事26
　　1.5.2　成功组织的共同关键特点27
　1.6　组织的期望28
　　1.6.1　任务分配记录表28
　　1.6.2　任务期望29
　1.7　正式和非正式29
　1.8　过程成熟度30
　　1.8.1　 一个成熟的过程在不同的地点分布执行，这是否容易做到30
　　1.8.2　什么使成熟过程起作用31
　参考书目32
第2章　两种文化的故事（分裂的项目）33
2.1　故事34
　　2.1.1　个人经验的影响36
　　2.1.2　文化、逆境和沟通37
　　2.1.3　虚拟团队的沟通障碍38
　　2.1.4　在虚拟项目中解决冲突为什么经常会失败39
　　2.1.5　回到这个故事中41
　2.2　虚拟合作的一个困境41
　　2.2.1　分裂的项目准则42
　　2.2.2　综合的项目准则42
　2.3　临近隔间探头的故事43
　2.4　关于创造性设计过程44
　　2.4.1　我们头脑中的电灯泡44
　　2.4.2　与过去经验的关系44
　　2.4.3　酝酿和借鉴45
　　2.4.4　虚拟合作和创造性的过程46
　2.5　在必要的时候一起工作46
　2.6　虚拟文化的实现47
　2.7　结论48
　参考书目50
第3章　远程任务管理： 我在按要求做事情吗51
　3.1　体系结构的故事52
　3.2　为什么体系结构是影响远程任务完成的关键54
　3.3　认识体系结构54
　　3.3.1　体系结构的组织观点55
　　3.3.2　体系结构的不同的组织观点55
　　3.3.3　组织结构与任务分配之间的关系55
　3.4　术语的“本地含义”的演变以及它与组织职责之间的关系56
　3.5　关键问题、风险和过去的经验之间的关系56
　3.6　使用体系结构来促进任务沟通57
　3.7　数据库工作过程的故事58
　3.8　基本准则、坚定的信仰和风险61
　3.9　回到我们的故事62
　3.10　结论64
　参考书目65
第4章　虚拟文化的实现：快速过滤项目准则67
　4.1　RFPM构造和维护指南68
　　4.1.1　规模大小69
　　4.1.2　关键问题和一致策略69
　　4.1.3　体系结构/系统设计指南69
　　4.1.4　 配置管理70
　　4.1.5　增量构建70
　4.2　为什么需要更为正式的任务分配71
　4.3　什么是CPDM以及它有哪些用途71
　　4.3.1　CPDM属性71
　　4.3.2　组件产品与任务分配的关系72
　　4.3.3　组件产品和可交付产品72
　　4.3.4　CPDM和项目/公司规程72
　　4.3.5　CPDM是连接公司规程和项目特定信息的桥梁73
　4.4　通过使用CPDM来避免虚拟项目缺陷的例子73
　　4.4.1　如何避免缺陷一：模棱两可的术语引起的沟通偏差73
　　4.4.2　如何避免缺陷二：过程不清晰引起的沟通偏差77
　4.5　CPDM的好处之一：系统和软件的集成79
　4.6　CPDM的好处之二：最终交付产品的灵活性80
　4.7　结论80
　参考书目81
第5章　团队沟通：游戏规则已经改变83
　5.1　团队忠诚度的故事84
　　5.1.1　故事短评85
　　5.1.2　团队信息分类85
　　5.1.3　团队原则一：对团队要忠诚86
　　5.1.4　虚拟项目与多团队忠诚86
　　5.1.5　我们是否对远程的团队成员要求得太多了88
　　5.1.6　返回我们的故事：困境89
　　5.1.7　自主管理的团队、老虎团队及以控制为导向的经理89
　　5.1.8　老虎团队89
　　5.1.9　另一种解决办法91
　　5.1.10　发言权不同于表决权91
　　5.1.11　关于团队忠诚的更多信息92
　5.2　怎样有效地利用虚拟沟通技术92
　　5.2.1　电子邮件93
　　5.2.2　远程电话会议系统98
　　5.2.3　小事情和大事情101
　5.3　虚拟项目有效运转的规则101
　5.4　总结和结论103
　参考书目105
第6章　集成：现实世界还不是无缝的107
　6.1　故事108
　　6.1.1　好消息109
　　6.1.2　不太好的消息110
　6.2　“这里和那里”的故事113
　　6.2.1　故事113
　　6.2.2　陷阱：“让我们采用可能得到的最成熟的过程”114
　　6.2.3　对工作过程的观察115
　6.3　怎样制定有效的工作分解决策115
　　6.3.1　开发的不同阶段116
　　6.3.2　体系结构的因素（子系统）116
　6.4　集成工作的困难117
　6.5　全球组件方法117
　　6.5.1　什么是全球组件117
　　6.5.2　使用全球组件的好处118
　　6.5.3　全球组件方法和虚拟的概念相抵触吗118
　　6.5.4　澄清术语119
　　6.5.5　全球组件的三个主要特点119
　6.6　分析和建议120
　　6.6.1　任务分配120
　　6.6.2　质量121
　　6.6.3　集成121
　6.7　总结122
　参考书目123
第7章　使用切实可行的八步骤方法来建立和维护一个成功的虚拟项目125
　7.1　虚拟项目的11种常见问题125
　7.2　八步骤计划介绍126
　7.3　第一步——建立高层的项目组织128
　　7.3.1　指派团队领导128
　　7.3.2　制订宪章并在其中清晰地定义职责130
　　7.3.3　开始建立RFPM131
　7.4　第二步——建立工作分解131
　　7.4.1　确定方法（子系统、阶段和其他）132
　　7.4.2　建立初始的系统体系结构132
　　7.4.3　建立CPDM——连接体系结构和子系统的桥梁133
　　7.4.4　工作分解134
　　7.4.5　由于不恰当的原因拖延工作分解的定义135
　7.5　第三步——系统计划135
　　7.5.1　系统构建计划135
　　7.5.2　需求分配136
　　7.5.3　集成计划136
　7.6　第四步——特殊任务：基础设施和项目规则137
　　7.6.1　什么是基础设施以及如何确定自己的项目的需求137
　　7.6.2　项目规则——经验教训的交流141
　7.7　第五步——建立组织的第三层142
　7.8　第六步——详细计划143
　　7.8.1　详细计划编制方法中的文化差异143
　　7.8.2　三个必须预先完成的任务144
　　7.8.3　首先做最该做的事145
　7.9　第七步——测试项目组织的运作概念146
　　7.9.1　任务方向——当顾问领导和职能领导发生抵触时147
　　7.9.2　任务管理——严格的方法和综合的方法之比较150
　　7.9.3　跨不同组织及跨多个工作地点之间的交互——使用检查清单152
　　7.9.4　集成工程职责——使用检查清单152
　　7.9.5　与客户的沟通——建立一个定义良好的策略154
　7.10　第八步——执行过程中聚焦冲突管理〖JP〗155
　　7.10.1　项目执行过程中非技术层面的因素〖JP〗156
　　7.10.2　冲突的两种形式156
　　7.10.3　良性冲突的标志156
　　7.10.4　破坏性冲突的警告信号157
　　7.10.5　 预防性维护161
　7.11　总结162
　参考书目164
第8章　总结165
　8.1　虚拟公司165
　8.2　虚拟合作方法总结166
　8.3　有关非正式活动的重要注释166
　8.4　未来的虚拟项目策略166
　8.5　使策略起作用167
　8.6　虚拟文化概念的总结167
　8.7　虚拟文化的产物168
　8.8　虚拟文化的哲学169
　8.9　未来的虚拟文化169
　8.10　 现在应该做什么169
　　8.10.1　新项目170
　　8.10.2　现有的项目171
　8.11　虚拟项目管理框架171
　　8.11.1　第一级：组织171
　　8.11.2　第二级：虚拟文化基础层172
　　8.11.3　第三级：虚拟文化中间层172
　　8.11.4　第四级：虚拟文化动态层172
　8.12　如何使用框架172
　参考书目173
附录175
附录A　组件产品开发矩阵（CPDM）的指导177
附录B　定义181
附录C　模板185
附录D　表格187
附录E　表格样例191
附录F　标准193
附录G　警告信号197
附录H　检查清单199
附录I　规则205
附录J　常见问题207
附录K　宏观的观点225
附录L　34个小贴士和50个解决方法大纲235