本页内容

	摘要
	读者
	介绍
	MSF 起源和简史
	MSF 和 Microsoft 操作框架
	MSF 关键术语
	基础原理
	MSF 模型
	MSF 准则
	Microsoft 对 MSF 的使用
	实现 MSF
	小结
	附录：MSF、行业标准和方法

摘要

Microsoft® 解决方案框架 (MSF) 是一种成熟的、系统的技术项目方法，它基于一套制定好的原理、模型、准则、概念、指南，以及来自 Microsoft 的、经过检验的做法。本白皮书将介绍 MSF，概述其基本原理、核心模型以及主要准则，并把重点放在如何应用它们推动技术项目成功上。最后，本白皮书提供的参考内容可以用来获得关于 MSF 的更加深入的信息，以及在组织内部实现 MSF 的指导。在附录里，白皮书会简要地将 MSF 与行业里的其他方法以及标准进行比较，并描述 MSF 能够如何与它们结合起来共同使用。

返回页首

读者

本白皮书为希望更多地了解 Microsoft 解决方案框架的人员提供了一个起始点。典型的读者群包括：顾问、执行人员、技术专家、开发人员，以及希望领导团队和组织采用最佳做法改进结果的项目经理，或者只想在发布业务驱动的技术解决方案的时候提高其自身工作技能的项目经理。

本白皮书的第二受众包括相同的专家，只不过这些读者对 MSF 已经有所了解。他们感兴趣的是，它与各种行业标准及方法之间的关联是什么样的，以及能够如何被用来与它们一起使用。在附录里对一些著名方法的简要描述将有助于在这个广泛的背景下确定 MSF 的范围和应用。

返回页首

介绍

按期并在预算范围内创建行之有效的业务解决方案需要一种经过检验的方法。Microsoft 解决方案框架提供了一个适应性的框架，用于以更快的速度、更少的人员、更少的风险来成功地交付信息技术解决方案，同时取得更高质量的结果。MSF 会帮助小组直接解决导致项目失败的大多数常见原因，以提高成功率、解决方案的质量和业务影响。MSF 就是创建用来处理技术项目和环境动态特性的，它能够提高项目实施过程中适应持续变化的能力。

MSF 被叫做框架而不是方法是有特定原因的。和规定性的方法不同，MSF 提供了一个灵活的和可伸缩的框架，其适应能力能够满足任何项目（不论其规模和复杂性）的要求，以规划、构建和部署业务驱动的技术解决方案。MSF 的观点是，没有哪个单一的结构或者过程能够适应所有项目的环境和要求。尽管如此，但是它也认为：对指导的需求是存在的。作为一个框架，MSF 就提供了这样一种指导，而不会强迫实施很多限制性的细节，否则这只会将其用处限制到有限范围的项目方案里。MSF 组件能够被单独应用或者共同应用，以提高下列类型项目的成功率：

用于这些不同项目类型的 MSF 指导把重点放在了“人员和过程”的管理以及大多数项目会碰到的技术元素上。由于技术小组的要求和做法是持续变化的，所以 MSF 所收集的材料也都在不断变化和扩展，以便跟上其步伐的。此外，MSF 还与 Microsoft 操作框架 (MOF) 交互，以提供到操作环境的顺利转变，这是长期项目成功的一个要求。

返回页首

MSF 起源和简史

这一章节将描述对 MSF 需求的产生和它是如何被创建的。

挑战和机遇

总所周知，今天的业务环境的特点是复杂型、全球互连性，以及从客户需求到生产方法再到变化率自身的加速。所有人也都知道，技术对这些因素中的每一个都有所贡献。这也就是说，技术常常是额外复杂性的来源，它支持全球的连接，并已经成为变化发生的主要催化剂之一。理解和使用技术变化所提供的机遇已经成为了组织里时间和资源消耗的主要原因。

信息系统和技术组织（以下简称 IT）已经在受困于时间和精力了，根据技术变化来开发和部署业务驱动的解决方案就需要这些时间和精力。它们正不断认识到低质量的结果所带来的负面影响及其无法接受的业务风险。为了让其工作收到更好的效果，它们从业界的领导者处寻求指导。

技术开发和部署项目可能会极其复杂，这就加大了其难度。技术本身就可能成为项目失败的因素；但是，它极少是主要原因。令人意外的是，经验表明：项目成功这一结果更多的与所涉及的人员以及过程有关，而非技术本身的复杂性。

在把人员和过程的组织和管理分解开来的时候，可以看到它们对项目的下列作用：

克服了这些问题的组织通过更高的产品和服务质量、提高的客户满意度，以及吸引行业最佳人员的工作环境获得了更好的业务结果。这些因素会转化成为对底线的正面影响以及组织战略效力的提高。

改变企业行为以有效地应对这些挑战并取得出色的结果是可能的，但是这需要奉献精神、责任心和领导力。为了实现这一目标，就要需要在 IT 和业务之间建立联系 — 建立理解、责任、协作和沟通之间的关联。但是只有结果才有发言权：IT 必须成为领导角色，以消除自身成功道路上的障碍。MSF 就是设计和构建用来提供框架实现这种转化的。

基于经验的解决方案

Microsoft 解决方案框架于 1994 年首次引入，当时还是一个来自 Microsoft 的产品开发努力和 Microsoft 咨询服务中心参与的最佳做法的松散集合。从那时起，MSF 已经有了发展，这来自 Microsoft 产品组、Microsoft 服务中心、Microsoft 的内部操作和技术组 (OTG)、Microsoft 合作伙伴和客户那里成功的和真实的最佳做法。MSF 元素基于行业著名的最佳做法，并融合了 Microsoft 在高技术行业超过 25 年的经验。这些元素都被设计用来共同工作，以帮助 Microsoft 的顾问、合作伙伴和客户来解决技术生命周期过程中碰到重大挑战。

MSF 使用这套经过内部和外部检验的真实最佳做法，并对这些做法进行简化、整理和检查，以便合作伙伴和客户理解和采用。现在已经成为一个可靠和成熟框架的 MSF 由 Microsoft 里一个专门的产品小组在管理和开发，它同时还得到了国际顾问理事会该方面专家的指导和评论。MSF 还在继续吸收 Microsoft 当前的经验。Microsoft 各种业务线里的其他小组也在日常工作中在内部创造、寻找和共享最佳做法和工具。从这些内部项目工作所学到的知识会通过 MSF 被整理和分发到 Microsoft 之外（的组织里）。

返回页首

MSF 和 Microsoft 操作框架

Microsoft 操作框架 (MOF) 提供的操作指导让组织能够在基于 Microsoft 产品和技术的任务关键系统里取得可靠性、可用性、可支持性，以及可管理性。MOF 基于一套国际认可的 IT 服务管理最佳做法，叫做 IT 基础结构库 (ITIL)，由英国政府的政府商务办公室 (OGC) 颁布。MOF 可以被看作是 ITIL 标准的超集。

MOF 以白皮书、操作指南、评估工具、最佳做法、案例研究、模板、支持工具、课件和服务等形式提供操作指导。这一指导将用于解决与复杂的、分布式的、差异巨大的技术环境相关的人员、过程、技术和管理等问题。

Microsoft 利用 MSF 发展过程中获得的知识创建了 MOF，把 MOF 建立关于组织结构和过程所有权的 ITIL 最佳做法之上，并为合作伙伴、客户和 Microsoft 内部操作和技术组 (OTG) 所使用的重要成功因素建立模型。.

MSF 和 MOF 共享基础原理和核心规范。它们的不同之处在于这些原理和规范的应用，它们每个都使用独特的小组和过程模型以及专门针对各自领域的、经过检验的做法。MSF 从 解决方案交付的角度体现了小组的结构和活动，而 MOF 从 服务管理的角度体现了小组的结构和活动。MSF 强调的是项目；而 MOF 强调是生产环境的运行。 MSF 和 MOF 提供了解决方案开发域和解决方案操作域之间的接口。

MSF 和 MOF 被设计用来在技术生命周期过程中联合使用，以成功地提供业务驱动的技术解决方案 — 从启动到交付，再到操作和最后的淘汰。MSF 和 MOF 专门用在当今业务的典型组织结构里；它们共同描述不同的部门能够如何最好地在一起工作，以便在一个互相支持的环境里取得共同的业务目标。

返回页首

MSF 关键术语

作为一个框架，MSF 包括能够被单独使用或者作为一个集成的整体使用的多个组件。它们共同创造一个可靠而且灵活的方法，用来成功地执行技术项目。下面的列表定义了这些组件。

下面图表里的例子有助于说明 MSF 某些组件之间的关联。

图 1：MSF 组件举例

或者，把上面的图标用文字表达出来就是：

MSF 的一个基础原理是 学习所有的经验。这一原理在 MSF 过程模型 里的关键里程碑上得到了充分的应用，在过程模型里 愿意学习 这一关键概念成功应用这一原理所需要的。愿意学习这一概念通过 后里程碑回顾的经过检验的做法在项目里得到体现。在大型的和复杂的项目里，Microsoft 建议 是利用客观的外部服务商来确保有一个无过错的环境，并把学习最大化。

相反的， 定义和监视风险触发器 （Microsoft 建议 在企业数据库或者存储库里捕捉它们，以便供跨项目使用）的经过检验的做法是 持续评估风险这一关键概念的一个应用。这些做法和概念是 风险管理准则 的一部分，风险管理准则通过 MSF 过程模型 每个阶段里 MSF 小组模型的所有成员来运用，这些概念和做法还用到了 保持灵巧 — 预测变化这一基础原理。

基础原理、模型和准则在下面的章节里都得到了进一步的解释，这就提供了它们之间相互关系的背景。

返回页首

基础原理

MSF 的核心有八个基础原理：

这些原理共同传达了 MSF 观点，构成了一种统一方法的基础，这一方法用来组织项目所需的人员和过程，以便交付技术解决方案。它们是 MSF 结构和应用的基础。尽管每个原理都已经显示出了自身的优势（请参阅本白皮书结尾部分的参考文献），但是它们很多都是相互依存的，因为其中任何一个的应用都对另一个的成功起到了支持作用。在依次应用的时候，它们建立了一个稳固的基础，使得 MSF 能够很好地适用于规模、复杂程度和类型都不相同的多种项目。

下面经过挑选的例子说明了 MSF 如何将每个原理应用到 MSF 模型或者准则上。请注意：本白皮书并不会描述 MSF 里这些原理的每个应用实例。

推动开放式沟通

“日程安排一团糟、功能不合适、到处都是系统错误，而原因就是左撇子不知道右撇子在做什么……。那么，小组之间应该如何相互沟通呢？用尽可能多的方式沟通。”

Frederick P. Brooks，Jr¹

技术项目和解决方案是由人的活动来构建和交付的。从事某个项目的每个人都会给小组带来自己的智慧、能力和观点。为了将成员的个人效力最大化，同时优化其工作效率，信息就必须随时可用且能够被积极共享。如果没有能够从多种渠道获取该信息的开放式沟通，那么小组成员就无法有效地完成其任务，也无法作出正确的决策。随着项目规模和复杂性的增加，对开放式沟通的需要就变得更加紧迫。完全基于须知（历史标准）的信息共享可能导致误解的产生，以至于削弱小组交付行之有效的解决方案的能力。这种受限的交流方式的最终结果可能会是解决方案和预期效果都无法满足要求。

MSF 里的开方式沟通

MSF 推出了一种开方式和包容式的沟通方式，既满足了小组内部也满足了利益所有人之间沟通的需要，同时能够符合诸如时间约束和特殊环境等条件的限制。一个畅通的信息流不仅会减少误解和无用功产生的机会，还会确保小组成员都能够致力于通过共享属于各自领域的信息减少与项目有关的不确定性。

在 MSF 项目里，可以采用任何形式来进行开放式和包容式的沟通。它是 MSF 小组模型的基本原理，而前者将它集成到了角色职责的描述里。当在整个项目生命周期过程中使用的时候，开发式沟通会推动客户、用户和操作等的积极参与。这种参与也通过将开方式沟通的概念融合到 MSF 过程模型的关键里程碑的定义里得到了支持。沟通成为了共同的前景和性能目标能够被建立、测量和取得的媒体。

为共同的前景而工作

“在项目开始之前，小组需要建立一个共同的前景。如果没有这样一个共同的前景，就无法获得表现优异的小组工作。对 75 个小组展开的一项研究表明：在小组有效运作的 每个案例 里，小组都对其目标有一个明确的理解。”

— Steve McConnell²

所有伟大的小组都有一个明确的和上升的前景。这一前景通过前景陈述的形式得到了最好的表达。尽管很简洁 — 只有一个到两个段落 — 前景陈述会描述业务的去向，以及所提出的解决方案将如何有助于实现业务价值。拥有一个长期的和不受限制的前景会激励小组克服其对不确定性的畏惧感，专注于事情当前的状态，取得应该取得的成果。

如果没有共同的前景，小组成员和利益相关人可能会在项目目标和目的的看法上产生分歧，无法形成一个具有凝聚力的小组。工作努力不协调会浪费和削弱小组的成果。即使小组生产出了交付内容，成员也将很难评估其是否成功，因为评估要依靠他们测量所需的前景。

为共同的前景而工作需要很多其他原理的应用，这些原理也是小组成功的必要因素。赋予小组成员权力、职责、沟通，以及关注业务价值等原理中的每一个，都在成功到达共同前景这一困难的和无畏的工作中起到了重要作用。对为共同的前景而工作的需求是如此重要，以至于 Jim 和 Michele McCarthy 在其著作 Software for Your Head³ 中提供了一个路标，用于有效地和反复地将小组带往共同的前景。

MSF 里的共同前景

共同的前景是 MSF 小组和过程模型里的一个关键组件，它强调理解项目目标的重要性。当所有的参与者都理解了共同的前景并为之而工作的时候，他们就能够通过这一前景来表达更加宽泛的小组目的，进而调整自己的决定和工作重点（代表他们角色的观点）。MSF 过程模型的这种反复性要求有一个共同的前景存在，以便指导解决方案朝着最终的业务结果前进。没有这一前景，解决方案的业务价值就只会走向平庸。

项目的共同前景是小组工作的基础。建立这一前景的过程会有助于明确目标，减轻并解决可能发生的冲突和错误。一旦达成一致，前景就会激励小组前进，并帮助确保所有的努力都服务于项目目标。它会提供一种测量成功的方式。明确并承担共同目标是如此重要，以至于它成为了任何 MSF 项目第一阶段的主要目标。

赋予小组成员权力

“在最优秀的小组里，不同的个人会在不同场合下体现出其领导能力，他们会在其专长的领域里担负起领导职责。没有哪个人是永远的领导，因为如果这样的话，这个人就无法和其他人融为一个整体，而小组的互动会因此而开始分裂。小组的结构应该是一个网络型的而不是一个层次型的。”

— Tom DeMarco 和 Timothy Lister⁴

在确定性是标准、且每个个人的贡献都是规定好的和可以重复的项目里，被较少赋予权力的小组会生存下来并取得成功。但是，即使是在这样的情况下，解决方案潜在的价值也不太可能达到所有的小组成员被赋予权力时能够达到的水平。缺乏权力的赋予不仅会扼杀创造力，而还降低士气，阻碍建立表现出色的小组的能力。挑出个人来进行奖励或者责问的组织将会破坏赋予小组权力的基础。

在一个高效的小组里，所有的成员都被赋予权力以便根据他们自己的承诺交付任务，并且充分信任小组的其他成员也能实现各自的承诺。类似的，客户也能够认为小组将会兑现其承诺，并进行相应的规划。支持和滋养被赋予权力的小组和小组成员，建立起这样一种文化可能是极具挑战性的，这需要组织的承诺。在 The Empowered Manager⁵里，Peter Block 把权力的赋予叫做“自我兴趣的启迪”，并把它描述成为表达和推动我们朝着这一方向前进的承诺。

MSF 里被赋予权力的小组成员

权力的赋予对 MSF 有着深远的影响。MSF 小组模型建立在同级小组的概念以及这种小组成员所暗含的权利赋予本质之上。被赋予权力的小组成员认定他们自己以及其他每个人都对项目的目标和交付内容负有责任。被赋予权力的小组成员都接受项目风险管理和小组就绪管理的职责，因此能够预先就对这样的风险和就绪进行管理，以便尽最大可能确保项目成功。

创建和管理日程安排提供了另一个赋予小组权利的例子。MSF 主张从下到上日程安排方法，这就意味着正在工作的人要承诺它会在什么时候被完成。这样做的结果就是一个能够得到小组支持的日程安排，因为小组相信自己。MSF 小组成员确信，任何延迟都会在它们被发现的时候被报告，这样就让小组领导能够去扮演一个更具推动性的角色，从而在最关键的时候提供指导和帮助。对过程的监视被分布在小组里，成为了一项支持性而非控制性的活动。

建立清晰的职责和共同的责任

“每个［小组］成员与小组之间的关系都必须根据可能的角色以及角色所产生的结果来定义。最终，小组的任何努力都会归结为个人的责任和职责。”

— Carl Larson 和 Frank LaFasto⁶

无法实现对项目职责和责任的清晰理解常常会导致重复的工作或者交付内容的缺失。这些都是功能紊乱的小组的症状，尽管这些小组投入了大量的精力，但是他们还是无法取得进步。同样具有挑战性的是专制地运行项目，这样会扼杀创造性，将个人的贡献将到最低，并使小组失去权力。在人力投资是主要资源的技术项目里，这是失败的主要原因。

跨职能小组的成功都具有清晰的职责和共同责任，这在 Larson 和 LaFasto 的一次详尽研究里有详细的文字证实。⁷ 他们的研究显示：建立对职责和责任的充分理解会减少与“谁、什么、什么时候，以及为什么”相关的不确定性，其结果就是执行变得更加有效和回报也更高。

MSF 里的职责和责任

MSF 小组模型基于这样一个前提，即小组里的每个角色都代表了对项目的一种独一无二的观点。但是，对于项目成功而言，客户和其他利益相关人需要一个对项目状态、行动和当前问题等信息的权威来源。为了解决这一问题，MSF 小组模型把对各种利益相关人的清晰角色职责与实现这个项目成功的整个小组的责任结合起来了。

小组的每个角色对小组本身以及各自的利益相关人都是负有责任的，以取得角色的高质量目标。从这个意义上讲，每个角色对于最终解决方案的质量都负有责任。同时所有的职责都要在小组的同级之间共同分担，因为任何小组成员都可能导致项目的失败。它是相互依存的，原因有两个：首先，需要这样，因为把每个角色的工作分隔开来是不可能的；其次，出于优先的原因，因为如果每个角色都了解全局情况，那么小组的效率会更高。这种相互的依赖性会鼓励小组成员对由他们责任的直接区域以外的工作作出评论和贡献，以确保小组所有的知识、能力和经验能够被应用到解决方案里。

关注交付业务价值

“经验教会托马斯·爱迪生把商业和技术结合到一起。爱迪生取得第一项发明专利的‘电子选票记录器’能够快速地记录选票，原先专门用在立法机构里。但是当他向国会委员会推销这个发明的时候，委员会的主席告诉他说：”年轻人，这就是我们不想要的。“（它会破坏阻止议案通过的神圣制度。）他的机器从来都没有投入生产，所以他决定不再把他的精力放在那些缺乏‘商业需求’的任何东西上。“

— Randall E. Stross⁸

忽略、匆忙地或者没有经过深思熟虑就定义项目业务价值的项目会在以后的阶段备受煎熬，因为项目的持续推动力会变得很模糊和不确定。没有目的的行动让想要获得有成效的结果变得很困难，并最终失去小组这一层的和组织内部的动力。这可能会导致错过交付日期，或者交付甚至无法满足客户最低要求的东西，或者干脆项目被取消。

通过把注意力放在改进业务上，小组成员的活动将变得更有可能去做他该做的事情。Tom Peters， Thriving on Chaos 的作者，常常声称组织和小组必须维持一个“业务思想”的氛围。⁹ 尽管很多技术项目都把精力放在技术的交付上，但是技术不是为了技术本身而交付的 — 解决方案必须提供切实的业务价值。

MSF 里的关注交付业务价值

成功的解决方案，无论它们是针对组织还是个人的，都必须满足一些最基本的需要，并向购买者交付价值或者利益。通过把对业务价值的关注与共同的前景结合起来，项目小组和组织能够清晰地理解为什么项目会存在，以及如何以对组织业务价值的形式来衡量成功。

MSF 小组模型主张小组的决定应该以对客户业务的充分理解以及客户在项目过程中的积极参与为基础。产品管理和用户经验这两个角色分别代表着客户和用户对小组的主张。这些角色常常由业务和用户群的成员来承担。

不到被完全部署到生产（环境）里并被有效地使用，解决方案就无法提供其业务价值。由于这个原因，MSF 过程模型的生命周期把开发和部署包括进解决方案的生产里，从而确保业务价值的实现。将强大的、小组对业务的多维表示同对过程中对业务影响的明确关注结合起来，就是 MSF 确保项目满足技术前景的方式。

保持灵巧，预测变化

”思维活跃的经理们知道，在碰到不确定性的时候才去要求确定性是不正常的 。他们会为创造力和创新力的踊跃发展设定目标和约束。“

— Jim Highsmith¹⁰

传统的项目管理方法和”瀑布“式的解决方案交付过程模型会假定某一层次的可预测性，在其它行业里很常见的这一点在技术项目里却不是很常见。常见的情况是，交付的结果和方式都没有得到很好的理解，而探索成了项目的一部分。组织越是寻求将技术投资的业务影响最大化，他们就越可能步入新的领土。这片新的土地本来就是不确定的，随着探索和试验带来新的需要和方法，解决方案必须顺应新的变化。在面对这种不确定性的时候要假装或者要求确定性（至少）将会是不现实的，或者（至多）是不正常的。

MSF 里的灵巧性

MSF 主张技术项目的 混乱有序 (chaordic) （即混乱和有序的结合，这个词由 Visa International 的创建者和前执行总裁 Dee Hock 发明）¹¹ 的本质。它的一个基本假设是，连续的变化应该能够被预计到，而把解决方案交付项目与这些变化隔离开来是不可能的。例如，它认为项目要求可能从一开始就很难说清，而且它们常常会随着参与者把可能性看得越来越清楚而发生相当大的修改。

MSF 已经将其小组和过程模型设计成能够预计和管理变化的形式。MSF 小组模型通过在关键决策中实现所有小组角色的参与从而加强了处理新挑战的灵巧性，因此确保了从所有重要的角度去探索和审查这些问题。MSF 过程模型通过其构建项目交付内容的反复方法，提供了交付内容在每个发展阶段的状态的清晰状况。小组能够更容易地认清任何变化的影响，并有效地处理它，将任何负面效应降到最低，同时将利益最大化。

近几年来，产生了一些开发软件的专门方法，这些方法致力于将灵巧性的原理和为变化而做好准备的原理最大化。有了这一理念，MSF 会鼓励在合适的地方应用这些方法。MSF 和灵巧方法将在本白皮书后面的章节里进行讨论。

质量投资

”提高质量是一个永无止尽的历程。没有所谓最高质量的产品或者服务。所有的质量都是相对的。每一天，每件产品或者每项服务都在变得相对更好或者相对更差，但是它从来都不是静止不变的。”

— Tom Peters¹²

质量，或者由此而产生的质量不佳，能够以多种方式定义。质量可以被简单地当作是产品稳定性的直接反映，或者被看作是交付、成本和功能的复杂综合体。但是无论你怎么定义它，质量不是什么突然就发生的事情。只有明确的投入努力才能够确保质量被融入到组织所交付的产品或者服务里。

所有产业的发展都来自对质量的追求，这已经得到了质量管理系统里大量的书籍、教学、理论和方法的证明。有效地提高质量就需要在过程、工具和质量指导方针上的不断投资。提高质量的所有努力包括定义一个过程，用来通过对成果的详尽评估，即测量，把质量融合到产品和服务里。用测量工具来实现这些过程会通过发展结构和一致性来强化它们。

最重要的是，这样的努力会激励小组和个人发展出一种围绕提高质量的思想概念。人们会因为其工作、学习和获得权力而感到骄傲，而提高质量意识就是对的这种基本渴望的一种补充。

因此对提高质量的投资就成为了对人员以及过程和工具的投资。成功的质量管理程序认同这一点，并把质量融入到了组织的文化里。它们都强调对质量进行持续投资的需要，因为对质量的期望会随着时间的推移而不断提升，在原地踏步不是一种可行的选择。

MSF 对质量的投资

MSF 小组模型要求小组里的每一个人都要对质量负起职责，同时承担起测试过程管理的角色。测试角色会鼓励小组在项目期间进行必要的投资，以确保质量水平能够满足所有利益相关人的期望。在 MSF 过程模型里，由于项目交付内容是逐步生产和审查的，所以测试就成为了质量的一部分 — 它从项目生命周期的第一个阶段开始，并延续到其五个阶段的每一个。该模型定义了关键里程碑，并提出了中间里程碑，供测试角色和利益相关人使用小组建立的质量标准对解决方案进行测量。对这些里程碑进行检查可以确保对质量的不断关注，并为在必要的时候进行中途的修正提供机会。

把质量融入到产品和服务里的一个重要因素是学习环境的发展。MSF 通过就绪管理准则来强调学习的重要性。为小组工作而获取合适的技能代表着一种投资；生产工作之外的时间加上课堂培训、课件、辅导，甚至是咨询，可能会是一笔相当大的费用。就绪管理准则通过让成员获得合适的技能来直接对小组进行投资，因为它基于这样一种想法，即对技能的投资会转化成质量的投资。

学习所有的经验

“那些忘记过去的人肯定会重复过去（的错误）。”

— George Santayana¹³

当你看到技术项目成功率的增长微乎其微的时候，当你认为失败的主要原因没有随着时间的推移而改变的时候，那么可能的情况是：在这样一个行业里，我们无法从（过去）失败的项目中学到教训。在资源有限、期限紧迫的情况下花时间去学习对于小组和利益相关人来说是很困难的，而要去证明其合理性则更困难。但是，不去从所有的经验中学习东西肯定会让我们重蹈覆辙，并自食其后果。

捕捉和共享技术和非技术的最佳做法是不断提高和不断成功的基础，因为它：

支持学习环境的做法有很多。Peter Senge 的 The Fifth Discipline: The Art and Practice of the Learning Organization¹⁴ 是关于建立学习文化的最早书籍之一。他最近的一本书 The Dance of Change,¹⁵ 就是基于他早期的工作。他的书中收入了个人和小组的实践，对该领域里让经理和领导者进行持续学习的倡议进行了深度的说明，并提出了经过充分检验的实际建议。

MSF 里学习所有的经验

MSF 认为，通过学习把精力放在不断提高上会带来更大的成功。从一个项目获取的知识能够成为下一个项目里其他人可以利用的东西，这样就会减少因为信息不足而造成的决策的不确定性。在 MSF 过程模型里对里程碑进行有计划的审查会帮助小组来进行中途的修正，避免重复（过去的）错误。此外，捕捉和共享这一知识可以从工作良好的事物中创造出最佳做法。

MSF 强调在组织或者企业这一层次从项目成果中学习的重要性，它建议对项目进行事后检查，将项目的成功之处以及对成功作出贡献的小组和过程的特点付诸于文字。当从多个项目学到的知识在开放沟通的环境里进行共享的时候，小组成员之间的互动就会有一个向前的、能够解决问题的前景，而不是一个自身倒退和相互责难的未来。

返回页首

MSF 模型

MSF 模型代表了上述基础原理在技术项目的“人员和过程”方面的应用 — 人员和过程对项目的成功与否具有最重要的影响。MSF 小组模型和 MSF 过程模型是图解式的描述，用来从视觉上显示角色群周围的项目小组的逻辑组织，以及项目生命周期过程中的项目活动。这些模型将基础原则具体化了，并融入了核心规范；它们的细节经过了关键概念的提炼，它们的过程通过成功的做法和建议得到了应用。随着每个模型都得到了描述，底层的基础原理和规范就能够被认识到。

MSF 小组模型

MSF 小组模型定义了小组同级成员的一些角色和职责，这些成员都在以相互依存的跨学科角色进行信息技术项目工作。下面的图表对该模型的逻辑进行了描述。

图 2：MSF 小组模型

MSF 小组模型基于这样一种前提，即任何技术项目都必须达到特定的关键质量目标才能够被认为是成功的项目。达到每个目标都需要相关的、不同技能及知识领域的应用，它们每一个都包括在一个小组角色群（通常被简称为角色）里。相关的技能和知识领域被叫做基础领域，它们定义了每个角色的域。例如，程序管理角色群包括项目管理、解决方案体系结构、过程保证和管理服务等职能领域。总体来说，这些角色都具有这样的广度来满足项目成功的所有标准；如何任何一个角色无法实现其目标，这都会将危及整个项目。因此，这个同级小组里的每个角色都被认为是同等重要的，重要的决定都要共同作出。相关的目标和角色见下面的表格。

表 1：MSF 小组模型和关键质量目标

MSF 小组模型是行业里用于被赋予权力的小组工作和技术项目的最佳做法的汇编，它把重点放在了取得这些目标上。它们然后被应用到 MSF 过程模型里，以概括活动并创建小组所要生产的具体交付内容。这些主要的质量目标会定义和推动小组进行工作。

要注意的是，一个角色不同于一个个人 — 多个人员可以担当一个角色，或者一个个人可担当多个角色 — 例如，在模型需要缩小规模以适应小型项目的时候。在采用 MSF 小组模型上重要的一点是，所有的 质量目标 都应该在小组里体现出来，而且项目的各种利益相关人都应该知道项目里的哪个人在负责质量目标。

MSF 小组模型解释了这些角色的组合能够如何被用来扩大规模以便利用大量的人员来支持大型的项目，即通过定义两种类型的子小组：职能小组和特性小组。职能小组是由职能角色组织起来的单领域子小组。开发角色常常有一个或者多个职能小组来承担。第二种类型是特性小组，它们是跨专业的子小组，把主要精力放在构建解决方案的特定特性或者能力上。

MSF 小组模型可能是 MSF 里最与众不同的部分。小组模型的核心是，技术项目必须符合各种利益相关人完全不同的，且常常并列的质量观点，这包括操作、业务和用户。MSF 小组模型推动了各种观点的这种融合，因此承认技术项目不单单就是 IT 的工作。

MSF 过程模型

每个项目都要经过一个生命周期，这是一个包含项目里所有活动的过程，而这些活动的发生要到项目结束并过渡到操作状态才会结束。生命周期模型的主要

联系我们CONTACT 扫一扫

愿景：成为最专业的软件研发服务领航者
中睿信息技术有限公司 广州•深圳	Tel：020-38931912	务实 Pragmatic
广州：广州市天河区翰景路1号金星大厦18层中睿信息	Fax：020-38931912	专业 Professional
深圳：深圳市福田区车公庙有色金属大厦509~510	Tel：0755-25855012	诚信 Integrity
所有权声明：PMI, PMP, Project Management Professional, PMI-ACP, PMI-PBA和PMBOK是项目管理协会(Project Management Institute, Inc.)的注册标志。

版权所有：广州中睿信息技术有限公司 粤ICP备13082838号-2