研发交付物是研发过程中形成的、需要交付给下游角色或留存归档的成果资产，包括需求与设计文档、代码与构建产物、测试证据、发布包与说明材料等。判断一个物件是否属于交付物，关键看它是否有明确的接收方或归档用途、是否具备版本或状态、能否被验收或引用。本文围绕定义、组成范围、边界、流转机制与相邻概念展开，帮助团队统一口径；配置基线的建立维护与制品仓库的底层实现不在本文展开。
要点总览（TL;DR）
- 研发交付物是研发过程中形成的、需要交付给下游角色或留存归档的成果资产，判断标准是有明确接收方或归档用途、有版本或状态、可被验收或引用。
- 交付物可按研发阶段与资产形态交叉分类，覆盖文档、代码与构建产物、验证证据、发布说明四类形态，同一交付物在不同阶段可能重复出现。
- 日常沟通记录与临时草稿、配置基线与配置项管理、制品仓库的存储分发机制属于不同层面的对象，不宜直接等同于交付物。
- 交付物从产生登记、评审确认、版本状态变化到下游交接验收形成完整流转，验收结论才是本环节完成的标志。
- 常见误解包括把交付物等同于文档、认为交付物越多越规范、把提交当作完成，纠正方向是按需确定必备项并保留交接记录。
研发交付物指什么：一句话定义与判断标准
研发交付物是研发活动中产生的、以交付或归档为目的的成果资产。它既包括给下游角色使用的中间成果，也包括随版本发布对外提供的最终成果。这个定义有两个限定：一是成果必须可识别，能被单独命名、定位和引用；二是成果必须有去向，要么交给某个角色继续使用，要么进入归档供后续查阅和审计。
实际工作中可以用三条标准判断一个物件是否属于研发交付物：
- 有明确接收方或归档用途。接收方可以是测试团队、运维团队、客户或合规审计人员；归档用途指按流程留存以备追溯。两者都没有的物件，通常只是过程材料。
- 有版本或状态。交付物会随研发推进发生变化，需要能区分草稿、评审中、已确认、已发布等状态，并能回溯到某一具体版本。
- 可被验收或引用。下游角色能对它做出接受或退回的判断，或者其他工作项能引用它作为依据，例如测试报告引用需求规格、发布说明引用缺陷清单。
过程记录与交付物的区别在于目的和约束。日常沟通记录、会议纪要、临时排查笔记服务于当下协作，通常不设接收方，也不要求版本管理；交付物则因为要交接和追溯，必须明确责任人和状态。需要说明的是，过程记录在特定场景下可以转化为交付物，例如把评审会议结论整理成评审记录并纳入归档，此时它具备了接收方和版本，性质随之改变。
研发交付物包括哪些：按阶段与形态分类
交付物的范围可以从两个角度理解：按研发阶段看它在哪个环节产生，按资产形态看它以什么形式存在。两个角度交叉，能覆盖大多数实际场景，也便于团队建立自己的交付物清单。
| 研发阶段 | 文档类 | 代码与构建类 | 验证证据类 | 发布说明类 |
|---|---|---|---|---|
| 需求 | 需求规格、需求评审记录、验收标准 | — | 需求确认记录 | — |
| 设计 | 架构设计、接口设计、数据模型说明 | 原型代码、接口定义文件 | 设计评审结论 | — |
| 开发 | 开发说明、变更记录 | 源代码、构建脚本、构建产物 | 代码评审记录、单元测试结果 | — |
| 测试 | 测试方案、测试用例 | 自动化测试脚本 | 测试报告、缺陷清单、覆盖率数据 | — |
| 发布 | 部署手册、运维说明 | 发布包、镜像、配置文件 | 上线验证记录、回滚预案 | 版本发布说明、变更公告 |
形态区分有助于确定管理方式。文档类交付物重在内容评审与版本留痕；代码与构建类重在可复现，即能从某一版本源码重新构建出对应产物；验证证据类重在可追溯，能对应到具体需求或缺陷；发布说明类重在准确描述本次交付的范围与已知问题。
同一交付物在不同阶段可能重复出现，这是正常现象。需求规格在需求阶段是待评审的草稿，在设计阶段成为设计依据，在测试阶段成为验收参照，在发布后进入归档。它在每个阶段承担不同角色，但仍是同一份交付物，管理上应保持同一标识并记录状态变化，避免各阶段各自维护副本导致口径不一致。
边界在哪里：哪些内容不算研发交付物
明确排除项和明确包含项同样重要。以下三类内容容易被误当作交付物，实际属于不同层面的对象。
日常沟通记录与临时草稿一般不作为交付物。即时消息、口头讨论、随手画的草图服务于过程协作，缺少接收方和版本约束。它们可以支撑交付物的形成，但本身不进入交付清单。若团队确实需要留存某次讨论的结论，应将其整理为有明确标题、责任人和状态的正式记录，再纳入交付物管理。
配置项与基线属于配置管理范畴，交付物是其中被管理的对象之一。配置管理解决的是“哪些东西需要受控、在什么时点冻结成基线、变更如何审批”的问题。交付物是受控对象的一种，但配置项的范围通常更广，还可能包括工具配置、环境参数等不对外交付的内容。基线则是对某一时点配置状态的快照，它管理的是交付物的集合状态，本身不是交付物。
制品仓库的存储与分发机制属于工程实现，不等同于交付物本身。制品仓库负责存放构建产物、管理版本、提供下载和分发能力，是承载交付物的基础设施。发布包作为交付物需要被登记、评审和交接，而仓库如何分片存储、如何做缓存加速，属于平台实现细节，不进入交付物概念。
交付物如何形成与流转：从产生到验收的机制
交付物需要状态管理，是因为它在流转中会被多方使用，任何一次变更都可能影响下游判断。完整的流转可以概括为四步。
- 产生与登记。由阶段责任人产出交付物并登记基本信息，包括名称、类型、所属需求或版本、责任人。登记的目的是让交付物可被检索和引用，避免散落在个人目录中。
- 评审与确认。按交付物类型设置评审方式，文档走内容评审，代码走代码评审，测试证据核对执行结果。评审通过后状态转为已确认，未通过则退回修改。评审记录本身也应留存，作为确认动作的证据。
- 版本与状态变化。交付物在确认后仍可能因需求变更而修改，每次修改产生新版本，旧版本保留可查。状态随版本推进变化，例如从已确认变为已变更，再经重新评审回到已确认。版本与状态的组合，构成了交付物的历史轨迹。
- 向下游交接与验收。交付物移交下游角色时，接收方依据验收标准做出接受或退回的判断。验收通过意味着该交付物在本环节完成使命，进入下一环节使用或归档；退回则触发修改流程。交接动作应留下记录，明确交接时间、接收人和结论。
这四步在工具中落地时，需要把交付物与需求、版本、测试和发布关联起来。ONES 的 ALM 研发管理方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程可以关联到需求链路中，便于在出现问题时定位影响范围。方案层面也提到将评审节点、交付物模板和过程数据沉淀为可复用资产，具体配置方式需结合团队实际流程确定。
容易混淆的相邻概念：交付物、配置项、制品、里程碑成果
四个概念在实际沟通中经常混用，用同一口径对照可以减少歧义。
| 概念 | 核心含义 | 与研发交付物的关系 | 典型例子 |
|---|---|---|---|
| 研发交付物 | 需要交付或归档的成果资产 | 本体 | 需求规格、测试报告、发布包 |
| 配置项 | 纳入配置管理、需要受控的对象 | 交付物通常是配置项的子集，配置项还可能包含环境配置等非交付内容 | 受控的接口文档、环境参数文件 |
| 制品 | 构建过程产出的可部署文件 | 制品是交付物中代码与构建类的一部分，交付物范围更广 | 镜像、安装包、库文件 |
| 里程碑成果 | 某一时点需要达成的阶段性结果 | 里程碑成果往往由一组交付物共同证明，二者是目标与证据的关系 | 某版本通过验收所依赖的全部交付物 |
理解这组关系的关键是分清层次：配置项回答“管什么”，交付物回答“交什么”，制品回答“部署什么”，里程碑成果回答“阶段达成了什么”。同一个物件可能同时具备多重身份，例如一个发布包既是制品，也是交付物，还可能作为配置项受控，并在里程碑评审中作为成果证据。身份叠加不矛盾，但登记和管理时应明确当前语境下关注的是哪一层。
一个具体例子与三个常见误解
以一个版本发布场景为例，假设某团队要发布 2.3 版本，交付物清单可以这样组织：需求侧包括本版本需求规格与验收标准；设计侧包括新增接口的设计说明；开发侧包括对应源码版本标签与构建产物；测试侧包括测试报告、遗留缺陷清单及处理结论；发布侧包括发布包、部署手册和版本发布说明。每项交付物登记责任人、状态和关联需求，评审通过后随版本一并交接给运维和客户支持团队，验收记录留存归档。这份清单是演示情景，实际项目应按自身流程裁剪。
围绕这个例子，有三个误解值得纠正。
误解一：交付物等于文档。文档只是交付物的一种形态。代码版本、构建产物、测试证据、发布包同样是交付物，而且在很多项目中占据更关键的位置。只管理文档而忽略构建产物与验证证据，会导致交付结果无法复现、质量问题难以定位。
误解二：交付物越多越规范。交付物的价值在于被使用和被追溯，数量本身不构成规范。清单过长会稀释评审注意力，产生大量无人查阅的归档材料。合理做法是按项目类型和合规要求确定必备项，其余按需增减，并定期清理长期无人引用的条目。
误解三：交付物提交即完成。提交只是流转的起点。交付物需要经过评审确认、版本记录和下游验收，才算完成本环节使命。把提交当作完成，容易出现状态长期停留在待评审、下游拿到未确认版本、变更后旧版本仍在使用等问题。团队应把验收结论作为交付物的完成标志，并保留交接记录。
常见问题
研发交付物和配置项在实际管理中应该怎么分工？
两者关注的问题不同。配置项回答“哪些东西需要受控”，范围通常更广，可能包括环境参数、工具配置等不对外交付的内容；交付物回答“交什么”，是配置项中需要交接或归档的那部分成果。实际分工上，可以先由配置管理确定受控范围和基线时点，再在受控对象中标注哪些属于交付物、交付给谁、以什么状态交接。同一个物件同时是配置项和交付物是常见情况，登记时分别记录两层身份即可，不必强行二选一。
小团队也需要建立完整的交付物清单吗？
不一定按大团队的完整清单执行。交付物清单的价值在于让交接和追溯有据可查，小团队可以只保留与当前交付对象直接相关的必备项，例如需求说明、代码版本、测试结论和发布说明。判断是否保留某项，可以看它是否有明确接收方、是否会在后续被引用。随着项目合规要求或协作规模变化，再逐步补充，避免一开始就建立大量无人查阅的归档条目。
交付物提交后下游一直不验收，状态该怎么处理？
这种情况通常说明交接环节缺少明确的责任人和时限。可以在交付物流转规则中约定：提交时指定接收人，并给出验收的预期时间；超时未处理时状态标记为待跟进，由提交方或项目负责人推动确认。同时保留提交记录和催办记录，避免后续出现“已交付但无人确认”的口径争议。验收结论无论是接受还是退回，都应写入交付物状态，作为本环节结束的依据。
需求变更后，已经交付的文档和构建产物要怎么处理？
变更发生后，受影响的交付物需要重新走确认流程，而不是直接覆盖原版本。建议保留旧版本可查，新版本关联到变更记录，并标注哪些下游角色需要重新接收。构建产物尤其要注意可复现性，变更后的源码版本与产物版本应能对应上。若变更影响范围较大，可以借助需求与测试、发布之间的关联关系梳理受影响的任务和交付内容，再决定哪些交付物需要重新评审和交接。
发布包既是制品又是交付物，登记时会不会重复？
身份叠加不等于重复登记。制品身份关注它在构建与部署链路中的位置，交付物身份关注它交给谁、以什么状态交接、是否通过验收。可以在同一份记录上同时标注两类信息，避免维护两套互相对不上的清单。关键是明确当前管理动作针对哪一层：做版本追溯时看制品与源码的对应关系，做交接验收时看交付物的接收方和结论。
