《[项目名称] 范围管理计划》

¶

一、 范围管理流程概览¶

填写指南： 描述本项目管理范围的五个过程：规划范围管理、收集需求、定义范围、创建WBS、确认范围、控制范围。

本项目的范围管理遵循公司《项目管理规范》，流程如图所示：
[在此处可插入范围管理流程图]

二、 范围定义与WBS标准¶

2.1 需求收集方法¶

• 访谈/问卷： 针对[关键干系人]进行[1对1访谈/问卷调研]。
• 原型演示： 使用[Axure/Figma]制作原型，确认交互细节。
• 产品Backlog： 敏捷项目中，需求以User Story形式录入[Jira/PingCode]。

2.2 工作分解结构（WBS）编制规则¶

• 分解原则： 遵循“100%原则”，子任务之和必须等于父任务。
• 粒度要求： 最底层工作包的工期建议控制在 [4-40小时] 或 [1-5天]。
• 编码规则： WBS编号采用[1.1, 1.1.1]层级编码，便于追踪。

2.3 WBS词典（样例）¶

每个工作包需在WBS词典中定义清楚。
| WBS编号 | 工作包名称 | 详细描述 | 责任人 | 验收标准 |
| :--- | :--- | :--- | :--- | :--- |
| 1.1.1 | 登录模块开发 | 实现账号密码、手机验证码登录 | 张三 | 功能测试通过，无高危漏洞 |

三、 范围基准确认¶

• 范围说明书： 详细描述项目的可交付成果、假设和制约因素。
• 审批流程： 需求规格说明书需经[业务负责人/产品经理]签字确认后，纳入范围基准。
• 基准冻结： [XXXX年XX月XX日]正式启动执行后，范围基准冻结。

四、 范围控制与变更¶

核心章节： 明确如何防止“范围蔓延”。

4.1 变更控制流程¶

任何对范围基准的偏离，必须按照《变更管理快速指引》执行：

1. 识别变更（填写CR单）。
2. 分析影响（评估对进度、成本、质量的影响）。
3. 审批决策（PM或CCB审批）。
4. 更新基准（批准后调整WBS）。

4.2 范围蔓延预防机制¶

• 无单不做： 未录入[Jira/Project]系统的需求，开发人员有权拒绝开发。
• 定期审计： 每周五PM检查实际交付与WBS的一致性。

五、 范围验收管理¶

• 验收标准： 依据《需求规格说明书》及《验收测试用例》。
• 验收流程：
  1. 内部测试通过。
  2. 提交UAT测试申请。
  3. 干系人签署《用户验收报告》。