【PMBOK】第5章 项目范围管理
项目范围管理包括确保项目做且只做所需的全部工作。
“范围” = 产品范围 + 项目范围。
产品范围：产品、服务或成果具有的特征和功能。
项目范围：为了交付具有规定特性和功能的产品，必须完成的工作。
用项目管理计划衡量项目范围的完成情况，用产品需求衡量产品范围的完成情况。
5.1 规划范围管理
范围管理计划无范围，只是一个描述如果管理范围的指南。
5.1.1 输入
项目章程：项目章程记录项目目的、项目概述、假设条件、制约因素，以 及项目意图实现的高层级需求。
5.1.2 工具和技术 理解为主
5.1.3 输出
1.范围管理计划：描述如何定义、制定、监督、控制和确认项目范围。
2.需求管理计划：描述如何分析、记录和管理项目和产品需求。
注意： 范围管理计划无范围，范围是记录在范围基准中的； 需求管理计划无需求，需求是记录在需求文件中的。
5.2 收集需求
为实现目标而确定、记录并管理相关方的需要和需求的过程。
需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件或能力。
5.2.1 输入
项目章程：项目章程记录了项目概述以及将用于制定详细需求的高层级需 求。
商业论证：描述了为满足业务需要而应该达到的必要、期望及可选标准。
协议：协议会包含项目和产品需求。
5.2.2 工具和技术
数据收集
头脑风暴: 大量创意、各种想法、畅所欲言;
访谈: 直接交谈、预设和即兴问题、一对一、多对多、获取机密信息
焦点小组:同一领域（同职能）、主题专家（SME） ;
问卷调查:受众多样化、需快速完成、地理位置分散、适合开展统计分析 ;
标杆对照:识别最佳实践，形成改进意见。标杆可以是内部或外部、同行业或不同行业的。
数据分析
文件分析:分析现有文件
决策
投票:一致同意 每个人都同意、德尔菲（专家、匿名、多轮、趋同、消除 偏见）;大多数同意 超过 50%、一般把决策小组的人数定为奇数;相对多数同意:相对多数，通常候选项超过两个时使用。
*型决策制定 :一个人做决策;
多标准决策分析:决策矩阵、多种标准、评估和排序.
数据表现
亲和图:分组、以便进一步审查和分析;
思维导图:整合、反映共性与差异、激发新创意、脑图 .
人际关系与团队技能
名义小组:促进头脑风暴、投票、优先排序;
观察和交谈: “工作跟随”、难以或不愿清晰说明、挖掘隐藏的需求 ;
引 导:与主题研讨会结合使用、跨职能、协调相关方差异。
JAD: 软件开发行业、业务主题专家和开发团队集中
QFD 制造行业、收集客户需要（客户声音）开始、分类和排序;
用户故事:需求研讨会、角色、目标、动机 ;
系统交互图:拓扑图、可视化
原型法:支持渐进明细的理念。例如：故事板，能减轻返工的风险。 步骤（反复循环）：1.模型创建、2.用户体验、3.反馈收集、4.原型修改（可能需要走变更流程）
5.2.3 输出
1. 需求文件：需求文件描述各种单一需求将如何满足与项目相关的业务需求。
2. 需求跟踪矩阵：需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。
5.3 定义范围
定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，描述产品、服务或成果的边界和验收标准。
需要多次反复开展定义范围过程：在迭代型生命周期的项目中，先为整个项目确定一个高层级的愿景，再一次针对一个迭代期明确详细范围。
5.3.1 输入
项目章程：项目章程中包含对项目的高层级描述、产品特征和审批要求。
需求文件：需求文件识别了应纳入范围的需求。
5.3.2 工具和技术
产品分析：用以把高层级的产品或服务描述转变为有意义的可交付成果。 包括：产品分解；需求分析；系统分析；系统工程；价值分析；价值工程。
5.3.3 输出
项目范围说明书：记录了整个范围，包括项目和产品范围；详细描述了项目的可交付成果；还代表项目相关方之间就项目范围所达成的共识。
详细的项目范围说明书包括以下内容：
产品范围描述：细化项目章程和需求文件中的产品、服务或成果的特征。
可交付成果：可交付成果也包括各种辅助成果，如项目管理报告和文件。
(可交付成果对应的)验收标准：可交付成果通过验收前必须满足的一系列条件。
项目的除外责任：明确说明哪些内容不属于项目范围，有助于管理相关方 的期望及减少范围蔓延。
说到可交付成果和验收标准，首选范围说明书，次选WBS词典。
5.4 创建 WBS
把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。 WBS 组织并定义了项目的总范围，代表着经批准的当前项目范围说明书中 所规定的工作。WBS 最低层的组成部分称为工作包。 WBS 最低层的组成部分称为工作包，其中包括计划的工作。
5.4.1输入
项目范围说明书：描述了需要实施的工作及不包含在项目中的工作。
需求文件：需求文件详细描述了各种单一需求如何满足项目的业务需要。
5.4.2工具和技术
分解：可以项目生命周期的各阶段作为分解的第二层；可以以主要可交付成果作为分解的第二层 ；作为外包工作的一部分，卖方须制定相应的合同 WBS。 不同的可交付成果可以分解到不同的层次。工作分解得越细致，对工作的 规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、 资源使用效率低下、工作实施效率降低，同时造成 WBS 各层级的数据汇总困 难。要在未来远期才完成的可交付成果或组件，当前可能无法分解，需要滚动式规划。 几个重要的原则：80小时原则；4~6层原则；100%原则；责任唯一。
5.4.3输出
范围基准：经过批准的范围说明书、WBS 和相应的 WBS 词典。 WBS中的控制账户则是一个管理控制点。在该控制点上，把范围、预算和进 度加以整合，并与挣值相比较，以测量绩效。
WBS 词典：针对 WBS 中的每个组件，详细描述可交付成果、活动和进度信息的文件。
5.5 确认范围
确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用 是，使验收过程具有客观性；同时通过确认每个可交付成果，来提高最终产 品、服务或成果获得验收的可能性。 确认范围过关注可交付成果的验收，而控制质量关注可交付成果的正确性 及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时 进行。
5.5.1输入 核实的可交付成果：核实的可交付成果是指已经完成，并被控制质量过程 检查为正确的可交付成果。
5.5.2工具和技术
检查：开展测量、审查与确认等活动，来判断工作和可交付成果是否符合 需求和产品验收标准。
5.5.3输出
验收的可交付成果：符合验收标准的可交付成果应该由客户或发起人正式 签字批准。 变更请求：未通过验收则1.记录原因。2.走变更，开展缺陷补救。
5.6 控制范围
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。本过程的主要作用是，在整个项目期间保持对范围基准的维护。 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整） 被称为范围蔓延。
5.6.1输入 理解为主
5.6.2工具和技术
偏差分析：用于将基准与实际结果进行比较，以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。
趋势分析：审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。 5.6.3输出 理解为主
避免范围蔓延的最好做法是让变更走变流程；如果范围蔓延已经发生，一 样要补变更流程，变更同意则更新项目管理计划，不同意要取消不良变更。