可交付成果的确认与落实是一条连续链条：先把成果物识别出来并写成可验收的描述，经评审签字取得认可，再写入范围说明书形成基线，最后按成果导向分解到WBS工作包。本文按这四步展开，并给出角色分工、完整示例和收尾检查清单，帮助你把成果清单、确认记录、范围说明书与WBS字典串成可追溯的一套材料。
要点总览（TL;DR）
- 先按成果物而非工作阶段识别可交付成果，用名称、验收标准、责任人、交付时点、依赖五个字段写成清单初稿。
- 确认环节由发起人、客户代表、技术负责人与质量负责人参与，评审会逐条核对验收标准，会后书面签认并记录待定项。
- 确认后的成果写入范围说明书，承载成果描述、验收标准、排除项、假设与约束，基线化后作为变更比对基准。
- WBS以成果为分支起点逐层分解到工作包，用编码建立工作包与成果的双向追溯，并以100%原则检查覆盖度。
- 收尾时按清单完整性、标准可测量、确认记录、说明书一致性、WBS覆盖与追溯逐项检查，出现阻断项按性质返工。
先分清可交付成果、里程碑与工作包
范围管理中最常见的返工，来自三类对象被混着写。可交付成果是必须经过验收的成果物，里程碑是时间轴上的节点，工作包是WBS末级可估算、可分配的任务单元。三者在文档中的位置不同，判断标准也不同。
| 对象类型 | 判断标准 | 示例 | 写入位置 |
|---|---|---|---|
| 可交付成果 | 有实体或可检查的产出，需要验收人认可 | 用户登录模块、接口设计说明书、验收测试报告 | 可交付成果清单、范围说明书 |
| 里程碑 | 标记重要时间点、事件或决策点，本身不产出成果物 | 需求评审通过日、系统上线日 | 进度计划、里程碑清单 |
| 工作包 | WBS末级任务，可估算工期、可分配给具体责任人 | 编写登录接口代码、执行登录场景测试 | WBS与WBS字典 |
典型混淆是把动作写成成果，例如把“完成测试”列为可交付成果。测试是工作，成果应是“测试报告”或“缺陷修复记录”。判断方法很简单：问一句“验收时客户或发起人要看到、要签字的是什么”，答案指向成果物；如果答案是某个日期或某段工作过程，它属于里程碑或工作包。
第一步：识别并定义可交付成果
识别阶段的输入包括合同、需求文档、项目章程和干系人期望。做法是按成果物罗列，而不是按工作阶段罗列：先通读输入材料，把每一处“需要交付、需要确认、需要移交”的内容摘出来，再区分内部成果（团队内部交接，如设计文档）与外部成果（客户或发起人验收，如上线系统）。
每项成果用五个字段定义清楚，形成清单初稿：
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 名称 | 名词性表述，指向具体成果物 | 订单查询模块 |
| 验收标准 | 可测量、可逐条核对，避免“满足要求”这类表述 | 支持按订单号与时间段查询，响应时间不超过2秒，通过20条验收用例 |
| 责任人 | 对该成果完成与交付负责的单一角色 | 后端开发负责人 |
| 交付时点 | 计划完成或移交的时间 | 第8周周五 |
| 依赖 | 前置成果、外部输入或审批 | 依赖数据库设计说明书确认 |
清单初稿完成后做一次完整性检查：合同与需求文档中的每一项承诺是否都有对应成果；每个成果是否都有验收标准；是否存在只有动作没有成果的条目。初稿是后续评审的输入，不必一次写完美，但字段不能缺。
第二步：评审确认并取得正式认可
确认的目的是让成果具备范围基线效力，因此需要有权认可的人到场。参与角色通常包括发起人、客户代表、技术负责人和质量负责人：发起人与客户代表确认成果满足业务预期，技术负责人确认可实现，质量负责人确认验收标准可检验。
确认方式建议评审会与书面签认结合。会上逐条核对验收标准，逐项给出结论；会后以书面形式签认，避免口头认可后续无法追溯。确认记录至少包含：成果名称、确认结论（通过、有条件通过、不通过）、保留意见、待定项、责任人与关闭时间。
未通过的成果按以下路径处理：属于描述不清的，回到定义环节补充验收标准后重新评审；属于需求本身有争议的，提交发起人或客户代表决策，决策结果记入确认记录；属于依赖未满足的，标注待定项并明确关闭条件，不带着未决问题进入基线。
第三步：写入范围说明书
确认后的成果要转化为范围说明书中的固定条目，形成后续变更的比对基准。范围说明书的可交付成果章节建议承载四类内容：成果描述、验收标准、排除项、假设与约束。成果清单与范围说明书是一对多关系：清单是工作底稿，范围说明书是基线文件，两者条目应一一对应，编号保持一致。
排除项是防止范围蔓延的关键。写法要具体到对象和边界，例如“本期不含移动端适配”“不含与第三方物流系统的对接”，而不是笼统写“不含额外需求”。假设与约束同样写实：假设某项外部接口按期提供，约束为预算或合规要求，一旦假设不成立就触发变更评估。
范围说明书定稿后做基线化，记录版本号、基线日期与审批人。后续任何成果增删都通过变更流程处理，并在版本记录中留痕，保证基线可回溯。
第四步：按成果导向分解到WBS
WBS分解以可交付成果为分支起点，逐层细化到可估算、可分配的工作包。第一层通常对应主要成果或项目阶段，第二层起按成果的组成部分拆分，直到每个末级工作包都能估算工期、指定责任人。ONES的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，并可为任务设置前后置依赖、用里程碑标记关键时间点，便于把成果层级与时间节点分开管理。
WBS字典为每个工作包记录：工作包编号、对应可交付成果编号、验收标准、责任人、工期估算。编码建议采用层级加成果编号的方式，例如1.2.3对应成果D-05，使工作包与成果形成双向追溯：每个工作包指向唯一成果，每个成果至少有一个工作包承接。分解深度可用8至80小时规则判断，即单个工作包工作量落在8到80小时之间；团队也可自定粒度，但同一项目内应统一口径。
分解完成后用100%原则检查：下层工作包之和是否完整覆盖上层成果，既无遗漏也无重复。发现某成果没有工作包承接，说明分解缺失；发现工作包无法回溯到任何成果，说明存在范围外工作，需要确认是否纳入范围。
在ONES中，项目计划可设置计划与里程碑基线，对比计划与执行的偏差并追溯版本变更；成果清单、确认记录与WBS字典可通过项目文档与工作项承载，使确认结论与分解结果在同一项目空间内关联。具体配置方式以实际产品版本为准。
角色分工与各环节交付物
四个环节涉及的角色不同，明确谁输入、谁动作、谁输出，可以避免确认会开完却无人落笔的情况。
| 角色 | 主要环节 | 输入 | 动作 | 输出 |
|---|---|---|---|---|
| 项目经理 | 全流程 | 合同、章程、需求文档 | 组织识别、召集评审、维护范围说明书与WBS、发起基线 | 成果清单、确认记录、基线版本 |
| 需求或业务分析人员 | 识别与定义 | 需求文档、干系人期望 | 提取成果物、编写验收标准 | 成果清单初稿 |
| 技术负责人 | 定义与确认 | 成果清单初稿 | 评估可实现性、确认技术类验收标准 | 技术意见、确认签字 |
| 质量负责人 | 确认与检查 | 验收标准 | 核对标准可检验性、参与确认评审 | 质量意见、检查结论 |
| 发起人与客户代表 | 确认 | 成果清单、评审材料 | 认可成果与验收标准、决策争议项 | 确认签字、决策记录 |
审批权限建议这样归属：成果清单由项目经理组织编写、技术负责人与质量负责人会签；范围说明书基线由发起人或其授权人批准；WBS及字典由项目经理批准后纳入计划基线。权限归属应在项目启动时写明，避免确认会上临时确定签字人。
示例：一次完整的确认与分解过程
以下为演示情景：某企业建设内部报销系统，合同约定本期交付报销申请、审批流转与报表导出三部分，工期十周。
识别阶段产出成果清单片段：D-01报销申请模块，验收标准为支持费用类型选择、附件上传，通过15条验收用例，责任人为后端负责人，第6周交付，依赖组织架构数据就绪；D-02审批流转模块，验收标准为支持三级审批与退回重提，通过12条验收用例，第8周交付，依赖D-01完成；D-03报表导出模块，验收标准为按部门与时间段导出，字段与财务模板一致，第9周交付，依赖D-02完成。
确认记录要点：评审会由发起人、财务客户代表、技术负责人与质量负责人参加，D-01、D-02通过；D-03有条件通过，保留意见为导出字段需与财务确认，待定项责任人为需求分析人员，两周内关闭。所有结论书面签认。
范围说明书条目示例：本期交付报销申请、审批流转、报表导出三项成果，验收标准引用清单编号；排除项写明“不含移动端报销、不含与银行系统直连”；假设为组织架构数据在第2周前提供。
WBS分解片段：1.1报销申请模块下设1.1.1表单开发、1.1.2附件上传、1.1.3验收测试三个工作包，均标注对应成果D-01；1.2审批流转模块对应D-02；1.3报表导出模块对应D-03，其中导出字段确认作为独立工作包，承接D-03的待定项关闭。检查时确认三项成果均有工作包承接，无工作包落在成果之外。
完成检查：确认与落实是否到位
收尾时逐项核对以下检查项，全部通过才可认为确认与落实工作完成。
| 检查项 | 通过标准 | 常见阻断项 |
|---|---|---|
| 成果清单完整性 | 合同与需求文档中的每项承诺均有对应成果，字段五列齐全 | 存在只有动作没有成果的条目 |
| 验收标准可测量 | 每条标准可逐条核对，含数量、性能或格式要求 | 标准写成“满足业务要求” |
| 确认记录齐全 | 有权认可人签字，结论、保留意见、待定项均有责任人与关闭时间 | 口头确认、待定项无关闭条件 |
| 范围说明书一致性 | 成果条目与清单编号一一对应，排除项与假设写实，已基线化并记录版本 | 清单已更新但说明书未同步 |
| WBS覆盖度 | 100%原则检查通过，无遗漏无重复 | 某成果无工作包承接 |
| 双向追溯 | 每个工作包指向唯一成果编号，每个成果至少一个工作包 | 存在无法回溯的范围外工作包 |
出现阻断项时按性质返工：清单或标准问题回到定义环节；确认签字缺失回到评审环节；说明书与清单不一致先同步文档再重新基线；WBS覆盖或追溯问题回到分解环节修正字典。返工完成后重新执行对应检查项，通过后方可进入执行阶段。
常见问题
可交付成果在评审会上没有全部通过，还能进入范围基线吗？
不建议带着未决问题整体进入基线。可以按结论分类处理：描述不清的成果回到定义环节补充验收标准后重新评审；需求本身有争议的提交发起人或客户代表决策，决策结果记入确认记录；依赖未满足的标注为待定项，写明责任人与关闭条件。已通过的成果可以先纳入基线，待定项在关闭后通过变更流程补充，这样基线始终反映已确认的范围。
WBS分解到什么程度算合适，团队粒度不一致怎么办？
常用判断是8至80小时规则，即单个工作包的工作量落在8到80小时之间，便于估算和分配。团队也可以自定粒度，但同一项目内应统一口径，并在WBS字典中写明。粒度不一致通常表现为同一层级里有的工作包只有几小时、有的跨越数周，这时把过大的工作包继续拆分，把过小的合并到相邻工作包，再重新核对100%原则。
范围说明书里的排除项怎么写才能真正防止范围蔓延？
排除项要具体到对象和边界，例如写明“本期不含移动端适配”“不含与第三方物流系统的对接”，让读者能直接判断某项需求是否在范围内。笼统写“不含额外需求”无法作为比对依据。排除项与假设、约束一起写实，假设不成立时触发变更评估，后续成果增删统一走变更流程并在版本记录中留痕。
成果清单更新后，WBS和范围说明书怎么保持同步？
关键是编号一致与变更留痕。成果清单、范围说明书条目和WBS字典共用同一套成果编号，任何一方新增或删除成果，都同步检查另外两处：范围说明书条目是否对应更新，WBS中是否有工作包承接或需要移除。同步完成后重新执行覆盖度与双向追溯检查，并更新基线版本记录，避免出现清单已改而说明书未动的情况。
用ONES承载成果清单、确认记录和WBS时，哪些环节可以放在同一项目空间？
ONES的项目计划支持按目标、交付物或项目阶段等维度创建工作分解结构，并可为任务设置前后置依赖、用里程碑标记关键时间点；项目计划还可设置计划与里程碑基线，对比计划与执行的偏差并追溯版本变更。成果清单、确认记录与WBS字典可通过项目文档与工作项承载，使确认结论与分解结果在同一项目空间内关联。具体配置方式以实际产品版本为准。
