研发交付物与制品管理的落地做法可以概括为四件事：先划定纳入管理的对象并分类，再为每类对象定义标识、版本、状态和准入条件，随后明确产生、评审、归档、变更各环节的角色与交接动作，最后用清单和抽查验证执行效果。核心产物是一份交付物清单和一套制品台账，配套评审记录与变更记录。下面按范围、流程、角色、示例和检查五个部分展开，并说明这些记录可以如何在ONES中承载。
要点总览（TL;DR）
- 先按“是否被下游引用、是否需要追溯、是否随版本变化”三条标准划定纳入范围，把对象分为文档、代码与构建产物、测试与验证证据、发布包四类，产出一份带纳入理由的分类清单。
- 流程按六步执行：定义唯一标识与命名规则、确定版本与状态流转、定义准入条件与评审方式、规定存放位置、建立变更与替换规则、归档与发布时冻结，每步都有输入、动作、输出和完成标志。
- 角色分工的核心是每个交付物都有产生者和确认者：产品、开发、测试分别产出对应交付物，配置管理员维护清单与台账并执行冻结归档，项目负责人确认范围与发布结论；小团队可合并职责，但保留产生与确认分离、冻结归档定人两条底线。
- 用一个 V2.3 迭代示例演示从需求说明到发布包的流转，标识可定位、版本可追溯、状态有迁移记录、冻结有责任人。
- 检查按清单完整性、标识唯一性、版本可追溯性、评审与变更记录、冻结归档六项核对，迭代结束抽查、发布前核对发布清单，出现失效信号时优先检查准入条件与状态责任人。
先划范围：哪些交付物和制品要纳入管理
范围划分决定后续工作量。建议先把项目里已经存在的产出物全部列出来，再逐项判断是否纳入，避免一开始就追求大而全。判断标准可以统一为三条：是否被下游角色或下游环节引用，是否需要回溯到需求或变更，是否随版本迭代发生变化。三条中满足任意两条的，纳入管理；只满足一条的，可以先登记不深度管理；一条都不满足的，不纳入。
交付物与制品在管理上可以区分对待。交付物偏过程与证据，制品偏可部署、可分发的实体。分类口径建议如下：
| 类别 | 典型对象 | 管理重点 |
|---|---|---|
| 文档类 | 需求说明、设计说明、接口文档、用户手册、评审纪要 | 版本、评审状态、与需求的关联 |
| 代码与构建产物 | 源码分支、构建输出、依赖清单 | 与版本号的对应关系、构建可复现性 |
| 测试与验证证据 | 测试用例、测试报告、缺陷记录、验收记录 | 覆盖范围、执行结论、与版本的绑定 |
| 发布包 | 安装包、镜像、配置包、发布说明 | 唯一标识、冻结状态、发布去向 |
需要说明边界：配置基线的建立与维护、制品仓库的底层搭建属于另外的工作，本篇只处理“哪些对象要管、怎么管、谁负责、如何检查”。基线可以理解为某一时刻被正式确认的交付物集合，制品仓库负责存放构建产物和发布包本体；本篇给出的是清单、规则和记录，二者衔接但不重叠。
产出物是一份分类清单，每行包含对象名称、类别、纳入结论和理由。完成标志是清单经过项目负责人确认，且每个“不纳入”项都写明了理由。
核心操作步骤：从标识到归档的六步流程
六步流程按顺序执行，每一步都有明确输入、动作、输出和完成标志。流程可以整体套用，也可以按项目规模裁剪，但标识、版本、准入、存放、变更、归档六个环节不宜省略。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、定义唯一标识与命名规则 | 分类清单 | 为每类对象约定编号结构，如“项目代号-类别码-序号-版本号”；规定文件名与目录名规则 | 命名规则说明 | 任取一份交付物，能仅凭名称定位项目、类别和版本 |
| 二、确定版本规则与状态流转 | 命名规则 | 约定版本递增方式（主版本、次版本、修订号）及状态集合：草稿、评审中、已批准、已归档、已废弃；写明状态迁移条件 | 版本与状态规则 | 每个状态都有进入条件和退出条件，且有人负责变更状态 |
| 三、定义准入条件与评审方式 | 版本与状态规则 | 为每类对象写明进入“已批准”前必须满足的条件，如文档需评审通过、发布包需测试报告齐全；确定评审形式（会议、会签、异步评审） | 准入条件表、评审记录模板 | 每类对象至少有一条可核验的准入条件 |
| 四、规定存放位置与目录结构 | 分类清单、命名规则 | 指定每类对象的存放位置和目录层级，保证同一对象只有一个权威位置 | 目录结构说明 | 按目录能在一个入口找到某版本的全部交付物 |
| 五、建立变更与替换规则 | 准入条件表 | 规定已批准对象发生变更时如何升版、如何记录变更原因与影响范围、旧版本如何处理 | 变更记录模板 | 任取一次变更，能查到变更前后版本和影响对象 |
| 六、归档与发布时的冻结动作 | 变更记录、发布计划 | 发布前将对应交付物与制品状态置为冻结，记录冻结时间与冻结人；发布后转入已归档 | 冻结记录、发布清单 | 发布包与同版本交付物一一对应，且冻结后无未记录的改动 |
第三步的准入条件是整套流程的关键。条件写得越具体，评审越容易执行。例如“设计文档已批准”可以细化为“设计文档完成评审、评审意见已闭环、关联需求已确认”。第五步的变更规则要回答两个问题：变更由谁发起、旧版本保留多久。这两个问题没有统一答案，按项目对外交付要求确定即可。
这些规则和记录需要有承载位置。ONES 当前方案覆盖需求、基线、版本、变更、测试与发布，围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；标准流程、评审节点、交付物模板和研发过程数据可以沉淀为可复用资产。把交付物清单、评审记录和状态流转放进同一套工作项与文档体系中，规则就从文档要求变成了项目里的实际动作。
角色与交付物分工：谁产生、谁评审、谁归档
分工的原则是每个交付物都有明确的产生者和确认者，交接点留下记录。下表给出常见分工，项目可按实际岗位调整，但职责不能悬空。
| 角色 | 主要职责 | 输入来源 | 输出交付物 |
|---|---|---|---|
| 产品 | 提出需求、确认需求文档、参与验收 | 业务方输入、用户反馈 | 需求说明、验收结论 |
| 开发 | 产出设计与代码、提交构建产物、修复缺陷 | 已批准需求、设计评审意见 | 设计文档、源码与构建产物、缺陷修复记录 |
| 测试 | 编写并执行测试、出具测试报告、确认发布包 | 需求说明、构建产物 | 测试用例、测试报告、缺陷记录 |
| 配置管理员 | 维护命名与版本规则、管理存放位置、执行冻结与归档 | 各类交付物、变更申请 | 交付物清单、制品台账、冻结与归档记录 |
| 项目负责人 | 确认范围与准入条件、组织评审、对发布结论负责 | 各角色提交的交付物 | 评审结论、发布决定 |
交接点的确认方式建议统一为“提交加确认”：上游角色提交交付物并更新状态，下游角色确认接收或提出意见，确认动作留下记录。记录形式可以是评审纪要、会签记录或系统中的状态变更，关键是能回答“谁在什么时间确认了什么”。
小团队或单人团队可以把职责合并，例如开发兼任配置管理员、项目负责人兼任评审组织者。合并时保留两条底线：产生者与确认者尽量分离，至少做到自检记录留痕；冻结与归档动作由固定的人执行，避免发布时无人对版本一致性负责。
示例：一个版本迭代中的交付物与制品流转
以下为演示情景，用于说明流程如何在一个迭代内跑通，不代表真实客户案例。
背景：某项目进行 V2.3 版本迭代，纳入管理的对象包括需求说明、设计文档、测试报告、构建产物和发布包。命名规则为“项目代号-类别码-序号-版本号”，例如需求说明编号为 PRJ-REQ-012-V2.3，发布包编号为 PRJ-REL-005-V2.3。
流转过程：产品提交需求说明，状态为草稿；评审通过后置为已批准，进入开发。开发完成设计文档并提交评审，评审意见闭环后升版为 V2.3.1 并置为已批准。开发提交构建产物，测试据此编写用例并执行，出具测试报告，缺陷记录关联到对应需求。项目负责人组织发布评审，确认测试报告结论和遗留缺陷处理方式后，配置管理员将发布包与同版本交付物状态置为冻结，记录冻结时间与冻结人。发布完成后转入已归档。
记录样例：变更记录中登记一次设计调整，写明变更原因、影响的需求编号、变更前后版本号和处理结论；评审记录中登记参与人、评审结论和待办闭环情况；制品台账中登记发布包编号、对应构建产物、测试报告编号和发布去向。示例体现的规则是：标识可定位、版本可追溯、状态有迁移记录、冻结有责任人。
在ONES中，测试用例、缺陷、版本和发布过程可以关联到需求链路，出现问题时沿关联关系定位影响范围；需求发生变化时，也可沿关联关系分析受影响的任务、测试和交付内容，并保留过程追踪和审计依据。这类关联适合承载示例中的追溯要求。
完成检查：判断管理是否真正落地
检查的目的是验证规则是否被执行，而不是验证文档是否写得漂亮。建议按季度或每个大版本做一次全面检查，平时按抽查方式维持。检查清单如下：
| 检查项 | 通过标准 |
|---|---|
| 清单完整性 | 本版本实际产出的交付物与制品均能在清单中找到，无清单外的重要产出 |
| 标识唯一性 | 抽查十份对象，名称均符合命名规则，无重名或无法定位版本的情况 |
| 版本可追溯性 | 任取一个发布包，能查到对应构建产物、测试报告和需求编号 |
| 评审记录齐全 | 已批准对象均有评审记录，评审意见有闭环结论 |
| 变更记录齐全 | 已批准对象发生变更的，均有变更记录并完成升版 |
| 冻结与归档 | 发布包有冻结记录，冻结后无未记录的改动，归档位置可查 |
抽查方法：每个迭代随机抽取三到五份交付物，按上表逐项核对，记录不符合项并指定整改人。频次可以与迭代节奏对齐，迭代结束时抽查一次，版本发布前做一次发布清单核对。
常见失效信号包括：清单长期不更新、评审记录只有结论没有意见、变更后版本号不变、发布包与测试报告对不上、归档目录里出现多个同名文件。出现这些信号时，优先检查准入条件是否过于笼统、状态变更是否无人负责，再调整规则和分工。ONES 可自动收录系统内日常流转的研发数据并形成分析指标，检查时可作为执行情况的参考，具体指标口径按团队实际配置确定。
常见问题
项目刚开始推行这套管理，应该先做哪一步？
先做范围划分，也就是 S1 的分类清单。把项目里已经存在的产出物全部列出来，逐项按三条标准判断是否纳入，并写明理由。这一步不需要改动任何工具配置，成本最低，却能直接决定后续工作量。清单经项目负责人确认后，再进入标识与版本规则的制定。
不建议一开始就追求大而全。只满足一条标准的对象可以先登记、不深度管理，等下游引用关系变复杂后再升级管理方式。
准入条件写到什么程度才算够用？
判断标准是可核验：换一个人拿着条件去核对，能明确得出“满足”或“不满足”的结论。例如“设计文档已批准”偏笼统，细化为“设计文档完成评审、评审意见已闭环、关联需求已确认”就便于执行。
条件过粗会让评审流于形式，过细会增加维护负担。建议每类对象先写三到五条关键条件，运行一两个迭代后再按实际争议点补充。
小团队人手少，角色合并后怎么保证不失控？
职责可以合并，例如开发兼任配置管理员、项目负责人兼任评审组织者。合并时保留两条底线：产生者与确认者尽量分离，至少做到自检记录留痕；冻结与归档动作由固定的人执行，避免发布时无人对版本一致性负责。
单人团队无法分离产生与确认时，用记录补位：提交时写明自检项和核对结果，发布前按发布清单逐项打勾，让动作可回溯。
交付物清单和制品台账由谁维护，多久更新一次？
通常由配置管理员维护，项目负责人确认。更新节奏与流程节点绑定比按固定周期更新更可靠：新对象产生时登记，状态变化时更新，变更时记录前后版本，发布冻结时核对台账与发布清单一致。
如果清单长期不更新，往往说明登记动作没有嵌入日常流程，此时应把登记作为交付物提交的前置动作，而不是事后补录。
检查发现发布包与测试报告对不上，应该怎么整改？
先定位断点在哪一环：是测试报告没有绑定版本号，还是发布包冻结时未核对同版本交付物，还是变更后未升版导致版本错位。定位后优先修规则，例如在准入条件中增加“测试报告须标注对应版本号”，在冻结动作中增加发布清单核对项。
再检查责任人是否明确。若状态变更长期无人负责，仅补充检查项无法解决问题，需要指定固定的状态维护人。
