研发交付物清单登记的是可交付资产本体，而不是项目进度或任务列表。一张可直接使用的清单，每条记录应覆盖七类信息：标识（名称、编号、类型）、归属（项目、阶段、关联需求）、责任（责任人、验收人）、时间（计划与实际交付）、质量（验收标准与状态）、位置（存放或获取方式）、变更（版本、变更与作废记录）。下面给出空白表格、字段说明、必填选填划分、一条完整填写示例，以及清单上线后的维护方法。
要点总览（TL;DR）
- 研发交付物清单每条记录覆盖七类信息：标识、归属、责任、时间、质量、位置、变更，登记对象是可交付资产本体。
- 最小必填集合为交付物名称、编号、类型、所属项目、责任人、验收人、计划交付时间、验收标准、验收状态、存放位置，缺项会削弱验收与追溯。
- 填写时名称写资产本体而非动作，编号项目内唯一，验收人与责任人分离，实际交付时间在提交当天填写。
- 验收状态使用固定枚举值，退回修改与通过后变更都要在变更记录中写明原因；作废保留原行并标注替代关系。
- 字段增删需评审并更新模板版本，按周检查逾期与待验收记录，阶段结束或结项时归档为只读。
可复制空白模板：研发交付物清单表
下表为空白清单表头与两行空白记录，可直接复制到 Excel、在线表格或文档表格中使用。字段顺序按“先标识、再归属、后责任与状态”排列，便于逐条登记和横向筛选。
| 序号 | 交付物名称 | 交付物编号 | 交付物类型 | 所属项目 | 所属阶段 | 关联需求/任务 | 版本/标识 | 责任人 | 验收人 | 计划交付时间 | 实际交付时间 | 验收标准 | 验收状态 | 存放位置/获取方式 | 变更记录 | 作废状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
当项目阶段较多时，建议在表内按阶段分组排列记录，而不是为每个阶段单独建一张表。分组方式有两种：一是按“所属阶段”列排序后插入分组标题行，例如“需求阶段”“设计阶段”“开发与集成阶段”“测试阶段”“发布与移交阶段”；二是使用表格工具的分组或分级显示功能，把同一阶段的记录折叠在一起。分组行只写阶段名称，不填其他字段，汇总统计时按记录行计数，避免把分组行误算为交付物。
单条记录与汇总行的区别需要提前约定：单条记录一行对应一个可交付资产，字段填写完整；汇总行只用于统计某阶段或某项目的交付物数量、已验收数量、逾期数量，不参与逐条验收。若在同一张表中放汇总行，建议放在分组末尾并用底色区分，或在表外单独做统计区，防止筛选和排序时混入。
每个字段登记什么：字段说明
字段含义需要在建表时一次说清，否则不同人填出的清单无法合并比较。下表逐字段说明含义、取值方式和常见错误。
| 字段 | 含义 | 取值示例 | 常见错误 |
|---|---|---|---|
| 交付物名称 | 可交付资产的本体名称，能让人一眼识别交付的是什么 | 订单服务接口设计说明书 | 写成任务名，如“完成接口设计” |
| 交付物编号 | 项目内唯一的标识，便于引用和追溯 | PRJ-ORD-DOC-012 | 同一项目内编号重复或中途改号 |
| 交付物类型 | 资产类别，决定后续字段侧重点 | 文档、代码包、硬件、数据集 | 类型写得过细或混用多种分类口径 |
| 所属项目 | 交付物归属的项目 | 订单中心重构项目 | 填成部门名或产品线名 |
| 所属阶段 | 交付物产出的研发阶段 | 设计阶段、测试阶段 | 阶段名称与项目计划中的阶段不一致 |
| 关联需求/任务 | 交付物对应的需求编号或任务编号 | REQ-2024-087 | 只写需求标题，无法与需求库对应 |
| 版本/标识 | 交付物自身的版本号或唯一标识 | V1.2、批次号、数据集版本 | 版本号随意编，与文件内标注不一致 |
| 责任人 | 负责产出并提交该交付物的人 | 张明 | 填团队名而非具体人 |
| 验收人 | 负责判定交付物是否合格的人 | 李华（架构评审人） | 责任人与验收人填同一人且无复核 |
| 计划交付时间 | 约定的交付日期 | 2024-06-15 | 填成验收日期或里程碑日期 |
| 实际交付时间 | 交付物实际提交的日期 | 2024-06-14 | 验收通过后才补填，失去时效意义 |
| 验收标准 | 判定合格的依据，可引用评审清单或规范条款 | 通过设计评审且意见闭环 | 写“符合要求”等无法核验的表述 |
| 验收状态 | 交付物当前验收进展 | 待验收、通过、退回修改 | 状态值不统一，出现“基本通过”等自造状态 |
| 存放位置/获取方式 | 交付物所在位置或获取路径 | 文档库路径、制品库坐标、交付包编号 | 只写“已上传”，没有可定位的信息 |
| 变更记录 | 交付物内容或版本发生变化的说明 | V1.1 补充异常流程；V1.2 按评审意见修订 | 只改版本号不写变更原因 |
| 作废状态 | 交付物是否已被替代或取消 | 有效、已作废（替代为V2.0） | 直接删除作废记录，导致历史无法追溯 |
标识类字段的关键是唯一和稳定：编号一旦分配，项目内不再复用；名称描述资产本体，避免把动作写进名称。归属类字段要与项目计划、需求库使用同一套编号，否则清单无法与需求和阶段计划对齐。责任类字段要求填具体人，验收人应与责任人分离，至少在设计评审、代码评审等关键交付物上如此。时间类字段区分计划与实际，实际交付时间在提交时即填，不等验收结束。质量类字段中，验收标准要能对应到评审记录或检查项，验收状态使用固定枚举值。位置类字段要能让人按图索骥找到文件或制品，而不是只说明“已提交”。变更类字段保留历史，作废用状态标记而非删除行。
必填与选填怎么划分
必填字段的作用是保证每条记录可识别、可追责、可验收、可找到。建议的最小必填集合为：交付物名称、交付物编号、交付物类型、所属项目、责任人、验收人、计划交付时间、验收标准、验收状态、存放位置/获取方式。这十项缺任何一项，清单都难以支撑验收和追溯。
| 字段 | 建议 | 理由与适用场景 |
|---|---|---|
| 交付物名称、编号、类型 | 必填 | 没有标识就无法引用和去重 |
| 所属项目 | 必填 | 多项目共用清单时用于隔离和统计 |
| 责任人、验收人 | 必填 | 明确产出与判定责任 |
| 计划交付时间 | 必填 | 用于排期和逾期识别 |
| 验收标准、验收状态 | 必填 | 支撑验收动作和状态跟踪 |
| 存放位置/获取方式 | 必填 | 保证交付物可被找到和取用 |
| 所属阶段 | 建议必填 | 阶段划分清晰的项目必填，小规模项目可并入项目字段 |
| 关联需求/任务 | 选填 | 需要追溯需求覆盖时填写；纯内部工具类交付物可留空并注明原因 |
| 版本/标识 | 选填 | 文档和代码包建议填写；一次性交付物可只写日期标识 |
| 实际交付时间 | 选填（提交后转为必填） | 提交前为空，提交时补填 |
| 变更记录、作废状态 | 选填（发生时必填） | 无变更时留空，发生变更或作废时必须记录 |
不同交付物类型的字段侧重点不同。文档类交付物应重视版本/标识、验收标准中的评审要求以及变更记录；代码包类应重视版本标识、构建来源和存放位置中的制品坐标；硬件类应补充批次号、序列号等标识信息，可放在版本/标识或备注中；数据类应说明数据集版本和统计口径，验收标准中写明数据质量检查项。字段差异通过“版本/标识”和“验收标准”两列的填写内容体现，不必为每类交付物单独建表。
字段留空需要规则：必填字段不允许留空，确实不适用时填“不适用”并注明原因，例如某交付物无需关联需求时写“不适用：内部工具脚本”。选填字段留空表示尚未发生或不适用，不能表示“忘记填”。清单复核时，留空项应能对应到明确原因。
填写示例：一条完整记录
以下为演示情景构造的一条记录，用于说明各字段如何配合，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 序号 | 7 |
| 交付物名称 | 订单服务接口设计说明书 |
| 交付物编号 | PRJ-ORD-DOC-012 |
| 交付物类型 | 文档 |
| 所属项目 | 订单中心重构项目 |
| 所属阶段 | 设计阶段 |
| 关联需求/任务 | REQ-2024-087 订单创建接口重构 |
| 版本/标识 | V1.2 |
| 责任人 | 张明 |
| 验收人 | 李华（架构评审人） |
| 计划交付时间 | 2024-06-15 |
| 实际交付时间 | 2024-06-14 |
| 验收标准 | 通过架构评审，评审意见全部闭环，接口字段与需求文档一致 |
| 验收状态 | 通过 |
| 存放位置/获取方式 | 项目文档库/设计文档/订单服务接口设计说明书_V1.2 |
| 变更记录 | V1.1 补充异常返回码；V1.2 按6月12日评审意见修订幂等设计章节 |
| 作废状态 | 有效 |
逐项说明填写依据：名称写资产本体，不写“完成接口设计”这类动作；编号按项目前缀加类型加序号生成，项目内唯一；类型选“文档”，因此版本和评审信息成为重点；所属项目与阶段取自项目计划中的正式名称；关联需求填需求编号加标题，便于在需求库中反查；版本V1.2与文件内标注一致；责任人是文档作者，验收人是架构评审人，两者分离；计划交付时间来自阶段计划，实际交付时间在提交当天填写，早于计划一天；验收标准写成可核验的条件，对应评审记录；验收状态使用固定值“通过”；存放位置给到文档库路径和文件名，可直接定位；变更记录按版本逐条写原因，而不是只改版本号；作废状态为“有效”。
验收状态与变更记录要联动：状态为“退回修改”时，变更记录应写明退回原因和修改计划；状态为“通过”后若内容再修改，应升版本并在变更记录中说明，必要时将状态改回“待验收”。作废时保留原行，作废状态写“已作废（替代为PRJ-ORD-DOC-015 V2.0）”，不删除历史记录。
清单的调整与维护方法
清单建好后需要持续维护，否则字段会逐渐失真。以下规则可作为清单的使用约定。
- 字段增删须评审：新增或删除字段由项目负责人或质量角色提出，说明原因和影响范围，评审通过后更新清单模板版本号，并在模板说明中记录变更日期和变更内容。同一项目周期内避免频繁改字段，防止前后记录口径不一致。
- 更新时点与责任人：责任人负责在交付物提交时填写实际交付时间、版本和存放位置；验收人负责在验收完成后更新验收状态和验收意见；项目负责人或配置管理员按周检查逾期和待验收记录。
- 验收状态流转：建议固定为“待提交—待验收—通过/退回修改—已作废”几个状态。退回修改后由责任人修订并重新提交，状态回到待验收；通过后如需变更，升版本并重新走验收。
- 归档与作废：阶段结束或项目结项时，将清单连同交付物一起归档，归档后的清单只读；作废记录保留行并标注替代关系，不物理删除。
- 定期复核完整性：每月或每个里程碑节点抽查必填字段是否为空、编号是否重复、存放位置是否可访问、验收状态是否与评审记录一致，发现问题记录在复核表中并限期修正。
当清单需要多人协作维护时，可以把清单登记动作放进项目管理工作项中：每个交付物对应一条工作项或文档记录，关联所属需求与阶段，验收状态随评审动作更新，清单作为汇总视图导出。ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；ONES Wiki 支持文档关联项目任务、页面组关联项目，并提供页面模板库用于创建制式化文档模板，文档版本可查看与回滚。对于需要把交付物模板和过程数据沉淀为可复用资产的团队，可以在项目执行中沿用同一套字段口径，减少清单与文档、需求之间的手工对账。是否采用工具承载，取决于团队已有的协作方式和项目规模，清单本身的字段规则不因工具而改变。
常见问题
小型项目只有两三个人，清单字段可以精简到多少？
可以精简，但建议保留能支撑验收和追溯的最小集合：交付物名称、编号、类型、所属项目、责任人、验收人、计划交付时间、验收标准、验收状态、存放位置。小团队容易省略验收人和验收标准，结果是交付物提交后无人判定合格与否，返工和争议都难以追溯。若项目只有一个阶段，可把“所属阶段”并入项目字段；若交付物不需要关联需求，可在该列填“不适用”并注明原因，而不是直接删列。
交付物在验收通过后又修改了内容，清单应该怎么记？
保留原记录，升级版本号，并在变更记录中写明修改原因和修改内容，同时把验收状态改回“待验收”，重新走验收流程。若修改幅度很小且不影响验收结论，也应在变更记录中留痕，避免清单上的版本与文件实际版本不一致。已经归档的清单保持只读，新版本另起记录或按归档规则追加，不覆盖历史行。
清单里的“存放位置”写到什么程度才算可用？
标准是其他人拿到这一行就能直接定位到文件或制品。文档类写到文档库路径加文件名和版本，例如“项目文档库/设计文档/订单服务接口设计说明书_V1.2”；代码包写到制品坐标或交付包编号；硬件写到批次号或序列号所在的交付记录。只写“已上传”“见附件”无法定位，复核时会被视为缺失。存放位置还应定期抽查可访问性，链接失效或目录调整后及时更新。
清单和需求库、评审记录之间怎么保持对应？
关键是共用编号：关联需求列填需求编号加标题，验收标准引用评审清单或规范条款，验收状态与评审结论保持一致。这样在需求库中能反查覆盖了哪些交付物，在评审记录中能对应到具体交付物。若团队使用项目管理工作项承载交付物，可让每条交付物对应一条工作项或文档记录，清单作为汇总视图导出，减少手工对账。ONES ALM 方案围绕需求、基线、版本和变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；ONES Wiki 支持文档关联项目任务，并提供页面模板库用于创建制式化文档模板，文档版本可查看与回滚。
清单需要多久复核一次，复核哪些内容？
建议按周检查逾期和待验收记录，每月或每个里程碑节点做一次完整性抽查。抽查项包括：必填字段是否为空、编号是否重复、存放位置是否可访问、验收状态是否与评审记录一致、作废记录是否保留替代关系。发现问题记录在复核表中并限期修正，复核结果可作为阶段评审的输入。复核频率按项目节奏调整，交付密集阶段可加密，稳定阶段可放宽。
