信息系统项目策划管理师高级学习资料大全

如何推断您的企业是否需要SOA治理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促进你的业务时，你需要SOA促进你的治理环境去超越传统系统治理。这是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.01HTML是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文档之外的文件中。外部样式表使您有能力仅仅通过编辑一个简单的CSS文档来改变网站内所有页面的外观和布局。假如您曾经尝试过进行某些改变，比如同时改变站内所有网页标题的字体或颜色，您就会明白CSS如何能够达到事半功倍的效果。XHTML-HTML的以后XHTML指可扩展超文本标记语言(ExtensibleHyperTextMarkupLanguage)。XHTML1.0是源自W3C的最新的HTML标准。它于2000年1月26日成为正式的推举标准(Recommendation)。W3CRecommendation意味着其规范的稳定性，同时其规范目前已成为一种Web标准。XHTML是一种使用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("h1"+name+"/h1")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）在《成功软件项目的十大要决》（10KeystoSuccessfulSoftwareProjects）中阐述了成功软件项目的十大要决：

1.清晰的愿景；

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

3.详细的用户界面原型；

4.有效的项目治理；

5.精确的估算；

6.两时期预算；

7.注重质量；

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

9.积极的风险治理；

10.记住：软件来源于人。在组织间跨项目组加强推广学习优秀经验以往对项目总结的认识不够，专门多时候也确实是写写PPT或者开个会，专门多经验没有能被辨识出来成为案例，也就不能给大伙儿分享。特不是专门多教训，人性的问题，没有被讲出来，怎么讲讲出自己的不是不是每个人都能做到。导致教训库不能不断丰富，因此前人吃亏，后人无法继承到有效的经验。

前段时刻进行2008年度总结的时候，业主提出接触我们这么多项目，我们每个项目经理的风格都不一样，项目的成功与否太依靠于项目经理个人的能力。我想我们不是要让每个人都没有自己的风格，项目经理因此有能力水平的高低，因此有不同的价值体现。业主事实上确实是在讲我们的项目实践必须积存。

在之前的博文《业主的改进意识让我惊奇，我们应该更加积极地看待和推进CMMi的改进！》中讲到，一个业主的项目经理对口我们几个项目经理，A项目经理做得好的，业主方项目经理确信会将A做得好的地点来要求公司的另一个项目经理B。假如我们自己不传授这种经验，那才是傻子。

使用立即推行的CMMi的规程，重新Review一下2008年的各个项目，从中去分析各个项目组的强处以及弱项，从规程中扫漏洞，审视项目组的那些活动执行的力度和弱项之间的关系，关于来年指导项目建设是特不有关心的。今天在内审会议总结上，同事WN讲得好，我们现在的项目经理花了专门多时刻在做事，事实上缺少了时刻考虑如何去做事！治理不仅是规范、监督，还有教练一职。

故事一则：

在组织间跨项目组加强推广学习优秀经验，除了会议交流、专题培训，还能够去现场实地体验加强感性认识（呵呵，共产党宣传的那一套都要学习用上）。上次讲到项目O和项目C整合上线，整个上线持续了近三天时刻，有专门多地点值得总结。今天刚好有项目T正在组织部署上线，项目T的技术经理CC做为培训讲师以往培训过两次有关部署的工作，项目C的经理C当时也听过CC的课程，在没有和CC打招呼的前提，带上项目O和项目C的两位同事L和C到现场去抽查观摩，能够更加有感触其他同事的优秀实践。

到了现场，才明白项目T晚上6点才开始部署，因此安排两个项目的项目经理/技术经理进行现场的交流。在简单介绍了此行的目的后，CC首先发言，询问C上次部署的过程中打算和实际工作最大的出入在那些地点？通过近一个小时的访谈，同事C和L认识他们有许多改进的问题，那个地点讲最重点一点：项目组C和项目组O在系统的正式部署前，缺少完整的演练。尽管有部分的演练，然而没有通过演练将可能的问题辨识出来。也因为如此，吃亏最多的迁移方案中的校验问题，没有能够提早暴露。

涉及到新旧两个系统的迁移，数据需要从系统O迁移到系统C，采纳的方案是C直接访问O的数据方式，表面看这种方式最简单最直接，然而编写迁移和校验程序的同事都必须必须清晰了解C系统和系统O的业务逻辑，而实际由于逻辑覆盖不全面，导致校验的工作不完整，只使用抽样的方式即花了大量的人力（校验一个抽样数据，需要花20分钟人力），也导致有大量的迁移漏洞需要补救。

同事CC告诉C，应该采纳接口交互表的方式，约定好规格，系统O的同事熟悉O的业务逻辑，负责将数据迁移到接口表，再由他们进行业务逻辑的检查，因为他们熟悉旧系统的逻辑啊！检查完毕后，才由C负责从接口交互表中提取数据，C了解新系统的新业务逻辑，对接口交互表进行逻辑检查后，提取数据转换到新的系统。采纳两时期的迁移，由熟悉旧系统的同事做应该做的事，让新系统的同事做他该做的事、熟练的事，看似复杂反而简单！

我在旁边插了话，事实上假如旧系统是其他公司承建的，可能同事们就能想到两时期迁移的接口交互表方式，但是我们两个系统由因此同一个部门承建，我们把部门边界和系统边界给混淆了，反而欲速而不达。

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

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

使用

作用play()

wgzc.play()

播放Flash动画stopplay()

wgzc.stopplay()

停止播放Flash动画rewind()wgzc.rewind()

停止播放Flash动画并返回第一帧totalframes()

wgzc.totalframes()

返回Flash动画总帧数

gotoframe(intnum)

wgzc.gotoframe(intnum)

转到指定帧

二、程序代码：

<html>

<head>

<scriptlanguage="javascript">

functioninit()

{document.changeframe.totalfrm.value=document.wgzc.totalframes}

</script>

</head>

<bodyonload="init()"bgcolor="#FFFFFF"bgproperties="fixed">

<fieldset>

<legend><fontcolor="#FF0000">操纵Flash动画</font></legend>

<formname="changeframe">

<fontcolor="#800000">

Flash动画帧数:</font><fontcolor="#000080"><b><inputname="totalfrm"type="text"size=4value="1"disabled>

</b></font><fontcolor="#800000">

输入第</font><b><fontcolor="#000080"><inputname="framenum"type="text"size=4value="1"></font></b><fontcolor="#800000">帧,再点击"指定帧"。</font>

</form>

<ahref="#"onclick="javascript:document.wgzc.play()"><fontcolor="#800080">播放</font></a>

<b><fontcolor="#000080">

</font></b>

<ahref="#"onclick="javascript:document.wgzc.stopplay()"><fontcolor="#800080">停止</font></a>

<fontcolor="#000080">

<b></b></font>

<ahref="#"onclick="javascript:document.wgzc.rewind()"><fontcolor="#800080">停止返回第一帧</font></a>

<b><fontcolor="#000080">

</font></b>

<ahref="#"onclick="javascript:document.wgzc.gotoframe(document.changeframe.framenum.value)"><fontcolor="#800080">指定帧</font></a><center>

</fieldset>

<OBJECTclassid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"

codebase="/flash2/cabs/swflash.cab#version=4,0,0,0"

ID=wgzcWIDTH=500HEIGHT=100>

<PARAMNAME=movieVALUE="/upfiles/20070425/20070425232441_webjx_com_01.swf">

<PARAMNAME=qualityVALUE=high>

<PARAMNAME=bgcolorVALUE=#FFFFFF>

<EMBEDsrc="/upfiles/20070425/20070425232441_webjx_com_01.swf"quality=highbgcolor=#FFFFFF

WIDTH=500HEIGHT=100TYPE="application/x-shockwave-flash"

PLUGINSPAGE="/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash">

</EMBED>

</OBJECT>

</center>

</body>

</html>

以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虚拟核心模式（2）核心

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

（4）核心团队具有较强的创新优势，通过不同团队成员的交流与合作，更容易产生全新的理念。

要注意的是，核心团队本身也是一个虚拟团队，其成员来自于分散的各个团队成员，因此具有专门大的灵活性和柔性特征。另外，核心团队的组织边界也是相对变化的，其中的成员具有一定的流淌性，其规模则依照项目的情况而扩大或缩小。

三、集中团队模式

分散并行模式和虚拟核心团队模式的虚拟项目团队组织形式具有较低的集中度，其开发效率、时刻周期和协调程度都有一定的局限性。当项目规模比较大、复杂性比较高、时刻要求比较紧时，这两种组织形式往往无法应对。因此，必须采取更为高效的集中团队模式。

与前两种组织形式相比，集中团队模式首先强调的是团队成员必须集中在一个地点，并进行集中式的一体化开发。其次，集中化团队模式不是单一固定的开发组织，没有直线式的组织结构，其团队成员是来自于组织的各个部门的技术专家和治理专家。

集中化团队具有一些独特的优势。团队成员集中在一起，有利于知识的沟通和交流，尤其是有利于隐性知识的共享和扩散。团队成员之间的频繁交流和沟通，能够制造出共同的团队文化，增强项目团队的凝聚力和团队精神。同时，高水平专家的高度集聚能够大大提高开发效率，缩短开发周期。

例如，希赛教育的软考视频课程研发项目确实是采纳集中团队的研发模式。实际上，希赛教育的研发模式是高度分散的，其专家要紧来自CSAI顾问团，而CSAI顾问团成员遍布在全国各地的各个行业。在2006年上半年，为了迅速占据软考培训市场，希赛教育成立了由来自全国各地的10多名专家组成的视频课程研发项目团队，该项目团队的所有成员都集中在希赛教育总部（长沙）的办公楼里，其空间布局是开放式的，这有助于关键性的隐性技术知识的扩散、共享和保留。因此，该项目使得希赛教育在专门短的时刻里开发出软考全套视频教程，一举成为软考培训市场的首领。

要注意的是，集中团队模式具有专门大的成本负担和市场风险，因为组建集中化项目团队，往往需要调集组织内部的技术精英和治理精英，投放大量的资金，占用大量的资源。因此，集中化团队模式不宜频繁使用，要紧是用于战略性的重大研发项目。

四、下一篇文章

在《虚拟项目治理：虚拟项目团队的组织形式》中，我们把虚拟项目团队分为两种差不多组织形式，分不是单个组织的虚拟化、多个组织组成的虚拟项目团队。本文详细介绍了单个组织的虚拟化结构，在下一篇文章《虚拟项目治理：多主体虚拟项目团队》中，笔者（编者注：CSAI顾问团首席顾问张友生博士）将详细讲解多主体虚拟项目团队的组织结构。虚拟项目治理虚拟项目团队的组织形式在《虚拟项目治理：虚拟项目的特征》中，笔者（编者注：CSAI顾问团首席顾问张友生博士）简单地介绍了虚拟项目的概念和特征。我们明白，虚拟项目事实上是一个实实在在的项目，只只是参加项目开发的人员或部门分布在不同的地点（全国各地，甚至世界各地），那么，这种项目与传统的项目在团队的组织上有些什么区不呢？这确实是本文所要讨论的内容。

一、组织形式的分类

随着通信技术、计算机网络技术以及互联网技术的飞速进展，虚拟项目无处不在。依照笔者（编者注：CSAI顾问团首席顾问张友生博士）的研究和实践，在实际的运行过程中，存在着多种形式的虚拟项目组织，各个组织能够依照自身的条件和市场机遇，采取不同的虚拟项目组织形式。总的来讲，依照主体的不同，虚拟项目组织能够分为两大类。

第一类是单个组织的虚拟化，即某一组织通过计算机网络和通信技术，将分散在不同地点的研发资源联结起来而形成的虚拟性项目组织。

依照组织成员的集中度高低，这种虚拟项目组织形式还能够进一步分为三种，分不是分散并行模式、虚拟核心模式以及集中团队模式。其中分散并行模式的集中度最低，各个团队成员或模块独立开展研发工作；虚拟核心模式则是采取核心团队集中于一地、团队成员仍相对独立的方法，其集中度相对较高；集中团队模式强调在维持团队的虚拟灵活特性的同时，针对专门的研发任务而高度集中，紧密配合。

有关这方面的详细情况，笔者（编者注：CSAI顾问团首席顾问张友生博士）将在《虚拟项目治理：单主体虚拟项目团队》中进行讨论。

第二类是多个组织以计算机网络和通信技术为联结手段、以市场目标和关系契约为基础而形成的虚拟项目组织。这种多主体模式不仅以信息技术来超越地理空间和组织结构的限制，而且通过诸如合同契约、协议、政策等软约束来实现研发资源的共享和集成。

假如按照团队成员之间的竞争程度和关联程度两个维度作为划分标准，那么能够将多主体虚拟项目组织分为四种差不多类型，分不是价值关联非竞争性组织、技术关联非竞争性组织、技术关联竞争性组织、价值关联竞争性组织。其中价值关联非竞争性组织大多是不同行业内组织间的合作形式，团队成员之间没有直接的竞争关系，但往往是处于价值链的上下游企业（例如，希赛IT教育研发中心与电子工业出版社联合组成的软考图书研发项目组）；技术关联非竞争性组织是指同行业内非竞争性组织间的合作形式，团队成员间的研究开发合作专门紧密，但从事的研发领域不相重合，技术互补性强，没有直接的竞争领域；技术关联竞争性组织的成员间不仅在技术上高度相关，同处于一个竞争行业，而且在最终产品市场上成为直接的竞争对手（例如，希赛教育与SUN公司的Java合作项目）；价值关联竞争性组织的团队成员往往属于不同行业，但在研究开发同一类技术或产品。

有关这方面的详细情况，笔者（编者注：CSAI顾问团首席顾问张友生博士）将在《虚拟项目治理：多主体虚拟项目团队》中进行讨论。

二、需要考虑的因素

尽管虚拟项目组织是项目组织的一个要紧进展趋势，但目前还没有一个统一的组织模式和决策模式可供选择和利用，不同的虚拟项目组织和企业面对不同的场景，会作出个性化的、符合实际需要的选择。笔者（编者注：CSAI顾问团首席顾问张友生博士）认为，在组建虚拟项目组织的过程中，至少要考虑以下5个因素：

（1）虚拟项目组织的系统特征，即项目中的各个团队成员及子项目之间是高度耦合的依旧相对自主独立的。假如高度耦合，则适合采纳集中度高的组织方法；假如相对独立，则适合采纳比较松散的组织方法。

（2）各个团队成员的资源状况及其关联程度，即各团队成员研发资源的性质和数量，相互之间是互补性的依旧重复性的；不同成员是处于同一个行业，依旧不同的行业；处于同一个行业的成员，其产品是否会形成竞争关系。

（3）整个虚拟项目组织内部的沟通机制和协调机制。虚拟项目参与方众多，在文化背景、语言、时差等方面都会存在差异，那么，治理者需要依照团队成员的组成情况，选择合适的、有用的沟通机制和协调机制。

（4）知识系统的主导类型，即研发活动所涉及的知识要紧是显性知识依旧隐性知识。假如是隐性知识，则需要考虑如何把隐性知识转化为显示知识，以便在团队成员之间共享。

（5）项目的创新程度，即是渐进式的依旧突变式的。假如是渐进式的，则适合采取低集中度的组织形式；假如是突变式的，则适合采纳高集中度的组织形式。

具体来讲，关于单主体虚拟项目组织来讲，假如项目是渐进式创新，各个子项目相对独立，要紧知识是显性的，具有重复资源，那么能够采取低集中度的组织形式，相反则应采取高集中度的组织方式。关于多主体模式来讲，情况则有所不同，它要紧是针对重大的、复杂的、高投入的研发任务，其关注点不在于集中度，而在于资源的互补互利，以及成员企业间的竞争程度，它的组织形式更趋于无形化和网络化。虚拟项目治理虚拟项目的特征1近年来，随着经济全球化和信息技术的迅速进展，跨地区、跨国度的项目开发大量增加，组织（包括企业、学校、科研机构等，下同）研发资源的空间离散度也在不断加大，越来越多的组织开始组建虚拟项目（VirtualProject）团队。那个地点的“虚拟”是指项目团队成员不在同一个都市，不在同一个地区，甚至不在同一个国家，组织将分散的研发团队联结起来实施跨国或跨地区的研发项目；“团队成员”既能够是一个自然人，也能够是一个法人组织（或其中的一个机构和部门）。

一、引言

除了大型企业自己组织的虚拟项目外，由于世界各地的资源不对等，而自然形成的一种虚拟项目也应运而生。例如，软件外包和服务外包往往确实是基于人力成本的考虑而产生的一种虚拟项目机制。与传统的项目治理相比，虚拟项目的团队组织形式、治理方法和手段都有所不同。笔者（编者注：CSAI顾问团首席顾问张友生博士）作为CSAI顾问团项目治理专业委员会成员，在虚拟项目治理（VirtualProjectManagement，VPM）的理论与实践方面做了一些工作，组织实施了若干个虚拟项目；通过做治理工程与科学专业的博士后研究工作，在虚拟项目治理理论方面，也进行了初步的研究。

理论来源于实践，理论用于指导实践。从现在开始，笔者（编者注：CSAI顾问团首席顾问张友生博士）通过一系列文章，从各个视角介绍与讨论虚拟项目治理，期望起到抛砖引玉的作用，引领国内项目治理专业人士对虚拟项目治理的研究。同时，也希望通过这一系列文章，能对国内虚拟项目治理的实践工作起到一定的指导作用。

二、虚拟项目的特征

虚拟项目是项目的一种新的组织形式，具有传统项目的所有特征。同时，虚拟项目作为一种新的开发模式，虚拟项目是基于人才、技术、设备等资源的网络组织结构，它具有以下重要的含义和特征：

第一，虚拟项目是以计算机网络和通信技术为支撑的。假如单从联盟或合作来看，虚拟项目的“虚拟”特征在往常的某些跨国企业中也存在过，但只有在信息技术高度进展和广泛运用的今天，不同组织之间的合作和资源共享才会成为广泛的现实，并展示出优化组合的巨大优势，虚拟项目也才能成为项目活动的要紧组织形式之一。特不是互联网的飞速进展，进一步凝缩了信息时空，提升了知识的整合与再造，也加强了组织的研发能力。

第二，虚拟项目具有多种核心研发能力。一方面，任何组织自身都具有某个方面的资源和能力的优势。例如，与欧美等发达国家相比，中国在人力资源方面具有比较优势；与联想、华为等国内大型IT企业相比，希赛教育在IT在线教育方面具有比较优势。然而，任何组织都难以具备（甚至是不可能具备）所有方面的核心能力。因此，任何组织都有必要利用外部资源来弥补自身的不足，并形成虚拟技术联盟来构筑核心技术能力；另一方面，由于近年来全球化趋势的推动，跨国公司的研发活动和资源趋于分散，而虚拟项目则能够依旧保持组织研发能力的整体竞争力。虚拟项目的各个成员必须具备各自的核心研发能力（要注意的是，在保证质量的前提下能低成本地完成一个项目，这也是一种核心竞争力），优势互补、强强联手是虚拟项目成功的必备条件。

第三，虚拟项目具有一致的、明确的目标集合。项目必定有确定的和明确的目标，没有明确的目标，行动就没有方向，也就不能成为一项任务，因此也就可不能有项目的存在。传统的项目是在一个组织内部实施，因此，其目标确实是要符合组织的战略目标；而虚拟项目的团队成员来自多个不同的组织，因此，相互一致的目标是虚拟项目团队成员的黏合剂，也是维系虚拟项目的全然力量。虚拟项目的目标来自市场机遇和客户需求，一般由成果性目标与约束性目标组成。其中成果性目标是虚拟项目的来源，也是虚拟项目的最终目标；约束性目标是实现成果性目标的客观条件和人为约束的总称，由于其是虚拟项目实施过程中必须遵循的条件，从而也就成为虚拟项目治理的要紧目标。待虚拟项目目标按照预期的结果实现以后，各个团队成员都会在其中分享到自己的“一杯羹”，实现自身的目标。

第四，虚拟项目的团队组织是一种动态联盟形式。虚拟项目中各个成员之间的合作是动态的，往往具有任务导向性，它是围绕项目而组成的临时性网络，具有高度的敏捷性，其成员也是处于变动之中的，团队的边界往往具有不确定性。例如，在虚拟项目的实施过程中，某个成员可能由于其自身的不可抗力或战略目标的转移而退出项目；而另外的组织可能在中