范围管理
1.产品范围和项⽬范围
在项⽬环境中，“范围”这⼀术语有两种含义：（项⽬范围包含产品范围，因为要做产品）
•产品范围：指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据 产产品需求来
衡量的。“需求”是指根据特定协议或其他强制性规范，产品、服务或成果 必须具备的条件或能⼒。
•项⽬范围：包括产品范围，是为交付具有规定特性与功能的产品、服务或成果⽽必须完成的⼯作。 项⽬范围的完成情况是根据项⽬管理计划来衡量的。
项目范围管理过程
口诀：变瘦定份缺孔
范围管理主要是围绕需求所开展的过程
| 组 | 过程 | 定义 | 作用 | 开展频次 |
|---|---|---|---|---|
| 规 划 | 1.规划范围 管理 | 为了记录如何定义、确认和控制项目范 围及产品范围，而创建范围管理计划的 过程 | 在整个项目期间对如何管理范 围提供指南和方向 | 仅开展一次或 仅在项目的预 定义点开展 |
| 2.收集需求 | 为实现目标而确定，记录并管理干系人 的需要和需求的过程 | 为定义产品范围和项目范围奠 定基础 | 仅开展一次或 仅在项目的预 定义点开展 | |
| 3.定义范围 | 制定项目和产品详细描述的过程 | 述产品、服务或成果的边界和 验收标准 | 需要在整个项 目期间多次反 复开展 | |
| 4.创建 WBS | 把项目可交付成果和项目工作分解成较 小、更易于管理的组件的过程 | 为所要交付的内容提供架构 | 仅开展一次或 仅在项目的预 定义点开展 | |
| 监 控 | 5.确认范围 | 正式验收已完成的项目可交付成果的过 程 | ①使验收过程具有客观性; ②通过确认每个可交付成果来 提高最终产品、服务或成果获 得验收的可能性 | 在整个项目期 间定期开展 |
| 6.控制范围 | 监督项目和产品的范围状态，管理范围 基准变更的过程 | 在整个项目期间保持对范围基 准的维护 | 在整个项目期 间开展 |
| 组 | 过程 | 输入 | 工具和技术 | 输出 |
|---|---|---|---|---|
| 规 划 | 1.规划范围 管理 | 1.项目章程2.项目管理计划3.事业环境因素4.组织过程资产 | 1.专家判断2.数据分析3.会议 | 1.范围管理计划2.需求管理计划 |
| 2.收集需求 | 1.立项管理文件2.项目章程3.项目管理计划4.项目文件5.协议6.事业环境因素7.组织过程资产 | 1.专家判断2.数据收集3.数据分析4.决策5.数据表现6.人际关系与团 队技能7.系统交互图8.原型法 | 1.需求文件2.需求跟踪矩阵 | |
| 3.定义范围 | 1.项目章程2.项目管理计划3.项目文件4.事业环境因素5.组织过程资产 | 1.专家判断2.数据分析3.决策4.人际关系与团 队技能5.产品分析 | 1.项目范围说明书 | |
| 4.创建 WBS | 1.项目管理计划2.项目文件3.事业环境因素4.组织过程资产 | 1.专家判断2.分解 | 1.范围基准2.项目文件（更新） | |
| 监 控 | 5.确认 范围 | 1.项目管理计划2.项目文件3.工作绩效数据4.核实的可交付 成果 | 1.检查2.决策 | 1.验收的可交付 成果2.变更请求3.工作绩效信息4.项目文件（更 新） |
| 6.控制 范围 | 1.项目管理计划2.项目文件3.工作绩效数据4.组织过程资产 | 1.数据分析 | 1.工作绩效信息2.变更请求3.项目管理计划 （更新）4.项目文件（更 新） |
总结归纳：
- 较为通⽤的输⼊： 二项事组
•事业环境因素
•组织过程资产
- 较为通⽤的技术：
•专家判断（万能）；
•数据分析（万能）
•会议（万能）
- 较为通⽤的输出：【执⾏和监督过程组】
•项⽬管理计划（更新）
•项⽬⽂件（更新）
•组织过程资产（更新）
2.敏捷与适应方法
敏捷或适应型⽅法特意在项⽬早期缩短定义和协商范围的时间，为后续细化范围、明确范围争 取更多的时间。在许多情况下，不断涌现的需求往往导致真实的 业务需求与最初所述的业务需求之间存在差异。因此，敏捷⽅法有⽬的地构建和审查原型，并通过多次发布版本来明确需求，范围会在整个项⽬期间被定义和再定义。
采⽤敏捷或适应型⽣命周期，旨在应对⼤量变更，需要干系⼈持续参与项⽬。因此，应将适应型项⽬的整体范围分解为⼀系列拟实现的需求和拟执⾏的⼯作（有时称为产品未完成项），通过多次迭 代来开发可交付成果，并在每次迭代开始时定义和批准详细的范围。在⼀个迭代开始时，团队将努⼒ 确定产品未完成项中，哪些优先级⾼的未完成项需要在下⼀次选代中交付。在每次选代中，都会重复开展三个过程：
①收集需求：②定义范围：③创建 WBS。
在预测型项⽬中，经过批准的项⽬范围说明书、⼯作分解结构（WBS）和相应的 WBS 词典构成 项⽬范围基准。只有通过正式变更控制程序，才能进⾏基准变更。
3.规划范围管理
⼀群⼈只做⼀次
1 输⼊（总结归纳 ⼦计划的通⽤输⼊：⼆项事组）
1.项⽬章程
项⽬章程记录项⽬且的、项⽬概述、假设条件、制约因素，以及项⽬想要实现的⾼层级的需求。
2.项⽬管理计划
3.事业环境因素
4.组织过程资产
2输出（区分 范围和需求管理计划），
范围管理计划
①制定项⽬范围说明书；②根据详细项 ⽬范围说明书 建 WBS；③确定如何审批和维护范围基准。④正式验收已完成的项⽬可交付 成果。
需求管理计划
需求管理计划的主要内容包括：
①如何规划、跟踪和报告各种需求活动：②配置管理活动，例如，
如何启动变更，如何分析其影响，如何进⾏追溯、跟踪和报告，以及变更审批权限；③需 求优先级排 序过程：④测量指标及使⽤这些指标的理由：⑤反映哪些需求属性将被列⼊跟踪矩 阵等。
4.收集需求
收集需求是为实现⽬标⽽确定，记录并管理⼲系⼈的需要和需求的过程。本过程的主要作⽤是为 定义产品范围和项⽬范围奠定基础。本过程仅开展⼀次或仅在项⽬的预定义点开展（P276 考1分选择 题）。
让⼲系⼈积极参与需求的探索和分解⼯作（分解成项⽬和产品需求），并仔细确定、记录和管理 对产品、服务或成果的需求，能直接促进项⽬成功。
输入
- ⽴项管理⽂件
会影响收集需求过程的⽴项管理⽂件是商业论证产⽣的⽂件，它描述了为满⾜业务需要⽽ 应该达到的必要、期望及可选标准。
项⽬章程
项⽬章程记录了项⽬概述以及将⽤于制定详细需求的⾼层级需求。
项⽬管理计划
项⽬⽂件
协议
协议会包含项⽬和产品需求。
事业环境因素（通⽤输⼊）
组织过程资产（通⽤输⼊）
工具与技术
- 专家判断（三⼈⾏必有我师，你⾏你上）
2， 数据收集
可⽤于收集需求过程的数据收集技术主要包括：
•头脑风暴：是⼀种⽤来产⽣和收集对项⽬需求与产品需求的多种创意的技术。
•访谈：是通过与⼲系⼈直接交谈，来获取信息的正式或⾮正式的⽅法。访谈的典型做法 是向被访者 提出预设和即兴的问题，并记录他们的回答。访谈经常是⼀个访谈者和⼀个 被访者之间的“⼀对⼀” 谈话，但也可包括多个访谈者或多个被访者。访谈有经验的项、⾃参与者、发起⼈和其他⾼管及主题 专家，有助于识别和定义所需产品可交付成果的特 征和功能。访谈也可⽤于获取机密信息。
•焦点⼩组：是召集预定的⼲系⼈和主题专家，了解他们对所讨论的产品、服务或成果的 期望和态度。
由⼀位受过训练的主持⼈引导⼤家进⾏互动式讨论。售点⼩组往往⽐“⼀对⼀”的访谈更热烈。 •问卷调查：是指设计⼆系列书⾯问题，向众多受访者快速收集信息。问卷调查⽅法⾮常适⽤于受众多
样化，需要快速完成调查，受访者地理位置分散并且适合开展统计分析的情况。
•标杆对照：将实际或计划的产品、过程和实践。与其他可⽐组织的实践进⾏⽐较，以便识别最佳实 践，形成改进意见，并为绩效考核提供依据。标杆对照所采⽤的可⽐组织可 以是内部的，也可以是外部的。
数据分析
决策
数据表现
⼈际关系与团队技能
名义⼩组技术：是⽤于促进头脑⻛暴的⼀种技术，通过投票排列最有⽤的创意，以便进⼀ 脑⻛暴或优先排序。名义⼩组技术是⼀种结构化的头脑⻛暴形式。。
•观察和交谈：（尾随，偷窥，偷拍，探⼦，间谍）是指直接察看个⼈在各⾃的环境中如何执⾏⼯作（或 任务）和实施流程。当产品使⽤者难以或不愿清晰说明他们的需求时，特别需要通过观察来了解 他们的⼯作细节。观察也称为“⼯作跟随”，通常由旁站观察者观察业务专家如何执⾏⼯作，但也 可以由“参与观察者”来观察，通过实际执⾏⼀个流程或程序，来体验该流程或程序是 如何实施的，
以便挖掘隐藏的需求。
原型法（建筑模型，3D建模，2D建模）
输出
1.需求⽂件
描述各种单⼀需求将如何满⾜项⽬相关的业务需求。
（1）业务需求：整个组织的⾼层级需要，例如，解决业务问题或抓住业务机会，以及实施 项且
的原因。
（2）⼲系⼈需求：干系⼈的需要。 （3）解决⽅案需求：为满⾜业务需求和⼲系⼈需求，产品、服务或成果必须具备的特性、功能
和特征。解决⽅案需求⼜进⼀步分为功能需求和⾮功能需求：
①功能需求：描述产品应具 备的功能，例如，产品应该执⾏的⾏动、流程、数据和交互：
②⾮功能需求：是对功能需求的 补充，是产品正常运何所需的环境条件或质量要求，例如，可缩 性、保密性、性能、安全性、服务⽔平、可⽀持性、保留或清除等。
所需的临时能 （1过酸和斑新商 ⼒。 ⽶：如敦脂转換和指训⾬⽶，芝慧源装海造了以“当前状奋：过選到“将⽶识合” （5）项⽬需求：项⽬需要满⾜的⾏动、过程或其他条件，例如⾥程碑⽇期、合同责任、制 约因素等。
（6） 质量⿊求：⽤于确认项⽬可交付成果的成功完成或其他项⽬需求的实现的任何条件或 标准，例如， 测试、认证、确认等。
5.定义范围
由于在收集需求过程中识别出的所有需求未必都包含在项⽬电，所以定义范围过程需要从 需求 ⽂件（收集需求过程的输出）中选取最终的项⽬需求，然后制定出关于项⽬及其产品、服 务或成果的 详细描述。
输出：
1.项⽬范围说明书 项⽬范围说明书是对项⽬范围、主要可交付成果，假设条件和制约因素的描述（P283 考1分选 择题）。它记录了整个范围，包括：项⽬和产品范围：详细描述了项⽬的可交付成果：代表项⽬⼲系 ⼈之间就项 ⽬范围所达成的共识。
产品范围描述：逐步细化在项⽬章程和需求⽂件中所述的产品、服务或成果特征。
•可交付成果：为完成某⼀过程、阶段或项⽬⽽必须产出的任何独特并可核实的产品、成果或服 务能⼒，可交付成果也包括各种辅助成果，如项⽬管理报告和⽂件。对可交付成 果的描述可
略可详。
•验收标准：可交付成果通过验收前必须满⾜的⼀系列条件。
•项⽬的除外责任：识别排除在项⽬之
6.创建WBS
WBS 最低层的组成部分称为⼯作包， 工作包再向下分解为活动。
工具与技术
分解
要把整个项⽬⼯作分解为⼯作包，通常需要开展如下活动：（识确细制核）
1 | ①识别和分析可交付成果及相 关⼯作：（干什么） |
如果采⽤敏捷或适应型⽅法，可以将长篇故事分解成⽤户故事。
⽤户故事（user story）是从⽤户的⾓度来描述⽤户渴望得到的功能。⼀个好的⽤户故事包括三个要素：
1 | 1、⾓⾊：谁要使⽤这个功能。 |
确认 WBS较低层组件是完成上层相应可交付成果的必要且充分的⼯作，以此来核实分解的正确性。
注意事项
在分解的过程中，应该注意以下8个方面： 、在分解的过程中，应该注意以下8个⽅⾯：
1 | （1）WBS必须是**面向可交付成果**的:项目的目标是提供产品或服务，WBS中的各项工作是为提供可交 付的成果服务的（多次重复循环，软件测试） |
确认范围
本过程的主要作⽤：
1 | ①使验收过程具有客观性： ②通过确认每个可交付成果来提⾼最终产品、服各或成果获得验收的可能性。 |
1.确认范围的步骤
确认范围应该贯穿项⽬的始终。 确认范围的⼀般步骤包括：①确定需要进⾏范围确认的时间：②识别范围确认需要哪些 投⼊；③确 定范围正式被接受的标准和要素：④确定范围确认会议的组织步骤：⑤组织范围确认会议。 通常情况下，在确认范围前，项⽬团队需要先进⾏质量控制⼯作，例如，在确认软件项⽬ 的范围之 前，需要进⾏系统测试等⼯作，以确保确认⼯作的顺利完成。
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，⽽后者关注 可交付成 果的正确性及是否满⾜质量要求。控制质量过程通常先于确认范围过程，但⼆者也可 同时进⾏（P290 考案例）。
- 需要检查的问题
项⽬⼲系⼈进⾏范围确认时，⼀般需要检查以下6个⽅⾯的问题：
•可交付成果是否是确定的、可确认的。
•每个可交付成果是否有明确的⾥程碑，⾥程碑是否有明确的、可辨别的事件，例如，客 户的书⾯认可等。
•是否有明确的质量标准：可交付成果的交付不但要有明确的标准标志，⽽且要有是否按 照要求完 成的标准，可交付成果和其标准之间是否有明确联密⼼
•审核和承诺是否有清晰的表达：项⽬发起⼈必须正或同意项⽬的边界，项⽬完成的产品 或者服务： 以及项⽬相关的可交付成果。项⽬团队必须清楚地了解可交付成果是什么。所有的这些表达必 须清晰，并取得⼀致的同意。
•项⽬范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
•项⽬范围的风险是否太⾼：管理层是否能够降低风险发⽣时对项⽬的影响。
⼲系⼈关注点的不同
管理层主要关注项⽬范围。
客户主要关注产品范围
项⽬管理⼈员主要关注项⽬制约因素
项⽬团队成员主要关注项⽬范围中⾃⼰参与的元素和负责的元素