研发交付物清单用于按阶段或交付节点登记可交付资产，让评审、交接和追溯时有统一依据。本文提供一张可直接复制到文档或表格工具中的空白清单，并说明交付物编号、名称、所属阶段、类型、版本、责任人、验收标准、存放位置和状态等字段的填写口径、必填与选填划分、一份完整填写示例，以及后续按团队情况调整和维护的方法。
要点总览（TL;DR）
- 空白模板按“基本信息—交付与验收—存放与状态”三组排列，复制后保留表头、逐行登记交付物即可使用。
- 交付物编号、名称、所属阶段、类型、版本、责任人、验收标准、存放位置、状态为必填；计划交付日期和备注按需填写。
- 类型回答“是什么”、阶段回答“什么时候交”，版本标识内容迭代、状态标识流程位置，两组字段分别填写。
- 示例覆盖需求、设计、开发、测试、发布五个阶段，每行都能回答谁负责、怎样算合格、去哪里取、现在到哪一步。
- 模板需按项目类型增删选填字段，并把状态更新绑定到评审和发布流程，避免用一次就失效。
可复制空白模板：研发交付物清单表
下表为空白模板，表头按“基本信息—交付与验收—存放与状态”三组排列。复制到 Excel、在线表格或文档表格后，第一行保留为表头，从第二行开始逐条登记交付物。建议先在表格工具中冻结首行，并为“所属阶段”“类型”“状态”三列设置下拉选项，减少手工输入造成的口径不一致。
| 分组 | 交付物编号 | 交付物名称 | 所属阶段 | 类型 | 版本 | 责任人 | 验收标准 | 存放位置 | 状态 | 计划交付日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 基本信息 | |||||||||||
| 交付与验收 | |||||||||||
| 存放与状态 |
复制后的建行方法：先按项目阶段列出需要交付的资产，每个资产占一行；同一资产有多个版本时，保留一行主记录，在“版本”列更新，历史版本写入备注或在版本管理工具中留存。分组列仅用于阅读时快速定位，实际填写时可以把三组字段合并为一张连续表头，避免分组列干扰筛选。若团队使用在线表格，建议把“交付物编号”设为文本格式，防止前导零被自动去掉。
字段说明：每个字段填什么、怎么判断
字段定义决定清单能否在评审和交接中被他人读懂。以下逐项说明各字段的含义与填写口径，模板、说明和示例使用同一套字段名称。
| 字段 | 填什么 | 填写口径 |
|---|---|---|
| 交付物编号 | 唯一标识，如“REQ-001”“TST-012” | 按“阶段缩写-序号”编制，全项目内不重复；编号一经使用不回收、不复用 |
| 交付物名称 | 资产的具体名称，如“订单模块需求规格说明书” | 写清对象和文档或制品形态，避免只写“需求文档”“测试报告”这类无法区分具体内容的名称 |
| 所属阶段 | 该交付物产生或提交的研发阶段，如需求、设计、开发、测试、发布 | 填阶段名称，不填日期；跨阶段复用的交付物填首次正式提交的阶段，在备注中说明复用情况 |
| 类型 | 资产类别，如需求文档、设计文档、源码包、测试用例、测试报告、发布说明 | 类型描述“是什么”，与阶段描述“什么时候交”区分；同一资产只选一个主类型 |
| 版本 | 当前登记版本号，如 V1.0、V1.2 | 按团队版本规则填写；内容发生实质变更时递增，仅格式调整可在备注说明 |
| 责任人 | 对该交付物内容和提交负责的个人 | 填姓名而非团队名；多人协作时填主责人，协作者写入备注 |
| 验收标准 | 判断该交付物合格的依据，如“评审通过并关闭全部阻断意见”“用例覆盖核心流程且执行通过率100%” | 写成可核验的条件，避免“质量良好”“内容完整”这类无法判定的表述 |
| 存放位置 | 文档库路径、代码仓库地址、制品库坐标或共享目录 | 填可定位的具体位置，不填“群里”“邮件里”；位置变更时同步更新 |
| 状态 | 当前处理进度，如草稿、评审中、已通过、已发布、已作废 | 状态描述流程位置，与版本区分；状态变化时记录变更日期 |
| 计划交付日期 | 约定的提交或评审完成日期 | 填日期，不填“尽快”“本迭代内”等模糊表述 |
| 备注 | 复用说明、协作者、变更原因、关联需求编号等补充信息 | 只写影响理解或追溯的信息，避免堆积过程流水 |
容易混淆的两组字段需要特别约定。“类型”和“所属阶段”回答不同问题：一份测试报告属于“测试报告”类型，可能产生于测试阶段，也可能在发布前补充回归结论，此时阶段填测试、类型仍为测试报告。“版本”和“状态”也分属两个维度：版本标识内容迭代到第几版，状态标识这一版走到流程哪一步，同一版本可以经历草稿、评审中、已通过多个状态。填写前团队应统一阶段名称、类型清单和状态取值，并把取值写入表格的下拉选项或填写说明，避免同一含义出现多种写法。
必填与选填：哪些列不能空
必填项的判断依据是：缺少该字段时，评审人无法确认交付物是什么、由谁负责、是否合格、在哪里取用。满足这一条件的字段设为必填，其余按管理需要选填。
| 字段 | 必填/选填 | 理由与适用场景 |
|---|---|---|
| 交付物编号 | 必填 | 唯一标识是引用、追溯和去重的基础 |
| 交付物名称 | 必填 | 没有名称无法识别资产内容 |
| 所属阶段 | 必填 | 决定交付节点和评审安排 |
| 类型 | 必填 | 用于分类统计和确定评审方式 |
| 版本 | 必填 | 交接和追溯需要明确取用哪一版 |
| 责任人 | 必填 | 明确提交与整改的对接人 |
| 验收标准 | 必填 | 评审通过的判定依据，缺失会导致验收口径不一 |
| 存放位置 | 必填 | 保证他人能实际取到交付物 |
| 状态 | 必填 | 反映当前进度，支撑清单筛选和交接判断 |
| 计划交付日期 | 选填 | 有明确里程碑或迭代节奏的项目建议填写；探索性任务可暂不填 |
| 备注 | 选填 | 按需补充复用、协作和变更信息 |
必填项缺失时，不建议留空后直接进入评审。处理方式有三种：能在评审前补齐的，由责任人补填并更新清单；暂时无法确定的，在对应单元格写明待定原因和预计补齐时间，并在备注中标注；确实不适用的，填写“不适用”并说明理由，避免空白被误读为遗漏。清单进入交接或归档前，应至少完成一轮必填项检查，把仍为空的单元格逐条确认。
填写示例：一份完整的研发交付物清单
以下示例为演示数据，覆盖需求、设计、开发、测试、发布五个阶段和多种交付物类型，必填字段全部填写，用于展示各字段如何配合。
| 交付物编号 | 交付物名称 | 所属阶段 | 类型 | 版本 | 责任人 | 验收标准 | 存放位置 | 状态 | 计划交付日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|
| REQ-001 | 订单模块需求规格说明书 | 需求 | 需求文档 | V1.2 | 张敏 | 需求评审通过，阻断意见全部关闭 | 文档库/订单项目/需求 | 已通过 | 2025-03-14 | 关联需求单 REQ-118 |
| DES-003 | 订单模块接口设计说明 | 设计 | 设计文档 | V1.0 | 李哲 | 架构评审通过，接口清单与需求条目一一对应 | 文档库/订单项目/设计 | 已通过 | 2025-03-21 | 与支付模块联调前定稿 |
| DEV-007 | 订单服务源码包 | 开发 | 源码包 | V1.0.3 | 王磊 | 代码评审通过，单元测试通过率不低于90% | 代码仓库/order-service 标签 v1.0.3 | 已发布 | 2025-04-02 | 含热修复提交 2 个 |
| TST-012 | 订单模块测试用例集 | 测试 | 测试用例 | V2.0 | 陈璐 | 覆盖全部核心流程，评审通过 | 测试管理/订单项目/用例 | 已通过 | 2025-04-08 | 核心流程 36 条 |
| TST-015 | 订单模块测试报告 | 测试 | 测试报告 | V1.0 | 陈璐 | 用例执行率100%，遗留缺陷均有处理结论 | 文档库/订单项目/测试 | 评审中 | 2025-04-15 | 遗留 2 个低优先级缺陷 |
| REL-002 | 订单模块发布说明 | 发布 | 发布说明 | V1.0 | 赵航 | 发布评审通过，回滚方案已确认 | 文档库/订单项目/发布 | 草稿 | 2025-04-18 | 待补充监控指标 |
示例中每一行都能独立回答“这是什么、哪个阶段交、谁负责、怎样算合格、去哪里取、现在到哪一步”。REQ-001 的版本为 V1.2，说明需求经过两轮修订，状态为已通过，表示当前版本已完成评审；TST-015 状态为评审中，表示报告已提交但结论未定，交接时不能当作已完成资产。发布说明处于草稿状态，计划交付日期临近，可作为清单筛选时的跟进对象。
调整与维护：按团队情况改表并持续更新
模板需要随项目类型和交付节奏调整，否则容易在第一个项目结束后被弃用。调整时保留必填字段作为骨架，按实际管理需要增删选填字段。
按项目类型增删字段的方法：硬件或嵌入式项目通常需要增加“物料或样件编号”“关联变更单”字段；纯软件项目可增加“关联需求编号”“构建号”；涉及外部供应商的项目可增加“交付对象”字段，区分内部团队与供应商。交付节奏快的迭代项目，可把“计划交付日期”细化为“计划提交日期”和“计划评审日期”；节奏较慢的里程碑项目，可增加“里程碑名称”。每次增删字段后，同步更新字段说明和下拉选项，避免新旧口径并存。
清单更新时机与责任人：责任人负责在交付物状态变化时更新本人负责的行，包括提交评审、评审通过、发布和作废；项目负责人或配置管理员在每个交付节点前检查必填项完整性和状态准确性。建议把更新动作绑定到评审和发布流程中，评审开始时核对清单，发布完成后确认状态，避免集中补录。
版本与状态字段的维护约定：版本号按团队规则递增，历史版本在版本管理工具或文档库中留存，清单只保留当前有效版本；状态取值固定为草稿、评审中、已通过、已发布、已作废五类，作废行保留不删除，便于追溯。清单本身也应标注更新日期和维护人，多人协作时可开启表格的修改记录。
当清单需要多人跨阶段维护、并与需求、测试和发布记录对应时，可以把清单承载在支持文档协作与工作项关联的平台中。ONES 可将标准流程、评审节点、交付物模板和过程数据沉淀为可复用资产，支持在项目执行中持续使用；其方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯，并支持把测试用例、缺陷、版本和发布过程关联到需求链路中。团队可据此把清单中的交付物与对应需求、测试和发布记录建立关联，减少在多个表格之间手工核对。具体字段结构和配置方式需按团队流程在平台内设定。
常见问题
交付物清单和配置基线有什么区别，什么时候需要同时使用？
交付物清单登记的是可交付资产本体，回答有哪些交付物、由谁负责、放在哪里、当前什么状态；配置基线关注的是在某个节点把一组配置项固定下来，并控制后续变更。两者可以配合使用：清单用于日常跟踪交付进度，基线用于在评审或发布节点锁定一组已确认的交付物。本文只讨论清单本身，基线的建立与变更控制属于相邻主题，需要按组织的配置管理流程另行约定。
同一个交付物在多个阶段复用，清单里要重复登记吗？
建议保留一行主记录，在“所属阶段”填首次正式提交的阶段，并在备注中说明后续复用情况。如果复用过程中内容发生实质变更，按团队版本规则递增版本号，状态随流程更新。这样既避免同一资产出现多条记录造成统计重复，也能通过版本和备注追溯它在各阶段的使用情况。若团队需要按阶段统计交付数量，可在表格工具中增加一列“复用阶段”作为选填字段，而不复制整行。
必填项在评审前确实无法确定，清单还能提交吗？
可以提交，但需要在对应单元格写明待定原因和预计补齐时间，并在备注中标注，避免空白被误读为遗漏。评审时把这类待定项单独列出，明确补齐责任人和时间点。清单进入交接或归档前，应完成一轮必填项检查，把仍为空的单元格逐条确认；确实不适用的填“不适用”并说明理由。这样处理能让评审人区分“尚未填写”和“确认不需要”，减少返工。
清单里的状态取值可以按团队习惯自定义吗？
可以，但建议在项目内固定一套取值并写入下拉选项，例如草稿、评审中、已通过、已发布、已作废五类。状态描述的是流程位置，取值过多会让筛选和交接判断变得困难；取值过少又无法反映关键节点。团队可在此基础上增加“已归档”等状态，但应同步更新字段说明，避免新旧口径并存。状态变化时记录变更日期，便于回溯交付节奏。
清单需要多人跨阶段维护时，用什么方式承载比较合适？
如果清单只在单个项目内短期使用，在线表格配合修改记录即可满足。当清单需要跨阶段、跨角色维护，并与需求、测试和发布记录对应时，可以考虑承载在支持文档协作与工作项关联的平台中。ONES 可将标准流程、评审节点、交付物模板和过程数据沉淀为可复用资产，支持在项目执行中持续使用；其方案围绕需求、基线、版本和变更建立统一管理对象，并支持把测试用例、缺陷、版本和发布过程关联到需求链路中。团队可据此把清单中的交付物与对应记录建立关联，减少多表手工核对。具体字段结构和配置方式需按团队流程在平台内设定。
