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

如何判断您的企业是否需要 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 系统还是轻量级的专用系统，都需要在企业特征优势方面具有传承的作用， 在规模化和规范化方面具有充分的空间，在流程上要注重核心流程的重点环节和保留未来 优化的弹性空间，这样实现的信息系统就会十分切合小企业多方面的需求，也能够体现信 息化在推动企业发展上的价值。 制作网页需要学习哪些技术 HTML 4.01 HTML 是 Web 的语言，每一个 Web 开发者都需要对它拥有基本的了解。 HTML 4.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 标准。 层叠样式表(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 年 1 月 26 日成为正式的推荐标 准(Recommendation)。W3C Recommendation 意味着其规范的稳定性，同时其规范目前已成 为一种 Web 标准。 XHTML 是一种使用 XML 进行重构的 HTML 4.01，并可以通过遵循一些简单的指导方针立 即在现有的浏览器中投入使用。 XML - 用于描述数据的工具 扩展标记语言(XML)并不是 HTML 的替代品。在未来的 web 开发中，XML 会被用来描述 和存储数据，而 HTML 会被用来显示数据。 我们对 XML 最合适的描述是，一个跨平台的、独立与软硬件的，信息存储和传输工具。 我们相信 XML 的重要性不亚于 HTML 对于 web 的基础性地位，并且 XML 将会成为最重要 的数据处理和传输工具。 XSLT - 用户转换数据的工具 XSLT(可扩展的样式表语言转换，Extensible Stylesheet Language Transformations)， 是用于转换 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)是对诸如下列数据库进行访问的通用标准：SQL Server、Oracle、Sybase 以及 Access。 对于那些希望从数据库存储和提取数据的人们来说，有关 SQL 的知识是极具价值的。 任何 web 管理员都应当明白，SQL 对于 web 上的数据库来说，是一种真正切合的引擎。 站在别人的肩上:项目管理的规则 美国著名软件工程专家勃姆（B.W.Boehm）在总结软件工程准则和信条的基础上，于 1983 年提出软件工程的 7 条基本原则，也是软件项目管理应该遵循原则。勃姆认为，这 7 条原则是确保软件产品质量和开发效率的原理的最小集合，相互独立但结合得相当完备。 1.用分阶段的生命周期计划严格管理。统计表明，不成功的软件项目中约有一半左右 源自计划不周。本原则意味着，应该把软件生命周期划分成若干阶段，相应地制定出切实 可行的计划，然后严格按照计划对软件的开发与维护工作进行管理。勃姆认为，在软件的 整个生命周期中应该制定并严格执行 6 类计划，即项目概要计划、里程碑计划、项目控制 计划、产品控制计划、验证计划、运行维护计划。不同层次的管理人员必须严格按照计划 各尽其职地管理软件开发与维护工作，绝不能受顾客或上级人员的影响而擅自背离预定计 划。 2.坚持进行阶段评审。软件的质量保证工作不能等到编码阶段结束之后再加以实施， 其理由为：第一，大部分错误始于编码之前；第二，错误的发现与修改时间越晚，需要付 出的代价就越高。因此，本原则意味着，在软件开发的每个阶段应该进行严格的评审，以 便尽早发现软件开发过程中的错误。 3.实行严格的产品控制。软件开发过程中不应随意改变需求，因为改变一项需求往往 需要付出较高的代价；但是软件开发过程中改变需求又在所难免，基于外部环境的变化而 出现改变用户需求的情况是一种客观需要，而且迅速应对客户的需求变更是顾客本位的内 涵之一。在这种情况下，只能依靠科学的产品控制技术来顺应这种要求。当改变需求时， 为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配 置管理。所谓基准配置又称基线配置，它们是经过阶段评审后的软件配置成分（各个阶段 产生的文档或程序代码） 。基准配置管理也称为变更控制：一切有关修改软件的建议，特别 是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实 施修改。避免开发人员对软件随意进行修改。 4.采用现代程序设计技术。从提出软件工程的概念开始，人们一直把主要精力用于研 究各种新的程序设计技术。从 60 年代末提出的结构程序设计技术到最近的面向对象技术， 人们不断创造先进的程序设计技术。实践表明，采用先进的技术既可提高软件开发的效率， 又可提高软件维护的效率。 5.结果应能清楚地审查。与其他有形产品不同，软件是看不见摸不着的逻辑产品。软 件开发人员的工作进展情况可见性差，难以准确度量，从而使得软件产品的开发过程比一 般产品的开发过程更难以评价和管理。为了提高软件开发过程的可见性，更好地进行管理， 应该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得 所得到的结果能够清楚地审查。 6.开发小组的人员应该少而精。该原则意味着，软件开发项目的组成人员的素质应该 好，而人数则不宜过多。开发小组人员的素质和数量是影响软件产品质量和开发效率的重 要因素。素质高的人员的开发效率比素质低的人员的开发效率可能高几倍至几十倍，而且 素质高的人员所开发的软件中的错误明显少于素质低的人员所开发的软件。此外，随着开 发小组人员数目的增加，因为交流问题而造成的沟通成本也急剧增加。因此，构建和维持 少而精的开发团队甚至标杆团队是软件工程的一条基本原理。 7.承认不断改进软件工程实践的必要性。遵循上述 6 条基本原则，就能够按照当代软 件工程基本原理实现软件的工程化生产，但是，仅遵循上述 6 条原则并不能保证软件开发 与维护的过程能赶上时代前进的步伐，能跟上技术的不断进步。因此，勃姆提出应把承认 不断改进软件工程实践的必要性作为软件工程的第七条基本原则。按照这条原理，不仅要 积极主动地采纳新的软件技术，而且要注意不断总结经验。 威格的成功软件项目管理秘诀 过程影响（Process Impact）公司的首席咨询顾问卡尔。威格（Karl E.Wiegers）在 其成功项目管理秘诀 （Secrets of Successful ProjectManagement）一文中总结了成 功项目管理的 20 条秘诀： 构筑基础 1.定义项目成功标准； 2.识别项目的驱动、约束和自由度； 3.定义产品发布标准； 4.协商承诺。 规划工作 5.制作计划书； 6.将任务分解成较小的里程碑； 7.为共通的大任务开发计划工作表； 8.计划在质量控制活动后实施修改； 9.为过程改进安排时间； 10.管理项目的风险。 估算项目 11.根据工作量而不是日历估算； 12.不要为项目人员安排超过其 80的时间； 13.将培训时间纳入计划中； 14.记录估算以及如何达致估算； 15.利用估算工具； 16.尊重学习曲线； 17.考虑意外事件的缓冲。 追踪进展 18.记录实绩与估算； 19.只有当任务百分之百完成时，才认为该任务结束； 20.公开而诚实地跟踪项目状态。 麦克康奈尔的成功软件项目十大要决 史蒂夫。麦克康奈尔（SteveMcConnell）在成功软件项目的十大要决 （10 Keys to Successful SoftwareProjects）中阐述了成功软件项目的十大要决： 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(int num) wgzc.gotoframe(int num) 转到指定帧 二、程序代码： function init() document.changeframe.totalfrm.value=document.wgzc.totalframes 控制 Flash 动画 Flash 动画帧数: 输入第帧,再点击“指定帧“。 播放 停止 停止返回第一帧 指定帧 以 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 的创立者 普拉特纳、霍普和特奇拉决定为他们最畅销 SAP R2 企业解决方案软件创造一个新版本。 新的 R/3 将利用一个可塑性强得多的设计。 但是新产品应该运行于哪些系统之上呢？当时，许多大学刚刚开始使用 Unix，这是一 个新的操作系统，允许在不同厂家的计算机之间构建网络，从而有可能创造一个新的系统 结构: 客户/服务器模型。虽然有这些优点，它却相当不稳定，没有达到企业解决方案应用 所需的表现水平。因此，尽管它提供了许多超过大型计算机的专业优势，许多从业者认为 它永远不会取代那时的大型机。 但普拉特纳不同意。他鼓吹为新的 R3 系统采用 Unix，从而指出了一种当时看上去 高度投机和冒险的方向。 他立刻在自己公司内陷入阻力之中。但是他相信他的远见于是运用他作为一个大 股东的影响力，得到了董事会的同意。4 年之后，1991 年，SAP 向全世界推出了 R3，安 装在一个小的 HP Unix 工作站。人们被震惊了。 “它几乎是可笑的， ”普拉特纳回忆道， “他 们在说：这个小机器，带着一些存储器就是伟大的 SAP？ ”但是，这个小机器为 SAP 在 ERP 市场的主导地位奠定了基础。基于 Unix 的 R3 向大群的 Windows PC 用户开 放了 SAP，用一个“漂亮的前端吹走了“绿色显示屏之争” ，正如理查森波士顿的高 等制造业研究公司的一位顾问所描述的。此外，基于 Unix 的 R3 的表现要比基于大型机 的 R2 更好。 R3 在全球 EPR 市场成了一个王牌产品。从 1992 年到 1998 年，单在美国，SAP 的收 入就从 4500 万美元上升到 20 亿美元。 是普拉特纳深入技术内部的洞察和他对未来发展的预见，使这一设想成为可能，也说 明了软件领导者必须生活于剃刀边缘。 软件业已经产生了许多其他的幻想家，他们在全球范围内改变了这个行业，从库比 （他在很久以前就相信软件可以与硬件分开销售）和基恩（他于 1965 年在一家汽车轮胎铺 里创立了他的软件服务公司） ，一直到比尔盖茨、埃里森和其他人。 特征二：敢于冒险 他们承受巨大的风险并希望有高额的回报。 在梦想成真的路上，软件领导者们必须能够面对无数次风险。麦肯锡的调查显示，成 功软件产品公司的领导者做出重要战略决定所花的时间平均要少 25，其原因并不主要是 他们有更好的信息或市场研究，更多的来自他们的冒险精神。 以莱曼特为例，他从学校退学，并在 1989 年建立了以得克萨斯州奥斯汀为所在地的 Trilogy 软件公司，一家专门从事前台办公室销售和营销软件的公司。对莱曼特来说，决 定冒险是很自然的。他告诉我们: “我想我不得不退学以抓住市场机遇。 ” 没有一个风险资本家想资助他，所以莱曼特靠赊欠度日。不过创立 Trilogy 两年后， 莱曼特从他冒险的愿望中得到了回报。他终于做成了与惠普的一笔 350 万美元的合同。其 他有名的客户，像波音和朗讯也接踵而来。到 1996 年，莱曼特进入了福布斯 400 名富豪榜 并成了其中最年轻的自力更生者，拥有估计 5 亿美元的净资产。在 1998 年，他有 850 名员 工，销售额超过 1 亿美元。 莱曼特及其公司并非孤立的个案。安德烈森在他合作创立网景并开发因特网浏览器软 件时只有 22 岁。比尔盖茨、巴尔默或 SAP 的普拉特纳同样都是冒险家，而且他们全都通 过冒险而成了亿万富翁。 特征三：多样选择 他们在多个选择上押注，来为所有不确定性做准备。 微软并不单单押注于它的 Windows PC 操作系统的成功，而是与 IBM 一起共同开发一 个与之竞争的操作系统 OS2。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 日，微软的 IE30，新的具有竞争力的浏览器发布了。 它在每个方面都赶上网景的 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 部反映的需求，我们说的不是这样的!“。 缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文档又出现了新的问题。 曾经有多个项目经理抱怨，在用户方进行的需求评审会完全是走形式，因为用户根本不去 听他读那上百页的需求文档。不同层次的客户(用户)关心的问题是不一样的，想要每个客 户都成为需求专家是不现实的。 需求的完备程度问题 需求如何做到没有遗漏?如何准确划定系统的范围?这确实是一个两难问题，稍微大一 点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至 于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还 要硬性的划定一个，从而建立一个基线。 需求开发的工期问题 在需求上花费了大量的时间(而不是人*工时，因为需求阶段人多了也没有作用)，客户、 软件公司是否能够忍受?为了确保需求的正确性，完备性，项目经理往往坚持要在需求阶段 花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担 心不已!他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变 的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。 需求的细致程度问题 需求到底描述到多细，才算可以结束了?仁者见仁，智者见智，并没有定论，如果时间 允许，要想细总可以细下去的。但是，需求的周期越长，可能的变化越多，对设计的限制 越严格，对需求的共性提取要求越高，所以只要大家(客户、用户、需求分析人员、设计人 员、测试人员)认为描述清楚了，就可以进入设计阶段了。 需求的变化问题 在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不 可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事， 也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。 需求变化的原因很多，如： 一开始没有识别全，需要增加需求； 业务发生了变化，需求必须变化； 需求错误； 需求不清楚； 需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题， 一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调 整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦， 怎么办?管理它!使需求在受控的状态下发生变化，而不是随意变化，需求管理就是要按照 标准的流程来控制需求的变化。 难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是“项目需求的 渐变“(Project Scope Creep)问题，这种渐变很可能是客户与开发方都没有意识到的，当 达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。 控制需求渐变需要注意以下几点： (1)需求一定要与投入有显示的联系，否则如果需求变更的成本由开发方来承担，则项 目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求 变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始 无论是开发方还是出资方都要明确这一条：需求变，软件开发的投入也要变。 (2)需求的变更要经过出资者的认可，需求的变更引起投入的变化，所以要通过出资者 的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。一个项目， 为了避免项目的风险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过 程提出了大量小“的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实 施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代 表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。 (3)小的需求变更也要经过正规的需求管理流程，否则会积少成多。在实践中，人们往 往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。 正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。 (4)精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免 需求的渐变，这是 2 个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求 的变化是永恒的，并非由于需求写细了，它就不会变化了。 注意沟通的技巧。实际情况是用户、开发者都认识了到了上