项目范围管理：把要做的事讲清、拆全、验明

软考动态

湖南、新疆：报名窗口仍在，留意缴费截止时间

截至 9 月 12 日，下列两地仍可报名。已经提交材料的考生，应继续查看审核结果和缴费状态。

地区	报名截止	缴费截止	本周行动
湖南	9 月 14 日 17:00	9 月 15 日 17:00	尽快提交属地证明；审核截至 9 月 15 日 12:00，通过后及时缴费
新疆	9 月 18 日 17:00	9 月 22 日 17:00	核对报考材料和审核结果，在缴费截止前完成确认

两地通知所列下半年资格包含系统集成项目管理工程师，未列入信息系统项目管理师。备考高项的读者请勿把这些日期当作高项报名窗口；具体资格、属地要求和后续调整以所在考区官方通知为准。

来源：湖南软考办通知、新疆自治区工信厅通知。本条是仍有效窗口的提醒。

知识点

项目范围管理：把要做的事讲清、拆全、验明

客户说“做一个采购管理系统”，业务部门希望能走审批，财务需要对账，采购人员还希望自动催单。团队如果直接把这些想法当作开发清单，往往会在交付时才发现：有人期待的功能从未约定，有人约定的工作没有安排，还有人把“测试通过”当作“客户已经验收”。

范围管理要建立一套可追溯的约定：目标对应哪些需求，哪些需求进入项目，工作怎样分解，成果怎样验收，后来的变化怎样受控。

本文沿用《信息系统项目管理师教程（第4版）》的六过程口径。术语名称与通俗解释分开呈现；标为“编辑提示”的内容以及采购系统示例，均为学习整理。

先分清产品范围和项目范围

产品范围关注产品、服务或成果具备的特征与功能，例如采购申请可以分级审批、能导出指定格式的对账数据。项目范围关注为交付这些成果必须完成的工作，例如需求分析、系统设计、开发测试、数据迁移、培训及项目管理。

教程将产品范围包含在项目范围之中。产品做什么，会影响项目需要做什么；项目范围也包含支撑交付的工作。只列功能菜单，容易漏掉迁移、培训、验收准备和外包接口。

编辑提示：判断产品范围是否完成，要看产品需求；判断项目范围是否完成，要对照项目管理计划。不能用“代码写完了”代替对全部约定工作的检查。

过程组	过程	要解决的问题	主要结果
规划	规划范围管理	用什么规则定义、确认和控制范围	范围管理计划、需求管理计划
规划	收集需求	各方需要什么，怎样记录和追溯	需求文件、需求跟踪矩阵
规划	定义范围	本次承诺交付什么，边界在哪里	项目范围说明书
规划	创建WBS	全部工作怎样分解到可管理的程度	范围基准
监控	确认范围	已完成的成果是否获得正式验收	验收的可交付成果
监控	控制范围	实际范围有何偏离，变更怎样处理	工作绩效信息、变更请求等

六个过程不包含执行过程组的过程，但范围约定会指导执行工作。教程对开展频率作了区分：规划范围管理、收集需求、创建WBS仅开展一次或在预定义点开展；定义范围需要反复开展；确认范围按需要定期开展；控制范围贯穿项目期间。

在敏捷或适应型项目中，收集需求、定义范围、创建WBS，以及确认范围和控制范围，会随迭代重复开展。先辨认题干所处的生命周期，再判断过程的开展方式。

图：范围管理的主要文件关系。管理计划提供规则，控制范围持续开展；这是文件流示意，实际项目可以迭代。图中执行工作和控制质量用于说明成果的上游来源。

规划范围管理：先约定怎样管

题干出现“规定范围如何定义、如何验收、变更怎样审批”，首先考虑规划范围管理。此时主要形成管理规则，尚未产出详细的项目范围说明书。

输入

条目	主要内容与理解提示
项目章程	提供项目目的、高层级需求、概述、假设条件及制约因素。先弄清项目为何成立，再选择管理范围的方法。
项目管理计划	本过程关注质量管理计划、项目生命周期描述、开发方法。质量要求和交付方式会影响范围怎样定义、确认与控制。
事业环境因素	如组织文化、基础设施、人事管理制度、市场条件，构成方法选择所处的环境。
组织过程资产	如政策、程序、历史信息和经验教训知识库，可复用已有的管理经验。

工具与技术

条目	主要内容与理解提示
专家判断	借助类似项目、行业和应用领域的经验，判断什么管理方式适合本项目。
数据分析	本过程关注备选方案分析：比较收集需求、细化范围、确认和控制范围的不同方法。
会议	让项目经理、发起人、团队、相关干系人及过程负责人共同约定规则。

输出

条目	主要内容与理解提示
范围管理计划	说明怎样编制范围说明书、创建WBS、审批和维护范围基准、正式验收成果。它回答“范围怎样管”。
需求管理计划	说明需求活动如何规划、跟踪和报告，需求变更及配置管理如何开展，怎样排序、测量和追溯需求。它回答“需求怎样管”。

编辑提示：需求管理计划规定跟踪方式，需求跟踪矩阵落实每条需求的跟踪记录；两者不可互换。

收集需求：把口头期待变成可追溯的要求

这一过程要确定、记录并管理干系人的需要和需求，为范围定义提供依据。收集到的需求需要分析和取舍，不能全部自动转成项目承诺。

输入

条目	主要内容与理解提示
项目章程	用高层级需求和项目概述限定需求探索的方向。
项目管理计划	包括范围管理计划、需求管理计划、干系人参与计划：明确工作方法、记录规则和参与安排。
项目文件	包括假设日志、经验教训登记册、干系人登记册：检查需求所依赖的假设，借鉴有效方法，找到能提供需求的人。
立项管理文件	本过程关注商业论证产生的文件，从中识别满足业务需要的必要、期望及可选标准。不要把需求探索割裂成单纯的功能收集。
协议	从协议中识别已约定的项目和产品要求。
事业环境因素	如文化、基础设施、人事管理制度和市场条件，会影响需求及其获取方式。
组织过程资产	如需求管理政策、程序和历史项目经验，可作为需求活动的参考。

工具与技术

条目	本过程的具体方法与使用情境
专家判断	借助可行性研究与评估、需求获取与分析、需求文件编制、类似项目经验、图解、引导及冲突管理等专业能力，识别遗漏或含糊的需求。
数据收集	头脑风暴收集多种想法；访谈适合深入了解个人需要；焦点小组由主持人组织特定群体讨论；问卷调查适合人数多、地点分散且需统计分析的情境；标杆对照参考可比组织的实践。
数据分析	本过程关注文件分析：从协议、业务流程、接口资料、业务规则、现行流程、政策和用例等已有信息中发现需求。
决策	投票、独裁型决策制定、多标准决策分析。投票可以采用一致同意、大多数同意、相对多数同意；多标准决策分析用多个评价维度比较需求。
数据表现	亲和图把大量创意分类；思维导图表现创意间的联系、共性与差异。前者偏归组，后者偏关联。
人际关系与团队技能	名义小组技术用结构化讨论和投票排序；观察和交谈发现使用者难以说清的实际工作需要；引导帮助不同角色协调需求。联合应用设计或开发、质量功能展开、用户故事是理解引导应用的情境。
系统交互图	展示系统边界，以及系统与用户、其他系统间的输入输出关系。采购系统与财务平台的接口是否在范围内，可借此澄清。
原型法	让使用者体验模型，尽早反馈并反复修改。原型包括界面模型、实物模型等，故事板也是一种原型技术。

名义小组技术可以按“个人提出想法—记录—共同讨论澄清—私下投票排序”理解。它通过结构化步骤组织意见，不能只记成“大家随便讨论”。

输出

条目	主要内容与理解提示
需求文件	记录单项需求及其业务理由。需求应清楚、可测量或可测试、可跟踪、完整且相互协调，并得到主要干系人的认可。
需求跟踪矩阵	把需求连接到来源、目标、范围与WBS、设计、开发和测试，记录标识、负责人、优先级、版本、状态等属性，用来追溯需求有没有落实及变更会影响哪里。

需求可以涉及业务需求、干系人需求、解决方案需求、过渡和就绪需求、项目需求、质量需求。解决方案需求又包括功能需求和非功能需求；性能、安全等属于非功能需求，迁移和培训可能体现过渡和就绪需要。

下面是一个编辑示例。实际项目可按需要增加字段。

需求标识	需求与业务目的	对应工作包	验证与状态
R-01	采购申请按金额分级审批，减少越权审批	1.2 审批功能	测试金额边界和角色权限；待验收
R-02	迁移历史供应商数据，保证上线后可检索	1.3 数据迁移	核对总量及关键字段；待验证
R-03	财务导出对账数据，减少重复录入	1.4 对账接口	核对格式与汇总结果；待开发

编辑提示：需求文件让人看懂“要求是什么”；跟踪矩阵让人查到“要求来自哪里、落实到哪里、现在怎样”。只有标题和完成勾选框的功能清单，通常不足以承担需求追溯。

定义范围：把需求收敛为明确承诺

定义范围要形成项目与产品的详细描述。题干若强调确定产品边界、主要成果、验收条件和不包含的内容，重点通常在这一过程。

输入

条目	主要内容与理解提示
项目章程	提供高层级项目描述、产品特征和审批要求，防止详细范围偏离项目初衷。
项目管理计划	本过程关注范围管理计划，依照其中规定的方法定义范围。
项目文件	包括假设日志、需求文件、风险登记册。从需求中选择本次承诺的内容，同时考虑假设、限制和风险应对对范围的影响。
事业环境因素	如文化、基础设施、人事管理制度、市场条件，限制或影响可行的范围方案。
组织过程资产	如范围说明书的政策、程序、模板、项目档案及经验教训，帮助形成完整描述。

工具与技术

条目	主要内容与理解提示
专家判断	利用类似项目经验检查边界是否清晰、成果是否完整。
数据分析	本过程关注备选方案分析，比较实现目标与需求的不同路径。
决策	本过程关注多标准决策分析，综合需求、进度、预算、资源等标准选择范围方案。
人际关系与团队技能	本过程关注引导，促进跨职能干系人对成果和边界达成共识。
产品分析	可采用产品分解、需求分析、系统分析、系统工程、价值分析、价值工程，把高层级产品描述细化为有意义的成果。

输出

条目	主要内容与理解提示
项目范围说明书	详细说明范围、主要成果、假设条件与制约因素；重点写清产品范围描述、可交付成果、验收标准、项目的除外责任。可以直接写明，也可引用相关文件。
项目文件更新	本过程涉及假设日志、需求文件、需求跟踪矩阵、干系人登记册。范围取舍发生变化时，相应记录也要一致。

采购系统的范围说明书可以明确：“本期交付申请、审批和对账导出；不包含自动付款；历史数据迁移限定为已确认的数据集；验收按约定用例和结果进行。”这比“系统运行正常”更便于检查。

编辑提示：项目章程是高层级授权和描述；项目范围说明书是详细范围约定。明确除外责任有助于管理期望，也有助于判断新增请求是否越过边界。

创建WBS：把全部工作拆到可管理

WBS 是对全部项目工作范围的层级分解，最低层为工作包。分解要围绕可交付成果，并把项目管理、外包和支撑交付的工作纳入考虑。

输入

条目	主要内容与理解提示
项目管理计划	本过程关注范围管理计划，其中规定如何依据范围说明书创建WBS。
项目文件	包括项目范围说明书、需求文件。前者给出承诺的整体范围和边界，后者提供细化需求。
事业环境因素	如行业WBS标准，提供外部参考。
组织过程资产	如WBS政策、程序、模板、既往项目档案及经验教训，支持复用。

工具与技术

条目	主要内容与理解提示
专家判断	利用类似项目经验识别漏项，判断分解粒度是否便于估算、分工和控制。
分解	识别成果和相关工作，确定结构，自上而下细化，为组件分配标识编码，再检查分解程度是否合适。

输出

条目	主要内容与理解提示
范围基准	经过批准的项目范围说明书、WBS及相应的WBS字典，作为比较和控制的依据。获批后要通过正式变更控制维护。
项目文件更新	本过程涉及假设日志、需求文件。分解发现的新假设、制约因素和已获批准的需求变更，需要回写相应文件。

WBS字典帮助读者理解每个组件的具体含义，可包括账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关进度活动、资源、成本估算、质量要求、验收标准、技术参考和协议信息。

容易混淆的概念	应当怎样理解
WBS 与活动清单	WBS 表达成果及工作范围的层级；活动清单在此基础上进一步确定为完成工作包所需的活动。WBS本身不负责排列活动先后顺序。
工作包与控制账户	工作包是WBS最低层；控制账户是整合范围、预算和进度进行绩效测量的管理控制点。教程写明一个控制账户包含两个或更多工作包，每个工作包只关联一个控制账户。
规划包与工作包	规划包位于控制账户之下、工作包之上，工作内容已知，但详细进度活动未知，后续可以继续细化。不能把规划包当作没有任何范围约定。
WBS 与范围基准	WBS 是范围基准的组成部分。一张未经批准的分解图不能代表完整的范围基准。

教程提示：分解注意事项包括100%原则（包含原则）、每个元素由一个人负责、避免交叉从属、主要干系人参与，以及纳入管理和分包工作。教程还给出WBS控制在 4～6层、每个级别将上一级元素分为 4～7个新元素的指导；大型项目可先分为子项目，再分别创建WBS。

编辑提示：用100%原则检查下层工作汇总是否覆盖上层范围，既不遗漏，也不多加。不同分支可以分解到不同深度，应结合规模和复杂程度判断是否便于估算、分工与控制；颗粒度过细也会增加维护负担。

确认范围：让成果获得正式验收

确认范围关注客户或发起人是否正式接受成果。题干中的“签字验收”“按验收标准审查已完成成果”是重要识别线索。

输入

条目	主要内容与理解提示
项目管理计划	包括范围管理计划、需求管理计划、范围基准，提供正式验收的方法、需求确认规则和比较依据。
项目文件	包括经验教训登记册、质量报告、需求文件、需求跟踪矩阵，帮助检查验收依据、需求落实和此前遇到的问题。
核实的可交付成果	已经完成并通过控制质量检查的成果，是本过程接受审查的对象。
工作绩效数据	如符合需求的程度、不一致的数量与严重性、已开展确认的次数，属于实际观察和测量数据。

工具与技术

条目	主要内容与理解提示
检查	通过测量、审查等活动判断成果是否符合需求和验收标准。
决策	本过程关注投票，在适用情境下帮助参与验收的人形成结论。不能把其他过程的全部决策方法直接套过来。

输出

条目	主要内容与理解提示
验收的可交付成果	符合验收标准，并获得客户或发起人正式确认的成果；相关验收文件向项目或阶段收尾传递。
工作绩效信息	记录哪些成果通过验收、哪些未通过及原因，供干系人了解进展。
变更请求	对未通过验收的成果记录原因，必要时提出缺陷补救等变更请求，交由实施整体变更控制处理。
项目文件更新	本过程涉及经验教训登记册、需求文件、需求跟踪矩阵，记录验收方法、实际结果及需求状态。

编辑提示：控制质量关注成果的正确性和质量要求，确认范围关注正式验收。控制质量通常先于确认范围，也可同时开展。测试报告能证明完成了相应测试，却不能单独证明客户已经正式验收；验收也不必等到整个项目最后一天才发生。

控制范围：发现偏差，并让变化受控

控制范围持续对照基准观察项目和产品的范围状态，分析偏差及原因，协调处理范围变更。它并不意味着拒绝所有新增需求。

输入

条目	主要内容与理解提示
项目管理计划	包括范围管理计划、需求管理计划、变更管理计划、配置管理计划、范围基准、绩效测量基准。分别提供控制方式、需求规则、变更程序、配置项管理及比较依据。
项目文件	包括经验教训登记册、需求文件、需求跟踪矩阵，帮助发现偏离、评估影响和追踪受控需求的状态。
工作绩效数据	如收到与接受的变更请求数量，以及已完成、核实和验收的成果数量。数据本身还需要结合基准分析。
组织过程资产	如范围控制政策、程序、指南和监督报告模板，使处理方式具有一致性。

工具与技术

条目	主要内容与理解提示
数据分析	偏差分析比较实际与基准，确定原因、程度及是否需要措施；趋势分析观察范围绩效随时间的变化，判断情况在改善还是恶化。

输出

条目	主要内容与理解提示
工作绩效信息	将数据与背景、基准关联，说明变更类型、偏差原因及对进度成本的影响，并形成范围绩效判断。
变更请求	将需要调整范围或其他计划的事项提交正式处理。提出请求不等于批准请求。
项目管理计划更新	本过程涉及范围管理计划、范围基准、进度基准、成本基准、绩效测量基准；需要变更时依照正式流程，在获批后更新相应内容。
项目文件更新	本过程涉及经验教训登记册、需求文件、需求跟踪矩阵，记录有效控制方法、偏差原因和需求变化。

客户临时提出“再加一个自动付款功能”，应先记录并分析它对需求、范围、进度、成本、质量和风险等方面的影响，按变更管理程序交由有权限的角色审批。获批后同步更新受影响文件，再组织实施和跟踪。未经控制就增加功能，容易造成范围蔓延。

用一条文件链检查是否真正学懂

需求文件 → 项目范围说明书 → WBS与WBS字典 → 范围基准 → 核实的可交付成果 → 验收的可交付成果，可以作为复习线索。箭头省略了审批、执行和质量控制等环节；需求跟踪矩阵贯穿其中，管理计划为各环节提供规则。

看到的情境	应先检查的对象
客户与开发人员对“做好了”的理解不同	范围说明书里的成果、边界和验收标准是否足够明确
某个需求没有对应开发或测试工作	需求跟踪矩阵中的需求—工作包—测试关联是否断开
开发功能都完成，却漏了数据迁移和培训	WBS是否覆盖全部项目工作，是否满足100%规则
已经测试通过，却找不到客户确认记录	是否完成确认范围，是否取得正式验收文件
需求变了，团队直接改代码并修改原基准	是否先提出、分析和审批变更，文件版本是否同步

编辑自测：采购系统上线前，团队主动增加一个未经批准的统计看板，客户随后要求把看板列入正式验收范围。问题首先出在哪里？

参考思路：先检查新增工作是否有批准依据，以及是否对资源、工期等影响进行处理。团队认为“对客户有帮助”，不能代替变更审批。应补齐问题记录和影响分析，依照既定程序决定如何处置，并维护需求与范围文件的一致性。

实践与论文准备：让新增能力有可检查的边界

PMI 关于 WBS 的文章把范围分解应用到 AI 工作流，提醒项目人员同时考虑自动化能力、人工介入和交接责任。可将这个角度用于准备真实项目材料，不能据此推断软考命题方向。阅读原文

下面是一个编辑构造的采购系统示例：为采购人员生成询价邮件草稿。准备案例或论文材料时，可以记录以下管理动作和证据。

管理动作	可以留存的证据
明确本次能力和排除项	需求记录写明只生成草稿；自动发送、供应商定标和付款审批不包含在本次范围
把交付及保障工作纳入分解	WBS与字典记录草稿生成、人工复核、异常处理、运行记录和人员培训等工作
让验收条件能被检查	准备覆盖正常和异常输入的测试用例，记录是否按约定呈现草稿和转交人工
处理“希望自动发出邮件”的后续请求	保留变更单、影响分析、审批结论，以及范围与需求文件的版本关系

只有项目中真实实施并有证据支持的动作，才适合写入个人项目叙述。技术工具可以辅助形成文档，范围取舍和验收责任仍需由项目中的相应角色承担。

延伸查阅

教程第四版官方书目信息可用于确认版本；官方目录可定位本专题。继续用知识领域图谱查看范围过程与知识对象之间的关系，也可在绩效域中思考交付、规划和干系人参与如何共同支持范围工作。

图谱使用“预测型项目管理学习图谱·教材逐条审校中”的学习口径；通俗解释和编辑提示应与教材标准名称区分使用。

好文章

本周新文：Agentic AI Is Revealing the Organizational Readiness Gap

Virginia Thompson · PMI · 2026-09-10 · 英文

文章讨论 AI 应用对组织流程、人员能力和责任安排提出的要求。值得读的原因是，它能提醒范围管理者在识别需求时关注组织如何承接成果。阅读时可以给自己的项目补问：哪些培训、流程调整和交接工作也需要纳入范围？这是阅读后的实践思考。阅读全文

专题延伸：Work Breakdown Structure: Define the Work Before You Build It

Project Management Institute · 2026-08-18 · 英文 · 历史文章

这篇文章适合在学完创建WBS后阅读：它把工作包、WBS字典、100%规则与责任边界联系起来，也讨论人和 AI 配合时容易含糊的交接工作。可以拿自己的分解结果对照检查，尤其留意每个工作包的边界是否已得到相关人员理解。阅读全文