1、MSF 组队模型 v. 3.1发布日期： 点击此处下载本白皮书的副本Microsoft 解决方案框架白皮书致谢Paul Haynes，程序经理， Microsoft Solutions FrameworkAllison Robin，主任， Microsoft Solutions FrameworkEnzo Paschino，程序经理， Microsoft Solutions FrameworkMark Short，程序经理， Microsoft Solutions FrameworkPervez Kazmi，程序经理， Microsoft Solutions FrameworkRob Oika
2、wa，程序经理， Microsoft Solutions FrameworkScott Getchell，程序经理， Microsoft Solutions FrameworkLaura Hargrave，技术编辑， Microsoft Solutions FrameworkMike Lubrecht，技术撰稿人， Microsoft Solutions FrameworkNany Huber，技术编辑， Microsoft Solutions FrameworkSuzana Vukcevic，程序经理，Microsoft 比利时 Paulo Henrique Leocadio, Micros
3、oft Consulting Services，巴西Paulo Rocha, Microsoft Consulting Services，新西兰Dolph Santello, Microsoft Consulting Services，美国Ralph Schimpl，主任，Microsoft 澳大利亚摘要Microsoft 解决方案框架 (MSF) 组队模型描述了微软如何通过构建人员以及人员的行为来实现项目成功。模型专门为小组成员定义了各类角色群、职能领域、职责和指导，帮助他们在整个项目生命周期中实现各自的工作目标。本页内容介绍组队模型基础原理MSF 基础原理关键概念成功的做法组队模型概述组队
4、模型角色群产品管理角色群开发角色群测试角色群用户经验角色群发布管理角色群按比例缩放组队模型逐步升级与责任性小结尾注介绍为了在整个 IT 生命周期中将 IT 项目及其操作的成效最大化，Microsoft 解决方案框架和 Microsoft 操作框架 (MOF) 提供了指导文档和各种成功做法。通过它们，小组可以实现有效的规划、构建、部署和操作解决方案。这些信息来源于微软内部进行大规模软件开发和服务操作项目过程中积累的经验、微软的顾问专家的经验，以及在世界范围内 IT 行业里通行的最佳做法，并以白皮书、指导文档、工具、模板、案例研究和课件等形式发布。这些指导和做法被组织成两个相互补充并有效整合的知识
5、体系。Microsoft 解决方案框架在预算范围内按期创建一个业务解决方案需要一种经过检验的方法。MSF 为成功地规划、设计、开发和部署 IT 解决方案提供了经过检验的做法。与规定性的方法相反，MSF 提供了一个可以伸缩的灵活框架，以满足任何规模的组织或者项目小组的需要。MSF 指导由原理、模型和用来管理人员、项目和技术元素的准则（大多数项目都会碰到）组成。Microsoft 操作框架Microsoft 操作框架 (MOF) 提供了技术指导，从而让组织能够在使用 Microsoft 产品和技术创建的 IT 解决方案上取得任务关键系统的可靠性、可用性、可支持性，以及可管理性。MOF 的指导致力于
6、解决人员、过程、技术和管理等问题。关于 IT 基础结构库 (ITIL) 的更多信息 ITIL 是 MOF 的基础，它包含了行业中最佳做法，请浏览：http:/www.itil.co.uk/index.html返回页首组队模型基础原理MSF 组队模型经过数年时间的发展，祢补了传统项目小组自上而下的层次结构的一些不足。按照 MSF 组队模型组织建立的小组是小型、跨学科的小组，在这样的小组中成员们共同承担各项职责，权衡彼此间能力差异，以便将主要精力集中到手头上的工作中。他们拥有共同的项目前景，以部署项目为中心，坚持高标准的质量和沟通，保持乐意学习的心态。本文描述了小组中的各种角色群，以及他们的目标和
7、职能领域。同时提供了指导，以便使用 Microsoft 的方法根据规模和复杂性的高低来建立小组。下面将概述应用于 Microsoft 组队模型的 MSF 的各类基础原则、关键概念和成功做法。本章以及整篇文章里的各种主要思想将被重点标出，并将作 MSF 组队模型的细节进行讨论。返回页首MSF 基础原理MSF 包括一些基础原理和框架方法的里程碑。本部分中与成功的小组相关联的一些原理将被重点标出。清晰的责任，共同的职责MSF 将工作进行中需要共同承担的职责和确保工作如期完成需明确的工作责任结合起来。MSF 组队模型基于这样一个前提，即小组里的每个角色都代表了对项目的一种独一无二的观点，但是没有哪个个
8、人能够完全代表所有的不同质量目标。为了解决这一问题，MSF 组队模型把对各种利益相关人的清晰角色职责与实现这个项目成功的整个小组的责任结合起来了。在小组内部，每个角色通过对小组本身负责（也对他们各自所属的组织负责）实现该角色的质量目标。在这种意义上，每个角色都对最终解决方案质量的一部分负责。小组成员之间共同承担职责（根据不同小组角色指派）。角色之间是相互依赖的，有以下两个原因：首先，就其必要性而言，因为把每个角色的工作分隔开来是不可能的；其次，出于优先的原因，如果每个角色都了解全局情况，那么小组的效率会更高。这种相互的依赖性会鼓励小组成员对由他们负责的直接区域以外的工作做出评论和贡献，以确保小
9、组所有的知识、能力和经验能够被应用到解决方案里。项目的成功属于所有的小组成员；他们共同分享一个成功的项目所带来的荣誉和回报，他们也同时希望，即使是一项不太成功的项目，也能做到全心投入并从中吸取教训以完善他们的专长。赋予小组成员权力在一个高效的小组里，所有的成员都被赋予权力以便根据他们自己的承诺交付任务，并且充分信任小组的其他成员也能实现各自的承诺。类似的，客户也能够认为小组将会兑现其承诺，并进行相应的规划。在最坏的情况下，小组也应该尽快地告知客户项目出现了哪些延迟和变化。MSF 小组赋予小组成员权力以帮助他们履行承诺。反过来，MSF 小组又要依赖所有小组成员的整体配合和动力来： 准备好向其他成
10、员作出允诺。 清楚定义自己担负的承诺。 做出一切合理的努力交付承诺的工作。 发现承诺陷入危机时进行真诚的沟通。由于每个参与者的工作都要依赖于其他小组成员的工作，所以一旦一项活动需要一个以上的小组成员参与，那么他的工作就要受到其他成员工作的影响。然而，小组成员不会花时间监视他们的各项工作是否会对别的小组成员产生影响。有效的小组会逐渐形成一种信任，他们了解同事被授予权力正在履行实现小组目标的承诺。拿接力队打个比方。在接力队中，当第二棒的运动员起跑的时候，他不会减速也不会向后看究竟前一队员离他有多远，他只会集中精力全力加速，跑完赛程后回头接棒，并且他有信心可以从队友手中顺利拿到接力棒。这种信心来源于
11、做法、经验和信任。在一个复杂的项目中，小组成员需要逐渐形成一种同级信任，这种信任会在实现每项承诺（无论大小）时建立。下面给出了形成这种信任的一些简单指导思想： 赋予小组成员权力，让其承担指派的承诺。这种授权包括向小组成员提供进行工作所需的各种资源；负责制定决策以有效影响队员的工作；理解队员的权力界限，并不断增加各种可用途径来处理越权问题。 准备好向其他成员允诺。这些准备包含了心态（进行面谈并乐意采取行动）、就绪，并理解承诺的内在含义以及它对当前工作量和资源的影响。这样做的结果就是，不到小组成员清楚承诺的内在含义，就不要作出承诺。相反，小组成员要提出一个更小的、他们能够理解的承诺，例如对这些承诺
12、的内在含义进行研究，然后再迅速坚定地作出承诺。对较小承诺的成功交付将建立小组的信任。 清晰定义自己担负的承诺。这样可以避免一些可能会导致小组成员间信任危机的误会。 做出一切合理的努力来交付承诺的工作。如果一个小组有来自不同组织的成员，那么合理的期望也将因人而异。例如，某些小组成员可能认为在周末工作是合理的；而其他人则可能将他们视为例外或者可能在周末几乎不会去上班。 发现承诺陷入危机时进行真诚的沟通。有时将无法避免事情的变化，原因可能是某些任务的优先级调整、一个意外事件或仅仅是因为一项工作延期完成。及早的进行沟通将使与之相依赖的其他小组成员可以有机会制定相应的计划。也许他们还可以提出解决这些问题
13、的途径。在大多数组织中，这些行为与企业文化是融合在一起的，队员们已经将它们视为一种文化，因此很少讨论它们。但是，MSF 小组有时需要与不同的组织一起工作，在这些组织中的相关的价值观念并没有被完全地了解和注重。这些组织常常呈现出一种高度推诿的文化，这种文化约束着应该开放的信息流。在这些情况下，小组领导应当根据这一点来清楚地陈述他们的期望并帮助新的小组成员适应这种工作方式。聚焦业务价值MSF 组队模型提倡将小组决策建立在小组对客户业务全面的认识以及项目交付过程中客户能动的参与之上。产品管理角色在小组中担当客户的拥护者，这个角色常常由客户组织中的成员来担任。产品管理有其业务案例，这些案例保证了从初期
14、战略工作开始的连续性。产品管理职责的一部分是确保关键的项目决策建立在一个健全的业务认识基础上。发布管理角色会确保顺利的部署和各项操作。通过这些工作，该角色在解决方案开发、部署以及不断进行的各项操作之间起桥梁作用，它确保项目交付组时刻了解其决策在产品操作过程中对价值交付的影响。共同的项目设想MSF 全力提倡采用一个共同的设想，以便把注意力放在小组的工作方法上，包括在一个操作环境里交付 IT 解决方案或是提供 IT 服务对项目和过程的目标有一个清晰的了解是很重要的。因为小组成员和客户都在猜测这项解决方案能为组织做些什么。一个共同的设想将使这些猜测明确化，并确保所有参与者都在为完成相同的目标而努力着
15、。共同的设想是 MSF 组队模型的基础之一。当所有的参与者都了解了这一设想并朝着这一设想工作的时候，小组便能够根据成员使自己的决策与这一设想体现的更为广阔的小组意图相吻合，从而获得他们的权力。没有共同的设想，小组成员可能出现与目标相抵触的观点，作为一个团体的交付将变得更加困难。并且即便小组完成交付，小组成员也很难确定自己的成功，因为这种成功依赖于他们评价成功的设想。保持灵活，预测变化MSF 认为事情在不断发生变化，将一项 IT 解决方案交付项目与这些变化相孤立是不可能的。MSF 组队模型确保所有核心的准则在一个项目的始终可用性，这些核心准则将有助于由各种变化引出的各项决策。当新的变化产生，MS
16、F 组队模型将强化解决这些问题的灵活性。所有小组角色对决策制定的贡献确保了对问题的深入研究，确保了以批判的观点对问题进行探讨。推动开放式沟通从历史上看，许多组织和项目的操作单纯以需要认识为基础，它将频繁地导致误解同时影响了小组交付一项成功的解决方案的能力。MSF 提出一个开放式的真诚的沟通方式，这种沟通存在于小组内部以及小组与关键利益相关人之间。开放的信息流不仅减少出现误解与成效耗损的频度，而且确保了所有小组成员可以降低项目周边环境中存在的不确定性。同级小组的方法涉及了在关键决策中的所有角色。它是共同的小组设想被视为解决方案交付过程的基本开端的原因之一。它也是 MSF 风险管理的基础， MSF
17、 风险管理全力提倡所有小组成员运用风险意识辨识问题和分析问题，提倡促发一个无推诿的文化环境来实现风险管理。开放的、真诚的讨论做好工作的标准以及应该如何改进工作提供了 MSF 寻求营造的学习环境的基础。有一些重要的因素可能抑制小组交流的开放性，例如个人和业务信息的机密性。然而，小组成员在决定保留这些信息时应该认真询问自己，以保证保密的原因确实是不可置疑的。如果小组成员已经通过开放的交流建立了信任关系，并且在大多数场合上都开诚布公，那么他们便能够向同事解释之所以这样做是因为存在高于一切的理由，并且让同事相信这些理由是以实现项目的最大利益为基础的。返回页首关键概念MSF 组队模型的成功实现存在几个特
18、征。在本部分，这些特征已经被列出并作为关键概念进行阐述。同级小组“同级小组”这一概念寄予了每个角色同等的价值。它实现了角色间的自由交流，强化了小组的责任观念，补充强调了六个质量目标都是同等重要且必须实现的。为成功实现平等的小组，每个角色都必须对产品质量负责，必须以客户的角度思考，必须清楚正试图解决的业务问题。虽然每个角色对小组的价值都是相同的，小组的平等存在于角色 之间 ，并且不应该与受多数意见驱动的决策相混淆。每个角色需要某种内部组织层次实现分配工作和管理资源的目的。当小组成员集中精力实现他们各自的目标时，每一个角色的小组领导人都有责任管理、指导和协调小组。以客户为中心满足客户对任何优秀的小
19、组来说都被看作是第一位的。在整个开发过程中，以客户为中心包含了小组对了解和解决客户业务问题的承诺。衡量以客户为中心的理念体系获得成功的方法之一是能否使设计中每一个特性都符合客户和用户需求。同样，实现客户满意度的一个关键方式是使用户积极地参与设计并在整个开发过程中提供反馈意见。这样，小组和客户都能的使期望和需求更加吻合。产品理念体系产品理念不是关于将业务软件推向市场（像 Microsoft 一样）或是只为内部客户开发应用程序。产品理念是将您的劳动成果看作产品的理念实现产品理念的第一步是认识您正进行的工作，它本身是一个项目也是一个大型项目的一部分。事实上，MSF 提倡项目标识的创造，这样小组成员将
20、更少的将自己视为个体，而更多的视为一个项目小组的成员。Microsoft 使用的一个方式是为项目代码取名字。这将有助于清楚的标识项目，清楚的标识小组，强化责任意识并且形成提升小组士气的机制。将小组项目代码名印制于 T 恤衫、咖啡杯和其他与团体有关的小礼物上也是创造和强化小组标识和灵魂的一种方式。如果小组是由一个组织中的来自多个不同群体的要素组成的“虚拟小组”，这将尤其有用。一旦您清楚正为一个项目工作，那么无论最后它可否交付，您都应该把它看作是一个产品。那些应用于创造产品的原则和方式（就像 MSF 所提倡的那些）可以被用来帮助确保您的项目成功的交付。拥有产品理念同时意味着将更多的精力投向执行过程
21、和项目结束时要交付的成品上，而不是投向如何取得这一效果的过程。但这并不意味着过程是无利的或是不重要的，这样做意味着过程应该为最后的目标服务而不单单只为了利用过程。采用产品理念，小组中的每一个人都会感到背负着产品交付的责任。前任微软程序经理 Chris Peters 描述了应用于软件开发中的产品理念，下面是他在 1991 年所作的讲演的摘录：“每个人确切的说都在做相同的工作。他们有相同的工作描述。那就是售卖产品。您的工作不是写代码，不是进行测试，也不是书写规格书。您的工作就是售卖产品。这正是产品开发小组做的工作 ”您作为开发者或是测试员的角色是次要的。我并不是说这就不重要了 很显然是重要的 但是
22、对您真正的工作来说它是处于次位的，而您真正的工作是售卖产品。”“当您在清晨醒来并投身工作，您说，“工作中心是什么 我们正试图售卖产品还是编写代码？”答案是，我们正试图售卖产品。您并不是试图去编写代码，您应该不仅仅只是编写代码。零缺陷在一个成功的小组中，所有成员都感到要对产品的质量负责。产品质量责任不能由一个小组成员委托给另一个小组成员或部门。同样，每个小组成员都要作为客户的拥护者，在整个开发周期中考虑最终产品的可用性。零缺陷理念是对质量的承诺。这意味着小组的目标是尽可能最高效地执行工作，这样即使不得不在明天就交付产品，他们也可以交付出一些东西。这个想法是让每一天都有一个接近可交付的产品。这并不
23、意味着交付不存在任何缺陷的代码；这意味这产品满足或超出了项目出资人的质量要求并在预想阶段被小组接受。用自动机车装配线作类比最有力的描述了这一概念。传统上，工作人员将汽车由单独的部分组装起来并且为他们自身的质量负责。当汽车下线，一名检查员进行检查并判断该汽车的质量是否达到售卖的标准。然而在这个过程的后期，大量的时间将花费在查找所有的问题上，因为在此时进行纠错是极富价值的。同样，既然质量是不可预计的，在后期决定产品是否可售卖所需花费的时间也是不可预计的。在当前的汽车制造业中，质量已经成为了“第一工作”。这意味着当工作正在进行时（例如正在装配一扇车门或是安装一部收音机），检查员同时审查该项工作以确保
24、它符合为标准的汽车所定义的质量标准。只要在整个装配过程中保持该级别的质量，那么在后期为确保这辆汽车的质量可接受只需要花费更少的时间和资源。这使生产过程更可预测因为检测员只需要检查各个部分的整合处而不是所有个别的工作。乐意学习乐意学习包括了对通过收集和共享知识保持自身发展的承诺。它使小组成员可以从犯错中吸取教训，也使成员们通过实现他人的成功做法而获得连续的成功。进行里程碑的温习回顾和无指责的事后剖析检讨是 MSF 过程模型的组成部分，它们帮助小组进行交流沟通。小组在进度表中安排时间进行学习、回顾和事后检讨，这样做创建了一个持续进步和赢取不断成功的环境。此外，微软成功地建立一种乐意学习的文化，它将
25、学习和知识共享作为个人回顾目标的一部分。有动力的小组有效率缺少动力的小组效率低下来自于两个原因：从个人上说，小组成员表现不佳导致输出质量和数量的低下；小组成员在狭隘的目标指导下工作，没有意识到他们的工作将对同事产生的影响。 IT 项目是以高度的知识输出和相互作用为基础的。因此这两个因素对 IT 项目带来严重的负面影响。MSF 提倡付出努力激发小组的士气和动力。而在微软从事工作的人们都将其视为公司定义的特性之一。用来激发小组动力方法有： 明确小组设想。 构建小组标识，使用项目代码名字和小组特别物品 如吉祥物、T 恤衫、酒杯等等。 花时间通过社交和小组活动慢慢了解您的同事。 制定计划确定进行小组建
26、设会议的地点，在那里小组成员能够体验各种不同方式的合作和互动，这一地点通常选择在工作环境之外。 确保尊重个人目标，例如提供机会进行个人能力或技术能力发展，协调小组成员工作和生活的权衡。 让小组成员最大的感到授予了权力并积极听取他们的想法。 庆祝成功。返回页首成功的做法以下成功的做法对 MSF 小组的每个成员有共同的作用，这些做法确保队员们持续的专注于成功。小型的多学科小组小型的多学科小组具有与生俱来的优势，他们相对与大型的小组具有更迅速的响应能力。因此，对于大型的项目小组来说，在小组中创建小组的效果将更好 由多个更小的工作组并行工作。一些小组成员具有在特别领域内的专业知识或对特别领域有清晰的了
27、解，他们应在需要的时候在控制下被授权行动。在小组内部甚至在一个角色群内存在多重学科，这种多重学科要求了一套明确的技能。拥有不同的职业背景、受训情况和专业领域并组成小组或角色的人都能参与负责整个的产品质量，这取决于他们向各自的角色以及最终向整个解决方案引入的同一的全景设想。一起工作组队模型的目标之一是使沟通不再高不可攀，这样小组便能减少进行有效交流的障碍。除了小组结构，小组的地理分布和场所位置在小组内部和外部交流的有效性程度上起着主要的作用。在他们对 Microsoft 的研究中， Microsoft Secrets, Michael A. Cusumano and Richard W. Sel
28、by 如此陈述：“单一地点的开发提供了项目参与人员在地理上的一个不变动的地域，他们可以集合在一起并且相互交流探索各种想法。频繁而易于实现的沟通将使较大的问题不至于变得更糟。将小组集合在一起工作也有助于加强小组标识和小组联合的意识。选择共同的工作场所被以往的经验证明是促进开放的交流的最有效率的方式，工作场所可以选择在大楼的同一区、共用的办公间或是特别为小组成员集合选定的空地旁的环境。开放的交流是 MSF 小组规则中一个获得成功的基本要素。虽然共同的工作场所仍是首要选择，但是业务性质和可供利用的促进交流的技术使得“虚拟”小组得以成功。在虚拟小组中，小组成员主要依靠电子手段相互交流和协作。交流跨越了
29、组织边界、空间和时间。与同事通过 Internet 进行实时的合作深远地改变了人们工作和共享信息的方式。Internet 正成为小组成员间交流的新标准，同时，协作软件为将来提高工作效率铺平了道路。虚拟小组的观念是关键，因为没有了将各种规则集合成一个协调单元的组织边界，小组的虚拟性要求小组具有更强的交流能力，信赖协议与关系，使行动项目不至于迷失方向的清晰的行动计划和支持项目与任务跟踪的自动化工具。虚拟小组中的潜在要素是每个角色通过依赖和信任其他角色而履行职责的能力。这种能力的培养来自于文化的交融、良好的管理以及当需要时在相同的地点一起工作的方式。行业研究发现虚拟小组成员往往不注重交流的技巧和小组
30、和谐。分析师认为这种疏忽是许多虚拟小组失败的关键因素。如果要建立一个虚拟小组，请任用具有以下特征的队员： 能够独立工作。 显示出领导技能。 拥有开发解决方案需要的特别技能。 能够与组织分享知识。 能够有助于发扬有效的工作方式。全员参与设计每个角色都应参与撰写产品规格说明书的工作，因为每个角色都对设计以及设计与个人目标、团体目标之间关系存在着特别的观点。因而孕育出一种氛围，使来自不同观点中的最优秀的想法能够显露出来。返回页首组队模型概述为了使一个项目取得成功，必须实现六个关键的质量目标，这种理念是 MSF 的基础。这些质量目标驱动小组并定义了组队模型。虽然整个小组都对项目成功与否负责，组队模型还
31、是将六个质量目标和分离的角色群联系起来以确保义务分明和中心明确。组队模型的六个角色群 产品管理、程序管理、开发、测试、用户体验以及发布管理 定义了确定职能领域以及和他们相关联的职责的通用方式。角色群常常仅仅被看作多个角色。无论那一种解释，这个概念是相同的：解决方案框架和组队模型是可伸缩的，以满足构建一个特别的解决方案的需要。一个角色或是一个角色群，可能包含一个人员或许多人员，这依赖于一个项目的大小和复杂程度，依赖于为完成功能区内的职责而需要具备的各项技能。MSF 组队模型强调将各个角色群与各项业务需求相校准的重要性。角色分组和职能领域与各项职责相联系，职能领域和各项职责分别要求有不同的规则和重
32、心。角色分组为一个协调良好并且各项技能和观点代表了所有基本项目目标的小组带来了动力。拥有一个清晰定义的目标将促进对各项职责的理解并且鼓励项目小组控制项目，这将最终带来一个更优质的产品。既然每个角色对项目的成功都有决定性作用，那么代表了这些目标的角色在决策时是平等的，具有均等的发言权。请注意，这些角色群并不表示任何形式的组织机构示意图或是工作职位调整，因为这些角色群将随着组织和小组的变化而产生很大的改变。更常见的是，角色将分布在 IT 组织内部的不同组群之间，有时还可能分布于业务用户社区或者外部的咨询师和合作伙伴中。关键在于清晰的确定履行某一特定角色群的小组个体以及与之相关的有助于目标实现的各种
33、功能、职责和分布。角色群 目标 职能领域 职责产品管理 满足客户 市场开发业务价值客户拥护产品计划作为客户的拥护者驱动共同的项目和方案设想管理客户需求说明开发和维护业务案例管理客户期望驱动产品特征、日程表、资源权衡决策管理市场开发、产品宣传和公共关系开发、维护和执行交流计划程序经理 交付满足项目约束的解决方案项目管理解决方案体系结构过程保证管理服务驱动开发过程以期按时的交付产品管理产品规格说明书 首席项目构架师促进小组内部的交流和商议维护项目日程表和报告项目状态角色群 目标 职能领域 职责驱使关键的权衡决策的实现开发、维护和执行项目总规划和日程表驱使和管理风险评估和风险管理开发 根据规格说明创
34、建解决方案技术咨询实现的构架和设计应用程序开发基础结构开发指定物理设计的特征估算完成每个特征所需的时间和精力构建每个特征并监督其实现准备部署时使用的产品为小组提供技术主题的专门知识测试 在所有产品质量事宜被识别并处理后进行发布测试规划测试工程测试报告确保了解所有问题决定测试策略和制定计划执行测试用户体验 提高用户效率 技术交流培训可用性用户界面设计国际化易用性为项目小组充当用户拥护的角色管理用户需求说明设计和开发性能支持系统驱动可用性和用户性能增效的权衡决策为用户提供帮助特点和帮助文档的规格说明书开展和提供用户培训发布经理 进行平滑的部署及日常运行基础结构支持操作业务发布管理作为各种操作、支持
35、与交付渠道的拥护者管理所得管理产品部署驱使可用性和可支持性权衡决策管理各种操作、支持和交付渠道之间的关系为项目小组提供后勤支持满足客户项目必须满足客户和用户的需求，并且以满足客户与用户需求作为成功的标准。项目可能只实现了预算和时间的目标但却没有满足客户的需要，那么这种项目仍是不成功的。发布满足项目约束的解决方案所有小组的一个关键目标是发布满足项目约束的解决方案。任何项目的基本约束包括预算和日程进度的约束。大多数项目使用“按时、按预算”作为评价成功的标准。根据规格说明创建解决方案产品规格说明详细的描述了小组提供给客户的可交付产品。精确的按照规格说明交付产品对小组来说是很重要的，因为规格说明书代表
36、着小组与客户之间的一项协议。在所有产品质量事宜被识别并处理后进行发布所有的软件在交付时都存在缺点。一个关键目标是确保那些缺点在发布产品之前被确定和处理。处理涉及了从修复存在疑问的缺陷到为这些周边工作的解决方案提供文档的所有工作。相比交付一个存在未辨识缺陷而在稍后也许将惊呆小组和客户的产品，交付一个已知错误而这个错误已被处理并提供了周边工作解决方案的产品更为可取。提高用户效率为实现项目成功，用户工作和操作的方式必须实现改善。交付一项拥有丰富特性与内容但却无法被目标用户所操作的产品将被认为是失败。进行平滑的部署及日常运行有时进行平滑部署的需要会被忽视。部署的理解也被或对或错地带入了产品本身。例如，
37、一个错误的安装程序可能导致用户认为安装好的程序也同样存在错误，既便这可能并不是真实的情况。因此，小组不应只做简单的部署；小组必须争取实现一个平滑的部署并为产品的支持和管理做好准备。这些内容可以包括在部署前确保培训、基础结构和支持的准备就绪。返回页首组队模型角色群图 1：组队模型角色群看全图返回页首产品管理角色群产品管理角色群的关键目标是满足客户。小组必须让项目满足客户的各种需求，以实现成功。然而，首先要做的是清楚的确定和了解客户！在某些案例中，客户要求的解决方案和特性集将与项目支持和投资商的要求不同。因此小组必须进行清晰区别和需求分析，提出使双方都获益的因素。只有这样，定制和满足期望的职责才能
38、够被指派到恰当的职能领域内。有可能项目只实现了预算和时间的目标而没有满足客户的需要，那么这个项目仍是不成功的。 MSF 组队模型为每个角色群规定了不同的职能领域以便更为精细的定义一套职责，角色通过各项职责的履行形成一套常用技能集。为了实现满足客户的目标，产品管理角色群要求有多个职能领域：产品规划、业务价值、客户拥护和市场开发。职能领域市场开发 驱动销售和影响目标客户的公共关系讯息 高度区别化，使解决方案在竞争获得优势 通过零售商配销使目标客户能够容易获得产品 提供支持，使客户在购买和使用解决方案时有肯定的体验业务价值 为项目定义和维护业务解释 定义和评价业务价值实现客户拥护 驱动共同的项目和解
39、决方案设想 管理客户期望和沟通产品规划 收集、分析客户和业务需求并按优先级排序 执行市场研究、市场调查和竞争情报与分析 确定业务效绩评价与成功标准 确定多版本发布计划市场开发市场开发是筹划宣传、销售和配销一个产品、解决方案或服务的过程或技术。市场开发包括几个方面：启动市场、维持市场与公共关系。在一个解决方案生命周期的进程中，市场开发的中心将发生转移。了解您的解决方案在生命周期中的市场定位对执行适当的行动是至关重要的。业务价值在业务价值职能领域内，产品管理为客户、业务决策制定者 (BDM) 提供 他们所要求的简明的预测方法 以判断花费在一项 IT 解决方案上的投资对业务活动所带来的财务上和操作上
40、的回报。为有效的提供一个可用的解决方案，产品管理必须了解客户的业务活动、各种成功因素和关键工作指标。可以将获得这些知识的过程定义为业务价值评定或关键性成功因素辨识。很明显，了解使客户获得成功的方式有助于确定和提出恰当的解决方案。随着规律性的渐增，进行 IT 投资需要进行深入细致的调查，许多 IT 相关的解决方案都需要在项目停止前进行财务评议。通过进行客观的支出回报分析，满足客户的可能性将增加。财务结果的计算完善了进行 IT 投资的业务解决方案的开发。客户拥护这一职能领域包括了高级别交流和客户期望管理的职责。高级别交流包括了公共关系、高级管理客户简报、市场推广、演示和产品启动。一旦项目设想被确定
41、，期望管理将成为产品管理的关键角色。期望管理被认为是首要的角色，因为它可能决定成败。有效进行期望管理的重要性可以用例子来描述，假如小组预期交付给用户 10 个产品特性（数据是随便给出的）。如果小组实际只交付了 2 个产品特性而不是客户所期望的所有 10 个，那么这个项目无论对客户还是对小组来说都是失败的。然而，如果产品管理在特性开发和产品研发期间与客户维持好持续的双向交流，客户期望将得以实现而保证最后的成功。产品管理可以包括让客户参与权衡决策制定过程以及告知客户不断变化的风险和其他难题。与之前的情形不同，客户能够评估开发状态并且同意小组在指定时间能交付所有的 10 个产品特性是不现实的，而只交
42、付了 2 个却是可以接受的。在这种情形下，交付 2 个产品特性现在符合了客户的期望并且双方都会认为这个项目是成功的。产品规划产品规划确定了为解决方案的多个版本所设定的要求和特性。产品规划的目标是使程序经理或开发人员尽可能以最少的时间更容易地理解一个解决方案的要求。首先，它要求完全理解解决方案的当前要求 业务需求是什么，客户如何使用该解决方案，支持的要点有什么以及有哪些可用的供选择的方案。其次，检查那些为使用该解决方案的客户实现增值的特性，例如实现新业务内容的入口、与其他系统的集成、更优良的工作效率、从其他解决方案上升级、减少支持费用等等。以这些知识为基础，产品规划员能够推荐出指派给每个解决方案
43、版本的特别的特性并且为这些特性按优先级进行排序。产品规划的核心是研究和分析。了解客户和业务的需求以及竞争状况，并给予研究和分析恰当的关注。这将防止在解决方案中加入不必要的特性。程序管理角色群程序管理角色的中心是实现在各类项目约束内交付解决方案的目标。可以将其看做确保项目出资人满意项目成果的过程。为实现这一目标，程序管理控制和驱动工作日程表、特征定制和项目预算。程序管理确保了在适合的时间交付出适合的解决方案，确保了在整个项目进程中理解和管理项目出资人的期望。以下是被选定的职能领域的描述：程序管理 跟踪和管理预算。 管理总的项目工作日程表。 驱动风险管理进程。 促进小组内部交流和商议。 跟踪项目进
44、度和管理项目状态报告。 管理资源配置。解决方案体系结构 驱动全面的解决方案设计。 管理功能规范说明。 管理方案功能范围和各类关键权衡决策。过程保证 驱动进程质量保证。 定义和推荐改进。行政服务 实现项目管理进程，支持小组领导使用它们 提供一套行政服务，支持有效的小组工作项目管理作为项目日程的控制者，项目管理收集所有小组日程，确认这些日程，并将他们整合到总日程表中。总日程表被跟踪记录并报告给小组和项目出资者。作为项目预算的控制者，项目管理通过从小组中所有角色收集资源需求促进项目预算的建立。项目管理必须理解和赞同所有的资源决策（硬件、软件以及人员）并且跟踪实际开支。小组和项目出资人都应收到该状态报
45、告此外，项目管理还协调各种资源，促进小组交流，帮助驱动关键性决策解决方案体系结构解决方案体系结构是程序管理角色群的职能领域，它对解决方案的逻辑设计和功能规范负责。解决方案体系结构专注于确保一个解决方案能够被指定的用户使用，以达到指定的有效性、效率、满意度目标。解决方案架构师的责任包括： 促进解决方案的总体设计。 管理功能规范。 管理解决方案范围和关键性取舍决策。拥有着逻辑设计的解决方案体系结构提供了解决方案的业务部分（像概念设计中产品管理的描述）和解决方案的技术部分（像物理设计中开发的描述）之间的至关重要的连接。解决方案体系结构扮演了功能规范管理人的角色。它促使小组与它们的其它角色的需求一起就
46、解决方案的内容和设计达成一致，并证明已经被项目风险投资者同意的方法是正确的。它还对支持需求的功能的可追踪性负责（并最终完善业务价值），因此所有支持规定需求的功能都是可见的，且改变任一功能小组都可以评定其对解决方案价值的影响。解决方案体系结构行为包括： 创建解决方案概念，并以客户的企业体系结构进行编排；设计版本发布策略；审查需求获取规划。 从结构/标准工作组和互操作相关处获取需求；促进逻辑设计程序；提供一个可追踪映象来跟踪支持需求和利益的功能；创建功能规范；定义临时发布。 管理功能规范的变更；维护可追踪映象；为其它小组角色和外部风险承担者阐明规范；就互操作问题同其它项目小组保持联络。 参与筛选过
47、程；管理项目风险投资者期望的解决方案内容。 为企业体系结构小组提供更新；为未来的版本发布更新需求。解决方案体系结构实施者的技术必须是可靠的，它们需要拥有广博的知识和经验，还要有能力使技术问题同潜在的业务需求发生关联。虽然对于被用于解决方案的具体技术解决方案，架构师可能依赖开发小组向他们提供专业知识，不过他们肯定能迅速抓住那些解决方案细节的本质，了解它们的内在联系以及它们对部署解决方案的环境的影响。解决方案架构师肯定还能够同客户的架构师讨论那些影响，使得他们可以迅速的解决被提议的解决方案同企业体系结构之间的任何冲突。过程保证程序管理的过程保证职能领域确保项目小组采纳的过程致力于适应项目整体目标、
48、强调排除有缺陷的消息来源。过程保证对两个主要的区域负责： 定义被小组使用的关键项目过程，为小组的执行提供建议与指导。 承担过程、建议改进、和一致性监控的审查，以验证它们的关联性和有效性。过程保证致力于下列行为： 定义符合项目设计的项目协议和过程。 为项目过程的有效执行提供建议和指导；验证过程的一致性；承担里程碑的审查；建议过程改进。由于得益于一个独立于项目小组的地位，过程保证能够有一个客观的看法。因为这个原因，它经常从项目小组的外部进行管理，即使项目的大小使它不能成为一个专职的角色。行政服务本职能领域属于程序管理角色群，对执行项目管理过程和为项目小组提供行政支持负责。项目行政职能领域确保项目小
49、组执行过程符合项目管理定义的项目设计规范。它对确保项目小组能在最小的官僚作风下有效的运转负责。项目行政责任包括： 利用它们执行项目管理过程和支持小组领导。这包括统一小组输入以维护总体规划与进度，帮助领导程序报告。 提供一套诸如安排日程会议、常规获取、以及合同管理这样的行政服务来有效支持小组工作。项目管理致力于： 支持诸如有效的从第三方召集小组成员；管理合同安排；组织小组设施（空间、电话、安全访问等等）这样的项目启动过程。 建立统一的规划框架；帮助小组领导规划和日程安排；统一小组输入以维护总体规划与进度；建立财政与进度报告过程。 帮助小组领导进度报告；构建整体进度和财政报告。 确保在项目完成时关闭所有的行政系统。 执行一般的行政支持行为。比如：安排日程会议；执行风险与问题管理过程；维护主要风险表、操作表等各种表单；生成财政和进度报告；管理小组工作场所以提高士气。项目管理角色需要一个强有力的行政能力的组合，关注项目规划和日程安排技术中的可靠经验的细节，还有对供应方组织中的运作规则和指导方针的良好的了解。一个大型的项目为在项目指导旁边工作提供一个极好的机会，确立了指导未来的项目需要的经验。返回页首开发角色群
