PMBOK® 第六版定义范围

最新推荐文章于 2024-09-27 07:55:17 发布

幽反丶叛冥

最新推荐文章于 2024-09-27 07:55:17 发布

阅读量649

点赞数 23

分类专栏：项目管理&管理文章标签：经验分享

本文链接：https://blog.csdn.net/guyuelin123/article/details/141288380

版权

项目管理&管理专栏收录该内容

35 篇文章 2 订阅

订阅专栏

读后感—PMBOK第六版目录

在项目需求调研分析中，虽然可以搜集到大量的需求，但由于资源有限，我们需要筛选出真正需要且优先级高的需求。随着时间的推移，项目进程中可能会遇到因认知差异、环境变化等原因提出的新需求，这些需求可能不在原定范围内，但由于缺乏明确的范围定义，很难判断是否应当采纳。项目成员之间的理解差异或希望获得认可的心态也可能导致执行不属于项目范围的工作。

此外，项目推进过程中可能会因资源短缺而无法继续，这时需要花费时间沟通以暂缓某些需求的推进，并将其他优先级更高的需求调整至开展阶段。

最重要的是，明确的验收标准至关重要，确保所有相关人员了解质量要求、功能规格、性能指标、合规性要求、用户接受标准以及文档要求等，保证项目产出符合预期，为验收奠定基础，友好验收，促进客户满意度。

一、定义范围的内容

定义范围是制定项目和产品详细描述的过程，主要作用是明确所收集需求哪些在项目范围内、哪些在项目范围外，以明确项目、服务或成果的边界（见图1）。完整、准确地定义范围通常是项目成功的前提，范围说明书是该过程最重要的成果。

图-1 定义范围：数据流向图

在收集需求过程中识别的需求未必都包含在项目中，因此定义范围过程需从需求文件中选取最终项目需求，并制定项目及其产品、服务或成果的详细描述。准备详细的项目范围说明书对项目成功至关重要。

应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制项目范围说明书，并随着项目规划过程中信息的增加，逐步细化和定义项目范围。此外，还需分析现有风险、假设条件和制约因素，并进行必要的增补或更新。在迭代型生命周期项目中，先为整个项目确定高层级愿景，然后逐个迭代期明确详细范围，随着当前迭代期的进展，详细规划下一个迭代期的工作。

二、定义范围

定义范围过程整合了项目章程、管理计划、需求文件等输入，利用专家判断、备选方案分析、多标准决策分析和产品分析等工具与技术，最终产出项目范围说明书（见图2），该说明书详细界定了项目可交付成果、范围边界、假设条件与制约因素，作为项目执行的基准与规划依据。

图-2 定义范围：输入、工具与技术和输出

2.1 定义范围：输入

项目章程

项目章程中包含对项目的高层级描述、产品特征和审批要求。

项目管理计划

包含（但不限于）范围管理计划，其中记录了诸如如何定义、确认和控制项目范围等内容。

项目文件

可作为本过程输入的项目文件包括（但不限于）：

假设日志：识别有关产品、项目、环境、相关方以及会影响项目和产品范围的假设条件和制约因素。
需求文件：识别应纳入范围的需求。
风险登记册：包含了可能影响项目范围的应对策略，比如缩小或改变项目和产品范围，以规避或缓解风险。
事业环境因素

会影响定义范围过程的事业环境因素包括（但不限于）：

组织文化；
基础设施；
人事管理制度；
市场条件。
组织过程资产

能够影响定义范围过程的组织过程资产包括（但不限于）：

用于制定项目范围说明书的政策、程序和模板；
以往项目的项目档案；
以往阶段或项目的经验教训。

2.2 定义范围：工具与技术

专家判断

由具备相关专业知识或接受过相关培训的个人或小组针对以下主题给出意见。

数据分析

可用于本过程的数据分析技术包括（但不限于）备选方案分析。备选方案分析能够用于评估实现项目章程中所述的需求和目标的各种方法。

决策

可用于本过程的决策技术包括（但不限于）多标准决策分析。多标准决策分析（链接：PMBOK® 第六版收集需求 2.2 收集需求：工具与技术）是一种借助决策矩阵来使用系统分析方法的技术，其目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。

人际关系与团队技能

人际关系与团队技能的一个示例是引导。在研讨会和座谈会中运用引导技能来协调具有不同期望或不同专业知识的关键相关方，促使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。

产品分析

产品分析可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付的产品的用途、特征及其他方面。

每个应用领域都有一种或几种普遍公认的方法，用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求，然后将其细化到最终产品设计所需的详细程度。产品分析技术包括（但不限于）：

产品分解：树状结构分解产品部件，主要解决“做什么”；
需求分析：对要解决的问题进行详细的分析，弄清楚问题的要求，包括需要等到什么结果；
系统分析：要把解决问题作为一个系统，找出解决问题的可行方案；
系统工程：全面权衡得到最优解的方法，并使各组成部分能够最大限度地相互协助；
价值分析：在产品量产后，通过持续分析降低成本的主要手法 Value = function / cost；
价值工程：在产品开发设计阶段进行的价值与成本分析，旨在提高产品的价值。

2.3 定义范围：输出

项目范围说明书

项目范围说明书清晰定义了项目和产品的范围、关键交付物、假设条件以及制约因素，确保了项目团队和干系人对项目范围的共识。它确立了项目工作和非工作的范围界限，指导项目的规划和执行，并作为评估变更请求是否超出项目边界的基准。

直接影响项目管理团队控制项目范围的有效性。详尽的说明书通常包括可交付成果的详细描述及其他相关内容（可能引用其他文件）。

产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。
验收标准。可交付成果通过验收前必须满足的一系列条件。
可交付成果。团队在某一过程、阶段或项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。可交付成果也包括各种辅助成果，如项目管理报告和文件。可交付成果的描述可略可详。
项目的除外责任。团队通常需要识别出哪些内容是被排除在项目之外的。明确说明哪些内容不属于项目范围，有助于管理相关方的期望。
制约因素。对项目或过程的执行有影响的限制性因素。列举并描述与项目范围有关且会影响项目执行的各种内外部制约或限制条件，如客户或执行组织事先确定的预算、强制性日期或进度里程碑。如果项目是根据协议实施的，那么合同条款通常也是制约因素。关于制约因素的信息可以列入项目范围说明书，也可以独立成册。
假设条件。在制订计划时，不需要验证假设条件即可将其视为正确、真实或确定的因素。同时还应描述如果这些因素不成立，可能造成的潜在影响。在项目规划过程中，项目团队应该经常识别、记录并确认假设条件。假设条件的信息可以被列入项目范围说明书，也可以独立成册。
项目文件更新

假设日志：随同本过程识别出更多的假设条件或制约因素而更新假设日志。

需求文件：可以通过增加或修改需求而更新需求文件。

需求跟踪矩阵：应该随同需求文件的更新而更新需求跟踪矩阵。

相关方登记册：如果在本过程中收集到了现有或新相关方的更多信息，则记录到相关方登记册中。