软考高项-范围管理

高项--范围管理

我们直接切入核心。高项（信息系统项目管理师）考试中的第九章“项目范围管理”，说白了就是两件事：“做什么”和“不做什么”。

如果项目管理有底线，范围管理就是那条底线。下面我按照“核心目的 + 6个过程 + 论文金句 + 大白话对照”的结构帮你总结。

 

 一、核心目的（一句话总结）
保证项目做且只做成功完成项目所需要的全部工作。
（关键词：“且只做” —— 既要不少做（防止交付失败），也不能多做（防止范围蔓延）。）

二、六个管理过程（这是考试论文的骨架）
范围管理一共有6个过程，可以分为两组：“规划组”（定规矩）和“执行组”（防跑偏）。

第1组：写计划（动笔之前的事）
1.  规划范围管理
    -   做什么： 制定一份计划书，告诉团队以后该怎么管范围。
    -   输出： 《范围管理计划》（规定流程）、《需求管理计划》（规定怎么管需求）。
    -   大白话： 先定好游戏规则。

2.  收集需求
    -   做什么： 通过各种手段（访谈、问卷、原型法），把干系人脑子里的想法挖出来，变成白纸黑字。
    -   输出： 《需求文件》、《需求跟踪矩阵》。
    -   大白话： 你到底想要啥？写下来，别过后不认账。

3.  定义范围
    -   做什么： 把收集来的需求，加工成详细的项目范围说明书。
    -   输出： 《项目范围说明书》（包含产品范围描述、验收标准、项目可交付成果、除外责任）。
    -   大白话： 把这些需求翻译成我们要干的活，而且明确什么活我们不干。

4.  创建WBS（工作分解结构）
    -   做什么： 把大的可交付成果，一层层拆成小的、好管理的工作包（直到无法再分）。
    -   输出： WBS（图形化结构）、WBS词典（文字说明）。
    -   大白话： 大卸八块，直到每个人都知道自己该干那一小块。

第2组：控变更（干活之后的事）
5.  确认范围
    -   做什么： 干完一个阶段，让客户或发起人正式验收签字。
    -   输出： 验收的可交付成果、变更请求。
    -   大白话： 干完了，您看一眼，没问题请签字。不签字不干下一步。

6.  控制范围
    -   做什么： 监督项目状态，维护范围基准。当有人想加东西时，走变更流程。
    -   输出： 工作绩效信息、变更请求。
    -   大白话： 盯着，防止范围悄悄长胖（范围蔓延）。

---

三、论文必杀技：核心概念与术语转换

如果你在写论文，千万别只写“我们开会确定了要做啥”，要写出专业感。

1. 三个关键“基准”（论文里的高端词汇）
-   范围基准 = 范围说明书 + WBS + WBS词典。
    -   论文用法： “我们确立了范围基准，作为后续绩效考核的依据。”
-   项目范围说明书 = 包含产品范围描述、验收标准、项目可交付成果、项目除外责任。
    -   论文用法： “在范围说明书中，我们特别明确了‘除外责任’，将ERP系统与硬件采购剥离，避免了职责不清。”
-   需求跟踪矩阵 = 一张表，连接“需求”和“最终交付物”。
    -   论文用法： “我们建立了需求跟踪矩阵，确保每一个需求都能在产品中找到对应的功能，防止镀金。”

2. 两个必防的坑（论文里的反面案例）
-   范围蔓延：未经控制的产品或项目范围的扩大。（比如客户私下找程序员加个按钮）
-   镀金：团队成员私自给客户加功能，以为是对项目好。（这是大忌，属于讨好客户，浪费成本）

3. 常用工具与技术（让阅卷老师觉得你很专业）
-   收集需求时： 除了访谈，写“原型法”（快速做出demo给客户看）、“标杆对照”（看看竞争对手怎么做的）。
-   创建WBS时： 写“分解”技术，并强调遵循 “8/80原则”（工作包控制在8小时到80小时之间）。

---

四、考试偷分清单

| 过程名称 | 核心输出 | 易错点（考试爱考） |
| 规划范围管理 | 范围管理计划、需求管理计划 | 这两个计划是“计划的管理”，不是具体的范围内容。 |
| 收集需求 | 需求文件、需求跟踪矩阵 | 区分“需求”和“范围”，需求是源头。 |
| 定义范围 | 项目范围说明书 | “除外责任” 是考试高频点，明确不做什么。 |
| 创建WBS | 范围基准、WBS词典 | WBS最底层是 “工作包” ，不是活动。 |
| 确认范围 | 验收的可交付成果 | 这是正式验收，主要关注客户满意度。 |
| 控制范围 | 变更请求 | 这是监控过程组，关注范围基准是否被改变。 |

五、一句话速记口诀
> “规收定创确控”（规划-收集-定义-创建-确认-控制）

这六个字按顺序背下来，考试时顺着写，逻辑分就拿到了。