26.4 范围管理：案例分析理论题必背要点

一、范围管理过程中存在的问题

（一）规划范围管理

（二）收集需求

（三）定义范围

（四）创建WBS

（五）确认范围

（六）控制范围

二、需求管理可能的问题及应对措施

（一）常见问题

（二）应对措施

1. 建立需求变更控制策略和流程

   • 使用变更控制委员会（CCB）审批变更
   • 记录变更请求及其影响
   • 更新需求跟踪矩阵

2. 充分获取用户需求并进行详细分析

   • 采用多种需求收集方法（如访谈、问卷、原型）
   • 组织需求评审会议，确保需求清晰准确

3. 形成需求规格说明书并与用户进行需求验证和评审

   • 确保需求规格说明书覆盖所有需求
   • 邀请客户代表参与需求评审

4. 需求定稿后建立基线，后续变更走变更控制流程

   • 将需求规格说明书定稿为基线
   • 所有变更必须走正式流程

5. 编写需求跟踪矩阵，需求状态表等文档

   • 跟踪需求的状态与实现情况
   • 记录需求的变化与影响

6. 基于需求规格说明书编制技术方案，并进行评审

   • 技术方案应基于需求规格说明书
   • 组织技术评审，确保方案可行性

7. 定期检查项目绩效，找出问题原因并指导解决

   • 定期审查项目进展
   • 及时识别并解决问题

三、🔵 范围管理计划与需求管理计划的内容

（一）范围管理计划内容

1. 制定项目范围说明书
2. 根据详细项目范围说明书创建WBS
3. 确定如何审批和维护范围基准
4. 正式验收已完成的项目可交付成果

（二）需求管理计划内容

1. 如何规划、跟踪和报告各种需求活动
2. 配置管理活动（启动变更、分析影响、追溯、跟踪、报告、变更审批权限）
3. 需求优先级排序过程
4. 测量指标及使用这些指标的理由
5. 需求属性列入跟踪矩阵

四、🟠 范围说明书内容

范围说明书应包含以下关键要素：

1. 产品范围描述
2. 验收标准
3. 可交付成果
4. 项目的除外责任
5. 制约因素
6. 假设条件

🧠记忆口诀：“产验可除制假”

五、🔴 WBS分解的方法与原则

（一）分解方法

1. 以项目生命周期各阶段作为第二层

   • 产品和项目可交付成果放在第三层

2. 以主要可交付成果作为第二层

3. 纳入由外部组织开发的组件

   • 卖方须制定相应的合同WBS

（二）表示形式

• 树型结构图：层次清晰，结构性强，但不易修改
• 表格形式：直观性差，但能反映所有工作要素

（三）分解原则

1. 面向可交付成果
2. 符合项目范围
3. 支持计划和控制
4. 每个工作包只有一人负责
5. 工作包大小介于8/80小时之间
6. 包含项目管理工作和外包工作
7. 所有干系人参与编制
8. WBS并非固定不变

🧠记忆口诀：“一个人负责，4-6层，面果，盒饭，可变，全员，吃鸡，管饱”

六、🌟 需求跟踪矩阵与内容

（一）典型属性

• 唯一标识
• 需求的文字描述
• 收录该需求的理由
• 所有者
• 来源
• 优先级别
• 版本
• 当前状态和状态日期

（二）跟踪内容

1. 业务需要、机会、目的和目标
2. 项目目标
3. 项目范围和WBS可交付成果
4. 产品设计
5. 产品开发
6. 测试策略和测试场景
7. 高层级需求到详细需求的映射

七、✅ 案例题答题模板（直接套用）

当案例中出现“未编制范围管理计划”“需求获取不充分”“WBS未确认”等问题时，可答：

“该项目在范围管理方面存在严重缺陷：
① 未编制详细的范围管理计划与需求管理计划，缺乏正式指导；
② 需求收集工作不充分，未召开需求评审会，需求文档未经客户确认；
③ WBS由一人单独编写，未经干系人确认，缺乏团队共识；
④ 未进行正式的范围确认，导致部分功能未开发，范围蔓延风险高；
⑤ 变更未走正式流程，破坏了基线，引发返工。

建议：

• 制定详细的范围管理计划与需求管理计划，并组织正式评审；
• 采用多种方式全面获取需求，召开需求评审会，确保需求清晰准确；
• 让项目组成员共同参与WBS分解，并邀请干系人确认；
• 严格执行范围确认与变更控制流程，确保项目可控。”