文章目录

范围管理概述
规划范围管理
收集需求
范围定义
创建WBS
确定范围
控制范围

在这里插入图片描述

范围管理概述

项目范围管理：
明确项目边界——明确哪些工作是包括在项目范围之内，哪些工作是不包括
对项目执行工作进行监控——确保所有该做的工作都做了，而且没有多做。杜绝做额外的工作。
防止项目范围发生蔓延——项目蔓延指未对实践、成本和资源做相应调整，未经控制的产品或项目范围的扩大

在这里插入图片描述

规划范围管理

在这里插入图片描述

范围管理计划是制定项目管理计划和其他范围管理过程的主要输入，包含内容
如何制定项目范围说明书
如何根据范围说明书创建WBS
如何维护和批准WBS
如何确认和正式验收已完成的项目可交付成果
如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相关联
在这里插入图片描述

项目范围管理计划可能在项目管理计划之中，也可能作为单独的一项，根据不同的项目，可以是详细的或者概括的，可以是正式的或者非正式的

收集需求

在这里插入图片描述

在这里插入图片描述

需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求，包含的内容有
如何规划、跟踪和汇报各种需求活动
需求管理里需要使用的资源
培训计划
项目干系人参与需求管理的策略
判读项目范围与需求不一致的准则和纠正规程

需求跟踪结构——哪些需求属性将列入跟踪矩阵，并可在其他哪些项目文件中追踪到这些需求
配置管理活动

在这里插入图片描述

需求管理贯穿于整个过程，基本任务——建立需求基线——明确需求，并使整个项目团队和用户达成共识

要建立需求跟踪能力联系练确保所有用户需求都被正确地应用，并且在需求发生变更，能够完全地控制其影响范围，始终保持产品与需求的一致性

需求的分类：
业务需求——整个组织的高层级需要（解决业务问题、抓住业务机会、实施项目的原因）
干系人需求——干系人/干系人群体的需要
过渡需求——从当前状态过度到将来状态所需的临时能力（数据转换、培训需求）
质量需求——确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准。QFD对质量需求进行了细分（基本需求、期望需求、意外需求）

收集需求的工作和技术：访谈、焦点小组、引导式研讨会、群体创新技术、群体决策技术、问卷调查、观察、原型法、标杆对照、系统交互图、文件分析

焦点小组
将预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比一对一的访谈更加激烈。焦点小组是群体访谈而非一对一访谈，可以有6~10个被访谈者参加，针对访谈者提出的问题，被访谈者之间开展互动式讨论，以求得到更有价值的意见。

引导式研讨会
通过邀请主要的跨职能干系人一起参加会议。引导式研讨会对产品需求进行集中讨论和定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术，由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进古纳西、改善沟通、从而有利于参加者达成一致意见，该技术的另一个好处是，能够比单项会议更快地发现和解决问题

群体创新技术：可以组织一些群体活动来识别项目和产品需求，群体创新技术包括头脑风暴法、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析
头脑风暴：各抒己见
名义小组技术：通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用，是更加结构化的头脑风暴。
德尔菲技术：防止个人观点被不正确的放大
概念/思维导图：将头脑风暴法中的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意

亲和图：KJ法，针对某一问题，充分收集各种经验、知识、想法、和意见等语言、文字材料，通过图解方式进行汇总，并按其互相亲和性归纳整理这些资料，使问题明确起来，求得统一认识，以利于解决的一种方法。核心：头脑风暴，根据结果去找原因

多标准决策分析：借助决策矩阵，利用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准，从而对众多方案进行评估和排序的一种技术

群体决策：为达成某种期望结果对多个未来行动方案进行评估。可以用来开发产品需求，以及对产品需求进行归类和优先排序
一致同意：所有人都同意某个行动方案
大多数原则：获得群体中50%以上的人的支持，就能做出决策。参与决策的人数定为奇数。防止因平局而无法达成决策。
相对多数原则：在候选项超过两个时使用该原则
独裁：某个人为群体做出决策

原型法：根据干系人初步需求，利用产品开发工具，快速地建立一个产品模型展示给干系人，在此基础上与干系人交流，最终实现干系人需求的产品快速开发方法。

标杆对照：
将实际或计划的做法与其他类似组织的做法进行比较（流程、操作过程等）。以便识别最佳实践，形成改进意见，并以绩效考核提供依据。标杆对照所采用的类似组织可以是内部组织也可以是外部组织。

系统交互图：
产品范围的可视化描述，显示系统（过程、设备、信息系统）与参与者（用户、独立于本系统之外的其他系统）之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。

文件分析：
通过分析现有文档，识别与需求相关的信息来挖掘需求。可供分析的文档有很多（商业计划、营销文档、协议、招投标文件、建议邀请书、业务流程、逻辑数据模型、业务规则库、应用软件文档、用例文档、其他需求文档、问题日志、政策、程序和法规文件等）

需求文件：
描述单一的需求将如何满足于项目相关的业务需求
业务需求
干系人需求
解决方案需求
项目需求
过度需求
与需求有关的假设条件、依赖关系和制约因素

需求管理包括在产品开发过程中维持需求一致性和精确性的所有活动，包括控制需求极限，保持项目计划与需求一致，控制单个需求和需求文档的版本情况，管理需求和联系链之间的联系，或管理单个需求和项目其他可交付物之间的依赖关系，跟踪极限中需求的状态。

可跟踪性是项目需求的一个重要特征，需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑联系建立跟踪。这些元素包括各种类型的需求、业务规则、系统组件以及帮助文件等。

每个配置项的需求到其设计的产品/构件需求都要具有双向可跟踪性（正向跟踪和反向跟踪）。
正向跟踪：检查需求文件中每个需求是否都能在后继工作产品（成果）中找到对应点
反向/逆向跟踪：检查设计文档、产品构件、测试文档，工作成果是否都能在需求文件中找到出处，具体来说

范围定义

在这里插入图片描述

创建WBS

将项目可交付成果和项目工作分解成较小的，更易于管理的组件的过程

在这里插入图片描述

在这里插入图片描述
分解步骤

识别和分析可交付成果及相关工作
确定WBS的结构和编排方法
自上而下逐层细化分解
为WBS组件制定和分配标识编码
核心可交付成果分解的程度是恰当的

在这里插入图片描述

分解注意事项

WBS必须面向可交付成果。项目目标是提供产品/服务，仅仅是一连串特别的活动。
必须符合项目范围。必须包括，也仅包括为了完成项目的可交付成果的活动
底层应该支持计划和控制。是项目管理计划和项目范围之间的桥梁。底层不但要支持项目管理计划，而且要让管理层能监视和控制项目的进度和预算
必须有人负责，而且只由一个人负责。尽管实际上可能需要多个人参与
WBS的指导，作为指导而不是原则，应控制在4~6层。当然，大项目可以超过6层。
应包括项目管理工作，也要包括包出去的工作
需要所有主要项目干系人的参与，需要项目团队成员的参与
并非是一成不变的，在完成了WBS之后的工作中，仍有可能需要对WBS进行修改

在这里插入图片描述

用途与作用

明确和准确说明项目范围，项目团队成员能够清楚地理解任务的性质和需要努力的方向
清楚地定义项目地边界
为各独立单元分派人员，规定这些人员的职责，可以确定完成项目所需要的技术和人力资源
针对独立单元，进行时间、成本和资源的需求量的估算，提高估算的准确性
为计划、预算、进度安排和费用控制奠定共同基础，确定项目进度和控制的基准
将项目工作和项目的财务账目联系起来
确定工作内容和工作顺序，将项目分解为具体的工作任务，就可以按照工作任务的逻辑顺序来实施项目。可以使用图形化的方式来查看工作内容，任何人都能清楚地辨别项目的阶段、工作单元，并根据实际情况进行调节和控制
有助于防止需求蔓延

在这里插入图片描述