识别可交付成果时，最容易出现的偏差是把任务、阶段名称直接当成成果写进范围说明书，导致后续验收缺少可判定的对象。可行的做法是先按“成果—验收—边界”三要素筛选，把有形成果、可移交、可验收的条目从活动清单中分离出来，再逐条定义验收标准，写入范围说明书的成果清单与边界条款，最后分解到WBS工作包并取得干系人书面确认。下文按识别、定义、写入、分解、确认、检查的顺序展开，并给出可直接填写的表格与示例。
要点总览（TL;DR）
- 识别可交付成果时，用“有形成果、可移交、可验收”三个要素筛选，把“完成接口联调”“需求评审通过”这类动作和里程碑翻译成具体产出物。
- 定义颗粒度以“是否需要独立验收”为拆分依据，验收标准写成可观察结果加判定条件，例如用例通过率与缺陷级别要求。
- 范围说明书中设置成果清单、验收标准、范围边界与排除项、假设条件与制约因素、待定事项登记，成果条目与验收标准一一对应。
- WBS以成果为上层节点分解到工作包，用成果—WBS对照表双向核对，确保每条成果有节点支撑、每个工作包有成果归属。
- 成果候选清单和范围说明书分别评审一次，干系人签字版本、评审意见、待定事项关闭记录和变更记录作为确认证据留存。
先分清可交付成果与活动：识别前的判断口径
可交付成果是项目需要产出的、能够移交并被验收的有形成果。判断一个条目是否属于可交付成果，可以看三个要素：它是否是一个看得见、拿得到的产出物；它是否可以移交给接收方；它是否有明确的验收条件。三个要素同时成立，才适合写入范围说明书的成果清单。
活动描述的是“做什么动作”，例如“完成接口联调”“组织三轮用户培训”；里程碑标记的是时间点或决策点，例如“需求评审通过”“系统上线”；阶段名称描述的是项目的一段区间，例如“设计阶段”。这些内容可以出现在进度计划里，但它们本身不是可交付成果。接口联调对应的成果可能是“联调通过的接口清单及测试报告”，用户培训对应的成果可能是“培训课件与签到记录”。识别时把动作翻译成产出物，是排除误判的基本方法。
识别可交付成果的输入主要有四类：项目章程提供项目目标与高层级成果；合同或需求文件提供客户明确要求的交付内容；历史项目资料提供同类项目常见的成果清单与验收口径；干系人诉求补充合同和需求文件未写明的期望。四类输入交叉比对，可以减少遗漏，也能发现彼此矛盾之处。
常见误判有几种：把“完成某功能开发”当作成果，实际成果应是可运行的功能及对应文档；把“通过验收评审”当作成果，实际成果是评审所针对的交付物；把阶段名称直接列为成果，导致无法验收；把内部管理动作（如“召开周会”）写进成果清单。排除方法是逐条追问：这个条目交付给谁、对方凭什么判断合格、不合格时退回的是什么。三个问题答不上来，就先放入待定区，不写入正式清单。
| 成果候选 | 判断依据 | 是否保留 |
|---|---|---|
| 完成用户登录模块开发 | 描述的是动作，缺少可移交产出物 | 不保留，改写为“登录模块及接口说明文档” |
| 登录模块及接口说明文档 | 有形成果、可移交、可按功能清单验收 | 保留 |
| 需求评审通过 | 是决策点，属于里程碑 | 不保留为成果，作为里程碑管理 |
| 需求规格说明书（评审版） | 有形成果、可移交、可按评审意见闭环验收 | 保留 |
| 设计阶段 | 是阶段名称，无具体产出物 | 不保留，拆出该阶段的具体成果 |
| 数据迁移方案与迁移结果核对表 | 有形成果、可移交、可按核对规则验收 | 保留 |
识别可交付成果的四步操作
识别工作可以按四个步骤推进，每一步都有明确的输入和输出，完成后进入下一步，避免边找边写造成清单混乱。
第一步：从需求与合同条款抽取成果线索。输入是合同、需求文件、项目章程。动作是逐条阅读条款，把出现“提供”“提交”“交付”“完成并移交”等表述的句子摘出来，形成原始线索列表。输出是一份未经筛选的线索清单，每条注明出处条款编号。这一步只做抽取，不做判断，保证不遗漏。
第二步：按成果类型归类。把线索分为产品类、文档类、服务或移交类。产品类指软件功能、硬件设备、可运行系统等；文档类指方案、报告、手册、图纸等；服务或移交类指培训、运维交接、数据迁移、现场部署等。归类的作用是让后续定义验收标准时有统一的参照，不同类型成果的验收方式差别较大。
第三步：逐条核对可验收、可归属、可移交。对每条线索追问：验收标准能否写出来；是否有明确的责任人；接收方是否清楚。三项都满足的进入候选清单；有一项不满足的标注原因，放入待定区，在干系人确认环节解决。
第四步：形成成果候选清单并标注来源与责任人。候选清单至少包含编号、成果名称、类型、来源（合同条款或需求编号）、初步责任人、备注。来源字段用于后续追溯，责任人字段用于定义阶段的对接。清单形成后提交评审，作为定义表的输入。
| 编号 | 成果名称 | 类型 | 来源 | 初步责任人 | 备注 |
|---|---|---|---|---|---|
| D-01 | 需求规格说明书（评审版） | 文档类 | 合同附件一第2条 | 业务分析负责人 | 需明确评审通过口径 |
| D-02 | 订单管理模块 | 产品类 | 需求文件 REQ-12 至 REQ-20 | 开发负责人 | 验收标准待细化 |
| D-03 | 数据迁移结果核对表 | 服务或移交类 | 合同附件二第5条 | 数据负责人 | 核对规则需与客户确认 |
| D-04 | 管理员操作手册 | 文档类 | 需求文件 REQ-31 | 文档负责人 | 语言版本待定 |
把成果定义到可验收的颗粒度
候选清单只是名称，写入范围说明书前需要把每条成果定义到可验收的颗粒度。建议使用固定字段：名称、内容描述、验收标准、验收方式、责任方、交付时点。字段固定后，不同人填写的条目可以横向比较，评审时也容易发现缺项。
颗粒度控制有两个方向。成果过大时拆分，判断依据是验收时是否需要多个独立判断：如果一个成果包含功能、文档、培训三类内容，且分别由不同角色验收，就应拆成多条。成果过小时合并，判断依据是单独验收是否产生实际管理成本：如果两个条目总是同时提交、同时验收、接收方相同，可以合并为一条，避免清单冗长。
验收标准要写成可观察的结果和判定条件。可观察结果描述交付物应达到的状态，判定条件说明用什么方法、依据什么规则判断合格。例如“订单管理模块支持单笔订单创建、修改、取消，功能测试用例通过率100%，遗留缺陷中无严重及以上级别问题”，比“订单模块功能完善”更可判定。验收方式写明是演示、文档评审、抽样核对还是测试报告审查，并注明由谁执行。
识别和定义阶段常遇到信息不足的情况，例如客户尚未确定手册语言版本、核对规则尚未确认。这类事项应标注为“待定”，写明待定内容、影响范围和计划确认时点，不写成确定承诺。待定事项集中登记，在范围说明书评审时逐项确认，确认后更新定义表。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 名称 | 简洁、唯一、可检索 | 订单管理模块 |
| 内容描述 | 说明成果包含的范围与主要构成 | 含订单创建、修改、取消、查询四个功能及接口说明 |
| 验收标准 | 可观察结果加判定条件 | 功能测试用例通过率100%，无严重及以上缺陷 |
| 验收方式 | 演示、评审、测试报告审查或抽样核对 | 测试报告审查加现场演示 |
| 责任方 | 对成果完成负责的角色 | 开发负责人 |
| 交付时点 | 相对里程碑或具体日期 | 系统测试开始前 |
写入范围说明书：成果清单与边界条款
范围说明书中与可交付成果直接相关的部分包括：成果清单、验收标准、范围边界与排除项。成果清单按定义表的条目逐条列出，编号与定义表一致；验收标准可以紧随每条成果之后，也可以集中成节，但必须与成果条目一一对应，避免出现有成果无标准或有标准无成果的情况。
范围边界与排除项用于说明哪些内容不在本次交付范围内。表达方式应具体，指向容易产生歧义的对象。例如“本次交付不包含与第三方物流系统的接口开发，该接口由客户方另行采购实施”，比“不含外部系统对接”更清楚。排除项的作用是减少执行阶段的争议，也为后续变更提供判断依据：落在排除项内的需求，需要通过变更流程处理。
假设条件与制约因素应与成果条目相邻说明。假设条件是制定范围时假定成立的前提，例如“客户方在开发开始前提供完整的历史数据样本”；制约因素是必须遵守的限制，例如“系统须部署在客户指定的内网环境”。这些内容影响成果能否按定义交付，写在成果章节附近，便于评审时一并确认。
成稿结构可以按以下顺序组织：项目目标简述、可交付成果清单（含编号、名称、描述、验收标准、责任方、交付时点）、范围边界与排除项、假设条件与制约因素、待定事项登记。评审时按此顺序逐节确认，确认结果形成记录。
从成果清单分解到WBS工作包
WBS分解以成果为上层节点，把每条可交付成果作为分解的起点，向下逐层拆分到工作包。工作包是能够估算工期和成本、可以分配给具体责任人的最小单元。分解时保持成果条目与WBS节点的对应关系，每个工作包都能追溯到某条成果，每条成果至少对应一个工作包。
追溯方式可以在WBS节点上标注成果编号，形成成果—WBS对照表。对照表包含成果编号、成果名称、对应WBS节点、工作包负责人、完成标志。这样在进度检查和验收时，可以从成果反查工作包，也可以从工作包确认它服务于哪条成果，避免出现无成果归属的工作包。
分解停止的判断标准有三条：工作包可以估算工期和资源；工作包有明确的完成标志；工作包可以分配给单一责任人。三条满足即可停止分解，继续拆分只会增加管理成本。对于复杂度高的工作包，可以保留在较低层级，通过完成标志控制，不必无限细分。
分解完成后做双向核对：从范围说明书逐条成果检查是否都有WBS节点支撑；从WBS逐个工作包检查是否都能归属到某条成果。核对中发现的无归属工作包，要么补充成果条目，要么从范围中移除；发现的无支撑成果，要么补充工作包，要么调整成果定义。核对结果记录在对照表中。
| 成果编号 | 成果名称 | 对应WBS节点 | 工作包负责人 | 完成标志 |
|---|---|---|---|---|
| D-01 | 需求规格说明书（评审版） | 1.1 需求分析与文档编写 | 业务分析负责人 | 评审意见闭环并签署确认 |
| D-02 | 订单管理模块 | 2.1 订单功能开发、2.2 接口开发 | 开发负责人 | 测试报告通过审查 |
| D-03 | 数据迁移结果核对表 | 3.2 数据迁移与核对 | 数据负责人 | 核对规则全部通过 |
| D-04 | 管理员操作手册 | 4.1 手册编写与评审 | 文档负责人 | 客户方签收 |
在ONES中，可以使用项目计划按交付物维度创建工作分解结构，并为任务设置前后置依赖，用里程碑标记关键时间点；设置计划和里程碑基线后，可以对比计划与执行的偏差，并通过版本对比追溯变更细节。这些能力承接的是成果清单落地为可执行计划的管理动作，具体功能入口以实际产品版本为准。
角色分工与确认：谁识别、谁定义、谁签字
识别与定义不是项目经理单独完成的工作。项目经理负责组织识别过程、维护成果清单与定义表、协调评审；需求或业务负责人负责从合同和需求文件中抽取成果线索，确认业务口径；技术负责人负责判断成果的技术可行性和验收方式；干系人代表负责确认成果是否满足其期望，并在范围说明书上签字。
评审与确认的时点建议设在两个位置：成果候选清单形成后评审一次，确认清单完整性和分类；范围说明书成稿后评审一次，确认成果定义、验收标准和边界条款。评审形式可以是会议评审加书面确认，也可以是文档流转加电子签批，关键是留下可追溯的记录。
确认记录应保留的证据包括：评审会议纪要或评审意见表、范围说明书签字版本、待定事项登记表及其关闭记录、成果定义变更记录。证据的作用是在执行阶段出现争议时，能够说明当时的确认口径。变更处理入口应明确：成果定义发生变化时，通过变更申请提交，经原确认角色审批后更新范围说明书和WBS，并保留变更前后版本。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 组织识别、维护清单、协调评审、跟踪待定事项 | 成果候选清单、定义表、评审记录 |
| 需求或业务负责人 | 抽取需求与合同线索、确认业务口径 | 线索清单、业务确认意见 |
| 技术负责人 | 判断技术可行性、确定验收方式 | 技术评审意见、验收方式建议 |
| 干系人代表 | 确认成果满足期望、签署范围说明书 | 签字确认记录 |
当成果清单、范围说明书和WBS需要在多人之间流转确认时，可以在ONES的项目下管理需求范围与研发任务，把成果条目与对应工作项关联，确认记录随文档版本留存。ONES支持项目制管理，针对需求明确、交付周期固定的场景严控里程碑和交付物；深圳农商银行使用ONES瀑布项目模板对关键里程碑和交付物进行规范化管理，该案例仅说明其使用场景，不代表所有团队的效果。
示例：一个交付成果从线索到范围说明书的完整落地
以下为演示情景，非真实项目数据。某企业需要为客户实施一套内部订单系统，合同约定交付订单管理功能、需求文档、数据迁移和管理员手册。
线索来源：合同附件一第2条写明“提供订单管理功能并完成上线”，需求文件 REQ-12 至 REQ-20 描述订单创建、修改、取消、查询的具体要求。抽取后形成线索“订单管理功能”，归入产品类。
候选清单阶段，该线索被拆为“订单管理模块”一条，标注来源为 REQ-12 至 REQ-20，初步责任人为开发负责人。核对时发现验收标准尚未细化，标注为待定，进入定义阶段。
定义表填写：名称为订单管理模块；内容描述为含订单创建、修改、取消、查询四个功能及接口说明；验收标准为功能测试用例通过率100%，无严重及以上级别缺陷；验收方式为测试报告审查加现场演示；责任方为开发负责人；交付时点为系统测试开始前。
写入范围说明书的成稿条目为：“D-02 订单管理模块：交付订单创建、修改、取消、查询四个功能及接口说明文档。验收标准：功能测试用例通过率100%，遗留缺陷中无严重及以上级别问题。验收方式：测试报告审查并由客户方现场演示确认。责任方：开发负责人。交付时点：系统测试开始前。”同时在排除项中写明“不包含与第三方物流系统的接口开发”。
WBS对照：该成果对应节点2.1订单功能开发和2.2接口开发，工作包负责人为开发负责人，完成标志为测试报告通过审查。双向核对时确认两个工作包均归属D-02，D-02也有对应节点支撑，核对通过。
完成检查：范围说明书与WBS的验收清单
成果识别与写入完成后，按以下清单逐项核对。每项都能给出肯定回答，才进入基线确认。
- 成果条目完整性：范围说明书中的每条成果都有编号、名称、内容描述、责任方和交付时点；候选清单中的待定事项已逐项登记并有确认计划；活动、里程碑、阶段名称未被误列为成果。
- 验收标准可判定性：每条成果都有验收标准和验收方式；验收标准包含可观察结果和判定条件；验收方式注明了执行角色；不存在“符合要求”“满足需要”这类无法判定的表述。
- 范围说明书与WBS一致性：每条成果至少对应一个WBS节点；每个工作包都能归属到某条成果；对照表中的完成标志与验收标准口径一致；双向核对结果已记录。
- 确认记录与待定事项：范围说明书有干系人签字版本；评审意见已闭环；待定事项登记表记录了待定内容、影响范围和确认时点；变更处理入口已告知相关角色。
清单核对完成后，范围说明书与WBS作为基线保存。后续如需调整成果定义，通过变更入口提交并保留版本记录，基线对比可用于检查计划与执行的偏差。
常见问题
客户在项目启动阶段无法确认部分验收标准，范围说明书还能先定稿吗？
可以先形成评审版，但要把未确认内容登记为待定事项，写明待定内容、影响范围和计划确认时点，不写成确定承诺。范围说明书评审时逐项确认待定事项，确认后更新定义表与范围说明书，并保留更新前后的版本。待定事项若涉及关键成果的验收口径，建议在对应成果条目旁标注，避免执行阶段被误读为已确认。
一个可交付成果跨多个部门交付时，责任方怎么写？
按“单一责任方加协作方”的方式填写：责任方填写对成果整体完成负责的角色，协作方在内容描述或备注中列明各自承担的部分。验收时由责任方汇总提交，验收方式可以按协作部分分别执行，但验收结论统一记录在该成果条目下。若协作部分本身需要独立验收，说明该成果颗粒度过大，应拆成多条分别定义。
WBS分解后发现某个工作包无法归属到任何成果，应该怎么处理？
先判断该工作包是否属于项目范围内必须完成的管理或支撑工作。属于的，补充一条对应的成果条目，例如把“环境搭建”定义为可移交的环境配置说明与访问凭证；不属于的，从WBS中移除，避免范围蔓延。双向核对结果记录在成果—WBS对照表中，作为基线确认前的检查依据。
成果定义在项目执行中需要调整，走什么入口？
通过变更申请提交，说明调整内容、影响的范围说明书条目和WBS节点，经原确认角色审批后更新文档与计划，并保留变更前后版本。范围说明书与WBS的基线对比可用于检查调整带来的计划偏差。变更审批的具体流程属于项目变更管理范畴，本文不展开。
范围说明书中的排除项写到什么程度才够用？
排除项应指向容易产生歧义的具体对象，说明不包含什么、由谁另行承担。例如写明“不包含与第三方物流系统的接口开发，该接口由客户方另行采购实施”，比笼统写“不含外部系统对接”更能减少执行争议。排除项也是后续变更的判断依据：落在排除项内的需求，通过变更流程处理。
