《信息系统项目管理师总结》 第二章 项目范围管理
信息系统项目管理师的十大管理内容。
二、项目范围管理
1、规划范围管理
2、收集需求
3、定义范围
4、创建工作分解结构（WBS）
5、确认范围
6、控制范围
一、规划范围管理
规划范围管理是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，其主要作用是在整个项目中对如何管理范围提供指南和方向。
>>> 输入：
1、项目管理计划
2、项目章程
3、事业环境因素
4、组织过程资产
>>> 工具和技术：
1、专家判断
2、会议
>>> 输出：
1、范围管理计划
范围管理计划是制订项目管理计划过程和其他范围管理过程的主要输入，包含如下内容：
（1）如何制订项目范围说明书。
（2）如何根据范围说明书创建WBS。
（3）如何维护和批准 WBS。
（4）如何确认和正式验收已完成的项目可交付成果。
（5）如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相联。
项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项。根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的。
2、需求管理计划
需求管理贯穿于整个过程，它的最基本的任务就是明确需求，使项目团队和用户达成共识，并建立需求基线。另外，还要建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
需求管理计划（ Requirements Management Plan）描述在整个项目生命周期内如何分析、记录和管理需求。主要包括以下内容。
（1）如何规划、跟踪和汇报各种需求活动。
（2）需求管理需要使用的资源。
（3）培训计划。
（4）项目干系人参与需求管理的策略。
（5）判断项目范围与需求不一致的准则和纠正规程。
（6）需求跟踪结构，即哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求。
（7）配置管理活动。
二、收集需求
>>> 输入：
1、范围管理计划
2、需求管理计划
3、干系人管理计划
4、项目章程
5、干系人登记册
>>> 工具和技术：
1、访谈
2、焦点小组
将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更加热烈。
焦点小组是一种群体访谈而非一对一访谈，可以有6~10个被访谈者参加。针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的意见。
3、引导式研讨会
通过邀请主要的跨职能干系人一起参加会议，引导式研讨会对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一个好处是，能够比单项会议更快地发现和解决问题。
4、群体创新技术
群体创新技术是指可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析等。
（1）头脑风暴法：各抒己见。
（2）名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴法。
（3）德尔菲技术：可以防止个人的观点被不正确的放大。
（4）概念/思维导图：是将从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。
（5）亲和图又称为KJ法，是针对某一问题，充分收集各种经验、知识、想法和意见等语言、文字资料，通过图解方式进行汇总，并按其相互亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。亲和图的核心是头脑风暴法，是根据结果去找原因。
（6）多标准决策分析是借助决策矩阵，用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术。
5、群体决策技术
群体决策（Group
Decision-Making）就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。
（1）一致同意 （Unanimity ）。所有人都同意某个行动方案。
（2）大多数原则 （Majority ）。获得群体中 50% 的人的支持，就能做出决策。参与决策的人数定为奇数，防止因平局而无法达成决策。
（3）相对多数原则（Plurality）。根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。且常在候选项超过两个时使用该原则，例如，某个软件构件的功能有3种实现方案（标记为A、B、C），在群体决策时，同意A 方案的人有 40% ，同意B方案的人有 35% ，同意C方案的人有 25% ，则最终确定采用A万案。
（4）独裁（Dictatorship ）。由某一个人（例如，项目经理）为群体做出决策。
6、问卷调查
7、观察
8、原型法
原型法是一种根据干系人初步需求，利用产品开发工具，快速地建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速开发的方法。
9、标杆对照
标杆对照；将实际或计划的做法与其他类似组织的做法（例如 ，流程、操作过程等）进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的“类似组织”可以是内部组织，也可以是外部组织。
10、系统交互图
系统交互图是是范围模型的一个例子，它是对产品范围的可视化描述，显示系统（过程、设备、信息系统等）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
11、文件分析
文件分析就是通过分析现有文档，识别与需求相关的信息来挖掘需求。可供分析的文档很多，包括商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库，应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等。
>>> 输出：
1、需求文件
需求文件的内容包括（但不限于）以下几个方面：
（1）业务需求
（2）干系人需求
（3）解决方案需求
（4）项目需求
（5）过渡需求
（6）与需求有关的假设条件、依赖关系和制约因素。
2、需求跟踪矩阵
三、定义范围
定义范围是制定项目和产品详细描述的过程，其主要作用是明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确产品、服务或成果的边界。
>>> 输入：
1、范围管理计划
2、项目章程
3、需求文件
4、组织过程资产
>>> 工具和技术：
1、专家判断
2、产品分析
产品分析是一种有效的工具。通常，针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述。
3、备选方案生成
备选方案生成是一种用来指定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。
4、引导式研讨会
>>> 输出：
1、项目范围说明书
作为定义范围过程的主要成果，项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书记录了整个范围，包括项目范围和产品范围，详细描述项目的可交付成果，以及为提交这些可交付成果而必须开展的工作。
项目范围说明书包括如下内容：
（1）产品范围描述。
（2）验收标准。定义可交付成果通过验收前必须满足的一系列条件，以及验收的过程。
（3）可交付成果。
（4）项目的除外责任。通常需要识别出什么是被排除在 项目之外的。明确说明哪些内容不属于项目，有助于管理干系人的期望。
（5）制约因素。列出并说明与项目范围有关且限制项目团队选择的具体项目制约因素。
（6）假设条件。
2、项目文件更新
四、创建工作分解结构（WBS）
创建 WBS 是将项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程，其主要作用是对所要交付的内容提供一个结构化的视图。
工作包是位于 WBS 每条分支最底层的可交付成果或项目工作组成部分。工作包应该非常具体，以便承担者能明确自己的任务、努力的目标和承担的责任。工作包的大小需要遵循8/80原则。
控制账户是一种管理控制点。是 WBS 某个层次上的要素，既可以是工作包，也可以是比工作包更高层次上的一个要素。如果是后一种情况，一个控制帐户中就包括若干个工作包，但一个工作包仅属于一个控制账户。项目管理团队在控制账户上考核项目的执行情况，即在控制账户的相应要素下，将项目执行情况与计划情况进行比较，以便评价执行情况好坏，并发现与纠正偏差。
规划包是指在控制帐户之下，工作内容已知但尚详细进度活动的 WBS 组成部分。是在控制账户之下、工作包之上的 WBS 要素。规划包是暂时用来做计划的。随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。
>>> 输入：
1、范围管理计划
2、项目范围说明书
3、需求文件
4、事业环境因素
5、组织过程资产
>>> 工具和技术：
1、分解
要将整个项目工作分解为工作包，通常需要开展以下活动：
（1）识别和分析可交付成果及相关工作。
（2）确定 WBS 的结构和编排方法。
（3）自上而下边层细化分解。
（4）WBS 组件制定和分配标识编码。
（5）核实可交付成果分解的程度是恰当的。
2、专家判断
>>> 输出：
1、范围基准
项目的范围基准是经过批准的项目范围说明书、 WBS和WBS词典。
2、项目文件更新
五、确认范围
确认范围是正式验收项目完成的可交付成果的过程，其主要作用是使验收过程具有客观性，同时，通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。确认范围包括与客户或发起入一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。
核实产品是针对产品是否完成，在项目（或阶段）结束时由发起人或客户来验证，强调产品是否完整；确认范围是针对项目可交付成果，由客户或发起人在阶段末确认验收的过程。
确认范围与质量控制的不问之处在于：
（1）确认范围主要强调可交付成果获得客户或发起人的接受；质量控制强调可交付成果的正确性，并符合为其制定的具体质量要求（质量标准）。
（2）质量控制一般在确认范围前进行，也可同时进行；确认范围一般在阶段末尾进行，而质量控制并不一定在阶段末进行。
（3）质量控制属内部检查，由执行组织的相应质量部门实施；确认范围则是由外部干系人（客户或发起入）对项目可交付成果进行检查验收。
确认范围与项目收尾的不同之处在于：
（1）虽然确认范围与项目收尾工作都在阶段未进行，但确认范围强调的是核实与接受可交付成果，而项目收尾强调的是结束项目（或阶段）所要做的流程性工作。
（2）确认范围与项目收尾都有验收工作，确认范围强调验收项目可交付成果，项目收尾强调验收产品。
>>> 输入：
1、项目管理计划
2、需求文件
3、需求跟踪矩阵
4、核实的可交付成果
5、工作绩效数据
>>> 工具和技术：
1、检查
检査也称为审查、评审、审计、走查、巡检、测试等。
2、群体决策技术
>>> 输出：
1、验收的可交付成果
2、变更申请
3、工作绩效信息
4、项目文件更新
六、控制范围
控制范围是监督项目和产品的范围状态、管理范围基准变更的过程，其主要作用是在整个项目期间保持对范围基准的维护。
造成项目范围变更的主要原因：
（1）政府政策的问题。
（2）项目范围的计划编制不周密详细，有一定的错误或遗漏。
（3）市场上出现了或是设计人员提出了新技术、新手段或新方案。
（4）项目执行组织本身发生变化。
（5）客户对项目、项目产品或服务的要求发生变化。
范围变更控制的主要工作如下。
（1）影响导致范围变更的因素，并尽量使这些因素向有利的方面发展。
（2）判断范围变更是否已经发生。
（3）包围变更发生时管理实际的变更，确保所有被请求的变更按照项目整体变更控制过程处理。
6117
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
