软考高项-项目范围管理

范围管理总线索

定义、作用

项目范围管理包括确认项目做且只做所需的全部工作，以成功完成项目。项目范围管理主要要在于定义和控制哪些工作应包含在项目内，哪些不应该包含在项目内。

产品范围vs项目范围

五大过程组十大知识域

管理新实践

需求一直是项目管理的关注重点。
项目范围管理的新趋势和新兴实践更加注重与商业分析师一起合作，以便：

1. 确定问题并识别商业需求；
2. 识别并推荐能满足需求的可行解决方案；
3. 收集、记录并管理干系人需求，满足商业和项目目标；
4. 推动项目交付产品，服务最终成果成功应用。

商业分析师的职责应包括需求管理相关的活动，项目经理则负责确保这些活动列入项目管理计划，并在预算内按时完成，同时能够创造价值。
项目经理与商业分析师之间应是合作关系。

关键词：需求

裁剪考虑因素

对项目范围管理过程时应考虑的因素：

1. 知识和需求管理：项目经理应建立哪些指导？为了在未来项目中重复使用需求，组织是否拥有正式或非正式的知识和需求管理体系？
2. 确认和控制：组织是否有正式或非正式的确认和控制相关政策、程序和指引？
3. 开发方法：组织是否采用敏捷方法管理项目？开发方法属于迭代型还是增量型？是否采用预测型方法？混合型方法是否有效？
4. 需求的稳定性：项目中是否存在需求不稳定的领域？是否有必要采用精益、敏捷或其他适应性技术来处理不稳定的需求，直接需求稳定性是否明确？
5. 治理：组织是否拥有正式或非正式的审计和治理策略、程序和指引？

敏捷与适应方法

对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目周期内逐渐明确。敏捷或适应型方法特别强调在项目早期缩短定义和协调范围的时间，以后继续细化范围、明确范围争取更多的时间。

采用敏捷或适应型生命周期，旨在应对对大量变化，需要干系人持续参与与项目。

1. 采用多次迭代，重复开发三个过程：
   1. 收集需求；
   2. 定义范围；
   3. 创建WBS。

1. 发起人和客户代表应持续参与项目，重复开展两个过程：
   1. 确认范围；
   2. 控制范围。

规划范围管理

作用

在整个项目期间对如何管理范围提供指南和方向

ITTO

输出-范围管理计划

• 范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监控、控制和确认项目范围。可以是正式或非正式的，非常详细或高度概括的。
• 主要内容包括：
• 如何制定项目范围说明书；
• 如何根据详细项目范围说明书创建 WBS；
• 确定如何审查和维护范围基准；
• 正确验收已完成的项目可交付成果；

输出-需求管理计划

• 范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监控、控制和确认项目范围。可以是正式或非正式的，非常详细或高度概括的。
• 主要内容包括：
• 如何制定项目范围说明书；
• 如何根据详细项目范围说明书创建 WBS；
• 确定如何审查和维护范围基准；
• 正确验收已完成的项目可交付成果；

收集需求

作用

为定义产品范围和项目范围奠定基础

帮我们进一步确定本项目做且只做那些该做的事儿

ITTO

工具与技术-焦点小组、标杆对照

标准对照所采用的可比组织可以是内部的，也可以是外部的。

工具与技术-原型法

原型法是指在实际制造产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或虚拟模型。因为原型是有形的实体，它使得干系人可以体验最终产品的模型，而不是仅限于讨论抽象的需求描述。原型法支持渐进细的理念，需要经历原型创建、用户体验、反馈收集与原型修改的反馈循环过程。在经过反复的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。 故事板是一种原型技术，通过一系列的图像来展示顺序或导航路径。故事板用于各行业的各个项目中，如电影、广告、教学设计以及软件开发项目。在软件开发中，故事板使用实际模型来展示网页、屏幕或其他用户界面的导航路径。

工具与技术-名义小组技术

名义小组技术是用于促进头脑风暴的一种技术，通过投票排列最有用的创意，以便进一步开展头脑风暴优先排序。名义小组技术是一种结构化的头脑风暴形式。其步骤包括以下几点：

1. 向集体提出一个问题或难题，每个人在沉思后写出自己的想法；
2. 主持人在活动挂图上记录所有人的想法；
3. 集体讨论各个想法，直到全体成员达成一个明确的共识；
4. 个人私下投票决定各种想法的优先排序，通常采用5分制，1分最低，5分最高。为减少想法数量，集体关心想法，可以进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。

输出-需求文件

输出-需求跟踪矩阵

需求跟踪矩阵是把产品需求从其源连接到满足需求的可交付成果的一种表格。使用需求跟踪矩阵，把每个需求与业务目标或项目目标联系起来。

需求跟踪的内容包括： 1. 业务需求、机会、目标和目的； 2. 项目目标； 3. 项目范围和WBS可交付成果； 4. 产品设计； 5. 产品开发； 6. 测试策略和测试场景； 7. 高层级需求到详细需求。

需求跟踪矩阵示例

定义范围

作用

描述产品、服务或成果的边界和验收标准

ITTO

输出-项目范围说明书

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。

1. 产品范围描述。
2. 可交付成果。
3. 验收标准。
4. 项目的除外责任。 （明确说明哪些内容不属于项目范围，减少范围蔓延）

创建WBS

作用

为所要交付的内容提供架构

ITTO

分解的基本概念

把一个项目按照一定的原则分解，项目分解成任务，任务分解成一项一项工作，再把一项一项工作分配到每个人的日常活动中，知道分解不下去为止。

原则：

• 可度量
• 可检查
• 可量化

• 分解是一种把项目范围和项目可交付成果逐步分为更小、方便于管理的组成部分的技术。
• 工作包 是 WBS 最低层的工作，可对其成本和持续时间进行估算和管理。分解的程度取决于所需的控制程度，以实现对项目的高效管理。
• 工作包的详细程度因项目规模与复杂程度而异。

步骤

1. 识别和分析可交付成果及相关工作；
2. 确定 WBS 的结构与编排方式；
3. 自上而下逐层细化分解；
4. 为 WBS 组成部分制定和分配标识编码；
5. 核实可交付成果分解的程度是否合理；

结构

1. 按照生命周期：将项目生命周期作为分解的第二层，把产品和项目可交付成功放在第三次，例如：
   1. 需求分析
      1. 用户调研
      2. 需求分析
      3. 用户确认

1. 分析设计
   1. 数据库设计
   2. 基础类设计
   3. 系统接口设计
   4. 业务功能设计
2. 程序设计
   1. 数据库定义
   2. 及本页面设计
   3. 业务功能实现
   4. 接口功能实现

1. 软件测试
   1. 单元测试
   2. 集成测试
   3. 验收测试
2. 按照可交付成果：将交付成功作为分解的第二层，例如：
   1. OA系统
      1. 邮件服务
      2. 公文流转
      3. 公告板

1. 人事系统
   1. 职工管理
   2. 干部管理
   3. 员工培训
   4. 退休管理
2. 营销系统
   1. 用户管理
   2. 资费管理
   3. 客户挂你
   4. 欠费管理

1. 生产系统
   1. 设备管理
   2. 运行管理
   3. 检修计划

分解的两种表现形式

1. 分级的树形结构
   1. 适用于小型项目
   2. 特点：WBS层次清晰、直观、结构性强

1. 分析的表格形式
   1. 适用于大型项目
   2. 特点：可以缩进图标，表示方便，也可以装订成册

WBS字典

• WBS字典是针对WBS中的每个组件，详细描述可交付成果、活动和进度信息的文件。
• WBS字典对WBS组成部分（包括工作包和控制账户）进行更详细的描述。

WBS字典中的内容可能包括（但不限于）：

• 账户编码标识
• 工作描述
• 假设条件和制约因素
• 负责的组织
• 进度里程碑
• 相关的进度活动
• 所需资源
• 成本估算
• 质量要求
• 验收标准
• 技术参考文献
• 协议信息

控制账户

1. 控制账户是一个管理控制点。
2. 在该控制点上，将范围、预算和进度加以整合，并与挣值相比较来测量绩效。
3. 控制账户包含两个或更多工作包，每个工作包只与一个控制账户关联。
4. 项目管理实践中，通常控制账户和专业相关。

规划包

1. 规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容已知，但详细的进度活动未知。
2. 一个控制账户可以包含一个或多个规划包。
3. 由于当前无法分解到编制项目管理计划所需的细节程度，规划包是暂时用于做计划的。
4. 随着情况的逐渐清晰，规划包最终将被分解成工作包以及相应的具体活动。

工作包分解原则

1. WBS 必须是面向可交付成果的。
2. WBS 必须符合项目的范围。（100% 原则）
3. WBS 的底层应支持计划和控制。
4. WBS 中的元素必须有人负责，而且只有一个人负责。
5. WBS 应控制在 4～6 层：如果项目规模比较大，以至于 WBS 要超过 6 层，此时，可以使用项目分解结构将大项目分解成子项目，然后针对子项目来做 WBS。
6. WBS 应包括项目管理工作，也包括分包出去的工作。
7. WBS 的编制需要所有（主要）项目干系人的参与。
8. WBS 并非是一成不变的。

范围基准

包含：

1. 经过批准的范围说明书
2. WBS
3. WBS字典

确认范围

作用

1. 使验收过程具有可观性。
2. 通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。

ITTO

确认范围的步骤

1. 确定需要进行范围确认的时间；
2. 识别范围确认需要哪些投入；
3. 确定范围正式被接受的标准和要素；
4. 确定范围确认会议的组织步骤；
5. 组织范围确认会议。

需要检查的问题

项目干系人进行范围确认时，要检查的内容：

1. 可交付成果是否明确的、可确认的。
2. 每个可交付成果是否有明确的里程碑，里程碑是否明确的事件，例如，客户的书面认可等。
3. 是否有明确的质量标准。
4. 审核和承诺是否有清晰的表达。
5. 项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
6. 项目范围的风险是否太高，管理是否能够降低风险发生对项目的影响。

干系人关注点的不同

1. 管理层主要关注项目范围：
   指关注项目的进度、资金和资源的影响，这些因素是否超出了组织承受范围，是否在投入产出上具有合理性。
2. 客户主要关注产品范围：
   关注项目的可交付成果是否是完整的产品或服务。
3. 项目管理人员主要关注项目管理控制因素：
   关注项目可交付成果是否是完整的，时间、资金和资源是否足够，主要的潜在风险和备解的方法。
4. 项目团队成员主要关注项目范围中自己参与的元素和负责任务：
   通过确定范围中的时间检查自己的工作时间是否足够，自己在项目范围中是否有多项工作，而这些工作是否有冲突的地方。

可交付成果的演变

1. 可交付成果：指导与管理项目工作
2. 核实的可交付成果：质量控制
3. 验收的可交付成功：确认范围
4. 最终的产品、成果获服务：结束项目或阶段

质量控制vs范围确认

• 确认范围：关注可交付成果的验收
• 控制质量： 关注可交付成果的正确性及是否满足质量要求。

控制质量过程通常优先于确认范围过程，但二者也可以同时进行。

控制范围

作用

在整个项目期间保持对范围基准的维护

ITTO

范围蔓延

• 未经控制的产品或项目范围的扩大（不及时、成本和资源做相应调整）被称为范围蔓延。
• 狭义的范围蔓延， 特指在项目要求下，未经正式的范围控制程序而出现的产品或项目范围的扩大，也叫 “范围爬行”。
• 镶金 是广义范围蔓延的一种，是指在定义范围的工作范围之外，项目团队主动增加的额外工作，但没有经过范围控制程序。
• 不管镶金还是范围爬行，共同点都是没有经过整体变更控制程序而发生了范围变化。统称 “范围蔓延”。

[^1]:项目管理计划：质量管理计划、项目生命周期描述、开发方法

[^2]:数据分析：备选方案分析

[^3]:项目管理计划：范围管理计划、需求管理计划、干系人参与计划

[^4]:项目文件：假设日志、干系人登记册、经验教训登记册

[^5]:协议：项目和产品需求

[^6]:数据收集：头脑风暴、访谈、焦点小组、问卷调查、标杆对照

[^7]:数据分析：文件分析

[^8]:决策：投票、独裁型决策制定、多标准决策分析

[^9]:数据表现：亲和图、思维导图

[^10]:人际关系与团队技能：名义小组技术、观察和交谈、引导

[^11]:项目管理计划：范围管理计划

[^12]:项目文件：假设日志、需求文件、风险登记册

[^13]:数据分析：备选方案分析

[^14]:决策：多标准决策分析

[^15]:人际关系与团队技能：引导

[^16]:项目文件（更新）：假设日志、需求文件、需求跟踪矩阵、干系人登记册

[^17]:项目文件：需求文件、项目范围说明书

[^18]:项目文件（更新）：假设日志、需求文件

[^19]:项目管理计划：范围管理计划、需求管理计划、范围基准

[^20]:项目文件：需求文件、需求跟踪矩阵、质量报告、经验教训登记册

[^21]:决策：投票

[^22]:项目文件（更新）：需求文件、需求跟踪矩阵、经验教训登记册

[^23]:项目管理计划：范围管理计划、需求管理计划、变更管理计划、配置管理计划、范围基准、绩效测量基准

[^24]:项目文件：需求文件、需规跟踪矩阵、经验教训登记册

[^25]:数据分析：偏差分析、趋势分析

[^26]:项目管理计划（更新）：范围管理计划、范围基准、进度基准、成本基准、绩效测量基准

[^27]:项目文件（跟新）：需求文件、需求跟踪矩阵、经验教训登记册