2020微软的组织结构
微软公司的组织结构：
微软公司
Microsoft
视窗产品部
Windows Group
办公产品部
Office Group
商业方案部
Business Solution Group
微软网络部
MSN Group
服务器和开发工具部
Server and Tools Group
移动装置部
Mobile Devices Group
家庭娱乐部
Home & Entertainment Group
图 1‑1 微软公司的商业机构
从职能上讲，微软公司各部门都可以归入以下三个大类：
l 研发部门(R&D)：包括所有负责产品开发的技术部门，如平台产品部、开发工具部等。在微软，大约有超过3万名的工程师在从事产品软件开发工作。
l 全球销售、市场和服务部门：负责微软产品在市场上的宣传、推广、销售和服务、支持等工作。
l 基础研究部门(Research)：即微软研究院，是微软公司内专职负责基础科学和前沿技术研究的机构。微软研究院在多媒体用户界面、数字图像处理、自然语言识别等技术领域拥有多项专利。
上述三大类机构在微软公司内部相互独立，有各自的职责范围和工作方式，相互没有管辖或者汇报关系。在美国以外的国家和地区中，中国是唯一一个拥有微软所有三大类部门四个分支(亚洲研究院、销售和市场、研发中心、全球技术支持中心)的地方。
以下所列的是微软最新的7大商务部门(如图 1‑1)中部分负责的一些产品和服务：
l 视窗产品部：
n Windows操作系统：世界上大多数个人电脑使用的操作系统。
n 嵌入式操作系统(Windows Embedded OS)：为嵌入式装置设计的新产品。
n CE 操作系统(Windows CE OS)：为掌上电脑等所设计的操作系统。
n 平板式电脑操作系统(Windows Tablet OS)：平板式电脑视窗操作系统。
l 办公产品部：
n Office办公软件：这是微软公司最重要的产品之一，在办公类软件市场上占有绝对优势。
n BackOffice：后台应用软件。
n Exchange Server：微软公司著名的邮件服务软件。
n 其他服务类软件。
l 服务器和开发工具部：
n SQL Server数据库软件。
n 数据访问工具。
n 编程工具：如Visual Studio .NET等。
n BizTalk Server
l 消费类产品部：
n 家用和零售产品。
n 信息家电产品。
n MSN.com.网络服务。
2. MSF组队模型?
MSF组队模型总结了微软在成功的项目组中组织人力资源、安排工作任务的基本原则和方法，该模型定义了项目组内的角色分工、任务分配和人员职责，并为项目组成员提供了有关在项目生命周期中如何实现特定目标的指导性建议。
在微软内部，依据MSF组队模型创建和管理的项目组都是小型的、多元化的团队(在微软，即便是那些大型的项目组，也都是依照类似的原则组建的，从逻辑上可以被划分为若干个小型的团队)，这些项目组拥有严格的产品发布期限，项目组成员分工协作，各司其职，扮演着相互依赖、相辅相成的不同角色，共同完成项目的开发工作。项目组成员在特定的技术或业务领域拥有专业技能，在统一的项目指导思想的指引下，他们对各自的工作目标负责，每一个成员都参与项目的设计和讨论，并从过去的项目实践中吸取经验。项目组成员在同一地点办公，共同管理项目过程，制定相关决策。
3. MSF组队模型的基本原则
小型的、多元化的项目组(Small, Multidisciplinary Teams)
MSF组队模型建议我们在项目管理中采用小型的、多元化的项目组从事项目开发工作。正如比尔·盖茨先生所说的那样，只有在小型的、拥有确定目标和预算的项目组中，项目组成员才能更好地分工协作、更好地发挥个人在技术或管理上的经验和技能。
与其他类型的项目组相比，小型的、多元化的团队拥有许多先天的优势，如交流成本、运营成本和管理成本低，决策和执行速度快，产品质量高等等。
例如，假设一个规程经理需要管理40个项目组成员，为了保持项目组内的有效沟通，他每周都要与每一个项目组成员进行至少一小时的单独谈话，那么，他就没有任何时间处理其他事情了。况且，不同的人有不同的个性和不同的观点，我们很难把许多人集中在一个项目组中，统一安排工作。相反，如果把这40个人按照不同的层次结构或职能单位划分成几个小的项目组，每个小项目组大约5个人，项目组中每个人的职责就会更加清晰，我们也能更容易地对项目组成员进行管理，与项目组成员沟通和交流，更容易地控制每个人的开发质量和进度。
这里所说的团队的多元化体现为，在一个项目组内，甚至在一个角色内，通常有多种不同的工作方式，需要其成员具有不同的工作技能或经验水平。在大多数项目中，有着不同的背景、不同的培训经历和不同的专业技能的项目组成员按照各自的工作方式分工协作，共同构成整个项目组或某个特定的职能角色，共同完成项目开发工作，共同保证产品的质量。
角色依赖和职责共享(Interdependent roles and shared responsibilities)
在项目组内，每一个角色都对项目本身以及他们各自的主管部门负责，以实现该角色的工作目标。这就是说，每一个角色都分担了保证最终解决方案得以顺利完成的一部分责任。整个项目的各项工作职责通过对等团队(Team of Peers)的结构被项目组中不同的角色和成员共享，项目目标也通过不同角色的工作目标得以实现。
在项目组中，不同角色的工作是相互依赖、相辅相成的，这是因为：首先，我们无法将项目组中不同角色的工作完全孤立开来;其次，如果每个角色都对整个项目蓝图有一个清晰的认识，项目组的工作效率就会成倍提高。相互依赖的工作促使所有项目组成员在他们直接负责的领域之外主动发表意见、贡献力量，这显然可以提高项目组内的知识、技能和经验的共享程度。
专深的技术水平和业务技能(Deep technical and business acumen)
MSF组队模型提倡在深入理解客户的业务需求、熟练掌握相关技术的基础上进行项目开发，完成项目决策，这就要求项目组成员在各自的领域里具备专深的技术水平和业务技能。对产品开发而言，如果不能透彻地了解客户需求，熟悉客户的业务流程和业务模式，就无法真正把握产品的设计目标，无法开发出可以令客户满意的产品。同样的道理，如果项目组的成员对相关领域的技术发展情况不甚了了，项目组也不可能使用最合适的技术进行产品开发，不可能确保最终产品的性能和质量。
以产品发布为中心(Focus on competency and shipping products)
所有项目组成员都要有强烈的产品意识，项目组中的所有工作都应以按时发布高质量的产品为中心。这里的产品意识不仅仅指在市场上或在公司内部发布软件产品，在更高的层面上，产品意识要求你将你自己每一次劳动的成果都看成是你自己贡献给整个团队的一件产品。
事实上，MSF倡导为每一个产品给出一个显著的标识，这样，项目组的成员就会拥有更加强烈的参与感和主人翁责任感。微软通常的做法是，根据产品或项目组的不同，赋予每个产品或每个产品单元一个内部代码，这显然有助于明确产品的来源，考察项目组的工作，增强项目组成员的责任心，并能显著地提高项目组的士气。项目组也经常把产品代码印在T恤衫、咖啡杯或者其他小礼品上，这些办法可以有效提高项目组的自我认同感，增强项目组的凝聚力。
一旦你意识到你是在一个产品项目团队中工作，你就可以发现，无论你的工作结果是什么，你都可以把你自己的工作看成是一件特定的产品。MSF中有关产品开发的各种准则和方法也都可以适用于你自己的工作过程，以确保你自己的产品可以如期交付。
拥有产品意识也意味着你应当更多地关注整个项目最终发布的产品，而不是发布产品的过程。这并不是说产品开发过程不重要，这只是说我们应当从整体目标出发，而不是从局部利益出发开展工作。在一个拥有产品意识的项目组中，每一个项目组成员都可以感觉到自己对最终的产品发布负有重要的责任。
明确的目标(Clear goals and objectives)
是否拥有清晰、明确的项目目标，是否有统一的工作方向，这是项目管理中最重要的问题之一。这是因为，没有统一的方向，没有明确的目标，项目组成员就没有办法协同工作，没有办法为项目组贡献力量。
项目组必须拥有明确的项目目标，这一目标还必须与客户的最终需求相吻合。这样，项目组的开发工作才能始终和客户的业务需求保持一致，项目组开发的产品才能真正解决客户面临的实际问题。
客户的主动参与(Active customer participation)
赢得客户满意度的一个关键方法是邀请客户参与产品的设计，并在产品开发过程中随时征询客户的反馈意见。这一做法可以使项目组与客户在需求和项目目标上始终保持一致，客户对产品特性的实时反馈也可以不断激励项目组改进技术，改善产品。事实上，组队模型中的产品管理角色就常常以客户的身份向项目组提出业务需求，有时，产品管理角色中的某些成员甚至是由客户直接担任的。
分享产品的前景(Shared project vision)
MSF强烈建议在项目组内分享产品的前景或最终目标。项目组的所有成员都应该对产品前景有清晰的认识和明确的认同，每一位成员都以自己能为产品的美好前景贡献力量而自豪，每一位成员都在产品前景的激励下努力工作。
如果项目组不能在所有成员中分享产品的前景，项目组成员就会对工作目标产生困惑或迷茫，每一个成员都会对项目前景产生自己的看法，每一个成员判断自己工作是否成功的标准也会大相径庭。这显然无法调动项目组成员的积极性，无法切实保证产品开发的顺利进行。
所有人都参与设计(Everyone participating in design)
项目组中的每一个角色、每一个成员都应当参与产品的设计过程。不同的角色、不同的成员对产品的设计有着不同的视角和看法，他们可以从不同角度对产品设计提出有益的建议。让所有人都参与设计的做法可以在项目组中培养集思广益的氛围，并有助于项目组在产品设计过程中收集到所有最有价值的信息，使设计出的产品更加趋于完善和合理。
认真从过去的项目中吸取经验(Deliberate efforts to learn from past projects)
项目组中的每一个成员都应该善于从过去的工作中吸取经验教训，在学习和总结中提高自己。没有哪一个项目组可以永远成功，对于那些已经结束的项目，无论项目组经历的是成功的喜悦，还是失败的痛苦，我们都应该认真、细致地总结和反省。只有那些善于从成功的项目中总结项目管理的诀窍，勇于对失败的项目进行分析和反省的项目组才能不断进步。
共同管理，共同决策(Shared project management and shared decision-making)
在MSF组队模型中，每一个团队成员的职责可能都不尽相同，但每个成员都对项目管理和项目组中的重要决策负有一定的责任，都应当积极参与项目组中每一个重要的决策过程。当然，共同管理和共同决策并不意味着项目组中的所有人都可以不受限制地对项目组的工作安排指手划脚，项目组中每一个角色的负责人仍然拥有该职责领域的最终决定权，但任何项目决策都应该在集思广益、广泛征求项目组其他成员意见的基础上做出。
项目组成员在同一地点办公(Team members working together at one site)
尽管今天的通信技术已经日臻完美，项目组的成员们即使在不同的地点工作也可以通过电话和电子邮件相互沟通，但过去成功的项目管理经验仍然告诉我们，那些所有成员都在同一个办公地点工作的项目组有着更高的沟通效率和更好的工作业绩。很显然，如果项目组的所有成员都在同一个楼层或是同一间办公室里工作，他们之间就会有相当多的机会进行非正式的交流，项目组中的人际关系往往会因此而得到改善，项目中很多棘手的问题也可以在电梯间、午餐桌等非正式的场合里得到解决。这也是微软解决方案框架为什么要特别强调项目组小型化、办公地点尽量集中的原因所在。
大型项目组也像小项目组一样运转(Large teams working like small teams)
微软解决方案框架建议使用小型项目组来完成项目开发工作。对那些规模较大的项目来说，我们应当在项目组成立之初就把较大的项目团队拆分成若干个结构清晰、目标明确、可以灵活管理的小型项目组。这些小型项目组按照MSF组队模型进行管理和角色划分，并对各自的工作目标负责。小型项目组之间通常是并行的工作关系。在微软公司的大型项目中，每隔三到六个月，项目管理者往往会根据项目的整体进展情况对项目内的小型项目组进行重组，以适应最新的项目需求。从总体上看，微软内部的大型项目在运作方式上都非常近似于MSF中定义的小型项目组，并能够像小型项目组一样具备沟通便捷、生产效率高等诸多优点。
4. 小型项目组的优势
建立小型化、多元化的项目组是MSF组队模型的基本准则之一。如前所述，与机构繁冗、人员结构复杂的项目组相比，小型项目组具备以下优势：
l 交流和沟通便捷：小型项目组的交流节点少、沟通路径短，能够有效降低项目组内部的交流和沟通成本。
l 运营成本低：小型项目组中不需要配置很多管理和协调人员。在日常工作中，项目组成员花在管理、协调上的精力较少，项目组在场地、办公等方面的费用支出也不会太多。
l 管理成本低：很明显，一个管理30人团队的经理将把大多数时间花在日常管理而不是产品开发上，而在一个只有5到6人的项目组中，经理可以将更多的精力花在与产品开发直接相关的领域里。
l 产品发布周期短：小型项目组拥有较小的项目目标和较明确的产品需求，可以集中力量在较短的时间内推出完善的产品。
l 产品质量高：与大型项目组相比，小型项目组在开发产品的过程中，因为沟通、协调或管理方面的原因导致产品故障的概率大大降低。此外，在一个每人都可以自由发挥特长的小型团队里，项目组成员的工作热情较高，产品质量可以因此得到有效的保证。
在小型的、多元化的项目组中，项目组成员的分工不同、担任的角色不同，每个人都拥有特定的工作目标，每个人的工作目标共同构成了统一的项目需求。在这样的氛围里，项目组成员可以更容易地分工协作、取长补短，更好地完成项目开发任务。
5. 成功的项目组
通常，成功的项目组都具有以下特点：
l 有经验的项目领导者：拥有一个经验丰富、善于管理和激励团队成员的项目带头人是项目成功的必要条件之一。一个出色的项目领导者可以在有限的资源条件下，最大程度地激发项目组成员的热情，大幅度提高项目组的生产效率和产品质量。
l 积极参与项目决策，主动贡献力量并承担责任的项目组成员：任何项目的成功都离不开项目组中每一个角色、每一个成员的共同努力，在一个人人都有权利、有责任参与项目管理和项目决策，人人都能主动担负工作任务的项目组中，项目开发工作没有理由不取得成功。
l 以产品发布为共同的目标：成功的项目组必须在项目组成立之初就确保项目目标的清晰和明确，项目组内的所有成员都应当以产品的发布为最高使命。
l 共同分享项目前景：与项目组的所有成员分享美好的项目前景是一种有效的激励和管理手段，它可以在项目组中营造出一种主动参与、积极奉献的良好氛围，这也是项目能否取得成功的关键因素之一。
在微软公司，当你赋予一个项目组或一个项目组成员某种职责的时候，它或他就拥有了对该工作的决策权，同时也必须对该工作的结果负责。
6. 组队角色
MSF组队模型将项目组中的所有职能划分为六种角色，他们是产品管理角色、规程管理角色、开发角色、测试角色、用户体验角色和发布管理角色。如图 6‑1所示
规程管理
角色
开发角色
测试角色
发布管理
角色
产品管理
角色
用户体验
角色
沟通
图 6‑1 组队模型的六种角色
图 6‑1中的六种项目角色处于对等的项目组结构中，各自完成特定的职能。在六种角色构成的环形结构里，沟通(Communication)占据了核心地位，这是因为：在MSF组队模型中，交流和沟通是促使六种角色协同工作，共同完成项目目标的关键因素。所有成功的项目组都拥有顺畅的内部和外部沟通渠道，项目组成员之间、项目组与客户之间、项目组与其他项目组之间都能够随时保持信息的正常交流和反馈。
下面，我们分别阐述这六种项目角色在项目组中的职能、工作方式和主要特点。
产品管理角色(Product Management)
产品管理角色的主要使命是提高客户满意度。在项目组内，通常由产品经理担任此角色。
得不到客户满意的项目永远无法取得成功。当然，在项目组成立之初，产品经理就必须明确谁是我们的客户，客户需要我们做什么。在某些时候，最终客户的需求可能和项目发起人或项目出资人所描述的需求有较大的差异，我们必须对双方的需求内容进行清晰的界定和仔细的分析。只有在明确了项目需求的基础上，客户的需求才能在项目开发过程中转化为产品的特性。如果客户的业务需求与最终产品的特性不相吻合，即便我们在规定的预算和期限内开发出了产品，这也是一个失败的项目。
在大多数时候，项目组内的六个角色之间并没有时间上的先后顺序之分，不过产品管理角色可能是一个例外。这是因为，产品管理角色在产品经理响应客户需求并着手筹备项目组的时候就已经存在了。
产品经理的主要工作内容包括：
l 在项目组中扮演客户代言人的角色：对项目组内的其他角色来说，产品经理就是临时的客户，产品经理的发言事实上代表了客户的想法和意见。
l 确保项目组成员对项目前景和项目范围了如指掌：产品经理有义务随时将客户的需求和产品的前景告知项目组成员，以保证项目目标的一致，并不断鼓舞项目组成员的士气。
l 管理客户的需求定义：产品经理应当为规程经理、开发人员和测试人员准备一份书面的客户需求说明书，以使得相关的开发人员能在最短时间内把握客户的需求，设计出可行的产品方案。
l 开发、管理和提供业务用例说明(Business Case)：业务用例说明是对业务需求的细化，是对每一个特定业务处理环节的书面说明，它可以从项目组的角度更加准确地界定客户需求，展现项目目标。
l 管理客户的预期目标：如果客户预期的产品与最终得到的产品不是一回事，项目就一定是一个失败的项目。产品经理必须经常与客户沟通，将项目组所理解的和正在开发中的产品特征描述给客户，将项目的进展情况告诉客户，并获取客户的反馈意见，以确保客户预期的产品就是项目组正在开发的那个产品。
l 控制产品特性和开发周期之间的关系：产品经理控制着项目的执行范围。如果产品的特性过多而来不及开发的话，产品的开发周期就势必要相应地延长;反之，如果客户对产品开发周期的要求比较苛刻，产品管理角色就不得不暂时舍弃那些不太重要的产品特性。前面提到过的“资源—进度—功能”三角形就形象地反映了这一原则。而在项目组中，根据三角形原则对产品特性进行取舍的角色正是产品经理。
l 管理市场宣传和公共关系：市场工作是通过市场渠道宣传产品、解决方案或服务并最终促使客户产生购买需求的行为。产品经理有责任配合公司内部的市场部门，做好产品发布、产品宣传、公共关系等相关工作，促使用户接受和喜爱项目组开发出来的产品。
规程管理角色(Program Management)
规程管理角色的主要使命是在规定的项目资源、期限等限制条件下，确保产品能够如期发布。我们通常所说的规程经理就扮演了这一角色。为达到产品发布的目标，规程经理需要制定和管理项目日程、费用预算、产品特性说明等文档，并负责推动产品开发过程顺利进行。规程经理有责任通过对整个项目开发过程的管理，确保项目发起人的意图得到落实，确保项目组可以在合适的时间交付合适的产品。
规程管理角色往往容易和传统项目管理理论中的项目经理相混淆。在MSF对等团队的组织结构中，六个组队角色的地位是相互平行、相辅相成的，一个项目组并没有一个唯一的最高领导人。规程经理只是项目开发过程的组织者和管理者，而不是项目组的领导者。
规程经理的工作内容主要包括：
l 推动产品开发过程：规程经理有责任保证产品在规定的期限内发布，有责任保证产品特性符合产品的需求定义。
l 管理产品范围和产品特性说明：规程经理应当确保所有产品特性都来自最终客户的需求，规程经理编写并维护产品特性说明文档(Feature Specifications)，这一文档可以被看作是项目组与客户就产品特性达成的一份契约。
l 推动项目组内的交流和讨论：开发过程中有关技术细节、项目进度、开发方式的交流和讨论通常都由规程经理发起和组织，项目组成员在规程经理的协调下保持良好的沟通。
l 管理产品开发进度，汇报项目状态：规程经理创建、维护和管理产品开发进度表，随时报告项目进度和项目当前状态，并负责管理项目组内的资源分配。这一工作内容与传统意义上的项目经理有些近似，但在MSF组队模型中，规程经理的工作性质更偏重于一种服务，即规程经理通过自己的服务促使项目组内的其他成员更好地完成工作任务。
l 控制项目开发中关键的取舍和决策：当项目开发过程需要根据具体情况进行调整，产品的开发方式、技术结构、资源分配等需要根据当前的客户需求及项目资源情况进行取舍的时候，规程经理对此拥有最终的决定权。
开发角色(Development)
项目组内的开发人员扮演了MSF组队模型中的开发角色，他们的主要任务是使用适当的技术和工具实现项目目标，满足客户需求。除了技术因素以外，开发人员还必须仔细考虑可能影响产品质量的每一个开发环节，确保最终产品可以真正满足客户需求。
此外，作为创造产品的工程师，开发人员还应当承担起技术咨询的职责，即在项目组内扮演技术顾问的角色。也就是说，开发人员在项目开发过程中，不但要根据客户需求，设计和实现产品特性，还有责任从技术角度对项目决策提供建议，帮助项目组防范风险。
作为产品的开发者，开发人员为产品提供技术层面的解决方案，设计产品的技术细节，在谨慎评估的基础上使用最合适的技术手段实现产品的功能特性。开发人员创建与自己的开发工作相关的开发进度表，管理自己可以支配的开发资源。
有人说编写代码的开发人员只不过是项目组中的“蓝领”工人，这是一种关于开发人员的错误认识。在微软公司，开发人员通常都拥有著名大学的学士、硕士甚至博士学位，他们主动参与产品的设计过程，在设计阶段可以为规程经理和产品经理提供许多有价值的信息，他们也亲自设计具体功能模块的实现算法。
例如，微软公司的资深工程师，C#语言的设计者安德斯·海尔斯伯格(Anders Hejlsberg)就是一个著名的“程序员”。他加入微软之前就曾经主持开发过Turbo Pascal、Delphi等著名的开发工具。在微软，安德斯·海尔斯伯格将他的聪明才智贡献给了微软新一代的网络应用平台MS .NET和新一代网络开发语言C#。无论从哪个角度来说，他都是当今世界上最好的程序员。
开发人员的工作内容主要包括：
l 完成产品特性的物理设计：物理设计过程可以确保开发人员完全理解并可以用技术手段实现规程经理的所有功能规范(Functional Specification)。
l 在项目组内承担技术顾问的职责：在产品开发的早期阶段，开发人员从技术角度对客户需求进行确认，在产品开发过程中，开发人员就技术问题为项目决策提供建议，在技术层面帮助项目组防范风险。
l 确保每一个产品特性在规定的时间内完成：开发人员需要在规定的时间和资源条件下，利用合适的技术和工具实现每一个产品特性，对产品进行初步的测试。
l 使产品达到可发布的状态：为了顺利发布产品，开发人员可能需要编写特定的安装和配置程序，提供给测试人员和最终用户使用。
测试角色(Testing)
测试角色是项目组内保证产品质量的最后一个环节。实践证明，所有软件产品都可能存在缺陷或错误，测试人员的主要任务就是在产品最终发布前找到尽可能多的缺陷或错误。即便开发期限或开发资源不允许项目组改正所有已发现的Bug，测试人员也应当尽可能准确地定位所有已发现Bug的位置，以便在产品的后续版本中改正Bug。
测试人员的工作内容主要包括：
l 制定测试策略和测试计划：测试人员在测试之前应该对用户的业务需求和产品的功能特点有一个清晰、透彻的把握，并以此制定周密的测试计划。
l 确保产品的所有特性都经过了严格的测试：测试人员应该通过严格的测试了解产品的每一个细节，在产品最终发布之前对产品功能和性能进行科学、完整、周密的检验。测试人员也同时负责测试所需的软件工具、脚本程序、技术文档等的编写工作。
l 向项目组提供翔实、准确的测试报告：测试人员应及时告知软件开发人员当前版本Bug的分布情况及位置，跟踪每一个Bug的发现、报告、修正和复核的全过程，管理和维护Bug的优先级关系，确保所有已发现的软件故障都在项目组的有效管理和控制之中。
用户体验角色(User Experience)
用户体验角色的主要任务是协助用户更好地使用产品，排除用户在使用产品时遇到的问题和障碍。
用户体验角色的主要工作内容包括：
l 在产品设计阶段确保产品可被最终用户接受：软件产品应满足操作简单、易于学习掌握、可供不同经验水平的用户使用的要求，否则就无法被最终用户接受。用户体验角色在项目开发过程中应代表最终用户向产品开发人员提出有关产品使用和操作方面的建议，帮助项目组设计产品特性中可对用户使用产生影响的部分，并确保与用户操作相关的各类文档的准确和完整。
l 对产品的国际化功能提供支持：帮助项目组设计和开发适用于全球市场的国际化软件产品，这包括软件产品的全球化(Globalization)和本地化(Localization)两类工作内容。产品全球化指的是设计和开发那些可以用最小代价满足世界上不同地区市场需求的产品，产品本地化是指将软件产品的用户界面、帮助文件、印刷或联机文档、市场资料及Web站点等内容转换为符合特定地区市场中语言、文化习惯的形式。
l 设计和开发产品的技术支持系统：这包括设计、编写和开发与产品相关的技术问答(Q&A)、术语词典、安装和升级手册、用户手册、联机帮助、操作向导以及疑难解答等等。
l 用户培训：设计与产品操作、管理或开发相关的培训策略、培训规划、培训方法或培训课程，并通过不同的途径帮助尽可能多的用户提升技能、掌握产品。
l 确保产品的可用性：用户体验角色有责任保证产品可以有效帮助目标客户完成既定的工作任务，并可获得较高的用户满意度。此方面的工作内容主要包括，收集、统计和分析用户的使用习惯，编写使用情境描述(Usage scenarios)和用例说明(Use cases)，收集用户在测试或使用过程中的反馈信息，帮助产品开发人员理解用户的使用过程，设计出最佳的业务模式和业务流程。
l 图形用户界面设计：规划、组织和设计软件产品的图形用户界面或与之相关的操作流程，确保产品的操作界面符合业界标准和用户使用习惯。
发布管理角色(Release Management)
MSF组队模型中发布管理角色的主要任务是确保产品的顺利发布，为项目组的正常运营提供服务和支持。发布管理人员的主要工作内容包括：
l 代表项目组协调公司内的运营、支持、发布渠道等部门的工作：发布管理人员协调项目组外部与产品发布相关的工作，帮助项目组解决日常工作中遇到的各类问题，确保产品的顺利发布。
l 项目组的后勤和基础设施管理：为项目组提供产品开发所需的办公环境，采购相关的软件工具和硬件设备，创建、管理和维护项目组使用的IT系统。
l 管理产品发布事宜：发布管理人员负责制定和执行产品发布的计划，协调与产品发布相关的市场、渠道等部门共同完成产品发布工作。
l 参与和管理、支持相关的项目决策过程：帮助项目组完成与产品发布相关的项目决策，在产品设计阶段就与产品管理、支持和发布相关的内容提出建议。
l 管理产品的认证或许可模式，创建并分发产品的序列号、许可协议等。
u 按产品特性划分项目组
对于大型项目，我们可以按照产品特性将整个项目划分成多个小型的产品特性项目组(Feature Team)。这种管理方式是和现代企业使用的矩阵管理模型相适应的。例如，在企业的日常组织结构内(现代企业的组织结构相对比较扁平)，测试部门的测试工程师统一汇报给测试部门经理，开发人员则汇报给开发部门经理。当项目启动时，项目发起者可以根据产品特性，从不同部门(如测试部门、开发部门等)挑选最合适的工程师组成多个小型项目组，每一个小型项目组具有多种职能角色，负责某一个或某一组产品特性的开发。同时，不同职能角色的经理或主管人员还可以临时组成一个领导小组，在项目进展过程中对整个项目进行协调和监管。
图 6‑2显示了一个酒店管理软件的项目组结构：在一个由产品管理、规程管理、开发、测试等角色主管组成的领导小组的管理之下，负责“接待”、“客房预订”、“结帐”等三个产品特性的项目组并行完成项目开发工作。
资源
接待功能开发组
客房预订功能开发组
结账功能开发组
领导小组
规程管理
产品管理
测试
发布管理
用户体验
开发
规程管理
开发
测试
规程管理
开发
测试
规程管理
开发
测试
图 6‑2 按产品特性划分项目组
在具体的产品特性项目组内，根据不同产品特性的开发需要，可以适当调整项目组内的角色划分。例如，图 6‑2中的三个产品特性项目组都只拥有规程管理、开发和测试三种角色。不一定非要在每一个小型项目组中设置所有六种职能角色。
此外，不同产品特性项目组在整个项目范围内，共同分配、管理和使用相关资源。整个项目的大部分可用资源都是由这些小型项目组共享的(图 6‑3)：
共享资源
规程管理
产品管理
测试
发布管理
用户体验
开发
接待功能开发组
客房预订功能开发组
结账功能开发组
规程管理
开发
测试
规程管理
开发
测试
规程管理
开发
测试
图 6‑3 产品特性项目组共享相关资源
按照产品特性划分项目组的做法有利于增强每一个小项目组的责任感，有利于在每一个产品特性项目组之间保持竞争和激励机制，有利于对项目总体目标的控制和把握。这是因为，在这样的项目组管理机制中，每一个小型项目组都为自己开发的那部分产品特性负责，每一个项目组都拥有足够的、与工作目标相关的可用资源，每一个项目组都必须自主地完成相关工作范围内的项目决策。当然，项目领导小组在这种组织结构中仍需要开展大量的协调和监管工作，以确保不同产品特性之间可以顺利连接，确保不同项目组开发出来的产品特性在可用性和易用性方面保持一致。
u 按职能划分项目组
在某些时候，我们也可以将大型项目组拆分成多个不同的职能项目组(Function Team)。职能项目组是那些只担负某种职能角色的项目组，或者说，职能项目组是组队角色内部的项目组。
当项目规模特别庞大，项目组中的某个或某几个职能角色需要更多的资源配置的时候，特定的角色就可以由一组人员来担任，这一组人员以小型项目组的方式工作，共同完成该角色的工作目标。例如，在微软公司，许多项目组都有一个产品规划专员(Product Planner)和一个产品市场专员(Product Marketer)，这两个岗位都属于产品管理角色的范畴，前者更加关注客户需要的产品特性，后者则注重向潜在客户宣传产品，他们共同构成了产品管理角色内部的小型项目组。
一个分工更加细致的产品管理项目组如图 6‑4所示：
产品总体
管理
市场调研
宣传
公共关系
产品规划
市场工作
图 6‑4 产品管理项目组
类似的，一个具有项目组结构的规程管理角色如图 6‑5所示：
规程总体
管理
项目协调
产品架构
版本管理
图 6‑5 规程管理项目组
开发角色也可以拥有内部的项目组结构，开发人员可以按照用户层、业务逻辑层、数据层的原则分成不同的团队，或者根据需要分为整体解决方案开发人员和组件开发人员。一个开发项目组的例子如图 6‑6所示：
开发管理
数据库
系统服务
用户界面
图 6‑6 开发项目组
拥有内部项目组结构的测试角色如图 6‑7所示：
测试管理
功能测试
集成测试
压力测试
配置测试
图 6‑7 测试项目组
用户体验角色也可以拥有类似的内部结构(图 6‑8)：
用户体验
管理
媒体管理
文档编撰
用户资源
设计
本地化
图 6‑8 用户体验项目组
具有内部结构的发布管理项目组如图 6‑9所示：
发布管理
项目沟通
项目运营
系统管理
渠道管理
支持平台
HelpDesk
内部培训
图 6‑9 发布管理项目组
通常，职能项目组内部拥有简单的层次和级别关系。例如，规程管理项目组内部，不同分工的项目组成员都要向规程经理汇报工作。但是，角色内部的级别关系并不影响组队模型整体上的对等团队结构，无论是否拥有内部项目组结构，每一种角色在组队模型中的地位及其承担的任务都不会发生变化。