介绍
为了在整个 IT 生命周期中将 IT 项目及其操作的成效最大化，Microsoft 解决方案框架和 Microsoft 操作框架 (MOF) 提供了指导文档和各种成功做法。通过它们，小组可以实现有效的规划、构建、部署和操作解决方案。这些信息来源于微软内部进行大规模软件开发和服务操作项目过程中积累的经验、微软的顾问专家的经验，以及在世界范围内 IT 行业里通行的最佳做法，并以白皮书、指导文档、工具、模板、案例研究和课件等形式发布。这些指导和做法被组织成两个相互补充并有效整合的知识体系。
Microsoft 解决方案框架
在预算范围内按期创建一个业务解决方案需要一种经过检验的方法。MSF 为成功地规划、设计、开发和部署 IT 解决方案提供了经过检验的做法。与规定性的方法相反，MSF 提供了一个可以伸缩的灵活框架，以满足任何规模的组织或者项目小组的需要。MSF 指导由原理、模型和用来管理人员、项目和技术元素的准则（大多数项目都会碰到）组成。
Microsoft 操作框架
Microsoft 操作框架 (MOF) 提供了技术指导，从而让组织能够在使用 Microsoft 产品和技术创建的 IT 解决方案上取得任务关键系统的可靠性、可用性、可支持性，以及可管理性。MOF 的指导致力于解决人员、过程、技术和管理等问题。
关于 IT 基础结构库 (ITIL) 的更多信息 － ITIL 是 MOF 的基础，它包含了行业中最佳做法，请浏览：http://www.itil.co.uk/index.html
组队模型基础原理
MSF 组队模型经过数年时间的发展，祢补了传统项目小组自上而下的层次结构的一些不足。
按照 MSF 组队模型组织建立的小组是小型、跨学科的小组，在这样的小组中成员们共同承担各项职责，权衡彼此间能力差异，以便将主要精力集中到手头上的工作中。他们拥有共同的项目前景，以部署项目为中心，坚持高标准的质量和沟通，保持乐意学习的心态。本文描述了小组中的各种角色群，以及他们的目标和职能领域。同时提供了指导，以便使用 Microsoft 的方法根据规模和复杂性的高低来建立小组。
下面将概述应用于 Microsoft 组队模型的 MSF 的各类基础原则、关键概念和成功做法。本章以及整篇文章里的各种主要思想将被重点标出，并将作 MSF 组队模型的细节进行讨论。
MSF 基础原理
MSF 包括一些基础原理和框架方法的里程碑。本部分中与成功的小组相关联的一些原理将被重点标出。
清晰的责任，共同的职责
MSF 将工作进行中需要共同承担的职责和确保工作如期完成需明确的工作责任结合起来。
MSF 组队模型基于这样一个前提，即小组里的每个角色都代表了对项目的一种独一无二的观点，但是没有哪个个人能够完全代表所有的不同质量目标。为了解决这一问题，MSF 组队模型把对各种利益相关人的清晰角色职责与实现这个项目成功的整个小组的责任结合起来了。
在小组内部，每个角色通过对小组本身负责（也对他们各自所属的组织负责）实现该角色的质量目标。在这种意义上，每个角色都对最终解决方案质量的一部分负责。小组成员之间共同承担职责（根据不同小组角色指派）。角色之间是相互依赖的，有以下两个原因：首先，就其必要性而言，因为把每个角色的工作分隔开来是不可能的；其次，出于优先的原因，如果每个角色都了解全局情况，那么小组的效率会更高。这种相互的依赖性会鼓励小组成员对由他们负责的直接区域以外的工作做出评论和贡献，以确保小组所有的知识、能力和经验能够被应用到解决方案里。项目的成功属于所有的小组成员；他们共同分享一个成功的项目所带来的荣誉和回报，他们也同时希望，即使是一项不太成功的项目，也能做到全心投入并从中吸取教训以完善他们的专长。
赋予小组成员权力
在一个高效的小组里，所有的成员都被赋予权力以便根据他们自己的承诺交付任务，并且充分信任小组的其他成员也能实现各自的承诺。类似的，客户也能够认为小组将会兑现其承诺，并进行相应的规划。在最坏的情况下，小组也应该尽快地告知客户项目出现了哪些延迟和变化。
MSF 小组赋予小组成员权力以帮助他们履行承诺。反过来，MSF 小组又要依赖所有小组成员的整体配合和动力来：
| • |
准备好向其他成员作出允诺。 |
| • |
清楚定义自己担负的承诺。 |
| • |
做出一切合理的努力交付承诺的工作。 |
| • |
发现承诺陷入危机时进行真诚的沟通。 |
由于每个参与者的工作都要依赖于其他小组成员的工作，所以一旦一项活动需要一个以上的小组成员参与，那么他的工作就要受到其他成员工作的影响。然而，小组成员不会花时间监视他们的各项工作是否会对别的小组成员产生影响。有效的小组会逐渐形成一种信任，他们了解同事被授予权力正在履行实现小组目标的承诺。
拿接力队打个比方。在接力队中，当第二棒的运动员起跑的时候，他不会减速也不会向后看究竟前一队员离他有多远，他只会集中精力全力加速，跑完赛程后回头接棒，并且他有信心可以从队友手中顺利拿到接力棒。这种信心来源于做法、经验和信任。
在一个复杂的项目中，小组成员需要逐渐形成一种同级信任，这种信任会在实现每项承诺（无论大小）时建立。下面给出了形成这种信任的一些简单指导思想：
| • |
赋予小组成员权力，让其承担指派的承诺。这种授权包括向小组成员提供进行工作所需的各种资源；负责制定决策以有效影响队员的工作；理解队员的权力界限，并不断增加各种可用途径来处理越权问题。 |
| • |
准备好向其他成员允诺。这些准备包含了心态（进行面谈并乐意采取行动）、就绪，并理解承诺的内在含义以及它对当前工作量和资源的影响。这样做的结果就是，不到小组成员清楚承诺的内在含义，就不要作出承诺。相反，小组成员要提出一个更小的、他们能够理解的承诺，例如对这些承诺的内在含义进行研究，然后再迅速坚定地作出承诺。对较小承诺的成功交付将建立小组的信任。 |
| • |
清晰定义自己担负的承诺。这样可以避免一些可能会导致小组成员间信任危机的误会。 |
| • |
做出一切合理的努力来交付承诺的工作。如果一个小组有来自不同组织的成员，那么合理的期望也将因人而异。例如，某些小组成员可能认为在周末工作是合理的；而其他人则可能将他们视为例外或者可能在周末几乎不会去上班。 |
| • |
发现承诺陷入危机时进行真诚的沟通。有时将无法避免事情的变化，原因可能是某些任务的优先级调整、一个意外事件或仅仅是因为一项工作延期完成。及早的进行沟通将使与之相依赖的其他小组成员可以有机会制定相应的计划。也许他们还可以提出解决这些问题的途径。 |
在大多数组织中，这些行为与企业文化是融合在一起的，队员们已经将它们视为一种文化，因此很少讨论它们。但是，MSF 小组有时需要与不同的组织一起工作，在这些组织中的相关的价值观念并没有被完全地了解和注重。这些组织常常呈现出一种高度推诿的文化，这种文化约束着应该开放的信息流。在这些情况下，小组领导应当根据这一点来清楚地陈述他们的期望并帮助新的小组成员适应这种工作方式。
聚焦业务价值
MSF 组队模型提倡将小组决策建立在小组对客户业务全面的认识以及项目交付过程中客户能动的参与之上。产品管理角色在小组中担当客户的拥护者，这个角色常常由客户组织中的成员来担任。产品管理有其业务案例，这些案例保证了从初期战略工作开始的连续性。产品管理职责的一部分是确保关键的项目决策建立在一个健全的业务认识基础上。
发布管理角色会确保顺利的部署和各项操作。通过这些工作，该角色在解决方案开发、部署以及不断进行的各项操作之间起桥梁作用，它确保项目交付组时刻了解其决策在产品操作过程中对价值交付的影响。
共同的项目设想
MSF 全力提倡采用一个共同的设想，以便把注意力放在小组的工作方法上，包括在一个操作环境里交付 IT 解决方案或是提供 IT 服务
对项目和过程的目标有一个清晰的了解是很重要的。因为小组成员和客户都在猜测这项解决方案能为组织做些什么。一个共同的设想将使这些猜测明确化，并确保所有参与者都在为完成相同的目标而努力着。共同的设想是 MSF 组队模型的基础之一。
当所有的参与者都了解了这一设想并朝着这一设想工作的时候，小组便能够根据成员使自己的决策与这一设想体现的更为广阔的小组意图相吻合，从而获得他们的权力。
没有共同的设想，小组成员可能出现与目标相抵触的观点，作为一个团体的交付将变得更加困难。并且即便小组完成交付，小组成员也很难确定自己的成功，因为这种成功依赖于他们评价成功的设想。
保持灵活，预测变化
MSF 认为事情在不断发生变化，将一项 IT 解决方案交付项目与这些变化相孤立是不可能的。MSF 组队模型确保所有核心的准则在一个项目的始终可用性，这些核心准则将有助于由各种变化引出的各项决策。当新的变化产生，MSF 组队模型将强化解决这些问题的灵活性。所有小组角色对决策制定的贡献确保了对问题的深入研究，确保了以批判的观点对问题进行探讨。
推动开放式沟通
从历史上看，许多组织和项目的操作单纯以需要认识为基础，它将频繁地导致误解同时影响了小组交付一项成功的解决方案的能力。
MSF 提出一个开放式的真诚的沟通方式，这种沟通存在于小组内部以及小组与关键利益相关人之间。开放的信息流不仅减少出现误解与成效耗损的频度，而且确保了所有小组成员可以降低项目周边环境中存在的不确定性。
同级小组的方法涉及了在关键决策中的所有角色。它是共同的小组设想被视为解决方案交付过程的基本开端的原因之一。它也是 MSF 风险管理的基础，MSF 风险管理全力提倡所有小组成员运用风险意识辨识问题和分析问题，提倡促发一个无推诿的文化环境来实现风险管理。开放的、真诚的讨论做好工作的标准以及应该如何改进工作提供了 MSF 寻求营造的学习环境的基础。
有一些重要的因素可能抑制小组交流的开放性，例如个人和业务信息的机密性。然而，小组成员在决定保留这些信息时应该认真询问自己，以保证保密的原因确实是不可置疑的。如果小组成员已经通过开放的交流建立了信任关系，并且在大多数场合上都开诚布公，那么他们便能够向同事解释之所以这样做是因为存在高于一切的理由，并且让同事相信这些理由是以实现项目的最大利益为基础的。
关键概念
MSF 组队模型的成功实现存在几个特征。在本部分，这些特征已经被列出并作为关键概念进行阐述。
同级小组
“同级小组”这一概念寄予了每个角色同等的价值。它实现了角色间的自由交流，强化了小组的责任观念，补充强调了六个质量目标都是同等重要且必须实现的。为成功实现平等的小组，每个角色都必须对产品质量负责，必须以客户的角度思考，必须清楚正试图解决的业务问题。
虽然每个角色对小组的价值都是相同的，小组的平等存在于角色 之间 ，并且不应该与受多数意见驱动的决策相混淆。每个角色需要某种内部组织层次实现分配工作和管理资源的目的。当小组成员集中精力实现他们各自的目标时，每一个角色的小组领导人都有责任管理、指导和协调小组。
以客户为中心
满足客户对任何优秀的小组来说都被看作是第一位的。在整个开发过程中，以客户为中心包含了小组对了解和解决客户业务问题的承诺。衡量以客户为中心的理念体系获得成功的方法之一是能否使设计中每一个特性都符合客户和用户需求。同样，实现客户满意度的一个关键方式是使用户积极地参与设计并在整个开发过程中提供反馈意见。这样，小组和客户都能的使期望和需求更加吻合。
产品理念体系
产品理念不是关于将业务软件推向市场（像 Microsoft一样）或是只为内部客户开发应用程序。产品理念是将您的劳动成果看作产品的理念
实现产品理念的第一步是认识您正进行的工作，它本身是一个项目也是一个大型项目的一部分。事实上，MSF 提倡项目标识的创造，这样小组成员将更少的将自己视为个体，而更多的视为一个项目小组的成员。Microsoft 使用的一个方式是为项目代码取名字。这将有助于清楚的标识项目，清楚的标识小组，强化责任意识并且形成提升小组士气的机制。将小组项目代码名印制于 T 恤衫、咖啡杯和其他与团体有关的小礼物上也是创造和强化小组标识和灵魂的一种方式。如果小组是由一个组织中的来自多个不同群体的要素组成的“虚拟小组”，这将尤其有用。
一旦您清楚正为一个项目工作，那么无论最后它可否交付，您都应该把它看作是一个产品。那些应用于创造产品的原则和方式（就像 MSF 所提倡的那些）可以被用来帮助确保您的项目成功的交付。
拥有产品理念同时意味着将更多的精力投向执行过程和项目结束时要交付的成品上，而不是投向如何取得这一效果的过程。但这并不意味着过程是无利的或是不重要的，这样做意味着过程应该为最后的目标服务而不单单只为了利用过程。采用产品理念，小组中的每一个人都会感到背负着产品交付的责任。
前任微软程序经理 Chris Peters 描述了应用于软件开发中的产品理念，下面是他在 1991 年所作的讲演的摘录：
“每个人……确切的说都在做相同的工作。他们有相同的工作描述。那就是售卖产品。您的工作不是写代码，不是进行测试，也不是书写规格书。您的工作就是售卖产品。这正是产品开发小组做的工作
”您作为开发者或是测试员的角色是次要的。我并不是说这就不重要了 － 很显然是重要的 － 但是对您真正的工作来说它是处于次位的，而您真正的工作是售卖产品。”
“当您在清晨醒来并投身工作，您说，“工作中心是什么 － 我们正试图售卖产品还是编写代码？”答案是，我们正试图售卖产品。您并不是试图去编写代码，您应该不仅仅只是编写代码。
零缺陷
在一个成功的小组中，所有成员都感到要对产品的质量负责。产品质量责任不能由一个小组成员委托给另一个小组成员或部门。同样，每个小组成员都要作为客户的拥护者，在整个开发周期中考虑最终产品的可用性。
零缺陷理念是对质量的承诺。这意味着小组的目标是尽可能最高效地执行工作，这样即使不得不在明天就交付产品，他们也可以交付出一些东西。这个想法是让每一天都有一个接近可交付的产品。这并不意味着交付不存在任何缺陷的代码；这意味这产品满足或超出了项目出资人的质量要求并在预想阶段被小组接受。
用自动机车装配线作类比最有力的描述了这一概念。传统上，工作人员将汽车由单独的部分组装起来并且为他们自身的质量负责。当汽车下线，一名检查员进行检查并判断该汽车的质量是否达到售卖的标准。然而在这个过程的后期，大量的时间将花费在查找所有的问题上，因为在此时进行纠错是极富价值的。同样，既然质量是不可预计的，在后期决定产品是否可售卖所需花费的时间也是不可预计的。
在当前的汽车制造业中，质量已经成为了“第一工作”。这意味着当工作正在进行时（例如正在装配一扇车门或是安装一部收音机），检查员同时审查该项工作以确保它符合为标准的汽车所定义的质量标准。只要在整个装配过程中保持该级别的质量，那么在后期为确保这辆汽车的质量可接受只需要花费更少的时间和资源。这使生产过程更可预测因为检测员只需要检查各个部分的整合处而不是所有个别的工作。
乐意学习
乐意学习包括了对通过收集和共享知识保持自身发展的承诺。它使小组成员可以从犯错中吸取教训，也使成员们通过实现他人的成功做法而获得连续的成功。进行里程碑的温习回顾和无指责的事后剖析检讨是 MSF 过程模型的组成部分，它们帮助小组进行交流沟通。小组在进度表中安排时间进行学习、回顾和事后检讨，这样做创建了一个持续进步和赢取不断成功的环境。此外，微软成功地建立一种乐意学习的文化，它将学习和知识共享作为个人回顾目标的一部分。
有动力的小组有效率
缺少动力的小组效率低下来自于两个原因：从个人上说，小组成员表现不佳导致输出质量和数量的低下；小组成员在狭隘的目标指导下工作，没有意识到他们的工作将对同事产生的影响。 IT 项目是以高度的知识输出和相互作用为基础的。因此这两个因素对 IT 项目带来严重的负面影响。
MSF 提倡付出努力激发小组的士气和动力。而在微软从事工作的人们都将其视为公司定义的特性之一。用来激发小组动力方法有：
| • |
明确小组设想。 |
| • |
构建小组标识，使用项目代码名字和小组特别物品 — 如吉祥物、T 恤衫、酒杯等等。 |
| • |
花时间通过社交和小组活动慢慢了解您的同事。 |
| • |
制定计划确定进行小组建设会议的地点，在那里小组成员能够体验各种不同方式的合作和互动，这一地点通常选择在工作环境之外。 |
| • |
确保尊重个人目标，例如提供机会进行个人能力或技术能力发展，协调小组成员工作和生活的权衡。 |
| • |
让小组成员最大的感到授予了权力并积极听取他们的想法。 |
| • |
庆祝成功。 |
成功的做法
以下成功的做法对 MSF 小组的每个成员有共同的作用，这些做法确保队员们持续的专注于成功。
小型的多学科小组
小型的多学科小组具有与生俱来的优势，他们相对与大型的小组具有更迅速的响应能力。因此，对于大型的项目小组来说，在小组中创建小组的效果将更好 － 由多个更小的工作组并行工作。一些小组成员具有在特别领域内的专业知识或对特别领域有清晰的了解，他们应在需要的时候在控制下被授权行动。
在小组内部甚至在一个角色群内存在多重学科，这种多重学科要求了一套明确的技能。拥有不同的职业背景、受训情况和专业领域并组成小组或角色的人都能参与负责整个的产品质量，这取决于他们向各自的角色以及最终向整个解决方案引入的同一的全景设想。
一起工作
组队模型的目标之一是使沟通不再高不可攀，这样小组便能减少进行有效交流的障碍。除了小组结构，小组的地理分布和场所位置在小组内部和外部交流的有效性程度上起着主要的作用。
在他们对 Microsoft 的研究中， Microsoft Secrets, Michael A. Cusumano and Richard W. Selby 如此陈述：
“……单一地点的开发提供了项目参与人员在地理上的一个不变动的地域，他们可以集合在一起并且相互交流探索各种想法。频繁而易于实现的沟通将使较大的问题不至于变得更糟。
将小组集合在一起工作也有助于加强小组标识和小组联合的意识。
选择共同的工作场所被以往的经验证明是促进开放的交流的最有效率的方式，工作场所可以选择在大楼的同一区、共用的办公间或是特别为小组成员集合选定的空地旁的环境。开放的交流是 MSF 小组规则中一个获得成功的基本要素。
虽然共同的工作场所仍是首要选择，但是业务性质和可供利用的促进交流的技术使得“虚拟”小组得以成功。
在虚拟小组中，小组成员主要依靠电子手段相互交流和协作。交流跨越了组织边界、空间和时间。与同事通过 Internet 进行实时的合作深远地改变了人们工作和共享信息的方式。Internet 正成为小组成员间交流的新标准，同时，协作软件为将来提高工作效率铺平了道路。
虚拟小组的观念是关键，因为没有了将各种规则集合成一个协调单元的组织边界，小组的虚拟性要求小组具有更强的交流能力，信赖协议与关系，使行动项目不至于迷失方向的清晰的行动计划和支持项目与任务跟踪的自动化工具。
虚拟小组中的潜在要素是每个角色通过依赖和信任其他角色而履行职责的能力。这种能力的培养来自于文化的交融、良好的管理以及当需要时在相同的地点一起工作的方式。
行业研究发现虚拟小组成员往往不注重交流的技巧和小组和谐。分析师认为这种疏忽是许多虚拟小组失败的关键因素。如果要建立一个虚拟小组，请任用具有以下特征的队员：
| • |
能够独立工作。 |
| • |
显示出领导技能。 |
| • |
拥有开发解决方案需要的特别技能。 |
| • |
能够与组织分享知识。 |
| • |
能够有助于发扬有效的工作方式。 |
全员参与设计
每个角色都应参与撰写产品规格说明书的工作，因为每个角色都对设计以及设计与个人目标、团体目标之间关系存在着特别的观点。因而孕育出一种氛围，使来自不同观点中的最优秀的想法能够显露出来。
组队模型概述
为了使一个项目取得成功，必须实现六个关键的质量目标，这种理念是 MSF 的基础。这些质量目标驱动小组并定义了组队模型。虽然整个小组都对项目成功与否负责，组队模型还是将六个质量目标和分离的角色群联系起来以确保义务分明和中心明确。
组队模型的六个角色群 － 产品管理、程序管理、开发、测试、用户体验以及发布管理 － 定义了确定职能领域以及和他们相关联的职责的通用方式。角色群常常仅仅被看作多个角色。无论那一种解释，这个概念是相同的：解决方案框架和组队模型是可伸缩的，以满足构建一个特别的解决方案的需要。一个角色或是一个角色群，可能包含一个人员或许多人员，这依赖于一个项目的大小和复杂程度，依赖于为完成功能区内的职责而需要具备的各项技能。
MSF 组队模型强调将各个角色群与各项业务需求相校准的重要性。角色分组和职能领域与各项职责相联系，职能领域和各项职责分别要求有不同的规则和重心。角色分组为一个协调良好并且各项技能和观点代表了所有基本项目目标的小组带来了动力。拥有一个清晰定义的目标将促进对各项职责的理解并且鼓励项目小组控制项目，这将最终带来一个更优质的产品。既然每个角色对项目的成功都有决定性作用，那么代表了这些目标的角色在决策时是平等的，具有均等的发言权。
请注意，这些角色群并不表示任何形式的组织机构示意图或是工作职位调整，因为这些角色群将随着组织和小组的变化而产生很大的改变。更常见的是，角色将分布在 IT 组织内部的不同组群之间，有时还可能分布于业务用户社区或者外部的咨询师和合作伙伴中。关键在于清晰的确定履行某一特定角色群的小组个体以及与之相关的有助于目标实现的各种功能、职责和分布。
| 角色群 | 目标 | 职能领域 | 职责 |
|
产品管理 |
满足客户 |
市场开发 业务价值 客户拥护 产品计划 |
作为客户的拥护者 驱动共同的项目和方案设想 管理客户需求说明 开发和维护业务案例 管理客户期望 驱动产品特征、日程表、资源权衡决策 管理市场开发、产品宣传和公共关系 开发、维护和执行交流计划 |
|
程序经理 |
交付满足项目约束的解决方案 |
项目管理 解决方案体系结构 过程保证 管理服务 |
驱动开发过程以期按时的交付产品 管理产品规格说明书 － 首席项目构架师 促进小组内部的交流和商议 维护项目日程表和报告项目状态 驱使关键的权衡决策的实现 开发、维护和执行项目总规划和日程表 驱使和管理风险评估和风险管理 |
|
开发 |
根据规格说明创建解决方案 |
技术咨询 实现的构架和设计 应用程序开发 基础结构开发 |
指定物理设计的特征 估算完成每个特征所需的时间和精力 构建每个特征并监督其实现 准备部署时使用的产品 为小组提供技术主题的专门知识 |
|
测试 |
在所有产品质量事宜被识别并处理后进行发布 |
测试规划 测试工程 测试报告 |
确保了解所有问题 决定测试策略和制定计划 执行测试 |
|
用户体验 |
提高用户效率 |
技术交流 培训 可用性 用户界面设计 国际化 易用性 |
为项目小组充当用户拥护的角色 管理用户需求说明 设计和开发性能支持系统 驱动可用性和用户性能增效的权衡决策 为用户提供帮助特点和帮助文档的规格说明书 开展和提供用户培训 |
|
发布经理 |
进行平滑的部署及日常运行 |
基础结构 支持 操作 业务发布管理 |
作为各种操作、支持与交付渠道的拥护者 管理所得 管理产品部署 驱使可用性和可支持性权衡决策 管理各种操作、支持和交付渠道之间的关系 为项目小组提供后勤支持 |
满足客户
项目必须满足客户和用户的需求，并且以满足客户与用户需求作为成功的标准。项目可能只实现了预算和时间的目标但却没有满足客户的需要，那么这种项目仍是不成功的。
发布满足项目约束的解决方案
所有小组的一个关键目标是发布满足项目约束的解决方案。任何项目的基本约束包括预算和日程进度的约束。大多数项目使用“按时、按预算”作为评价成功的标准。
根据规格说明创建解决方案
产品规格说明详细的描述了小组提供给客户的可交付产品。精确的按照规格说明交付产品对小组来说是很重要的，因为规格说明书代表着小组与客户之间的一项协议。
在所有产品质量事宜被识别并处理后进行发布
所有的软件在交付时都存在缺点。一个关键目标是确保那些缺点在发布产品之前被确定和处理。处理涉及了从修复存在疑问的缺陷到为这些周边工作的解决方案提供文档的所有工作。相比交付一个存在未辨识缺陷而在稍后也许将惊呆小组和客户的产品，交付一个已知错误而这个错误已被处理并提供了周边工作解决方案的产品更为可取。
提高用户效率
为实现项目成功，用户工作和操作的方式必须实现改善。交付一项拥有丰富特性与内容但却无法被目标用户所操作的产品将被认为是失败。
进行平滑的部署及日常运行
有时进行平滑部署的需要会被忽视。部署的理解也被或对或错地带入了产品本身。例如，一个错误的安装程序可能导致用户认为安装好的程序也同样存在错误，既便这可能并不是真实的情况。因此，小组不应只做简单的部署；小组必须争取实现一个平滑的部署并为产品的支持和管理做好准备。这些内容可以包括在部署前确保培训、基础结构和支持的准备就绪。
组队模型角色群
产品管理角色群
产品管理角色群的关键目标是满足客户。小组必须让项目满足客户的各种需求，以实现成功。然而，首先要做的是清楚的确定和了解客户！在某些案例中，客户要求的解决方案和特性集将与项目支持和投资商的要求不同。因此小组必须进行清晰区别和需求分析，提出使双方都获益的因素。只有这样，定制和满足期望的职责才能够被指派到恰当的职能领域内。有可能项目只实现了预算和时间的目标而没有满足客户的需要，那么这个项目仍是不成功的。
MSF 组队模型为每个角色群规定了不同的职能领域以便更为精细的定义一套职责，角色通过各项职责的履行形成一套常用技能集。
为了实现满足客户的目标，产品管理角色群要求有多个职能领域：产品规划、业务价值、客户拥护和市场开发。
职能领域
市场开发
| • |
驱动销售和影响目标客户的公共关系讯息 |
| • |
高度区别化，使解决方案在竞争获得优势 |
| • |
通过零售商配销使目标客户能够容易获得产品 |
| • |
提供支持，使客户在购买和使用解决方案时有肯定的体验 |
业务价值
| • |
为项目定义和维护业务解释 |
| • |
定义和评价业务价值实现 |
客户拥护
| • |
驱动共同的项目和解决方案设想 |
| • |
管理客户期望和沟通 |
产品规划
| • |
收集、分析客户和业务需求并按优先级排序 |
| • |
执行市场研究、市场调查和竞争情报与分析 |
| • |
确定业务效绩评价与成功标准 |
| • |
确定多版本发布计划 |
市场开发
市场开发是筹划宣传、销售和配销一个产品、解决方案或服务的过程或技术。市场开发包括几个方面：启动市场、维持市场与公共关系。在一个解决方案生命周期的进程中，市场开发的中心将发生转移。了解您的解决方案在生命周期中的市场定位对执行适当的行动是至关重要的。
业务价值
在业务价值职能领域内，产品管理为客户、业务决策制定者 (BDM) 提供 他们所要求的简明的预测方法 以判断花费在一项 IT 解决方案上的投资对业务活动所带来的财务上和操作上的回报。
为有效的提供一个可用的解决方案，产品管理必须了解客户的业务活动、各种成功因素和关键工作指标。可以将获得这些知识的过程定义为业务价值评定或关键性成功因素辨识。很明显，了解使客户获得成功的方式有助于确定和提出恰当的解决方案。随着规律性的渐增，进行 IT 投资需要进行深入细致的调查，许多 IT 相关的解决方案都需要在项目停止前进行财务评议。通过进行客观的支出回报分析，满足客户的可能性将增加。财务结果的计算完善了进行 IT 投资的业务解决方案的开发。
客户拥护
这一职能领域包括了高级别交流和客户期望管理的职责。高级别交流包括了公共关系、高级管理／客户简报、市场推广、演示和产品启动。一旦项目设想被确定，期望管理将成为产品管理的关键角色。期望管理被认为是首要的角色，因为它可能决定成败。
有效进行期望管理的重要性可以用例子来描述，假如小组预期交付给用户 10 个产品特性（数据是随便给出的）。如果小组实际只交付了 2 个产品特性而不是客户所期望的所有 10 个，那么这个项目无论对客户还是对小组来说都是失败的。
然而，如果产品管理在特性开发和产品研发期间与客户维持好持续的双向交流，客户期望将得以实现而保证最后的成功。产品管理可以包括让客户参与权衡决策制定过程以及告知客户不断变化的风险和其他难题。与之前的情形不同，客户能够评估开发状态并且同意小组在指定时间能交付所有的 10 个产品特性是不现实的，而只交付了 2 个却是可以接受的。在这种情形下，交付 2 个产品特性现在符合了客户的期望并且双方都会认为这个项目是成功的。
产品规划
产品规划确定了为解决方案的多个版本所设定的要求和特性。产品规划的目标是使程序经理或开发人员尽可能以最少的时间更容易地理解一个解决方案的要求。首先，它要求完全理解解决方案的当前要求 － 业务需求是什么，客户如何使用该解决方案，支持的要点有什么以及有哪些可用的供选择的方案。其次，检查那些为使用该解决方案的客户实现增值的特性，例如实现新业务内容的入口、与其他系统的集成、更优良的工作效率、从其他解决方案上升级、减少支持费用等等。以这些知识为基础，产品规划员能够推荐出指派给每个解决方案版本的特别的特性并且为这些特性按优先级进行排序。
产品规划的核心是研究和分析。了解客户和业务的需求以及竞争状况，并给予研究和分析恰当的关注。这将防止在解决方案中加入不必要的特性。
程序管理角色群
程序管理角色的中心是实现在各类项目约束内交付解决方案的目标。可以将其看做确保项目出资人满意项目成果的过程。为实现这一目标，程序管理控制和驱动工作日程表、特征定制和项目预算。程序管理确保了在适合的时间交付出适合的解决方案，确保了在整个项目进程中理解和管理项目出资人的期望。以下是被选定的职能领域的描述：
程序管理
| • |
跟踪和管理预算。 |
| • |
管理总的项目工作日程表。 |
| • |
驱动风险管理进程。 |
| • |
促进小组内部交流和商议。 |
| • |
跟踪项目进度和管理项目状态报告。 |
| • |
管理资源配置。 |
解决方案体系结构
| • |
驱动全面的解决方案设计。 |
| • |
管理功能规范说明。 |
| • |
管理方案功能范围和各类关键权衡决策。 |
过程保证
| • |
驱动进程质量保证。 |
| • |
定义和推荐改进。 |
行政服务
| • |
实现项目管理进程，支持小组领导使用它们 |
| • |
提供一套行政服务，支持有效的小组工作 |
项目管理
作为项目日程的控制者，项目管理收集所有小组日程，确认这些日程，并将他们整合到总日程表中。总日程表被跟踪记录并报告给小组和项目出资者。
作为项目预算的控制者，项目管理通过从小组中所有角色收集资源需求促进项目预算的建立。项目管理必须理解和赞同所有的资源决策（硬件、软件以及人员）并且跟踪实际开支。小组和项目出资人都应收到该状态报告
此外，项目管理还协调各种资源，促进小组交流，帮助驱动关键性决策
解决方案体系结构
解决方案体系结构是程序管理角色群的职能领域，它对解决方案的逻辑设计和功能规范负责。解决方案体系结构专注于确保一个解决方案能够被指定的用户使用，以达到指定的有效性、效率、满意度目标。
解决方案架构师的责任包括：
| • |
促进解决方案的总体设计。 |
| • |
管理功能规范。 |
| • |
管理解决方案范围和关键性取舍决策。 |
拥有着逻辑设计的解决方案体系结构提供了解决方案的业务部分（像概念设计中产品管理的描述）和解决方案的技术部分（像物理设计中开发的描述）之间的至关重要的连接。解决方案体系结构扮演了功能规范管理人的角色。它促使小组与它们的其它角色的需求一起就解决方案的内容和设计达成一致，并证明已经被项目风险投资者同意的方法是正确的。它还对支持需求的功能的可追踪性负责（并最终完善业务价值），因此所有支持规定需求的功能都是可见的，且改变任一功能小组都可以评定其对解决方案价值的影响。
解决方案体系结构行为包括：
| • |
创建解决方案概念，并以客户的企业体系结构进行编排；设计版本发布策略；审查需求获取规划。 |
| • |
从结构/标准工作组和互操作相关处获取需求；促进逻辑设计程序；提供一个可追踪映象来跟踪支持需求和利益的功能；创建功能规范；定义临时发布。 |
| • |
管理功能规范的变更；维护可追踪映象；为其它小组角色和外部风险承担者阐明规范；就互操作问题同其它项目小组保持联络。 |
| • |
参与筛选过程；管理项目风险投资者期望的解决方案内容。 |
| • |
为企业体系结构小组提供更新；为未来的版本发布更新需求。 |
解决方案体系结构实施者的技术必须是可靠的，它们需要拥有广博的知识和经验，还要有能力使技术问题同潜在的业务需求发生关联。虽然对于被用于解决方案的具体技术解决方案，架构师可能依赖开发小组向他们提供专业知识，不过他们肯定能迅速抓住那些解决方案细节的本质，了解它们的内在联系以及它们对部署解决方案的环境的影响。解决方案架构师肯定还能够同客户的架构师讨论那些影响，使得他们可以迅速的解决被提议的解决方案同企业体系结构之间的任何冲突。
过程保证
程序管理的过程保证职能领域确保项目小组采纳的过程致力于适应项目整体目标、强调排除有缺陷的消息来源。过程保证对两个主要的区域负责：
| • |
定义被小组使用的关键项目过程，为小组的执行提供建议与指导。 |
| • |
承担过程、建议改进、和一致性监控的审查，以验证它们的关联性和有效性。 |
过程保证致力于下列行为：
| • |
定义符合项目设计的项目协议和过程。 |
| • |
为项目过程的有效执行提供建议和指导；验证过程的一致性；承担里程碑的审查；建议过程改进。 |
由于得益于一个独立于项目小组的地位，过程保证能够有一个客观的看法。因为这个原因，它经常从项目小组的外部进行管理，即使项目的大小使它不能成为一个专职的角色。
行政服务
本职能领域属于程序管理角色群，对执行项目管理过程和为项目小组提供行政支持负责。
项目行政职能领域确保项目小组执行过程符合项目管理定义的项目设计规范。它对确保项目小组能在最小的官僚作风下有效的运转负责。
项目行政责任包括：
| • |
利用它们执行项目管理过程和支持小组领导。这包括统一小组输入以维护总体规划与进度，帮助领导程序报告。 |
| • |
提供一套诸如安排日程会议、常规获取、以及合同管理这样的行政服务来有效支持小组工作。 |
项目管理致力于：
| • |
支持诸如有效的从第三方召集小组成员；管理合同安排；组织小组设施（空间、电话、安全访问等等）这样的项目启动过程。 |
| • |
建立统一的规划框架；帮助小组领导规划和日程安排；统一小组输入以维护总体规划与进度；建立财政与进度报告过程。 |
| • |
帮助小组领导进度报告；构建整体进度和财政报告。 |
| • |
确保在项目完成时关闭所有的行政系统。 |
| • |
执行一般的行政支持行为。比如：安排日程会议；执行风险与问题管理过程；维护主要风险表、操作表等各种表单；生成财政和进度报告；管理小组工作场所以提高士气。 |
项目管理角色需要一个强有力的行政能力的组合，关注项目规划和日程安排技术中的可靠经验的细节，还有对供应方组织中的运作规则和指导方针的良好的了解。一个大型的项目为在项目指导旁边工作提供一个极好的机会，确立了指导未来的项目需要的经验。
开发角色群
“规范构建”目标是关注 MSF 项目期间的开发角色群。为了成功达到它的质量目标，开发角色构建了一个解决方案，它符合客户期望和在功能规范中表述出来的规范。开发角色群依附于解决方案体系结构，并与来自全面解决方案规范的功能规范一起设计它。
除了是解决方案的构建者之外，开发还为小组提供了如同技术顾问一样的服务。作为一个技术顾问，它为设计和技术选择决策提供输入，也为确认决策产生和减轻开发风险构建功能模型。
作为构建者，开发提供低级别解决方案和功能设计，评估这个设计交付所需要的工作，然后构建解决方案。开发之所以评估它自己的工作和计划，是因为它每天都和所有进展的可能性因素在一起工作。MSF 把这个概念看成是从底层向上的评估，而且它还是 MSF 方法的一个基本部分。它的目标是取得一个更高质量的计划，增加那些提供评估的角色和他们执行工作时的责任。
技术咨询职能领域
| • |
为小组提供像技术咨询一样的服务。 |
| • |
评估和确认技术。 |
| • |
积极参与到功能规范的创建和评审中。 |
| • |
为组织定义开发标准作出贡献。 |
执行体系结构和设计职能领域
| • |
通过向体系结构的具体的解决方案细节提供应用程序、数据、技术，为解决方案的执行体系结构映射企业体系结构(EA)决方案。 |
| • |
拥有和执行逻辑的与物理的解决方案设计。 |
应用程序开发职能领域
| • |
编码符合设计规范的功能。 |
| • |
在开发期间管理代码审查，以共享知识与经验。 |
| • |
完成由测试角色支持的测试规划定义的单元测试。 |
基础结构开发职能领域
| • |
开发符合设计规范的功能。 |
| • |
在开发期间管理代码审查，以共享知识与经验。 |
| • |
完成由测试角色支持的测试规划定义的单元测试。 |
| • |
开发自动化部署脚本。 |
| • |
开发部署文档。 |
技术咨询职能领域
技术咨询职能领域提供一个如同技术资源的服务，贯穿在项目生命周期中。作为一个技术咨询者，开发必须在高级设计、评估和验证技术中提供输入，并在开发过程的早期引导研究以减轻开发风险。
在预想阶段，这个职能领域致力于从执行的前景来分析用户/客户需求。为了通过项目的初始参数确定实施的可行性，职能领域评估项目技术的本质，促使对设想/范围文档的定义。它为执行方法的正反两面的可能性和有效的技术初始技术的选择提供指导。在这个过程中，职能领域可能会管理研究，与组织内部或别处的相应的人进行协商，并同技术供应商保持对话。对于附加的验证，职能领域可能开发一个被当成验证概念进行服务的有限功能模型。这在项目关联中是独特的，它要求新技术的使用或者应用在项目小组缺乏经验的领域内。
执行体系结构和设计职能领域
执行体系结构和设计职能领域描述在一个 MSF 项目中，与解决方案的执行体系结构定义和解决方案设计的开发相关的一组责任。
从设计的立场看，程序管理对解决方案的整个体系机构负责，它被部署在企业体系结构中。对企业体系结构向解决方案的执行体系结构的映射，开发通过提供具体的解决方案细节向其负责，具体包括解决方案的应用程序、数据、以及技术。
MSF 提出了一个三级设计过程：概念设计、逻辑设计、和物理设计。程序管理和产品管理共同拥有概念设计。概念设计包括了用户情境、高级可用性分析、概念数据建模、以及初始技术选择。开发拥有解决方案设计中的逻辑和物理方面。逻辑和物理设计要求对解决方案中相关技术和技术选择带来的影响的了解。
应用程序开发职能领域
应用程序开发职能领域描述了与一个 MSF 项目中的软件开发相关的一组责任。开发角色在整个职能领域中的主要责任是为被要求的解决方案构建功能，其中涉及到的内容包括：规范和设计、管理单元测试、处理在测试过程中查出的质量问题、为生产最终产品完成解决方案组件整合。
开发角色在解决方案过程中始终坚持促进标准的定义。开发管理代码审查，以评估单元级别的应用程序功能的质量等级。审查允许项目小组成员共享开发知识与经验、支持 MSF 的目标“自发学习”。测试角色主动的同开发角色一起工作，为解决方案特征计划和管理独立的质量评估，就如同一个完整的解决方案一般。
基础结构开发职能领域
基础结构开发职能领域描述了在 MSF 项目期间与系统开发相关的一组责任。系统基础结构包括一个分布式计算环境的网络接触结构、客户端和服务器系统、以及所有支持组件。软件基础结构包括客户端和服务器操作系统、还有提供必须的平台软件服务的软件产品，比如：目录、通信、数据库、企业应用程序集成、系统管理。网络管理等。
在基础结构开发期间，开发角色“开发”设计中规定的基础结构。这包括为解决方案配置基础技术解决方案，比如：网络支持、设计中定义的客户端和服务器系统。基础结构的各个方面可以被其所支持的应用程序的需求所影响，反之亦然。比如：一个关键项目高性能解决方案可能需要分组供应和后端服务器均衡负载。解决方案的操作系统和平台产品需要适当的开发。各式各样的软件平台产品必须被安装、配置、和优化以适应解决方案的需求。在适当的测试与稳定处理之后，基础结构解决方案在发布管理的掌握下在大规模配置，其中发布管理管理着解决方案基础结构需求的获取。
测试角色群
测试角色群的目标是只有当所有的产品质量问题被识别出来并被处理后，才可以批准发布。所有被交付的产品都是有缺点的。关键的目的是在发布产品之前，确保那些缺陷被识别出来并被处理。在维修被质询的缺陷的过程中，编制解决解决方案文档的处理几乎涉及到了一切。交付一个缺陷已知且被处理的有解决解决方案的产品，比起交付一个有着未被识别的缺陷的产品要好得多，因为稍后小组和用户就会为之大吃一惊。
要想成功，测试小组角色群必须致力于几个主要的责任。那些责任被分组在三个主要职能领域中。
测试计划
| • |
开发测试方法和规划。 |
| • |
参与设置质量规则。 |
| • |
开发测试规范。 |
测试工程
| • |
开发和维护自动测试案例、工具、和脚本。 |
| • |
管理测试以准确确定产品开发的状态。 |
| • |
管理构建过程。 |
测试报告
| • |
为小组提供产品质量相关的数据。 |
| • |
在产品发布之前跟踪所有的错误和交流问题来确保他们的解决方案。 |
测试规划
测试规划职能领域是测试角色群的一部分，它致力于使小组知道如何确保所有的产品质量问题被识别且处理。
测试角色开发测试方法和规划，并为小组测试解决方案之策略描绘轮廓。这些规划包括具体类型的测试、具体测试区域、测试成功标准、和资源(硬件和人员都是)中需要测试的信息。
测试规划职能领域的一个重要部分就是通过为项目小组的质量控制方法和规则提供输入，参与设置质量规则，以确保解决方案的成功。
测试规划职能领域的最后一个行为是开发测试规范。这是对需要工具和代码符合的测试规划的定义的详细描述。
测试工程
作为测试角色群的一部分，测试工程职能领域致力于完成测试规划中定义的行为，这是确保所有产品质量问题被识别出来且被处理所必须的。本域所定义的责任是：开发和维护测试案例的具体职责；开发工具、脚本、以及文档来执行测试功能；进行日常构建的管理，以确保测试规程能以单个参考标准执行和报告；还有管理测试以准确确定产品开发的状态——同当前的构建一起，通过运行测试案例、工具、和脚本来识别问题。
跟踪和报告
作为测试角色群的一部分，跟踪和报告职能领域致力于清晰的向项目小组表达解决方案中普遍错误的和普遍正确的是什么，从而使开发状态能被精确的描绘出来。
问题跟踪的执行是为了确保所有被识别出来的问题在发行之前已经被解决。问题状态文档包括了分配、优先级、决定、和解决，它们全部都频繁的向小组提供与当前产品质量状态和详细趋势分析有关的数据。
用户经验角色群
用户经验角色群的目标是提高用户效率。用户经验由六个职能领域组成：易用性、国际化、技术交流、培训、可用性、和图形设计。为了使解决方案被成功执行，用户经验角色群在每个职能领域中都有一些必须被管理的责任。下面是职能领域和相关责任的列表。
易用性
在设计中促进易用性概念与需求。
国际化
改善解决方案在国际市场中的质量和可用性。
技术交流
| • |
为支持系统设计和开发文档（helpdesk 手册，KB 文章等等）。 |
| • |
帮助/辅助文档。 |
培训
开发和实行学习策略（构建/购买/交付）。
可用性
| • |
收集、分析、区分用户需求。 |
| • |
为解决方案设计提供反馈与输入。 |
| • |
开发使用情境和使用案例。 |
| • |
为项目小组担当用户辩护者。 |
图形设计
| • |
促进用户接口设计。 |
易用性
易用性职能领域致力于通过促进设计中的易用性概念和需求，确保解决方案对那些有缺陷的人来说是易用的。易用性的重要是有很多原因的。最主要的一个方面，易用性很重要是因为不论人们的能力如何，产品和解决方案应该对所有人来说都是易用和可用的。一个产品或者解决方案没有在易用性上得分将缺乏完全的采用率。另外，遵从易用性可以符合政府法规的要求。
易用性观念和需求必须在整个解决方案开发周期中被提出，且必须包括：
| • |
每个功能规范内的易用性部分的结合。 |
| • |
将易用性信息集成进解决方案帮助部分。 |
| • |
确保易用性文档的完善。 |
| • |
确保易用性文档以易用的格式呈现。 |
国际化
国际化职能领域中的责任是提高解决方案在国际市场中的质量与可用性。国际化职能领域由全球化和本地化过程两部分构成。
全球化
全球化是一个定义和开发解决方案的过程，它考虑解决方案本地华化的需要，其内容要么没有改变，要么没有本地用户不需要的工作区。换句话说，一个彻底全球化的发行解决方案即是为了打算进行最小难度的本地化。
本地化
解决方案本地化包括改变解决方案用户界面、帮助文件、印刷品和联机文档、行销内容、还有Web站点。有些时候，这些内容可能需要为某个特定的语言版本改变为图形元素，甚至进行内容的更改。
技术交流
技术交流职能领域致力于解决方案文档支持系统的开发。
技术交流职能领域的一个主要责任是创建诸如帮助工具这样的工具组件。这种帮助工具能够为用户的基本的问题、关键字描述、错误解释、和经常被问到的问题提供答复。像帮助工具这样的工具可以使用户和组织双方得利。用户得利是因为他们的问题和询问通过及时有效的方式得到了回答。组织则得益于降低了支持成本。
技术交流职能领域得一个补充责任就是为解决方案设计和开发文档。这可能包括安装、升级、操作、和疑难解答指南的开发。
培训
培训职能领域致力于通过提供有效使用解决方案需要的技能知识，来提升用户执行能力。这个技能知识转移是通过执行一个学习策略来实现的。学习策略的开发是用户经验小组角色群的责任。
学习策略的开发可能在组织内部进行，或者外包给一个专门进行培训和开发的组织。不管实际上是谁开发这个学习策略，这个方法通常都由以下部分组成：
| • |
对用户和企业的目的与目标进行分析。 |
| • |
设定期望的技能级别集合。 |
| • |
开发和执行一个培训规划。 |
| • |
在执行时，测度培训规划的可行性，对培训规划进行适当的修改，以保证执行的成功。 |
学习策略可能由以下的一个或几个交付机制组成：教师指导培训、技术交付培训、自主学习或使用工作帮助。很多组织选择了混合方法来适应这种单独的自主学习风格。
可用性
可用性职能领域致力于保证解决方案可以被特定的用户使用，并高效且令人满意的完成规定的目标。
可用性职能领域定义的一个主要的责任是可用性研究，它包括收集、分析、区分用户需求。通过在早期以及贯穿解决方案工作中的了解客户工作上花费时间，项目将更有可能性有效的适应客户需要。
可用性职能领域中定义的另一个主要责任是开发使用情境和使用案例。这里的主要打算就是设想和考虑整个解决方案多大程度上可能被使用。这个工作帮助开发小组从一个整体和直观角度了解了用户如何处理解决方案，这通常可以导致设计被改进，从而使有效性增加。
可用性职能领域中定义的最后一个主要责任是为解决方案提供反馈和输入。通过在整个开发周期中花费时间把用户反馈提供给开发人员，解决方案将因此获取一个更高的用户满意率。
图形设计
本图形设计职能领域致力于确保解决方案中的图形原理的设计是恰当的。图形设计职能领域的主要职责是推动用户界面的设计。这包括设计用户打算与之结合的对象（还有应用于那些对象的操作），还包括接口的主要画面。
发布管理角色群
发布管理角色群的目标是使部署流畅和持续操作。发布管理是直接参与 MSF 小组操作的角色。它包含了下列职能领域的责任：
| • |
扮演项目部署和操作工作组的主要支持者。 |
| • |
为发布行为和驱动最优化自动管理工具选择。 |
| • |
为产品发布设置运作标准。 |
| • |
参与设计，致力于易管理性、可支持性、以及可部署性。 |
| • |
推进操作训练。 |
| • |
为首次部署提供促进和建立支持。 |
| • |
规划和管理生产解决方案部署。 |
| • |
确保稳定性测量以达到验收标准。 |
基础结构
| • |
企业基础结构规划 |
| • |
通过地理布局协调物理环境使用与规划（数据中心、实验室、外部办事处）。 |
| • |
为小组的统一的基础结构管理和标准提供规则和规程。 |
| • |
向 MSF 小组提供基础结构服务（构建服务器、标准映像、软件安装）。 |
| • |
为小组管理软硬件采购。 |
| • |
构建准确反映生产环境的测试与分级环境。 |
支持
| • |
为 IT 用户提供第一位的联络与客户服务。 |
| • |
通过同客户管理 SLA 支持业务，保证承诺被实现。 |
| • |
提供事件与问题决议；对用户需求和日志事件作出快速反应。 |
| • |
向开发和设计小组提供反馈。 |
| • |
开发故障转移和恢复规程。 |
操作
| • |
帐户和系统设置控制；管理用户帐户和权限。 |
| • |
通信、数据库、远程通信操作；网络操作。 |
| • |
系统管理、批处理。 |
| • |
防火墙管理；安全管理。 |
| • |
应用服务。 |
| • |
主机集成服务。 |
| • |
目录服务操作。 |
业务发布管理
| • |
产品注册码；注册验证程序。 |
| • |
许可管理。 |
| • |
封装。 |
| • |
管理销售渠道。 |
| • |
出版物与电子出版物。 |
基础结构
基础结构职能领域描述了一组责任，涉及到在 MSF 项目中必须令人满意的操作基础结构。它是 MSF 发布管理角色群的一部分。至于那些应用了 MOF 的项目，它们符合 MOF 基础结构角色群的责任。
支持
本职能领域致力于确保解决方案的构建和部署是 可支持的。至于那些应用了 MOF 的项目，它们符合 MOF 支持角色群的责任。
操作
本职能领域描述了一组在 MSF 项目中必须令人满意的操作责任。本职能领域致力于保证解决方案的构建和部署在 同其它服务进行操作时的可操作性和兼容性。至于那些应用了MOF的项目，它们符合 MOF 支持角色群的责任。
业务发布管理
本职能领域描述了涉及到业务软件产品发布的一组责任。业务发布管理致力于在渠道中获取产品。
按比例缩放组队模型
在 Microsoft 从前的软件开发人员 Steve McConnell 的书 快速开发中，他写道：
“大型项目要求组织实行公式化且简单有效的交流。……所有的进行简单有效交流的方法都依赖于建立各种层次，也就是建立小型的拥有与小组同样功能的工作组，然后从这些工作组中选定一些代表来相互组合，并与管理相结合。”
MSF 提倡把大型小组(那些多于十个员工的小组)分解成小型的、功能齐全的小组。这些小型小组并行工作，并经常进行同步工作。
另外，功能小组可能被用于一个要求多种资源来适应需求的特别角色，并因此被组合在这个角色中。
功能小组
在组队模型中，每个角色群都由组合在一个层次结构中的一个或多个资源组成（尽管它们是尽可能的扁平）。测试人员向一个测试经理或领导汇报就是一个例子。
覆盖在这个结构之上的是功能小组。这都是些小型的下级小组，它们把来自每个角色的一个或更多的成员组合进了一个模块组织中。然后这些小组被赋予了一个具体的功能，并对它所有的方面负责，包括设计与计划。例如，一个特征小组可能被指定去设计和开发印刷服务。
Steve McConnell 写进 快速开发：
“功能小组在授权、责任性、以及平衡上具有优越性。小组可以被灵敏的授权，因为它代表性的包含了……每个相关的人员。小组在它的决策中包含了所有的观点，因而很难出现一个超越它的决策的基础。”
“因为同样的原因，使这种小组变得有责任。他们所有人员需要的，制定好的决策的权限。如果他们没有制定出好的决策，除了自己他们谁也无法责备。这种小组是平衡的。您不能期望开发、市场、或者质量保证在一份产品说明书中各有一个独立的最终说辞，不过您可以从每个种类包含的一组代表性的说法中取得一个平衡。”
备注： 本图例并不是描绘组织功能小组的需求。举个例子，并不是所有的功能小组都需要用户经验角色；这些小组都是为了迎合它们的解决方案关注的目标而按需组织的。
功能小组
功能小组是在一个角色内部存在的小组。它们的存在是因为一个小组或项目的人员过多，以至需要将一个角色内部的员工根据职能来进行基于小组的分组。Microsoft 公司就是一个例子，它的一个产品开发小组通常拥有一个产品规划人员与一个产品生产人员。两个工作都是产品开发的一个方面：一个致力于取得客户真正需要的功能，另一个则集中注意力把产品的优点向潜在的用户传达。
这对开发同样是正确的，开发者可以通过他们工作的服务阶层来分组：用户、业务、或者数据。通常开发者还可基于他们是解决方案构建者还是组件构建者来分组。组件构建者通常是低级语言 C 的开发者，他们构建的可复用组件可以由企业调节。解决方案构建者来通过把这些组件封装在一起来构建企业应用软件。解决方案构建者通常使用像 Microsoft® Visual Basic® 这样的高级语言来工作。
功能小组常常被包含在工作组内部的一个层次结构种。比如在程序经理向一组程序经理进行汇报的同时，他们还通过领导程序经理向上进行汇报。像这样的结构同样可以在功能领域出现，且要优于角色群集层次。要牢记的重要事情就是：这个层次不可以阻碍项目级别的组队模型。角色的目标和它们的整个项目小组的责任性都被保留下来。
共享角色
即使组队模型由六个角色组成，一个小组还是不需要达到六个成员的最小值。它也不需要每个角色一个成员。关键的地方是每个小组中的六个目标必须被表现出来。有代表性的是，每个角色有一个成员可以帮助确保有人照顾到每个角色的利益，不过不是所有的项目都可以从这样的填满每个角色的情形中受益。通常，小组成员必须共享角色。
在小型小组中，角色必须被小组成员共享。两条原则指导角色共享。第一条原则是开发小组成员不能共享一个角色。开发人员是项目构建者，他们不能从他们的主要任务中分心。为开发小组添加附加的角色时，由于产生了这些附加的责任，只不过增加了偏离计划的可能性。
第二条指导原则是尽量不要使有内部利益冲突的角色被组合。例如，产品管理和程序管理因为有利益冲突而不能被组合。产品管理希望满足客户，相反的，程序管理希望按时按预算交付。如果这些角色被组合，同时客户又要求变革，那么出现的风险不是变革没有达到预期以维持客户满意，就是在没有理解给项目带来的影响的情况下被接受。拥有不同小组成员，表现了这些角色帮助确保了每个观点都受到了平等对待。如果尝试组合测试与开发，这一条同样是适用的。
下列表格说明了组合角色的风险(由"Not Recommended"或"Unlikely symbols"标识）和促进作用(由"Possible"记号标识），不过对任何小组的做法，成功的角色共享还涉及到现实成员自身和他们带来的经验和技能。
横排和纵排交叉处是 N 的，表示这些角色不被推荐来进行组合。因为有利益方面的冲突，除非有绝对的必要，或者关联的风险可以被关联风险的缓解与应变计划处理。很显然，这些角色的目标在多个层次上都有冲突，这将使组队模型不稳定，并增加了组合时出现问题的可能性。角色组合并不罕见——如果小组选择小巧的组合，并积极的管理相关风险，问题发生的几率将会降至最低。
逐步升级与责任性
MSF 组队模型不是一张组织结构图
当应用 MSF 组队模型的时候，一个问题经常被问起：“谁是主管？”。一张组织结构图描述了谁是主管以及谁向谁负责。与之不同的是，MSF 组队模型描述了主要角色以及项目小组的责任，但是没有从全体职员管理的角度来定义管理结构。在很多案例中，项目小组的成员来自于几个不同的组织，在行政上对不同的管理者负责。
这里有几个确定的情况可能会出现，尽管如此，小组仍然不能对其中的观点达成一致。在付出了应有的努力达成一致后，就到了程序管理角色逐步提高，并为项目的向前推进进行重要领导的时候了。 程序管理角色的首要目标是在项目限制下完成交付，时间就是其中的一个限制。因而，这个角色和小组要完成这个目标，程序管理角色会有很多次临时成为的最高决策下达者，以便使项目回到轨道上来。在这些图例中，领导地位特有的至始至终都被共享，这些角色理解这种变动的必要性，它为组队构建了一种更为健壮的可接受的层次并通过权威决策大宗买进，以达到实现项目目标的目的。这个问题一旦被解决，小组就可以达成一致，并立即共享领导地位责任。现在已经证明了同等级组队的灵活性与可适应性足够处理这些挑战，并为项目组队留下了一种无分层方法。
外部协调——谁应当负责？
为了保证组队的成功，还必须和其他外部工作组相互影响、交流、以及协调。这些工作组的范围涉及顾客、用户、还有其他开发小组。在多数案例中，那些与小组在某点上联系的顾客都会要求解决方案存在明确的责任性。虽然同等级的小组在解决方案的成功交付中要求共享责任，不过对于交流规划中的责任性和报告结构文档的清晰的区分是很重要的，因为这样顾客和开发小组都能懂得小组中谁对促进这个信息负责。
下列图表说明中列举的具有代表性的责任，不是协调业务中心就是协调技术中心。程序管理、产品管理、用户经验、以及发布管理是主要的促进者。这些角色都是内在和外在的中心，尽管开发和测试都是以内在的中心并与外部交流相隔绝。
不过这并不意味着开发者和测试者将会与外部世界相隔绝。对于 MSF 小组期望达成的建立以客户为中心理念的来说，与顾客组织和真正的用户的接触是无价之宝，特别是在早期的项目成形阶段。不管如何这种交流都不能沦为形式，因为在项目后期，这将使致力于解决方案交付的开发小组和测试小组遭遇麻烦。
本图表描绘了一个高水平的前景。富有特色的是，小组必须同更多的像质量保证、财政、法律这样的外部工作组协调。与外部工作组的接口的清楚与明了是很重要的，开发与测试继续保持隔绝，这样可以保证它们不受干扰的进行有效的工作。
另外，有一个重要的地方需要强调，当进行外部协调的各种角色能够提供输入与建议的时候，不要让单个的成员或是作为整体的小组拥有修改项目交替使用的，像功能、计划以及资源这样的优先级和细节的权限。这些改变都是项目客户与监护人的特权，并由项目小组执行。这也为由均等伙伴和对等者组成的小组通过组织权限、层次、和结构，如何服从与结盟提供了一个例子。
小结
MSF 组队模型并不能保证项目一定成功。除了小组结构之外，有着更多因素决定着一个项目的成功与失败。不过小组结构仍然是很重要的。
在 快速开发中，Steve McConnell 举例说明了这一点：
“即使您拥有了有技术、有动力、辛勤工作的员工，错误的小组结构也能够消弱他们的努力，而不是飞速的前往成功。一个不良的小组结构会增加开发时间、降低质量、使士气低靡、增大周转期间，最终导致项目取消。”
MSF 组队模型正好是来处理这个问题的。恰当的组队结构是成功的基石，贯彻这个模型并且运用它的优先原则能够帮助小组，使之更加有效，因而取得成功。
尾注
(1)参阅 Jim McCarthy Dynamics of Software Development (Redmond, WA: Microsoft 出版, 1995)以便在设计中分享更多的最优化的小组的经验。
本文档中的信息代表 Microsoft Corporation 到发布之日对所讨论问题的最新观点。由于 Microsoft 必须对不断变化的市场情况作出反应，这些信息不能解释为 Microsoft 一方的承诺。Microsoft 不保证所提供的任何信息在发布之后仍然正确。
本指南只用于提供信息。MICROSOFT 不对本文档的信息做任何明示或者暗示的保证。
用户有责任遵守所有生效的版权法。根据版权法的规定，如果没有 Microsoft Corporation 的书面许可，不得以任何形式或者利用任何手段（电子、机械、影印、录音带或其他方式），为了任何目的，对本文档的任何部分进行复制、存储、在检索系统引用以及传播。
Microsoft 对本文档中的所有内容都拥有专利、专利应用、商标、版权或其他知识产权。除非 Microsoft 通过书面许可协议明确提供，此文档并不意味着授予您对这些专利、商标、版权或其他知识产权的任何许可。
© 2002 Microsoft Corporation。保留所有权利。
Microsoft 和 Visual Basic 是 Microsoft Corporation 在美国和/或其它国家/地区的注册商标或商标。
这里提到的真实的公司名称和产品的名称可能是它们各自所有者的商标。
编号：602-i400a
