信息系统项目管理师(高级)学习资料大全.doc

《信息系统项目管理师(高级)学习资料大全.doc》由会员分享，可在线阅读，更多相关《信息系统项目管理师(高级)学习资料大全.doc（80页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、如何判断您的企业是否需要SOA管理SOA管理是我经常谈论的一个话题，得到的反馈也是好坏参半，这是因为对愿意以及方式缺乏了解。不管你的组织开始SOA多长时间，SOA管理都是需要多加注意的。我将首先解释一下SOA管理需要注意的原因，而后再谈一下需要注意的方面。但在我开始之前，我首先要澄清SOA管理与SOA治理的区别。对于我来说，SOA管理是SOA治理的一部分。SOA治理是由流程、标准以及政策来治理SOA实施的。一个完整的SOA治理解决方案设计注册表、存储、管理变革、服务控制、服务质量、安全等等。在此我将只谈SOA管理，对于多数厂商来说是服务控制、安全、业务流程可见度以及异常事件处理。首先，让我们看

2、看传统的智慧。组织通常认为他们不需要SOA管理的原因在于没有足够的业务动力。或者说：“在我们的SOA架构还没建立起来的时候就需要SOA管理呢？”这种想法正确吗？你可以在读完这篇文章之后做出自己的决定。我早前曾经提到过SOA实施像一场旅行，你的组织要达到一定的SOA成熟度是需要时间的。在SOA实施的某一个时间点，SOA管理就会牵涉进来，原因有两点：1. 你的SOA架构将单个的应用程序和筒仓型业务功能变成了分布式服务。随着灵活性和灵敏度的增加，安全和访问控制的复杂性也随之提高。这就需要管理工具上的新想法。2. 即使是在基础的SOA环境中，你的组织也将需要SOA架构的可见度。可见度的要求包括业务流程

3、、服务使用、性能瓶颈等等。随着你的环境变得越来越分散，使用原有的管理工具就会逐渐丧失可见度。因此，当SOA促进你的业务时，你需要SOA促进你的管理环境去超越传统系统管理。这是SOA发展的适当时机吗？那么，什么时候才是考虑SOA管理的适当时机呢？这个时间应该早于还是晚于你的SOA部署期呢？决定因素有以下几点：1 访问权控制和安全是SOA管理提出的关键问题。因此，SOA管理应该是你的SOA基础架构整体中不可分割的一部分，而不是随后加入。从实际出发，你需要在SOA项目早期考虑安全和控制。2 有了妥善的规划，SOA管理将降低SOA项目的成本实施时间。人们普遍认识到项目周期早期发生的改变/修复相较于晚期

4、来说影响更小。换句话说，你越晚决定对SOA管理提出的问题进行解决，对你之前所做决策的影响就会越大，而代价往往是巨大的。3 组织往往只有在出现问题的时候才会想到管理。我们很难去量化由于基础架构中累赘服务或安全破坏所造成的干扰带来的成本。你要做的不是去寻找救火措施，而是利用SOA管理工具主动的控制和监控业务。4 业务流程管理（BPM）是亚洲企业中的一大主题。SOA实施则是另外一个主题。SOA管理工具是BPM很好的补足解决方案。在使用BPM的时候，多数企业都想如何利用BPM工具建立并管控其业务流程。但是，我需要提出以下几个问题以供考虑：1 是不是所有的业务流程都能用BPM解决方案来定义？2 如果不是

5、，那么你要如何处理那些没有被BPM工具定义的业务流程？3 这些业务流程是遵循最初设计构想来运作的吗？换句话说，你要如何发现你的业务流程正导致一些始料未及的后果？我认为大多数企业都无法通过BPM解决方案为所有的业务流程建模。如果你的业务存在已久，那么就可能会比你想象中还要多的未定义业务流程。一些SOA管理工具，带有自动发现功能，能弥补这一空白。这些工具能够“看到”并告知你基础架构中正在发生的问题。所以不要以你认为有效的方式模拟业务流程，而让你的 SOA管理工具来告诉你真正发生的问题。这不仅仅有利于IT针对应用和瓶颈下功夫，还有利于分析师看到实时的业务流程。目前，我们已经讨论了进行SOA管理的原因

6、，如果你认为你真正需要SOA管理，以下几点是在挑选解决方案时需要注意的：注意事项：1 性能：所有的管理和监控工具会带来一些开销，你需要确定你的系统性能不会受到太大的影响。2 标准支持：你的业务是在异构的应用程序、服务和标准中运行的，你的管理解决方案也需要如此。如果你需要改变基础架构投资以服务SOA管理，那么你有可能在寻找错误的解决方案。3 跨功能支持。你的SOA基础架构可以跨越多个功能或应用解决问题，同样，你的SOA管理方案也是如此。千万确保你所制定出的解决方案能够真正的满足IT部门的需要，同时也能满足业务分析人员，甚至可能会是保安人员的需要。就如同整个企业架构体系中的其他资产一样，如果你能确

7、切的知道SOA管理解决方案存在的意义以及如何使用将会让你获得更加明显的竞争优势。那么，你是否真的需要SOA管理？这个决定是由你选择的。中小企业信息化：资金与需求该如何权衡小企业信息化考验IT人的能力什么是小企业?在我看来，小企业是特指那些已经度过了生存期、销售额在1亿到10亿元范围内、在特定细分行业或者区域内有独到之处的核心能力，看起来能够迅速发展的企业。小企业的信息化矛盾体在经济发达的地区，这样的小企业很多，造就了众多的亿万富翁。同时，这样的企业在发展上则是上上下下、起起伏伏，绝大多数无法持续发展成为更大的规模化现代企业。企业成功的独特优势受到挑战，与通用成熟的现代企业管理方法有严重的甚至根

8、本的冲突，规模和区域扩展后外部环境的压力和复杂度超出想像和承受能力。在这种情况下，信息化到底能够为小企业提供什么价值?这个问题是一直困扰着信息经理或者信息总监或者CIO的一个事情。我们知道，信息化是以系统化的体系和工具规范企业的运营方法和流程，让企业在一定的战略方向上持续稳定经营。从管理不成熟的角度看，小企业确实不是做信息化的最好时期;但是，从企业发展的角度看，信息化又是小企业做强做大必不可少的工具。这样的矛盾状态，使得小企业的信息化成为考验IT人残酷的熔炉。小企业信息化“四核心”“尊重环境，量力而行，保障基础，突出优势”似乎是小企业信息化的核心要义。“尊重环境”是要根据企业文化、企业的管理风

9、格、管理体系这个大环境，选择信息系统中能够有效体现这些特征的流程进行实施，在总体保证整体连续的业务流程的情况下，突出具有共识的重点环节，舍弃有争议的环节，在流程的基本面上保持“信息系统风格就是企业文化的反映”。“量力而行”的重点不是投资上的量力而行。通常情况下企业如果效益良好，投资不是问题。这个“力”是指企业的“管理能力”或者是“管理成熟度”，以及企业的学习速度或者对系统化、规范化操作的学习能力。一般情况下，企业通常高估自己的学习能力，低估过去的习惯势力，或者对信息系统给予太高的期望。在实施信息系统的时候要么过低地估计使用系统对业务的改变，要么过高地估计自己的适应或者学习能力，或者相反。这样会

10、形成众多的冲突，截然相反的评估或者意见经常同时出现。所以，对“能力”要做好充分的评估。“保障基础”则是要保持信息系统的流程完整性，特别是供应链、资金链的流程，重点要放在使整个链条通畅，不必有太多花哨的功能。开始是基本的核心流程，再在使用的过程中逐步优化、细化每步操作。这样可以达到“麻雀虽小五脏俱全”，符合小企业使用大系统的基本规律，对未来的发展具备良好的扩充和支持能力，也为未来规范的组织发展奠定系统基础。“突出优势”是小企业信息化的特征价值。由于小企业一般会具备某些特殊或者特有的管理方法、业务流程让企业引以为豪，那就要特别关注这些特征，在信息系统中重点突出这些优势，固化在系统中继承下去。这样的

11、信息系统也才能够充分体现企业的文化和管理特征，得到广泛的认可。总体来讲，由于小企业的管理尚未成熟，运营体系尚未职业化、标准化和系统化，企业发展速度和组织变动速度快，进行小企业信息化的时候要充分考虑这些因素。无论是选择重型的ERP系统还是轻量级的专用系统，都需要在企业特征优势方面具有传承的作用，在规模化和规范化方面具有充分的空间，在流程上要注重核心流程的重点环节和保留未来优化的弹性空间，这样实现的信息系统就会十分切合小企业多方面的需求，也能够体现信息化在推动企业发展上的价值。制作网页需要学习哪些技术HTML 4.01HTML是Web的语言，每一个Web开发者都需要对它拥有基本的了解。HTML 4

12、.01是重要的Web标准，它与HTML 3.2的差异非常之大。当类似font的标签和color属性被添加到HTML 3.2后，它就逐渐成为开发人员们的一场噩梦。开发那些必须把字体信息加入每个单独页面的网站，其过程成为了一种漫长而昂贵的折磨。通过HTML 4.01，所有的格式化信息可以被移出HTML文档，转而放入一个独立的样式表中。HTML 4.01之所以重要，另外一个原因是由于XHTML 1.0，这个最新的HTML标准是作为一种XML应用被重新表达的HTML 4.01。在您的页面中使用HTML 4.01可以确保在未来将HTML轻松升级到XHTML。请确保您使用了最新的HTML 4.01标准。层

13、叠样式表(Cascading Style Sheets - CSS)样式可定义HTML元素如何被显示，类似font标签在HTML 3.2中所起到的作用。样式通常被保存在HTML文档之外的文件中。外部样式表使您有能力仅仅通过编辑一个简单的CSS文档来改变网站内所有页面的外观和布局。如果您曾经尝试过进行某些改变，比如同时改变站内所有网页标题的字体或颜色，您就会明白CSS如何能够达到事半功倍的效果。XHTML - HTML的未来XHTML指可扩展超文本标记语言(Extensible HyperText Markup Language)。XHTML 1.0是源自W3C的最新的HTML标准。它于2000

14、年1月26日成为正式的推荐标准(Recommendation)。W3C Recommendation意味着其规范的稳定性，同时其规范目前已成为一种Web标准。XHTML是一种使用XML进行重构的HTML 4.01，并可以通过遵循一些简单的指导方针立即在现有的浏览器中投入使用。XML - 用于描述数据的工具扩展标记语言(XML)并不是HTML的替代品。在未来的web开发中，XML会被用来描述和存储数据，而HTML会被用来显示数据。我们对XML最合适的描述是，一个跨平台的、独立与软硬件的，信息存储和传输工具。我们相信XML的重要性不亚于HTML对于web的基础性地位，并且XML将会成为最重要的数据

15、处理和传输工具。XSLT - 用户转换数据的工具XSLT(可扩展的样式表语言转换，Extensible Stylesheet Language Transformations)，是用于转换XML的语言。未来的网站将不得不向不同的浏览器并向其他web服务器以不同的格式传递数据。而XSLT则是一种将XML数据转换为不同格式的新的W3C标准。XSLT可以把XML文件转换为浏览器可识别的格式，比如HTML，或者WML - 一种用于许多手持设备的标记语言。XSLT还可以添加元素，并对元素进行删除、重新排列及排序，测试并确定显示哪些元素，等等。客户端脚本客户端脚本脚本是一种有关因特网浏览器行为的编程。您应

16、该学习JavaScript，这样才能有能力传递更多的动态网站内容：JavaScript是为HTML设计者提供的一种的编程工具HTML的创作者通常都不是程序员，但是JavaScript是一种语法非常简单的脚本语言!几乎任何人都能够把某些JavaScript的代码片断放入他们的HTML页面中。JavaScript可以在HTML页面中放入动态的文本像这样的一条JavaScript语言可以在HTML页面中写入可变的文本：document.write(h1 + name + /h1)JavaScript能够对事件进行反应可以把JavaScript设置为在某事件执行时发生，比如当页面加载完毕或当用户点击某

17、个HTML元素时。JavaScript可读取并修改HTML元素JavaScript能够读取并修改HTML元素的内容JavaScript可被用来验证数据可使用JavaScript在表单被提交到服务器前对表单数据进行验证，这样可确保服务器进行正确的数据处理。服务器端脚本服务器端脚本和因特网服务器编程有关。您应该学习服务器端脚本，这样才能有能力传递更多的动态网站内容。通过服务器端的编程，你可以：动态地编辑、修改或添加网页内容对用户从HTML提交的查询或数据进行响应访问数据或数据库，并把结果返回浏览器访问文件或XML数据，并把结果返回浏览器把XML转换为HTML，并把结果返回到浏览器为不同的用户定制页

18、面，提高页面的可用性对不同的网页提供安全和访问控制为不同类型的浏览器设计不同的输出最小化网络流量使用SQL管理数据结构化查询语言(SQL)是对诸如下列数据库进行访问的通用标准：SQL Server、Oracle、Sybase以及Access。对于那些希望从数据库存储和提取数据的人们来说，有关SQL的知识是极具价值的。任何web管理员都应当明白，SQL对于web上的数据库来说，是一种真正切合的引擎。站在别人的肩上:项目管理的规则美国著名软件工程专家勃姆（B.W.Boehm）在总结软件工程准则和信条的基础上，于1983年提出软件工程的7条基本原则，也是软件项目管理应该遵循原则。勃姆认为，这7条原则

19、是确保软件产品质量和开发效率的原理的最小集合，相互独立但结合得相当完备。1.用分阶段的生命周期计划严格管理。统计表明，不成功的软件项目中约有一半左右源自计划不周。本原则意味着，应该把软件生命周期划分成若干阶段，相应地制定出切实可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。勃姆认为，在软件的整个生命周期中应该制定并严格执行6类计划，即项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。不同层次的管理人员必须严格按照计划各尽其职地管理软件开发与维护工作，绝不能受顾客或上级人员的影响而擅自背离预定计划。2.坚持进行阶段评审。软件的质量保证工作不能等到编码阶段结

20、束之后再加以实施，其理由为：第一，大部分错误始于编码之前；第二，错误的发现与修改时间越晚，需要付出的代价就越高。因此，本原则意味着，在软件开发的每个阶段应该进行严格的评审，以便尽早发现软件开发过程中的错误。3.实行严格的产品控制。软件开发过程中不应随意改变需求，因为改变一项需求往往需要付出较高的代价；但是软件开发过程中改变需求又在所难免，基于外部环境的变化而出现改变用户需求的情况是一种客观需要，而且迅速应对客户的需求变更是顾客本位的内涵之一。在这种情况下，只能依靠科学的产品控制技术来顺应这种要求。当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理

21、。所谓基准配置又称基线配置，它们是经过阶段评审后的软件配置成分（各个阶段产生的文档或程序代码）。基准配置管理也称为变更控制：一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改。避免开发人员对软件随意进行修改。4.采用现代程序设计技术。从提出软件工程的概念开始，人们一直把主要精力用于研究各种新的程序设计技术。从60年代末提出的结构程序设计技术到最近的面向对象技术，人们不断创造先进的程序设计技术。实践表明，采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。5.结果应能清楚地审查。与其他有形产品不同，软件是看不见摸不着的逻辑产

22、品。软件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一般产品的开发过程更难以评价和管理。为了提高软件开发过程的可见性，更好地进行管理，应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查。6.开发小组的人员应该少而精。该原则意味着，软件开发项目的组成人员的素质应该好，而人数则不宜过多。开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件。此外，随着开发小组人员数目的增加

23、，因为交流问题而造成的沟通成本也急剧增加。因此，构建和维持少而精的开发团队甚至标杆团队是软件工程的一条基本原理。7.承认不断改进软件工程实践的必要性。遵循上述6条基本原则，就能够按照当代软件工程基本原理实现软件的工程化生产，但是，仅遵循上述6条原则并不能保证软件开发与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。因此，勃姆提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条基本原则。按照这条原理，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。威格的成功软件项目管理秘诀过程影响（Process Impact）公司的首席咨询顾问卡尔。威格（Karl E.Wiegers）

24、在其成功项目管理秘诀（Secrets of Successful ProjectManagement）一文中总结了成功项目管理的20条秘诀：构筑基础1.定义项目成功标准；2.识别项目的驱动、约束和自由度；3.定义产品发布标准；4.协商承诺。规划工作5.制作计划书；6.将任务分解成较小的里程碑；7.为共通的大任务开发计划工作表；8.计划在质量控制活动后实施修改；9.为过程改进安排时间；10.管理项目的风险。估算项目11.根据工作量而不是日历估算；12.不要为项目人员安排超过其80的时间；13.将培训时间纳入计划中；14.记录估算以及如何达致估算；15.利用估算工具；16.尊重学习曲线；17.考虑

25、意外事件的缓冲。追踪进展18.记录实绩与估算；19.只有当任务百分之百完成时，才认为该任务结束；20.公开而诚实地跟踪项目状态。麦克康奈尔的成功软件项目十大要决史蒂夫。麦克康奈尔（SteveMcConnell）在成功软件项目的十大要决（10 Keys to Successful SoftwareProjects）中阐述了成功软件项目的十大要决：1.清晰的愿景；2.稳定的、完整的、书面的需求；3.详细的用户界面原型；4.有效的项目管理；5.精确的估算；6.两阶段预算；7.注重质量；8.听取技术专家的意见；9.积极的风险管理；10.记住：软件来源于人。在组织间跨项目组加强推广学习优秀经验以往对项目

26、总结的认识不够，很多时候也就是写写PPT或者开个会，很多经验没有能被辨识出来成为案例，也就不能给大家分享。特别是很多教训，人性的问题，没有被说出来，毕竟说出自己的不是不是每个人都能做到。导致教训库不能不断丰富，因此前人吃亏，后人无法继承到有效的经验。前段时间进行2008年度总结的时候，业主提出接触我们这么多项目，我们每个项目经理的风格都不一样，项目的成功与否太依赖于项目经理个人的能力。我想我们不是要让每个人都没有自己的风格，项目经理当然有能力水平的高低，当然有不同的价值体现。业主其实就是在说我们的项目实践必须积累。在之前的博文业主的改进意识让我惊讶，我们应该更加积极地看待和推进CMMi的改进！

27、中讲到，一个业主的项目经理对口我们几个项目经理，A项目经理做得好的，业主方项目经理肯定会将A做得好的地方来要求公司的另一个项目经理B。如果我们自己不传授这种经验，那才是傻子。使用即将推行的CMMi的规程，重新Review一下2008年的各个项目，从中去分析各个项目组的强处以及弱项，从规程中扫漏洞，审视项目组的那些活动执行的力度和弱项之间的关系，对于来年指导项目建设是非常有帮助的。今天在内审会议总结上，同事WN说得好，我们现在的项目经理花了很多时间在做事，其实缺少了时间思考如何去做事！管理不仅是规范、监督，还有教练一职。故事一则：在组织间跨项目组加强推广学习优秀经验，除了会议交流、专题培训，还可

28、以去现场实地体验加强感性认识（呵呵，共产党宣传的那一套都要学习用上）。上次说到项目O和项目C整合上线，整个上线持续了近三天时间，有很多地方值得总结。今天刚好有项目T正在组织部署上线，项目T的技术经理CC做为培训讲师以往培训过两次有关部署的工作，项目C的经理C当时也听过CC的课程，在没有和CC打招呼的前提，带上项目O和项目C的两位同事L和C到现场去抽查观摩，能够更加有感触其他同事的优秀实践。到了现场，才知道项目T晚上6点才开始部署，因此安排两个项目的项目经理/技术经理进行现场的交流。在简单介绍了此行的目的后，CC首先发言，询问C上次部署的过程中计划和实际工作最大的出入在那些地方？通过近一个小时的

29、访谈，同事C和L认识他们有不少改进的问题，这里讲最重点一点：项目组C和项目组O在系统的正式部署前，缺少完整的演练。虽然有部分的演练，但是没有通过演练将可能的问题辨识出来。也因为如此，吃亏最多的迁移方案中的校验问题，没有能够提前暴露。涉及到新旧两个系统的迁移，数据需要从系统O迁移到系统C，采用的方案是C直接访问O的数据方式，表面看这种方式最简单最直接，但是编写迁移和校验程序的同事都必须必须清晰了解C系统和系统O的业务逻辑，而实际由于逻辑覆盖不全面，导致校验的工作不完整，只使用抽样的方式即花了大量的人力（校验一个抽样数据，需要花20分钟人力），也导致有大量的迁移漏洞需要补救。同事CC告诉C，应该采

30、用接口交互表的方式，约定好规格，系统O的同事熟悉O的业务逻辑，负责将数据迁移到接口表，再由他们进行业务逻辑的检查，因为他们熟悉旧系统的逻辑啊！检查完毕后，才由C负责从接口交互表中提取数据，C了解新系统的新业务逻辑，对接口交互表进行逻辑检查后，提取数据转换到新的系统。采用两阶段的迁移，由熟悉旧系统的同事做应该做的事，让新系统的同事做他该做的事、熟练的事，看似复杂反而简单！我在旁边插了话，其实如果旧系统是其他公司承建的，可能同事们就能想到两阶段迁移的接口交互表方式，可是我们两个系统由于是同一个部门承建，我们把部门边界和系统边界给混淆了，反而欲速而不达。在网页中用JS函数控制Flash动画播放 一、

31、介绍与Flash动画控制有关的javascript函数：函数名使用作用play()wgzc.play()播放Flash动画stopplay()wgzc.stopplay()停止播放Flash动画rewind()wgzc.rewind()停止播放Flash动画并返回第一帧totalframes()wgzc.totalframes()返回Flash动画总帧数gotoframe(int num)wgzc.gotoframe(int num)转到指定帧 二、程序代码： function init() document.changeframe.totalfrm.value=document.wgzc.t

32、otalframes 控制Flash动画 Flash动画帧数: 输入第帧,再点击指定帧。 播放 停止 停止返回第一帧 指定帧 PARAM NAME=movie VALUE= EMBED src= quality=high bgcolor=#FFFFFF WIDTH=500 HEIGHT=100 TYPE=application/x-shockwave-flash PLUGINSPAGE= 以WBS为主线的集成项目管理任何流程或业务在我们学习的过程中始终都有一个主线，比如说知识管理的基础或主线是知识库和知识地图，ERP的数据基础是ITEM和BOM，主线是需求订单-MRP-生产计划和采购计划。对于

33、产品数据管理PDM的主线是产品结构，对于CRM客户关系管理的主线是营销-市场策划-销售计划-预测-项目-合同。而对于项目管理其基础是WBS工作结构分解，其主线是项目结构-项目-WBS-工作包-活动-任务。这条主线涉及到PMBOK里面的范围管理和进度管理两方面的内容。对于范围管理最终的输出就是范围说明书和WBS，而对于进度管理则输入是WBS，需要进行活动定义分解和排序，最终得到的进度表。在项目的执行过程中我们是按照具体的活动任务在执行，在执行的过程中会产生使用资源，消耗成本，产生文档和各种输出，进行设计开发，集成，评审和质量控制。我们活动分解的单位是到了具体的任务，但是我们产品的最终集成，我们的

34、成本核算和挣值管理是不能到活动任务的。因此WBS在整个项目管理中就起到了重要作用，其作用不仅仅在前期确定项目范围和制定项目的进度计划，更多的是后期的挣值管理和更高层次的项目监控。如果没有完善的WBS分解，我们就很难做到这一步，我们的整个项目管理执行过程中的产出就是凌乱的，没有一个主线串起来。感兴趣的可以再去翻看下PMBOK各个过程域中各个过程组的IPPO，可以发现很多过程的输入都有WBS，足以见WBS在整个项目管理中的基础和核心作用。在这个图中还强调了下在CMMI三级中我们强调的生命周期模型定义过程裁剪，在组织级我们可以根据项目的不同特点将项目进行分类制定不同的项目生命周期模板，这样在有实际的

35、项目来的时候，只需要根据项目的特点对模板内容进行自定义和裁剪，输入具体的需求项，即可以自动产生相应的WBS。(该点后续单独在发文阐述)，这样自动生成的WBS不仅仅实现了后续的主线跟踪，还实现了我们在CMMI二级中需要的需求追踪。一流软件领导的10个特征特征一：敢于设想他们是在不确定性上发展起来的技术空想家。软件领导者们必须生活于剃刀边缘。1987年，在驱车沿法兰克福到沃尔多夫从一家IBM代理商那儿回家时，SAP的创立者普拉特纳、霍普和特奇拉决定为他们最畅销SAP R2企业解决方案软件创造一个新版本。新的R/3将利用一个可塑性强得多的设计。但是新产品应该运行于哪些系统之上呢？当时，许多大学刚刚开

36、始使用Unix，这是一个新的操作系统，允许在不同厂家的计算机之间构建网络，从而有可能创造一个新的系统结构: 客户/服务器模型。虽然有这些优点，它却相当不稳定，没有达到企业解决方案应用所需的表现水平。因此，尽管它提供了许多超过大型计算机的专业优势，许多从业者认为它永远不会取代那时的大型机。但普拉特纳不同意。他鼓吹为新的R3系统采用Unix，从而指出了一种当时看上去高度投机和冒险的方向。他立刻在自己公司内陷入阻力之中。但是他相信他的远见于是运用他作为一个大股东的影响力，得到了董事会的同意。4年之后，1991年，SAP向全世界推出了R3，安装在一个小的HP Unix工作站。人们被震惊了。“它几乎是可

37、笑的，”普拉特纳回忆道，“他们在说：这个小机器，带着一些存储器就是伟大的 SAP？”但是，这个小机器为SAP在ERP市场的主导地位奠定了基础。基于Unix的 R3向大群的 Windows PC用户开放了SAP，用一个“漂亮的前端吹走了“绿色显示屏之争”，正如理查森波士顿的高等制造业研究公司的一位顾问所描述的。此外，基于Unix的R3的表现要比基于大型机的R2更好。R3在全球EPR市场成了一个王牌产品。从1992年到1998年，单在美国，SAP的收入就从4500万美元上升到20亿美元。是普拉特纳深入技术内部的洞察和他对未来发展的预见，使这一设想成为可能，也说明了软件领导者必须生活于剃刀边缘。软件

38、业已经产生了许多其他的幻想家，他们在全球范围内改变了这个行业，从库比（他在很久以前就相信软件可以与硬件分开销售）和基恩（他于1965年在一家汽车轮胎铺里创立了他的软件服务公司），一直到比尔盖茨、埃里森和其他人。特征二：敢于冒险他们承受巨大的风险并希望有高额的回报。在梦想成真的路上，软件领导者们必须能够面对无数次风险。麦肯锡的调查显示，成功软件产品公司的领导者做出重要战略决定所花的时间平均要少25，其原因并不主要是他们有更好的信息或市场研究，更多的来自他们的冒险精神。以莱曼特为例，他从学校退学，并在1989年建立了以得克萨斯州奥斯汀为所在地的Trilogy软件公司，一家专门从事前台办公室销售和营

39、销软件的公司。对莱曼特来说，决定冒险是很自然的。他告诉我们: “我想我不得不退学以抓住市场机遇。”没有一个风险资本家想资助他，所以莱曼特靠赊欠度日。不过创立Trilogy两年后，莱曼特从他冒险的愿望中得到了回报。他终于做成了与惠普的一笔350万美元的合同。其他有名的客户，像波音和朗讯也接踵而来。到1996年，莱曼特进入了福布斯400名富豪榜并成了其中最年轻的自力更生者，拥有估计5亿美元的净资产。在1998年，他有850名员工，销售额超过1亿美元。莱曼特及其公司并非孤立的个案。安德烈森在他合作创立网景并开发因特网浏览器软件时只有22岁。比尔盖茨、巴尔默或SAP的普拉特纳同样都是冒险家，而且他们全

40、都通过冒险而成了亿万富翁。特征三：多样选择他们在多个选择上押注，来为所有不确定性做准备。微软并不单单押注于它的 Windows PC操作系统的成功，而是与IBM一起共同开发一个与之竞争的操作系统OS2。SAP是另一个例子。它没有去“塑造”这个行业，而是宁愿适应领先者的标准，同时在几个标准上花钱。作为SAP的总裁和CEO，卡格曼评述说， SAP可以从第二排看到表演不断发展。专业软件公司的领导人同样通过选择权处理不确定性。西姆斯是剑桥技术伙伴公司的 CEO，该公司是波士顿一家6亿美元的软件服务公司。他确保剑桥连续投资几个新兴公司，它们可能会开发出一个新的技术标准。“我们与新技术一直保持接触，”西姆

41、斯说，“我们希望资助的这些公司之一有一天会成功。”但是，在通往成功的路上，软件领导者们必须接受不时的失败。事实上，失败并非是例外，而是惯例即使在成功的软件领导者之中。特征四：敢于尝试他们宁愿“迅速失败”而不是避免错误。“宁可做6个正确决定和4个错的，而不要等得太久，”SAP的霍普评述道。“Platinum技术公司的CTO波佩克同意这个说法。“快速移动是很重要的，”他说，“这常常会导致错误，但错误是可以改正的。”看看陈丕宏在他创立了BroadVision之后是如何反应的。尽管这名企业家在电子商务解决方案上押对了赌注，他却在选择交互式电视（它看起来像是“未来的潮流”）作为其产品的平台上犯了错误。事实上，当陈丕宏第一次看见因特网的时候，他的电视产品几乎已经完成了。特征五：强调速度陈丕宏几乎一夜之间就将BroadVision转变成了一家因特网公司。“对我来说非常清楚，我们错了，而且如果我们不迅速改弦易辙的话，我们就会失去一切。”陈丕宏回忆道。陈丕宏没有做长时间的讨论，而是几乎一夜