项目范围确认的依据，是一组能够相互印证、且处于受控状态的文件与记录：经批准的范围说明书、WBS与工作包说明、需求及跟踪信息、验收标准、合同条款、变更批准记录、沟通纪要和可交付成果证据。确认动作是把这些依据逐项对照，由客户或授权干系人书面签署结论，形成可追溯的验收记录。本文按依据清单、操作步骤、角色分工、示例与完成检查展开，并说明这类依据与记录如何在ONES中归集。
要点总览（TL;DR）
- 范围确认的依据要同时满足三个条件：经过批准、处于受控版本、能与其他材料相互对照，缺少任何一条，确认结论都容易在事后被推翻。
- 确认按四步推进：核对范围说明书与需求基线、逐项对照WBS工作包与可交付成果、逐条判定验收标准、形成书面结论并归档。
- 依据之间不一致时，先回到经批准的基线判断哪一版有效，把差异登记为差异项并转入变更流程，不在确认会上口头修改范围。
- 签署人应是合同或项目章程明确的授权代表，确认结论书需写明确认对象、依据版本、结论、例外事项与后续安排。
- ONES的瀑布项目管理方案可用项目计划承载WBS、用基线对比追溯版本差异、在项目下关联需求范围与研发任务，便于依据归集与记录留痕。
范围确认前先备齐哪几类依据
范围确认会开得顺不顺利，很大程度上取决于会前依据是否齐备。判断一份材料能否作为确认依据，可以看三个特征：它是否经过批准、是否处于受控版本、是否能与其他依据相互对照。缺少其中任何一点，确认结论就容易在事后被推翻。下面按类别列出常用依据、来源与作用。
| 依据类别 | 典型内容 | 提供方 | 在确认中的作用 |
|---|---|---|---|
| 经批准的范围说明书 | 项目目标、范围边界、包含与不包含的事项、主要可交付成果 | 项目经理、业务负责人 | 界定本次确认的对象与边界，防止把范围外事项带入验收 |
| WBS与工作包说明 | 分解层级、工作包描述、责任人、交付物 | 项目经理 | 把范围说明书落到可逐项核对的颗粒度 |
| 需求清单与需求跟踪信息 | 需求编号、优先级、来源、与设计/开发/测试的对应关系 | 需求负责人 | 证明每项需求都有实现与验证的落点 |
| 验收标准与质量要求 | 功能验收条件、性能指标、质量门槛、验收方法 | 业务负责人、质量角色 | 作为逐条判定“是否达到”的尺子 |
| 合同或协议条款 | 交付物清单、交付时间、验收方式与期限 | 项目经理、商务角色 | 约束确认的形式与时限，明确双方义务 |
| 变更与批准记录 | 变更申请、影响分析、批准结论、生效版本 | 项目经理、变更审批人 | 说明当前范围与原始基线之间的差异来源 |
| 沟通记录与会议纪要 | 需求澄清结论、口头承诺的书面确认、争议处理记录 | 项目经理、需求负责人 | 补充正式文件未覆盖的共识，减少理解偏差 |
| 可交付成果的证据材料 | 文档、测试报告、演示记录、实物或系统截图 | 技术负责人、测试角色 | 证明成果实际存在并达到验收标准 |
把上表转成一张可用的清单时，建议增加四列：来源、责任人、版本号或批准日期、是否已批准。会前逐行确认状态，未批准或版本不明的材料先补齐再进入确认环节。清单本身也应作为会议材料留存，它记录了本次确认所依据的到底是哪一版文件。
按四步完成一次范围确认
依据齐备之后，确认过程可以拆成四步。每一步都有明确的输入、动作、输出和完成标志，避免确认停留在“大家看过了”的层面。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：核对范围说明书与需求基线的一致性 | 经批准的范围说明书、需求清单、需求跟踪信息 | 逐条比对范围边界内的需求是否都被说明书覆盖，说明书中的可交付成果是否都有对应需求 | 一致性核对记录，列出缺失项与多余项 | 所有差异都有编号和处理意见，无悬空条目 |
| 第二步：逐项对照WBS工作包与可交付成果 | WBS、工作包说明、成果证据材料 | 按工作包逐一确认交付物是否存在、是否完整，检查工作包之间的接口是否闭合 | 工作包对照表，标注已交付、部分交付、未交付 | 每个工作包都有明确状态，部分交付项写明缺口 |
| 第三步：组织确认会议并逐条确认验收标准 | 验收标准、质量要求、对照表、证据材料 | 由客户或授权干系人逐条判定验收标准是否满足，现场记录判定结果与异议 | 逐条判定记录，含通过、不通过、待补充证据三类结论 | 每条验收标准都有判定结论和判定人 |
| 第四步：形成书面确认结论并归档 | 前三步的记录、差异清单 | 汇总确认结论，写明确认范围、例外事项、后续处理安排，提交授权人签署 | 范围确认结论书、差异项清单、归档记录 | 授权人完成签署，记录进入受控归档位置 |
四步中最容易出问题的是依据之间不一致的处理。常见情形有三类：范围说明书与需求清单对同一功能的描述不同；WBS工作包包含的内容超出批准范围；验收标准与合同条款的验收方式冲突。处理原则是先停下判定，回到经批准的基线确认哪一版有效，把差异登记为差异项，按变更流程处理后再继续确认。确认会上直接口头修改范围，会让后续的验收记录失去依据。
谁提供依据、谁签署确认：角色与交付物分工
范围确认涉及多方，职责不清时容易出现“材料都给了，但没人对版本负责”的情况。下表按角色列出各自提供的依据与交付物，以及需要承担的确认动作。
| 角色 | 提供的依据 | 交付物 | 确认中的职责 |
|---|---|---|---|
| 项目经理 | 范围说明书、WBS、变更记录、会议纪要 | 依据清单、确认会议组织方案、确认结论书 | 汇总依据、组织确认、跟踪差异项闭环 |
| 需求或业务负责人 | 需求清单、需求跟踪信息、验收标准 | 需求基线版本、验收标准说明 | 解释需求意图，参与验收标准逐条判定 |
| 技术负责人 | 设计文档、实现说明、成果证据 | 可交付成果证据包 | 说明成果与工作包的对应关系，回应技术异议 |
| 质量角色 | 测试报告、质量检查记录 | 质量结论与证据索引 | 核对验收标准是否有对应验证证据 |
| 配置或版本管理角色 | 基线记录、版本发布记录 | 受控版本清单 | 核对所有依据是否为当前受控版本 |
| 客户或授权干系人 | 合同条款、业务验收要求 | 签署后的范围确认结论 | 逐条判定验收标准，签署确认结论 |
签署环节需要特别注意授权范围。签署人应当是合同或项目章程中明确的授权代表，代签需有书面授权。确认结论书应写明确认的对象、依据的版本、确认的结论、例外事项和后续安排，签署后与依据清单一并归档，形成从依据到结论的完整链条。
一个范围确认会的依据对照示例
以下为演示情景，用于说明依据如何逐项对照并形成结论。某企业管理系统一期项目进入范围确认阶段，确认对象为一期合同约定的六个功能模块及配套文档。
| 对照项 | 依据 | 对照结果 | 处理方式 |
|---|---|---|---|
| 模块范围 | 范围说明书 vs 合同交付物清单 | 合同列出的报表模块在说明书中被标注为二期内容 | 登记差异项，提请变更审批确认是否调整一期范围 |
| 需求覆盖 | 需求清单 vs 需求跟踪信息 | 两条需求无对应设计与测试记录 | 要求补充实现与验证证据，暂列待确认 |
| 工作包交付 | WBS工作包 vs 成果证据 | 五个工作包证据齐全，一个工作包仅有部分文档 | 明确缺口内容与补充时限 |
| 验收标准 | 验收标准 vs 测试报告 | 功能验收标准均有测试记录；性能指标缺少峰值场景数据 | 补充峰值测试后二次判定 |
| 版本状态 | 受控版本清单 vs 各依据版本号 | 需求清单存在两个版本，会议使用的是较早版本 | 更换为当前受控版本后重新核对相关条目 |
对照结束后，确认结论写明：四个模块及配套文档通过确认；报表模块范围归属待变更审批后确定；两条需求与一项性能指标待补充证据后二次确认。授权干系人在结论书上签署，差异项清单同步转入变更流程跟踪。这个示例说明，确认会的产出是一份带例外事项的书面结论，把未决问题显性化，而非一个笼统的“通过”。
确认完成前要过的检查项
范围确认是否真正完成，可以用下面这组检查项逐条判断。任何一项为否，都说明确认还存在缺口。
| 检查项 | 判断标准 | 不通过时的处理 |
|---|---|---|
| 依据是否均为受控版本 | 每份依据都有版本号或批准日期，且与受控版本清单一致 | 更换为当前版本，重新核对受影响条目 |
| 每条验收标准是否有对应证据 | 验收标准与测试报告、演示记录等证据一一对应 | 补充证据或标注为待确认，不纳入本次通过范围 |
| 确认结论是否有授权人签署 | 签署人具备合同或章程规定的授权，签署日期完整 | 补签或取得书面授权后重新签署 |
| 差异项是否已记录并转入变更流程 | 每个差异项有编号、责任人、处理状态 | 补登记并指定跟踪人，明确处理时限 |
| 确认记录是否归档并可检索 | 结论书、依据清单、差异清单存放在统一位置，可按项目检索 | 按归档规则整理后入库，通知相关方位置 |
这组检查项也适合作为确认会结束前的收尾议程，由项目经理逐条宣读结论，避免会后补材料时遗漏。对于跨期项目，每次阶段确认都重复一遍检查，可以让范围基线在长周期内保持可追溯。
用ONES承载范围确认的依据与记录
范围确认的依据往往分散在文档、表格、邮件和会议纪要中，版本对齐和记录归档是常见的管理难点。ONES的瀑布项目管理解决方案提供了与这类管理动作相对应的承载方式：项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，任务可设置前后置依赖，里程碑用于标记重要时间点、事件或决策点；项目计划与里程碑可以设置基线，通过版本对比追溯变更细节；项目下可管理需求范围、研发任务，项目经理能在项目计划中关联迭代和研发任务。
把这些能力对应到范围确认的流程，可以形成一条连贯的路径：范围说明书与需求在项目中维护，需求范围与研发任务关联，形成可对照的需求基线；WBS工作项承载工作包与可交付成果，成果证据随工作项留存；确认会前用基线对比检查计划与执行偏差，识别哪些工作包状态与依据不一致；确认结论与差异清单作为项目记录归档，差异项按变更流程跟踪处理。这样，依据的版本、工作项的状态和确认的结论处在同一套记录体系中，事后追溯时能沿着需求、工作项、确认结论的线索还原当时的判断依据。
工具承载的是依据归集与记录留痕，确认的判定和签署仍由授权干系人完成。具体模块的可用性以实际使用的版本与套餐为准，部署方式需结合组织的信息管理要求确定。
常见问题
范围确认会上客户口头表示认可，但没有签署书面结论，这次确认算完成吗？
按范围确认的完成标准，口头认可只能算会议过程中的意见表达，不能作为确认完成的依据。确认完成的标志是授权干系人对验收标准逐条判定并签署书面结论，结论书要写明确认对象、所依据的版本、通过与否的结论、例外事项和后续安排。
如果客户当场不便签署，可以在会议纪要中记录逐条判定结果，注明待签署，并在约定期限内完成签署。在此之前，相关条目按“待确认”状态管理，不纳入已通过范围。
确认过程中发现合同交付物清单与范围说明书不一致，应该先改哪一份？
两份文件不一致时，先判断哪一份是当前有效的批准基线，再决定处理路径。合同条款通常具有更高的约束力，范围说明书与合同冲突时，应以合同约定为准，并通过变更流程调整范围说明书；如果差异源于合同签订后的范围调整，则需查变更批准记录，确认调整是否已经生效。
无论哪种情况，都应先把差异登记为差异项，写明编号、责任人和处理时限，再继续确认其余无争议的条目。直接在现场修改其中一份文件，会让后续验收失去可对照的依据。
WBS工作包与需求清单的颗粒度不同，逐项对照时怎么处理？
WBS工作包和需求清单本来就是两种颗粒度：工作包按交付物或工作阶段划分，需求按功能或业务规则划分，两者不必一一对应。对照时可以采用双向检查：每个工作包的交付物能否追溯到至少一条需求，每条需求能否落到至少一个工作包。
出现工作包没有对应需求，或需求没有对应工作包的情况，就是需要核实的缺口。前者可能是范围外内容，后者可能是分解遗漏，都应记录后按流程处理，而不是在对照表里强行匹配。
阶段确认和项目收尾确认，依据准备上有什么不同？
阶段确认的对象是阶段交付物，依据以阶段范围说明、阶段WBS、阶段验收标准和本阶段的成果证据为主，变更记录只需覆盖本阶段内的调整。项目收尾确认的对象是合同约定的整体交付范围，依据需要覆盖全周期的范围基线、全部变更批准记录、最终验收标准和完整成果证据。
跨期项目在每个阶段确认时都重复一遍受控版本核对和差异项检查，可以让范围基线在长周期内保持可追溯，收尾时不必重新梳理历史版本。
范围确认的依据和记录分散在多个工具里，怎么保证版本对齐？
核心做法是给每份依据建立受控版本标识，并在确认前用一份依据清单逐行核对版本号或批准日期。清单本身作为会议材料留存，记录本次确认依据的到底是哪一版文件。
在ONES中，项目计划与里程碑可以设置基线，通过版本对比追溯变更细节；需求范围与研发任务在项目下关联，项目经理可在项目计划中关联迭代和研发任务。把范围说明书、工作项状态和确认结论放在同一套记录体系中，事后追溯时可以沿需求、工作项、确认结论的线索还原当时的判断依据。具体模块的可用性以实际使用的版本与套餐为准。
