建立研发交付物清单，关键是把散落在需求、设计、开发、测试、发布各阶段的交付物收敛成一份可核对的登记表。先划定范围，再统一字段口径，通过识别、登记、校验、评审、维护五步落到具体负责人，最后用逐项检查确认清单可用。清单的登记与版本状态维护，可以在ONES这类研发管理平台中承载，具体能力以实际使用版本为准。
要点总览（TL;DR）
- 建立研发交付物清单，先按研发阶段与交付对象划定范围，并写明排除项，避免把配置基线和制品仓库底层内容混入。
- 每项交付物固定记录名称、类型、版本、来源、完整性、保留要求六类字段，其中版本、来源、完整性、保留要求是校验重点。
- 用识别、登记、校验、评审、维护五步推进，每步明确输入、动作、输出与完成标志，校验与评审分开执行。
- 清单可用性用范围、字段、责任、维护四项检查判断，任一项不通过即视为未完成。
- 清单登记与版本状态维护可在ONES中承载，具体字段配置与权限需结合组织实际流程确定。
清单先定范围：哪些研发交付物要进清单
清单范围决定后续工作量。范围过宽，会把配置基线、制品仓库底层内容一并卷入，清单迅速膨胀且难以维护；范围过窄，又会漏掉评审和发布环节必须核对的材料。建议用“研发阶段×交付对象”两个维度交叉划定，并显式写出排除项。
按研发阶段识别，常见交付物包括：需求阶段的需求规格说明、需求评审记录、需求变更记录；设计阶段的架构设计说明、接口设计文档、数据库设计说明；开发阶段的代码提交记录、单元测试报告、构建产物说明；测试阶段的测试计划、测试用例、测试报告、缺陷清单；发布阶段的发布说明、部署手册、回滚方案、上线检查记录。阶段划分可按组织实际流程调整，但每个阶段都要明确“本阶段必须产出什么”。
按交付对象区分内部交付与对外交付。内部交付指在研发团队、测试团队、运维团队之间流转的交付物，关注可追溯与可复现；对外交付指提交给客户、合作方或监管方的交付物，关注完整性、格式与保留要求。两类交付物可以共用一张清单，但要用字段区分，避免对外交付要求被内部条目稀释。
排除项要写清楚：组织级配置基线（基线建立、基线变更控制）归配置与基线管理，不在本清单逐条登记；制品仓库的底层开发与搭建属于制品管理范畴，清单只登记“需要交付的制品及其说明”，不登记仓库自身的实现细节。范围界定说明建议由清单负责人起草，经各阶段责任人确认后定稿，确认方式可以是评审会或书面会签，确认结果作为清单的第一份附件留存。
核心答案与操作步骤：五步建立清单
五步流程的每一步都要有明确输入、动作、输出和完成标志，避免停在“收集一下”的层面。下表给出可直接执行的操作口径。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步 识别 | 研发阶段划分、各阶段活动清单、合同或组织交付要求 | 从阶段活动和交付要求中逐条提取候选交付物，标注所属阶段与交付对象 | 候选交付物列表 | 每个阶段至少有一条候选记录，排除项已单独列出 |
| 第二步 登记 | 候选交付物列表、统一字段模板 | 按名称、类型、版本、来源、完整性、保留要求六类字段逐项填写 | 初版清单 | 每条记录六类字段均有取值，无空白项 |
| 第三步 校验 | 初版清单 | 逐条核对版本、来源、完整性、保留要求是否齐全且口径一致 | 校验记录与修订后的清单 | 校验问题全部关闭或标注处理结论 |
| 第四步 评审 | 校验后的清单、范围界定说明 | 相关角色确认清单完整性与准确性，重点看是否漏项、字段取值是否符合实际 | 评审结论与终版清单 | 评审角色签署确认，遗留问题有责任人和期限 |
| 第五步 维护 | 终版清单、更新触发条件 | 设定更新触发条件与唯一维护责任人，明确变更记录方式 | 维护规则与责任人名单 | 触发条件写入清单说明，责任人已确认 |
识别阶段容易漏掉的是“过程性交付物”，例如评审记录、变更记录、上线检查记录。这类材料在审计和复盘时经常被调取，建议在识别时单独列一类，避免只登记文档类交付物。登记阶段不要追求一次填全，先把六类字段的取值来源定下来，再逐条补。校验与评审是两道不同的关口：校验看字段是否齐全、口径是否一致；评审看内容是否准确、范围是否完整，两者不能合并。
字段怎么填：版本、来源、完整性与保留要求
六类字段中，名称和类型用于识别，版本、来源、完整性、保留要求用于核对和执行。四类关键字段的填写口径如下表。
| 字段 | 填写口径 | 取值来源 | 示例 |
|---|---|---|---|
| 版本 | 标识该交付物当前有效版本，规则与组织版本命名保持一致，注明版本取值依据 | 配置管理系统、文档管理系统或发布记录 | V1.2，依据发布记录2024-06批次 |
| 来源 | 写明产出活动、产出角色或产出系统，三者至少写清一项，能定位到具体产出环节 | 阶段活动清单、任务分配记录 | 测试阶段，由测试组在系统测试活动中产出 |
| 完整性 | 给出可判定的检查口径，例如文件齐全且可打开、关联附件无缺失、与对应版本一致 | 交付要求、评审检查表 | 正文、附件、签字页齐全，与V1.2版本一致 |
| 保留要求 | 同时写明保留期限、存放位置、保留责任人三项 | 合同约定、组织制度、监管要求 | 保留3年，存放于项目文档库发布目录，责任人为项目文档管理员 |
版本字段要避免只写“最新版”，否则清单无法回溯。来源字段的价值在于出问题时能快速找到产出环节和责任人。完整性字段最容易写成主观描述，建议改成可勾选的检查项，例如“文件可打开”“附件数量与清单一致”“签字页齐全”。保留要求缺任何一项都难以执行：只写期限不写位置，到期后无处查找；只写位置不写责任人，无人跟进清理和归档。
角色与交付物分工
清单建设涉及四类角色，职责和产出物要分开写清楚，避免出现“大家都参与、没人负责”的情况。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 清单负责人 | 统筹清单范围与字段口径，组织评审，裁决范围争议 | 范围界定说明、字段模板、终版清单 |
| 阶段责任人 | 提供本阶段交付物清单与来源信息，确认版本取值 | 本阶段候选交付物列表、来源说明 |
| 评审角色 | 校验完整性与保留要求，确认清单是否覆盖交付要求 | 评审意见、评审结论 |
| 维护责任人 | 处理交付物变更与清单更新，记录变更历史 | 更新后的清单、变更记录 |
清单负责人通常由项目管理人员或质量管理人员担任，重点在口径统一，不承担逐条填写。阶段责任人由各阶段的技术负责人担任，对本阶段交付物的真实性负责。评审角色建议包含测试、运维和使用方代表，因为完整性和保留要求往往在使用环节才暴露问题。维护责任人应设为唯一角色，避免多头更新导致版本混乱。
示例：一条研发交付物清单记录
以下是一条已填写的记录，用于示范字段如何组合成可用条目。示例为演示情景，不代表特定组织的实际要求。
| 字段 | 取值 |
|---|---|
| 名称 | 系统测试报告 |
| 类型 | 测试类文档 |
| 版本 | V1.0，依据测试阶段发布记录 |
| 来源 | 测试阶段，测试组在系统测试活动中产出 |
| 完整性 | 报告正文、测试用例执行记录、缺陷统计附件齐全，文件可打开，与V1.0版本一致 |
| 保留要求 | 保留3年，存放于项目文档库测试目录，责任人为测试组文档管理员 |
这条记录可以直接核对：版本能追溯到发布记录，来源能定位到测试组和具体活动，完整性有可勾选的检查项，保留要求三项齐全。迁移到其他交付物时，保持字段结构不变，只替换取值来源。例如把“系统测试报告”换成“接口设计文档”，版本依据改为设计评审记录，来源改为设计阶段和架构组，完整性改为“接口清单、字段说明、示例报文齐全”，保留要求按设计文档的管理制度填写。迁移过程中如果某个字段找不到取值来源，说明该交付物的管理要求尚未明确，应先补要求再登记。
完成检查：清单是否可用
清单是否达到可用状态，用四项检查逐条核对，任一项不通过即视为未完成。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 范围检查 | 需求、设计、开发、测试、发布各阶段均有覆盖，内部交付与对外交付已区分，排除项已写明 | 存在整阶段缺失或排除项未说明 |
| 字段检查 | 每条记录六类字段齐全，版本、来源、完整性、保留要求均有可核对取值 | 关键字段空白或以“待定”占位超过约定期限 |
| 责任检查 | 每条记录有明确负责人，维护责任人唯一 | 存在无责任人的条目或维护责任人未指定 |
| 维护检查 | 更新触发条件已写入清单说明，变更记录方式已明确 | 未设定触发条件或变更记录无承载位置 |
四项检查全部通过后，清单可以投入使用。投入使用后，建议在每次阶段评审和版本发布时复核一次，重点看新增交付物是否登记、版本取值是否更新、保留要求是否随合同或制度变化调整。清单登记、版本标识与状态更新如果放在ONES中承载，可以把交付物作为工作项或文档条目管理，让负责人、版本和状态在同一处维护，减少表格多头流转带来的口径不一致；具体字段配置与权限设置需结合组织实际流程确定。
常见问题
研发交付物清单和配置基线是什么关系，清单里要不要登记基线？
两者管理对象不同。交付物清单登记的是需要交付、需要核对的资产本体，例如需求规格说明、测试报告、发布说明；配置基线的建立与变更控制属于配置与基线管理，负责确定哪些配置项在什么时点被固定。清单里可以记录某项交付物对应的基线标识作为追溯线索，但基线的建立、审批和变更流程不在清单内展开。实际操作中，建议在清单说明里写明这一分工，避免清单负责人和配置管理员重复登记同一内容。
交付物在研发过程中频繁变更，清单怎么跟得上？
关键是预设更新触发条件并指定唯一维护责任人。常见触发条件包括：交付物内容变更、版本发布、阶段评审通过、合同或组织要求调整。触发后由维护责任人更新对应记录的版本与完整性字段，并在变更记录中写明变更时间、变更内容和依据。对于变更频繁的交付物，可以在清单中标注复核频率，例如每次迭代结束时复核一次，减少逐条追更的成本。清单本身也应保留历史版本，便于回溯某一时点的交付状态。
完整性字段怎么写才不是主观判断？
把完整性拆成可勾选的检查项，而不是写“内容完整”这类描述。可用的口径包括：文件可正常打开、正文与附件数量与清单一致、签字页或审批记录齐全、内容与登记的版本一致。不同交付物的检查项可以不同，例如测试报告看正文、用例执行记录和缺陷统计是否齐全，设计文档看接口清单、字段说明和示例报文是否齐全。检查项确定后写入字段模板，登记时逐项勾选，评审时按同一口径复核。
保留要求里的期限、位置、责任人，哪一项最容易出问题？
三项都容易出问题，但表现不同。只写期限不写存放位置，到期后难以查找；只写位置不写责任人，无人跟进归档和清理；只写责任人没有期限，保留要求无法执行。建议三项同时填写，并与合同约定或组织制度对齐。对外交付物的保留要求通常更严格，需要在清单中单独标注。制度或合同调整时，保留要求字段要同步更新，并在变更记录中说明调整依据。
清单建好后，多久复核一次比较合适？
复核频率取决于交付节奏和交付物变更频率。常见做法是在每次阶段评审和版本发布时复核一次，重点检查新增交付物是否登记、版本取值是否更新、保留要求是否随合同或制度变化调整。交付物变更频繁的项目可以缩短间隔，例如每个迭代结束时复核；变更较少的项目可以按季度复核。复核结果建议留痕，记录复核时间、复核人和处理结论，便于后续追溯。
