信息系统项目管理师学习资料大全

信息系统项目管理师学习资料大全

SOA管理是我经常谈论的一个话题，得到的反馈也是好坏参半，这是由于对愿意与方式

缺乏熟悉。不管你的组织开始SOA多长时间，SOA管理都是需要多加注意的。我将首先解释

一下SOA管理需要注意的原因，而后再谈一下需要注意的方面。

但在我开始之前，我首先要澄清SOA管理与SOA治理的区别。关于我来说，SOA管理是

SOA治理的一部分。SOA治理是由流程、标准与政策来治理SOA实施的。一个完整的SOA治

懂得决方案设计注册表、存储、管理变革、服务操纵、服务质量、安全等等。

在此我将只谈SOA管理，关于多数厂商来说是服务操纵、安全、业务流程可见度与特殊

事件处理。

首先，让我们看看传统的智慧。组织通常认为他们不需要SOA管理的原因在于没有足够

的业务动力。或者者说：“在我们的SOA架构还没建立起来的时候就需要SOA管理呢？”这

种办法正确吗？你能够在读完这篇文章之后做出自己的决定。

我早前曾经提到过SOA实施像一场旅行，你的组织要达到一定的SOA成熟度是需要时间

的。在SOA实施的某一个时间点，SOA管理就会牵涉进来，原因有两点：

1.你的SOA架构将单个的应用程序与筒仓型业务功能变成了分布式服务。随着灵活性

与灵敏度的增加，安全与访问操纵的复杂性也随之提高。这就需要管理工具上的新办法。

2.即使是在基础的SOA环境中，你的组织也将需要SOA架构的可见度。可见度的要求

包含业务流程、服务使用、性能瓶颈等等。随着你的环境变得越来越分散，使用原有的管理

工具就会逐步丧失可见度。因此，当SOA促进你的业务时，你需要$0A促进你的管理环境去

超越传统系统管理。

这是SOA进展的适当时机吗？

那么，什么时候才是考虑SOA管理的适当时机呢？这个时间应该早于还是晚于你的SOA

部署期呢？决定因素有下列几点：

1访问权操纵与安全是SOA管理提出的关键问题。因此，SOA管理应该是你的SOA基础

架构整体中不可分割的一部分，而不是随后加入。从实际出发，你需要在SOA项目早期考虑

安全与操纵。

2有了妥善的规划，SOA管理将降低SOA项目的成本实施时间。人们普遍认识到项目周

期早期发生的改变/修复相较于晚期来说影响更小。换句话说，你越晚决定对SOA管理提出

的问题进行解决，对你之前所做决策的影响就会越大，而代价往往是巨大的。

3组织往往只有在出现问题的时候才会想到管理。我们很难去量化由于基础架构中累赘

服务或者安全破坏所造成的干扰带来的成本。你要做的不是去寻找救火措施，而是利用SOA

管理工具主动的操纵与监控业务。

4业务流程管理（BPM）是亚洲企业中的一大主题。SOA实施则是另外一个主题。SOA

管理工具是BPM很好的补足解决方案。

在使用BPM的时候，多数企业都想如何利用BPM工具建立并管控其业务流程。但是，我

需要提出下列几个问题以供考虑：

1是不是所有的业务流程都能用BPM解决方案来定义？

2假如不是，那么你要如何处理那些没有被BPM工具定义的业务流程？

3这些业务流程是遵循最初设计构想来运作的吗？

换句话说，你要如何发现你的业务流程正导致一些始料未及的后果？

我认为大多数企业都无法通过BPM解决方案为所有的业务流程建模。假如你的业务存在

己久，那么就可能会比你想象中还要多的未定义业务流程。一些SOA管理工具，带有自动发

现功能，能弥补这一空白。这些工具能够“看到”并告知你基础架构中正在发生的问题。因

此不要以你认为有效的方式模拟业务流程，而让你的SOA管理工具来告诉你真正发生的问

题。这不仅仅有利于IT针对应用与瓶颈下功夫，还有利于分析师看到实时的业务流程。

目前，我们已经讨论了进行SOA管理的原因，假如你认为你真正需要SOA管理，下列几

点是在选择解决方案时需要注意的：

注意事项：

1性能：所有的管理与监控工具会带来一些开销，你需要确定你的系统性能不可能受到

太大的影响。

2标准支持：你的业务是在异构的应用程序、服务与标准中运行的，你的管懂得决方案

也需要如此。假如你需要改变基础架构投资以服务SOA管理，那么你有可能在寻找错误的解

决方案。

3跨功能支持。你的SOA基础架构能够跨越多个功能或者应用解决问题，同样，你的

SOA管理方案也是如此。千万确保你所制定出的解决方案能够真正的满足IT部门的需要，

同时也能满足业务分析人员，甚至可能会是保安人员的需要。

就如同整个企业架构体系中的其他资产一样,假如你能确切的明白SOA管懂得决方案存

在的意义与如何使用将会让你获得更加明显的竞争优势。那么，你是否确实需要SOA管理？

这个决定是由你选择的。

中小企业信息化：资金与需求该如何权衡

小企业信息化考验IT人的能力

什么是小企业?在我看来，小企业是特指那些已经度过了生存期、销售额在1亿到10

亿元范围内、在特定细分行业或者者区域内有独到之处的核心能力，看起来能够迅速进展的

企业。

小企业的信息化矛盾体

在经济发达的地区，这样的小企业很多，造就了众多的亿万富翁。同时，这样的企业在

进展上则是上上下下、起起伏伏，绝大多数无法持续进展成为更大的规模化现代企业。企业

成功的特殊优势受到挑战，与通用成熟的现代企业管理方法有严重的甚至根本的冲突，规模

与区域扩展后外部环境的压力与复杂度超出想像与承受能力。

在这种情况下，信息化到底能够为小企业提供什么价值?这个问题是一直困扰着信息经

理或者者信息总监或者者CIO的一个情况。

我们明白，信息化是以系统化的体系与工具规范企业的运营方法与流程，让企业在一定

的战略方向上持续稳固经营。从管理不成熟的角度看，小企业确实不是做信息化的最好时期;

但是，从企业进展的角度看，信息化又是小企业做强做大必不可少的工具。这样的矛盾状态,

使得小企业的信息化成为考验IT人残酷的熔炉。

小企业信息化“四核心”

“尊重环境，量力而行，保障基础，突出优势”大概是小企业信息化的核心要义。

“尊重环境”是要根据企业文化、企业的管理风格、管理体系这个大环境，选择信息系

统中能够有效表达这些特征的流程进行实施，在总体保证整体连续的业务流程的情况下，突

出具有共识的重点环节，舍弃有争议的环节，在流程的基本面上保持“信息系统风格就是企

业文化的反映”。

“量力而行”的重点不是投资上的量力而行.通常情况下企业假如效益良好，投资不是

问题。这个“力”是指企业的“管理能力”或者者是“管理成熟度”，与企业的学习速度或

者者对系统化、规范化操作的学习能力。通常情况下，企业通常高估自己的学习能力，低估

过去的习惯势力，或者者对信息系统给予太高的期望。在实施信息系统的时候要么过低地估

计使用系统对业务的改变，要么过高地估计自己的习惯或者者学习能力，或者者相反。这样

会形成众多的冲突，截然相反的评估或者者意见经常同时出现。因此，对“能力”要做好充

分的评估。

“保障基础”则是要保持信息系统的流程完整性，特别是供应链、资金链的流程，重点

要放在使整个链条通畅，不必有太多花哨的功能。开始是基本的核心流程，再在使用的过程

中逐步优化、细化每步操作。这样能够达到“麻雀虽小五脏俱全”，符合小企业使用大系统

的基本规律，对未来的进展具备良好的扩充与支持能力，也为未来规范的组织进展奠定系统

基础。

“突出优势”是小企业信息化的特征价值。由于小企业通常会具备某些特殊或者者特有

的管理方法、业务流程让企业引以为豪，那就要特别关注这些特征，在信息系统中重点突出

这些优势，固化在系统中继承下去。这样的信息系统也才能够充分表达企业的文化与管理特

征，得到广泛的认可。

总体来讲，由于小企业的管理尚未成熟，运营体系尚未职业化、标准化与系统化，企业

进展速度与组织变动速度快，进行小企业信息化的时候要充分考虑这些因素。不管是选择重

型的ERP系统还是轻量级的专用系统，都需要在企业特征优势方面具有传承的作用，在规模

化与规范化方面具有充分的空间，在流程上要注重核心流程的重点环节与保留未来优化的弹

性空间，这样实现的信息系统就会十分切合小企业多方面的需求，也能够表达信息化在推动

企业进展上的价值。

制作网页需要学习什么技术

HTML4.01

HTML是Web的语言，每一个Web开发者都需要对它拥有基本的熟悉。

HTML4.01是重要的Web标准，它与HTML3.2的差异非常之大。

当类似font的标签与color属性被添加到HTML3.2后，它就逐步成为开发人员们的一

场噩梦。开发那些务必把字体信息加入每个单独页面的网站，其过程成为了一种漫长而昂贵

的折磨。

通过HTML4.01,所有的格式化信息能够被移出HTML文档，转而放入一个独立的样式

表中。

HTML4.01之因此重要，另外一个原因是由于XHTML1.0,这个最新的HTML标准是作为

一种XML应用被重新表达的HTML4.01。在您的页面中使用HTML4.01能够确保在未来将HTML

轻松升级到XHTML,

请确保您使用了最新的HTML4.01标准。

层叠样式表(CascadingStyleSheets-CSS)

样式可定义HTML元素如何被显示，类似font标签在HTML3.2中所起到的作用。样式

通常被储存在HTML文档之外的文件中o外部样式表使您有能力仅仅通过编辑一个简单的CSS

文档来改变网站内所有页面的外观与布局。假如您曾经尝试过进行某些改变，比如同时改变

站内所有网页标题的字体或者颜色，您就会明白CSS如何能够达到事半功倍的效果。

XHTML-HTML的未来

XHTML指可扩展超文本标记语言(ExtensibleHyperTextMarkupLanguage)..

XHTML1.0是源自W3C的最新的HTML标准。它于2000年1月26日成为正式的推荐标

准(Recommendation)。W3CRecommendation意味着其规范的稳固性，同时其规范目前已成

为一种Web标准。

XIITML是一种使用XML进行重构的HTML4.01,并能够通过遵循一些简单的指导方针立

即在现有的浏览器中投入使用。

XML-用于描述数据的工具

扩展标记语言(XML)并不是HTML的替代品。在未来的web开发中，XML会被用来描述与

存储数据，而HTML会被用来显示数据。

我们对XML最合适的描述是，一个跨平台的、独立与软硬件的，信息存储与传输工具。

我们相信XML的重要性不亚于HTML关于web的基础性地位，同时XML将会成为最重要

的数据处理与传输工具。

XSLT-用户转换数据的工具

XSLT(可扩展的样式表语言转换，ExtensibleStylesheetLanguageTransformations),

是用于转换XML的语言。

未来的网站将不得不向不一致的浏览器并向其他web服务器以不一致的格式传递数据。

而XSLT则是一种将XML数据转换为不一致格式的新的W3C标准。

XSLT能够把XML文件转换为浏览器可识别的格式，比如HTML,或者者WML-一种用于

许多手持设备的标记语言。

XSLT还能够添加元素，并对元素进行删除、重新排列及排序，测试并确定显示什么元

系»等等。

客户端脚本

客户端脚本脚本是一种有关因特网浏览器行为的编程。您应该学习JavaScript,这样

才能有能力传递更多的动态网站内容：

JavaScript是为HTML设计者提供的一种的编程工具

HTML的创作者通常都不是程序员，但是JavaScript是一种语法非常简单的脚本语言！

几乎任何人都能够把某些JavaScript的代码片断放入他们的HTML页面中。

JavaScript能够在HTML页面中放入动态的文本

像这样的一条JavaScript语言能够在HTML页面中写入可变的文本：

document,write("hl"+name+"/hl")

JavaScript能够对事件进行反应

能够把JavaScript设置为在某事件执行时发生，比如当页面加载完毕或者当用户点击

某个HTML元素时。

JavaScript可读取并修改HTML元素

JavaScript能够读取并修改HTML元素的内容

JavaScript可被用来验证数据

可使用JavaScript在表单被提交到服务器前对表单数据进行验证，这样可确保服务器

进行正确的数据处理。

服务器端脚本

服务器端脚本与因特网服务器编程有关。您应该学习服务器端脚本，这样才能有能力传

递更多的动态网站内容。通过服务器端的编程，你能够：

动态地编辑、修改或者添加网页内容

对用户从HTML提交的查询或者数据进行响应

访问数据或者数据库，并把结果返回浏览器

访问文件或者XML数据，并把结果返回浏览器

把XML转换为HTML,并把结果返回到浏览器

为不一致的用户定制页面，提高页面的可用性

对不一致的网页提供安全与访问操纵

为不一致类型的浏览器设计不一致的输出

最小化网络流量

使用SQL管理数据

结构化查询语言(SQL)是对诸如下列数据库进行访问的通用标准：SQLServer.Oracle、

Sybase与Access,

关于那些希望从数据库存储与提取数据的人们来说，有关SQL的知识是极具价值的。

任何web管理员都应当明白，SQL关于web上的数据库来说，是一种真正切合的引擎。

站在别人的肩上:项目管理的规则

美国著名软件工程专家勃姆(B.W.Boehm)在总结软件工程准则与信条的基础上，于1983

年提出软件工程的7条基本原则，也是软件项目管理应该遵循原则。勃姆认为，这7条原则

是确保软件产品质量与开发效率的原理的最小集合，相互独立但结合得相当完备。

1.用分阶段的生命周期计划严格管理。统计说明，不成功的软件项目中约有一半左右源

自计划不周。本原则意味着，应该把软件生命周期划分成若干阶段，相应地制定出切实可行

的计划，然后严格按照计划对软件的开发与保护工作进行管理。勃姆认为，在软件的整个生

命周期中应该制定并严格执行6类计划，即项目概要计划、里程碑计划、项目操纵计划、产

品操纵计划、验证计划、运行保护计划。不一致层次的管理人员务必严格按照计划各尽其职

地管理软件开发与保护工作，绝不能受顾客或者上级人员的影响而擅自背离预定计划。

2.坚持进行阶段评审。软件的质量保证工作不能等到编码阶段结束之后再加以实施，其

理由为：第一，大部分错误始于编码之前；第二，错误的发现与修改时间越晚，需要付出的

代价就越高。因此，本原则意味着，在软件开发的每个阶段应该进行严格的评审，以便尽早

发现软件开发过程中的错误。

3.实行严格的产品操纵。软件开发过程中不应随意改变需求，由于改变一项需求往往需

要付出较高的代价；但是软件开发过程中改变需求又在所难免，基于外部环境的变化而出现

改变用户需求的情况是一种客观需要，而且迅速应对客户的需求变更是顾客本位的内涵之

一。在这种情况下，只能依靠科学的产品操纵技术来顺应这种要求。当改变需求时，为了保

持软件各个配置成分的一致性，务必实行严格的产品操纵，其中要紧是实行基准配置管理。

所谓基准配置又称基线配置，它们是通过阶段评审后的软件配置成分(各个阶段产生的文档

或者程序代码)。基准配置管理也称之变更操纵：一切有关修改软件的建议，特别是涉及到

对基准配置的修改建议，都务必按照严格的规程进行评审，获得批准以后才能实施修改。避

免开发人员对软件随意进行修改。

4.使用现代程序设计技术。从提出软件工程的概念开始，人们一直把要紧精力用于研究

各类新的程序设计技术。从60年代末提出的结构程序设计技术到最近的面向对象技术，人

们不断制造先进的程序设计技术。实践说明，使用先进的技术既可提高软件开发的效率，又

可提高软件保护的效率。

5.结果应能清晰地审查。与其他有形产品不一致，软件是看不见摸不着的逻辑产品。软

件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比通常

产品的开发过程更难以评价与管理。为了提高软件开发过程的可见性，更好地进行管理，应

该根据软件开发项目的总目标及完成期限，规定开发组织的责任与产品标准，从而使得所得

到的结果能够清晰地审查。

6.开发小组的人员应该少而精。该原则意味着,软件开发项目的构成人员的素养应该好,

而人数则不宜过多。开发小组人员的素养与数量是影响软件产品质量与开发效率的重要因

素。素养高的人员的开发效率比素养低的人员的开发效率可能高几倍至几十倍，而且素养高

的人员所开发的软件中的错误明显少于素养低的人员所开发的软件。此外，随着开发小组人

员数目的增加，由于交流问题而造成的沟通成本也急剧增加。因此，构建与维持少而精的开

发团队甚至标杆团队是软件工程的一条基本原理。

7.承认不断改进软件工程实践的必要性。遵循上述6条基本原则，就能够按照当代软件

工程基本原理实现软件的工程化生产，但是，仅遵循上述6条原则并不能保证软件开发与保

护的过程能赶上时代前进的步伐，能跟上技术的不断进步。因此，勃姆提出应把承认不断改

进软件工程实践的必要性作为软件工程的第七条基本原则。按照这条原理，不仅要积极主动

地采纳新的软件技术，而且要注意不断总结经验。

威格的成功软件项目管理秘诀

过程影响(ProcessImpact)公司的首席咨询顾问卡尔。威格(KarlE.Wiegers)在其

《成功项目管理秘诀》(SecretsofSuccessfulProjectManagement)一文中总结了成功项

目管理的20条秘诀：

构筑基础

1.定义项目成功标准；

2.识别项目的驱动、约束与自由度；

3.定义产品公布标准；

4.协商承诺。

规划工作

5.制作计划书；

6.将任务分解成较小的里程碑；

7.为共通的大任务开发计划工作表；

8.计划在质量操纵活动后实施修改；

9.为过程改进安排时间；

10.管理项目的风险。

估算项目

11.根据工作量而不是日历估算；

12.不要为项目人员安排超过其80%的时间；

13.将培训时间纳入计划中；

14.记录估算与如何达致估算；

15.利用估算工具；

16.尊重学习曲线；

17.考虑意外事件的缓冲。

追踪进展

18.记录实绩与估算；

19.只有当任务百分之百完成时，才认为该任务结束；

20.公开而诚实地跟踪项目状态。

麦克康奈尔的成功软件项目十大要决

史蒂夫。麦克康奈尔(SteveMcConnell)在《成功软件项目的十大要决》(10Keysto

SuccessfulSoftwareProjects)中阐述了成功软件项目的十大要决：

1.清晰的愿景；

2.稳固的、完整的、书面的需求；

3.全面的用户界面原型；

4.有效的项目管理；

5.精确的估算；

6.两阶段预算；

7.注重质量；

8.听取技术专家的意见；

9.积极的风险管理；

10.记住：软件来源于人。

在组织间跨项目组加强推广学习优秀经验

以往对项目总结的认识不够，很多时候也就是写写PPT或者者开个会，很多经验没有能

被辨识出来成为案例，也就不能给大家分享。特别是很多教训，人性的问题，没有被说出来,

毕竟说出自己的不是不是每个人都能做到。导致教训库不能不断丰富，因此前人吃亏，后人

无法继承到有效的经验。

前段时间进行2008年度总结的时候，业主提出接触我们这么多项目，我们每个项目经

理的风格都不一样，项目的成功与否太依靠于项目经理个人的能力。我想我们不是要让每个

人都没有自己的风格，项目经理当然有能力水平的高低，当然有不一致的价值表达。业主事

实上就是在说我们的项目实践务必积存。

在之前的博文《业主的改进意识让我惊讶，我们应该更加积极地看待与推进CMMi的改

进！》中讲到，一个业主的项目经理对口我们几个项目经理，A项目经理做得好的，业主方

项目经理确信会将A做得好的地方来要求公司的另一个项目经理Bo假如我们自己不传授这

种经验，那才是傻子。

使用马上推行的CMMi的规程，重新Review一下2008年的各个项目，从中去分析各个

项目组的强处与弱项，从规程中扫漏洞，审视项目组的那些活动执行的力度与弱项之间的关

系，关于来年指导项目建设是非常有帮助的。今天在内审会议总结上，同事WN说得好，我

们现在的项目经理花了很多时间在做事，事实上缺少了时间思考如何去做事！管理不仅是规

范、监督，还有教练一职。

故事一则:

在组织间跨项目组加强推广学习优秀经验，除了会议交流、专题培训，还能够去现场实

地体验加强感性认识（呵呵，共产党宣传的那一套都要学习用上）。上次说到项目0与项目

C整合上线，整个上线持续了近三天时间，有很多地方值得总结.今天刚好有项目T正在组

织部署上线，项目T的技术经理CC做为培训讲师以往培训过两次有关部署的工作，项目C

的经理C当时也听过CC的课程，在没有与CC打招呼的前提，带上项目0与项目C的两位同

事L与C到现场去抽查观摩，能够更加有感触其他同事的优秀实践。

到了现场，才明白项目T晚上6点才开始部署，因此安排两个项目的项目经理/技术经

理进行现场的交流。在简单介绍了此行的目的后，CC首先发言，询问C上次部署的过程中

计划与实际工作最大的出入在那些地方？通过近一个小时的访谈，同事C与I.认识他们有很

多改进的问题，这里讲最重点一点：项目组C与项目组0在系统的正式部署前，缺少完整的

演练。尽管有部分的演练，但是没有通过演练将可能的问题辨识出来。也由于如此，吃亏最

多的迁移方案中的校验问题，没有能够提早暴露。

涉及到新旧两个系统的迁移，数据需要从系统0迁移到系统C,使用的方案是C直接访

问0的数据方式，表面看这种方式最简单最直接，但是编写迁移与校验程序的同事都务必务

必清晰熟悉C系统与系统0的业务逻辑，而实际由于逻辑覆盖不全面，导致校验的工作不完

整，只使用抽样的方式即花了大量的人力（校验一个抽样数据，需要花20分钟人力），也导

致有大量的迁移漏洞需要补救。

同事CC告诉C,应该使用接口交互表的方式，约定好规格，系统0的同事熟悉0的业

务逻辑，负责将数据迁移到接口表，再由他们进行业务逻辑的检查，由于他们熟悉旧系统的

逻辑啊！检查完毕后，才由C负责从接口交互表中提取数据，C熟悉新系统的新业务逻辑，

对接口交互表进行逻辑检查后，提取数据转换到新的系统。使用两阶段的迁移，由熟悉旧系

统的同事做应该做的事，让新系统的同事做他该做的事、熟练的事，看似复杂反而简单！

我在旁边插了话，事实上假如旧系统是其他公司承建的，可能同事们就能想到两阶段迁

移的接口交互表方式，但是我们两个系统由因此同一个部门承建，我们把部门边界与系统边

界给混淆了，反而欲速而不达。

在网页中用JS函数操纵Flash动画播放

一、介绍与Flash动画操纵有关的javascript函数:

函数名使用作用

play()wgzc.play()播放Flash动画

stopplayOwgzc.stopplay()停止播放Flash动画

rewind()wgzc.rewind()停止播放Flash动画并返回第一帧

totalframes()wgzc.totalframes()返回Flash动画总帧数

gotoframe(intnum)wgzc.gotoframe(intnum)转到指定帧

二、程序代码:

以WBS为主线的集成项目管理

任何流程或者业务在我们学习的过程中始终都有一个主线，比如说知识管理的基础或者

主线是知识库与知识地图，ERP的数据基础是ITEM与BOM,主线是需求订单-＞MRP-＞生产计

划与采购计划。关于产品数据管理PDM的主线是产品结构，关于CRM客户关系管理的主线是

营销-＞市场策划-＞销售计划-＞预测-＞项目合同。而关于项目管理其基础是WBS工作结构分

解，其主线是项目结构-＞项目-＞WBS-＞工作包-〉活动-＞任务。

这条主线涉及到PMBOK里面的范围管理与进度管理两方面的内容。关于范围管理最终的

输出就是范围说明书与WBS,而关于进度管理则输入是WBS,需要进行活动定义分解与排序,

最终得到的进度表。在项目的执行过程中我们是按照具体的活动任务在执行，在执行的过程

中会产生使用资源，消耗成本，产生文档与各类输出，进行设计开发，集成，评审与质量操

纵。

我们活动分解的单位是到了具体的任务，但是我们产品的最终集成，我们的成本核算与

挣值管理是不能到活动任务的。因此WBS在整个项目管理中就起到了重要作用，其作用不仅

仅在前期确定项目范围与制定项目的进度计划，更多的是后期的挣值管理与更高层次的项目

监控。假如没有完善的WBS分解，我们就很难做到这一步，我们的整个项目管理执行过程中

的产出就是凌乱的，没有一个主线串起来。感兴趣的能够再去翻看下PMBOK各个过程域中各

个过程组的IPPO,能够发现很多过程的输入都有WBS,足以见WBS在整个项目管理中的基础

与核心作用。

在这个图中还强调了下在CMMI三级中我们强调的生命周期模型定义&过程裁剪，在组

织级我们能够根据项目的不一致特点将项目进行分类制定不一致的项目生命周期模板，这样

在有实际的项目来的时候，只需要根据项目的特点对模板内容进行自定义与裁剪，输入具体

的需求项，即能够自动产生相应的WBS。（该点后续单独在发文阐述），这样自动生成的WBS

不仅仅实现了后续的主线跟踪，还实现了我们在CMMI二级中需要的需求追踪。

一流软件领导的10个特征

特征一：敢于设想

他们是在不确定性上进展起来的技术空想家。

软件领导者们务必生活于剃刀边缘。

1987年，在驱车沿法兰克福到沃尔多夫从一家IBM代理商那儿回家时，SAP的创立者普

拉特纳、霍普与特奇拉决定为他们最畅销SAPR/2企业解决方案软件制造一个新版本。新

的R/3将利用一个可塑性强得多的设计。

但是新产品应该运行于什么系统之上呢？当时，许多大学刚刚开始使用Unix,这是一

个新的操作系统，同意在不一致厂家的计算机之间构建网络，从而有可能制造一个新的系统

结构：客户/服务器模型。尽管有这些优点，它却相当不稳固，没有达到企业解决方案应用

所需的表现水平。因此，尽管它提供了许多超过大型计算机的专业优势，许多从业者认为它

永远不可能取代那时的大型机。

但普拉特纳不一致意。他鼓吹为新的R/3系统使用Unix,从而指出了一种当时看上去

高度投机与冒险的方向。

他立刻在自己公司内陷入阻力之中。但是他相信他的远见一一因此运用他作为一个大股

东的影响力，得到了董事会的同意。4年之后，1991年，SAP向全世界推出了R/3,安装在

一个小的HPUnix工作站。人们被震惊了。“它几乎是可笑的，”普拉特纳回忆道，“他们在

说：'这个小机器，带着一些存储器一一就是伟大的SAP?'"但是，这个小机器为SAP在

ERP市场的主导地位奠定了基础。基于Unix的R/3向大群的WindowsPC用户开放了SAP,

用一个“漂亮的前端'吹走了“绿色显示屏之争”，正如理查森一一波士顿的高等制造业研

究公司的一位顾问所描述的。此外，基于Unix的R/3的表现要比基于大型机的R/2更好。

R/3在全球EPR市场成了一个王牌产品。从1992年到1998年，单在美国，SAP的收入

就从4500万美元上升到20亿美元。

是普拉特纳深入技术内部的洞察与他对未来进展的预见，使这一设想成为可能，也说明

了软件领导者务必生活于剃刀边缘。

软件业已经产生了许多其他的幻想家，他们在全球范围内改变了这个行业，从库比（他

在很久往常就相信软件能够与硬件分开销售）与基恩（他于1965年在一家汽车轮胎铺里创

立了他的软件服务公司），一直到比尔•盖茨、埃里森与其他人。

特征二：敢于冒险

他们承受巨大的风险一一并希望有高额的回报。

在梦想成确实路上，软件领导者们务必能够面对无数次风险。麦肯锡的调查显示，成功

软件产品公司的领导者做出重要战略决定所花的时间平均要少25%,其原因并不要紧是他

们有更好的信息或者市场研究，更多的来自他们的冒险精神。

以莱曼特为例，他从学校退学，并在1989年建立了以得克萨斯州奥斯汀为所在地的

Trilogy软件公司，一家专门从事前台办公室销售与营销软件的公司。对莱曼特来说，决定

冒险是很自然的。他告诉我们：“我想我不得不退学以抓住市场机遇。”

没有一个风险资本家想资助他，因此莱曼特靠赊欠度日。只是创立Trilogy两年后，莱

曼特从他冒险的愿望中得到了回报。他终于做成了与惠普的一笔350万美元的合同。其他有

名的客户，像波音与朗讯也接踵而来。到1996年，莱曼特进入了福布斯400名富豪榜并成

了其中最年轻的自力更生者，拥有估计5亿美元的净资产。在1998年，他有850名员工，

销售额超过1亿美元。

莱曼特及其公司并非孤立的个案。安德烈森在他合作创立网景并开发因特网浏览器软件

时只有22岁。比尔•盖茨、巴尔默或者SAP的普拉特纳同样都是冒险家，而且他们全都通

过冒险而成了亿万富翁。

特征三：多样选择

他们在多个选择上押注，来为所有不确定性做准备.

微软并不单单押注于它的WindowsPC操作系统的成功，而是与IBM一起共同开发一个

与之竞争的操作系统OS/2。SAP是另一个例子。它没有去“塑造”这个行业，而是宁愿习

惯领先者的标准，同时在几个标准上花钱。作为SAP的总裁与CEO,卡格曼评述说，SAP

能够从第二排看到表演不断进展。

专业软件公司的领导人同样通过选择权处理不确定性。西姆斯是剑桥技术伙伴公司的

CEO,该公司是波士顿一家6亿美元的软件服务公司。他确保剑桥连续投资几个新兴公司，

它们可能会开发出一个新的技术标准。“我们与新技术一直保持接触，”西姆斯说，“我们希

望资助的这些公司之一有一天会成功。”

但是，在通往成功的路上，软件领导者们务必同意不时的失败。事实上，失败并非是例

外，而是惯例一一即使在成功的软件领导者之中。

特征四：敢于尝试

他们宁愿“迅速失败”而不是避免错误。

“宁可做6个正确决定与4个错的，而不要等得太久，”SAP的霍普评述道。“Platinum

技术公司的CTO波佩克同意这个说法。“快速移动是很重要的，”他说，“这常常会导致错误，

但错误是能够改正的。”

看看陈丕宏在他创立了BroadVision之后是如何反应的。尽管这名企业家在电子商务解

决方案上押对了赌注，他却在选择交互式电视（它看起来像是“未来的潮流”）作为其产品

的平台上犯了错误。事实上，当陈丕宏第一次看见因特网的时候，他的电视产品几乎已经完

成了。

特征五：强调速度

陈丕宏几乎一夜之间就将BroadVision转变成了一家因特网公司。

“对我来说非常清晰，我们错了，而且假如我们不迅速改弦易辙的话，我们就会失去一

切。”陈丕宏回忆道。陈丕宏没有做长时间的讨论，而是几乎一夜之间就将公司转变成了一

家因特网公司一一不顾他的经理们的反对。“我几乎不得不解雇整个高层管理队伍，由于他

们对变革没有信心。”他说。他的敏捷行动获得了结果，到1998年底，BroadVision的市值

超过了7亿美元。

特征六：目标远大

软件领导者们同样设定了非常高的期望。

当菲利•波夫斯基于1987年创立Platinum时，他决定在10年之内将其建成一个10

亿美元收入的公司。菲利•波夫斯基觉得他不得不动作迅速，由于他看到软件业正在迅速转

向成熟。他同样明白在软件产品行业，只有领先者才能真正成功。”对我来说，迅速壮大是

件生死攸关的事。”他解释道。

菲利•波夫斯基并没有完全实现他的办法，''这花了我们11年，而不是10年。”他有些

不好意思的承认。但是他的窘迫是能够忍耐的，比尔•盖茨花了15年才使微软达到10亿美

元，英特尔、Oracle与SAP达到这个目标全都花了10年以上。只有思科的莫格里奇与钱伯

斯击败了菲利•波夫斯基，他们在10年里做到了这点。

在麦肯锡的全球性调查中，发现高期望水平与公司的成功之间有非常强的有关性。在成

功企业之中，93%都有一个清晰、明确的远见，而在不成功企业中只有25%有这样的雄心壮

志。

特征七：敢于变革

他们是高度动态的组织的建立者。

1995年12月7日，比尔•盖茨在微软的会议上宣布了一个突然的变革。他回顾历史，

引用了日本海军上将山本五十六在日本进攻美国时所做的评论：“我担心我们惊醒了一个沉

睡的巨人。”在这儿，这个巨人就是盖茨的公司，而进攻者是网景与因特网时代。

盖茨清晰地看到进攻者们正在来临。在其存在的20个月里，网景已经将其Navigator

万维网浏览器推到了全世界的领先位置。该公司也进行了一次最为成功的公开上市。同一时

间在微软，“我们确实有些错过了因特网航船，”微软德国公司总经理罗伊这样承认。

特征八：反应迅速

他们都是看准趋势迅速行动的人。

“这就是要改变的站在几百名程序分析员与记者面前，盖茨宣布他将重新调整每个

项目与每个产品以迎接因特网的挑战。确实，整个微软的管理人员仓促地停止了几个数百万

美元的项目一一并在数小时内启动了因特网项目。这些经理之一的路德维希走进一间满是程

序员的屋子，命令道：“清除你们机器里的源代码，今天起就开始用Java工作。”为因特网

浏览器工作的程序员的数目迅速从8人增长到800人。

9个月后，在1996年8月13日，微软的IE3.0,新的具有竞争力的浏览器公布了。它

在每个方面都赶上网景的Navigator,在第一个星期，超过100万用户下载了这个免费软件。

尽管两个公司之间的战斗1998年仍在进行，有一点已经十分清晰：微软已经在6个月略多

一点的时间内成功地改变了一个庞大的有2万名员工的组织。要做到这点，需要从高层领导

者那儿来的对巨大变革的极强的信心与清晰、可交流的信息。让整个组织对这种剧烈变动做

好准备是一项长期的任务。英特尔的格罗夫在谈到高技术公司中的管理时说：“你需要像一

个救火部门那样做计划：它不能估计下一场火出现在哪儿，因此它不得不塑造一支富有活力

与有效率的队伍，能像处理普通事务一样对突发事件做出反应。”

特征九：善于管理

他们建立十分平坦的、以团队为基础的组织。

SAP在1996年拥有2万名员工与50亿美元收入，它有一个3个层次的平坦的组织形态。

在公司位于德国沃尔多夫的总部，咖啡机旁的墙上挂着总裁霍普讲演中的一段话。他说「对

所有公司的新员工来说，在SAP这儿，我们是没有官僚主义并鼓励主动性的。”他还说：“这

要求每个人有的时候得为往往不在正常工作任务之中的情况负责。”

在专业软件服务中，构建以团队为基础的组织也是一个关键的领导任务。“在专业服务

中，获胜的是团队，”基恩解释说，“但正由于如此，领导者也就成了专业服务里的关键。在

产品行业，产品在整个公司范围内被聚合起来，而领导者们制造并代表它。在服务业，领导

者得与谐安排与构建一支通过授权的队伍。”

微软的首席营运官赫伯德，过去曾是消费品行业巨人宝洁的营销主管，在《财经时代》

的一次采访中说，软件业的团队结构与平坦的等级制度是他对这个行业印象最深的。“在宝

洁，大多数的交流是手写的。它只能上下一个层次，与这个行业相比，它是相对迟缓的。因

此你可能要花4个轮次的交流才能明臼自己实际上弄乱了什么情况。在微软，我们以直接接

触主题而自豪。”其他行业的管理者们也同意这一说法。''像Oracle与Sun这样的软件公司

都非常重视以团队为基础，我们喜欢仿效它们，"Texaco的石油勘探显示中心经理蔡特林说,

“中层管理人员有权做决定。他们能够自行其是。这种文化感染了我

特征十：制造文化

他们制造了一种文化，它吸引与留住人才。

当我们在芝加哥郊区访问Platinum公司时，我们问各个管理人员他们的公司给他们印

象最深的是什么。从公司数据中心经理韦伯、营销执行副总裁马修斯与开发人员德莫特那儿,

我们得到了同一个答案：菲利。他们说，CEO菲利•波夫斯基那与众不一致的风格产生了巨

大的影响。

甚至菲利•波夫斯基的办公室也与众不一致，有数百个印度玩偶排列在墙上，一架大电

视从天花板上吊下来，不停地播出因特网新闻服务。在另一个角落，供应的软饮料有6英尺

高。“初次来访的人总是感到惊讶。菲利确实是个十分特别的人，”一名经理助理说。在她向

我们展示菲利•波夫斯基的办公室时，她的脸上闪过一丝微笑。她并非惟一一个：几乎每一

个我们与之交谈的人在解释他们为什么进入这家公司与为什么喜欢在这儿工作时，都提到

Platinum的这位领导者与他制造的文化。

制造一种吸引人才的文化对软件领导者们是必不可少的，而且实际上，是他们最重要的

挑战之一。

需求管理的必要性及操纵需求渐变的方法

本文介绍了需求管理的必要性，并介绍了操纵需求渐变的一些方法。

软件需求是整个软件项目的最关健的一个输入，与传统的生产企业相比较，软件的需求

具有模糊性、不确定性、变化性与主观性的特点，他不像生产汽车、电脑等硬件的需求，是

有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性

表达在下列方面：

需求的描述问题

一个已经进入了编码后期阶段的项目，该项目已经换过2次项目经理了，这是第3次更

换项目经理，用户方的IT部经理找埋怨："我已经是第3次来给你们讲补货申请的处理规则

了！”。我只能表示抱歉，由于我无法找到原先的需求描述，这是一个变更的需求，前任的项

目经理讲他只是将当时与用户交流的需求记到2页草稿纸上，不幸的是，那2页珍贵的手稿

现在已经找不到了！更不幸的是，该IT部经理是在转述业务部门的需求，当软件开发完毕后，

业务部门讲"这不是我们最初给IT部反映的需求，我们说的不是这样的!”。缺少正式的完整

的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。曾经有多个项目

经理埋怨，在用户方进行的需求评审会完全是走形式，由于用户根本不去听他读那上百页的

需求文档。不一致层次的客户（用户）关心的问题是不一样的，想要每个客户都成为需求专家

是不现实的。

需求的完备程度问题

需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题，略微大一点

的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系

统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性

的划定一个，从而建立一个基线。

需求开发的工期问题

在需求上花费了大量的时间（而不是人*工时，由于需求阶段人多了也没有作用），客户、

软件公司是否能够忍耐?为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段

花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心

不已!他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的

需求折腾的筋疲力尽，他们也希望尽快结束此阶段。

需求的细致程度问题

需求到底描述到多细，才算能够结束了？仁者见仁，智者见智，并没有定论，假如时间

同意，要想细总能够细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制越

严格，对需求的共性提取要求越高，因此只要大家（客户、用户、需求分析人员、设计人员、

测试人员）认为描述清晰了，就能够进入设计阶段了。

需求的变化问题

在软件开发过程中假如只有一条真理的话，那一定是：需求的变化是永恒的，需求不可

能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也

有可能是好事，是商业机会，对市场敏感的人能够从需求的变化中发现市场机会。

需求变化的原因很多，如：

•一开始没有识别全，需要增加需求;

•业务发生了变化，需求务必变化;

,需求错误；

•需求不清晰；

需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一

旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你

的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的烦恼，怎么

办?管理它!使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照标准的

流程来操纵需求的变化。

难题随之而来，需求中的变化通常不是突发的革命性的变化，最常见的是”项目需求的

渐变”(ProjectScopeCreep)问题，这种渐变很可能是客户与开发方都没有意识到的，当达

到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。

操纵需求渐变需要注意下列几点：

(1)需求一定要与投入有显示的联系，否则假如需求变更的成本由开发方来承担，则项

目需求的变更就成为必定了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变

更。但是，同意需求变更目前却是软件开发商不得不咽下的苦果。因此，在项目的开始不管

是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。

(2)需求的变更要通过出资者的认可，需求的变更引起投入的变化，因此要通过出资者

的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。一个项目，为

了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提

出了大量小”的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶

段时，却有大量的这些变更需要改回去，问题就是出在我们的项目构成员视该用户代表的需

求为圣旨，却忽略了需求是否通过了客户方真正有决策权的人员的认可。

(3)小的需求变更也要通过正规的需求管理流程，否则会积少成多。在实践中，人们往

往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。

正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。

(4)精确的需求与范围定义并不可能阻止需求的变更。并非对需求定义的越细，越能避

免需求的渐变，这是2个层面的问题。太细的需求定义对需求渐变没有任何效果。由于需求

的变化是永恒的，并非由于需求写细了，它就不可能变化了。

注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需

求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出

更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更''精巧"，

因此作为需求管理者、项目经理需要使用各类沟通技巧来使项目的各方各得其所。

软件需求的复用问题

一位领域专家，他在有20多年的领域工程经验，积存了大量的领域需求，但是在其每

进行一次产品开发时，他总是感到他所懂得的需求无法为与他配合的分析人员、设计人员所

同意。一个观点就是：没有对需求进行有效的管理，已经形成的需求文档没有很好的复用。

因此需求管理一个很重要的目标应是提高软件需求的复用率。

基于上述的问题，务必对需求进行管理，使需求能够真正成为软件工程与管理的基线,

使软件计划、活动与工作产品同软件需求保持一致，使需求能够复用。

虚拟项目管理:虚拟项目团队的组织形式

一、组织形式的分类

随着通信技术、计算机网络技术与互联网技术的飞速进展，虚拟项目无处不在。根据笔

者（编者注：CSAI顾问团首席顾问张友生博士）的研究与实践，在实际的运行过程中，存

在着多种形式的虚拟项目组织，各个组织能够根据自身的条件与市场机遇，采取不一致的虚

拟项目组织形式。总的来说，根据主体的不一致，虚拟项目组织能够分为两大类。

第一类是单个组织的虚拟化，即某一组织通过计算机网络与通信技术，将分散在不一致

地点的研发资源联结起来而形成的虚拟性项目组织。

根据组织成员的集中度高低，这种虚拟项目组织形式还能够进一步分为三种，分别是分

散并行模式、虚拟核心模式与集中团队模式。其中分散并行模式的集中度最低，各个团队成

员或者模块独立开展研发工作；虚拟核心模式则是采取核心团队集中于一地、团队成员仍相

对独立的方法，其集中度相对较高；集中团队模式强调在维持团队的虚拟灵活特性的同时，

针对特殊的研发任务而高度集中，密切配合。

有关这方面的全面情况，笔者（编者注：CSAI顾问团首席顾问张友生博士）将在《虚

拟项目管理：单主体虚拟项目团队》中进行讨论。

第二类是多个组织以计算机网络与通信技术为联结手段、以市场目标与关系契约为基础

而形成的虚拟项目组织。这种多主体模式不仅以信息技术来超越地理空间与组织结构的限

制，而且通过诸如合同契约、协议、政策等软约束来实现研发资源的共享与集成。

假如按照团队成员之间的竞争程度与关联程度两个维度作为划分标准，那么能够将多主

体虚拟项目组织分为四种基本类型，分别是价值关联非竞争性组织、技术关联非竞争性组织、

技术关联竞争性组织、价值关联竞争性组织。其中价值关联非竞争性组织大多是不一致行业

内组织间的合作形式，团队成员之间没有直接的竞争关系，但往往是处于价值链的上下游企

业（比如，希赛IT教育研发中心与电子工业出版社联合构成的软考图书研发项目组）；技术

关联非竞争性组织是指同行业内非竞争性组织间的合作形式，团队成员间的研究开发合作很

密切，但从事的研发领域不相重合，技术互补性强，没有直接的竞争领域；技术关联竞争性

组织的成员间不仅在技术上高度有关，同处于一个竞争行业，而且在最终产品市场上成为直

接的竞争对手（比如，希赛教育软考学院与SUN公司的Java合作项目）；价值关联竞争性组

织的团队成员往往属于不一致行业，但在研究开发同一类技术或者产品。

有关这方面的全面情况，笔者（编者注：CSAI顾问团首席顾问张友生博士）将在《虚

拟项目管理：多主体虚拟项目团队》中进行讨论。

二、需要考虑的因素

尽管虚拟项目组织是项目组织的一个要紧进展趋势，但目前还没有一个统一的组织模式

与决策模式可供选择与利用，不一致的虚拟项目组织与企业面对不一致的场景，会作出个性

化的、符合实际需要的选择。笔者（编者注：CSAI顾问团首席顾问张友生博士）认为，在

组建虚拟项目组织的过程中，至少要考虑下列5个因素：

（1）虚拟项目组织的系统特征，即项目中的各个团队成员及子项目之间是高度耦合的

还是相对自主独立的。假如高度耦合，则适合使用集中度高的组织方法；假如相对独立，则

适合使用比较松散的组织方法。

（2）各个团队成员的资源状况及其关联程度，即各团队成员研发资源的性质与数量，

相互之间是互补性的还是重复性的；不一致成员是处于同一个行业，还是不一致的行业；处

于同一个行业的成员，其产品是否会形成竞争关系。

（3）整个虚拟项目组织内部的沟通机制与协调机制。虚拟项目参与方众多，在文化背

景、语言、时差等方面都会存在差异，那么，管理者需要根据团队成员的构成情况，选择合

适的、有用的沟通机制与协调机制。

（4）知识系统的主导类型，即研发活动所涉及的知识要紧是显性知识还是隐性知识。

假如是隐性知识，则需要考虑如何把隐性知识转化为显示知识，以便在团队成员之间共享。

（5）项目的创新程度，即是渐进式的还是突变式的。假如是渐进式的，则适合采取低

集中度的组织形式；假如是突变式的，则适合使用高集中度的组织形式。

具体来说，关于单主体虚拟项目组织来说，假如项目是渐进式创新，各个子项目相对独

立，要紧知识是显性的，具有重复资源，那么能够采取低集中度的组织形式，相反则应采取

高集中度的组织方式。关于多主体模式来说，情况则是完全不一致的，它要紧是针对重大的、

复杂的、高投入的研发任务，其关注点不在于集中度，而在于资源的互补互利，与成员企业

间的竞争程度，它的组织形式更趋于无形化与网络化。

虚拟项目管理：单主体虚拟项目团队

所谓单主体虚拟项目团队，是指某一组织通过计算机网络与通信技术，将分散在不一致

地点的研发资源联结起来而形成的虚拟性项目组织。根据团队成员的集中度高低，单主体虚

拟项目团队能够分为三种类型，分别是分散并行模式、虚拟核心模式与集中团队模式。其中

分散并行模式的集中度最低，各团队成员独立开展工作；虚拟核心模式则是采取核心团队集

中于一个地方、团队成员仍相对独立的方法，其集中度相对较高；集中团队模式强调在维持

团队的虚拟、灵活特性的同时，针对特殊的开发任务而高度集中，密切配合。

一、分散并行模式

在分散并行模式中，各团队成员分散在各个地区（或者国家），相互之间的直接交流较

少，相对独立地进行各自的开发活动。但是，各团队成员有着明确的分工与功能界定，开发

活动有既定的标准与规范来支持，各个模块之间的界面也存在一致明确的标准。

在分散并行模式中，项目管理者操纵各团队成员的要紧手段是通过项目计划与预算。比

如，CSAI顾问团的项目研发就能够采取分散并行组织模式。CSAI顾问团秘书处设在北京，

在长沙、上海、广州、深圳、大连、杭州等地设有分秘书处，各地分秘书处相互独立，它们

的负责人直接向CSAI顾问团秘书长汇报工作，如图1所示。

图1分散并行模式

分散并行模式的要紧缺点在于，可能会使团队成员之间缺乏充分的交流与懂得，不一致

团队成员的工作也可能缺乏协调，从而在特殊的情况下会影响项目整体目标的实现。

二、虚拟核心模式

所谓核心团队，是指由各个团队成员的主管经理构成的，是整个虚拟项目的领导小组。

核心团队具有下列功能：

(1)核心团队是虚拟项目组织的中心节点与领导小组，如图2所示。核心团队不仅将

分散的项目团队成员联结起来，而且保证项目团队与组织决策层的信息沟通。

(2)核心

(3)核心团队负责解决涉及多个项目团队成员的重大问题。

(4)核心团队具有较强的创新优势，通过不一致团队成员的交流与合作，更容易产生

全新的理念。

要注意的是，核心团队本身也是一个虚拟团队，其成员来自于分散的各个团队成员，因

此具有很大的灵活性与柔性特征。另外，核心团队的组织边界也是相对变化的，其中的成员

具有一定的流淌性，其规模则根据项目的情况而扩大或者缩小。

三、集中团队模式

分散并行模式与虚拟核心团队模式的虚拟项目团队组织形式具有较低的集中度，其开发

效率、时间周期与协调程度都有一定的局限性。当项目规模比较大、复杂性比较高、时间要

求比较紧时，这两种组织形式往往无法应对。因此，务必采取更为高效的集中团队模式。

与前两种组织形式相比，集中团队模式首先强调的是团队成员务必集中在一个地方，并

进行集中式的一体化开发。其次，集中化团队模式不是单一固定的开发组织，没有直线式的

组织结构，其团队成员是来自于组织的各个部门的技术专家与管理专家。

集中化团队具有一些特殊的优势。团队成员集中在一起，有利于知识的沟通与交流，特

别是有利于隐性知识的共享与扩散。团队成员之间的频繁交流与沟通，能够制造出共同的团

队文化，增强项目团队的凝聚力与团队精神。同时，高水平专家的高度集聚能够大大提高开

发效率，缩短开发周期。

比如，希赛教育的软考视频课程研发项目就是使用集中团队的研发模式。实际上，希赛

教育的研发模式是高度分散的，其专家要紧来自CSAI顾问团，而CSAI顾问团成员遍布在全

国各地的各个行业。在2006年上半年，为了迅速占领软考培训市场，希赛教育成立了由来

自全国各地的10多名专家构成的视频课程研发项目团队，该项目团队的所有成员都集中在

希赛教育总部（长沙）的办公楼里，其空间布局是开放式