研发供应商协作中的责任争议，多数源于约定写得不够具体：谁在什么时间交什么、达到什么状态算完成、出了问题找谁，这些内容如果没有写进双方共用的工作约定，执行时就只能靠口头确认。本文给出一套可落地的写法，覆盖交付物、责任分工、验收标准、协作规则四类内容，并配套责任矩阵、交付要求模板和分节点检查清单。采购招标流程、合同法律条款和项目整体排期不在本文范围内。
要点总览（TL;DR）
- 责任划分以交付物为单元，每份交付物只设一名主责，并在责任矩阵中写清配合、评审、知会角色、对接人和升级路径。
- 单条交付要求写清输入前提、完成标准、时间节点、交付证据四要素，把“尽快提供”“达到可用水平”等模糊表述改写为可检查的条件。
- 变更、评审不通过和交付异常都要预设处理路径：变更先评估影响再确认，评审意见逐条编号闭环，异常当日通报并明确处置责任方。
- 在合作启动、里程碑、验收三个节点逐项核对责任矩阵、交付证据和变更记录，三个通过条件同时满足才算约定真正落地。
- 多供应商、多专业方向协作时，责任矩阵、交付清单和变更记录需要在双方共用的协作环境中承载，避免信息散落在各自文档和邮件里。
责任与交付要求先落到哪几类内容
责任与交付要求要写成一份双方都能对照执行的工作约定，内容集中在四类：交付物、责任分工、验收标准、协作规则。四类内容各有需要写清的字段，缺一类就会在执行中留下模糊地带。
| 内容类别 | 需要写清的字段 | 缺失后的典型后果 |
|---|---|---|
| 交付物 | 名称、版本、形态（文档/代码/报告/样件）、所属模块、上下游依赖 | 交付范围理解不一致，验收时对“交了什么”各执一词 |
| 责任分工 | 主责方、配合方、评审方、知会方、对接人、升级路径 | 任务悬空，出问题时无人认领或多人重复处理 |
| 验收标准 | 输入前提、完成标准、时间节点、交付证据 | “基本完成”“差不多”成为争议焦点，验收反复拉扯 |
| 协作规则 | 变更流程、评审规则、异常通报路径、例会与沟通节奏 | 需求临时调整无记录，延期和质量问题发现滞后 |
需要区分的是，本文讨论的是双方在工作层面的协作约定，解决“谁做什么、做到什么程度”的问题。供应商准入与采购招标流程、合同中的法律责任与违约条款、关联项目计划的整体排期，分别由采购、法务和项目集管理承担，本文不展开，但工作约定中的交付物清单和验收结论可以作为这些环节的输入材料。
按交付物拆分责任：从工作分解到责任矩阵
责任划分悬空，常见原因是按部门或按公司拆分工作——“供应商负责开发、甲方负责验收”这类表述粒度太粗，无法定位到具体的人和具体的产物。更有效的做法是以交付物为单元拆分，每一份可交付的产物对应一行责任记录。
拆分步骤可以按以下顺序执行：
- 列出合作范围内的全部交付物，包括过程性交付物（设计说明、接口文档、测试用例）和结果性交付物（可运行模块、测试报告、上线包）。
- 对每份交付物继续下拆，直到单个交付物可以由一名责任人独立完成并接受检查，通常拆到“一个人一周左右能产出并提交评审”的粒度。
- 标注交付物之间的依赖关系，明确哪份产物是另一份的输入前提。
- 为每份交付物填写责任矩阵，指定角色和具体对接人。
责任矩阵建议区分四类角色：主责（对交付结果负责，推动完成并提交评审）、配合（提供输入、协助处理依赖）、评审（对交付物做出通过或不通过的判断）、知会（需要了解进展但不必参与执行）。每份交付物只设一名主责，避免共同负责变成无人负责。
| 交付物 | 主责 | 配合 | 评审 | 知会 | 对接人 | 升级路径 |
|---|---|---|---|---|---|---|
| 接口设计说明 v1 | 供应商开发负责人 | 甲方系统架构师 | 甲方技术负责人 | 双方项目经理 | 供应商：张工；甲方：李工 | 对接人 → 双方项目经理 → 双方部门负责人 |
| 模块测试报告 | 供应商测试负责人 | 甲方测试工程师 | 甲方质量负责人 | 项目经理 | 供应商：王工；甲方：赵工 | 同上 |
升级路径要写到具体岗位而非笼统的“上级”，并约定触发条件，例如对接人一个工作日内未响应、或双方对验收结论存在分歧时，升级到项目经理层面处理。对接人变更时，责任矩阵中的人员字段同步更新，并由原对接人完成在办事项的书面交接。
交付要求怎么写：输入、标准、时点与证据
一条可判断是否完成的交付要求，需要同时写清四个要素：输入前提、完成标准、时间节点、交付证据。缺少任何一个，验收时都可能产生解释空间。
- 输入前提：完成该交付物需要甲方或上游提供什么，例如接口协议、测试环境、样例数据。输入未按时提供时，交付时间相应顺延，顺延规则也写入约定。
- 完成标准：交付物达到什么状态算完成，尽量用可检查的条件描述，例如“覆盖全部 12 个接口”“单元测试通过率 100%”“缺陷密度低于约定阈值”。
- 时间节点：提交时间、评审时间、修改闭环时间分别写明，避免只写一个笼统的截止日期。
- 交付证据：以什么形式证明交付已完成，例如提交记录、评审纪要、测试报告、演示录屏。
把模糊表述改写为可验收表述，是这一步的核心动作。改写时把形容词替换为可观察的条件，把“完成”替换为“通过什么检查”。
| 模糊表述 | 改写后的可验收表述 | 对应证据 |
|---|---|---|
| 接口文档尽快提供，内容完整 | 在开发启动前 3 个工作日提交接口文档 v1，覆盖全部对外接口的入参、出参、错误码，经甲方架构师评审通过 | 文档提交记录 + 评审通过纪要 |
| 模块质量要达到可用水平 | 模块在测试环境连续运行 72 小时无阻断级缺陷，遗留缺陷中无严重级别以上问题 | 测试报告 + 缺陷清单 |
| 配合甲方完成联调 | 联调期间供应商指定一名工程师在工作日 4 小时内响应联调问题，问题关闭率在联调结束前达到 100% | 问题跟踪记录 |
验收标准与证据形式要一一对应：写“评审通过”就要约定评审纪要为证据，写“性能达标”就要约定测试报告和测试环境说明为证据。证据形式在约定阶段确定，验收时按约定收集，避免事后补材料。
角色分工与各阶段交付物
任务级责任解决“谁做哪份产物”，阶段级角色解决“在合作的每个阶段，双方各自承担什么动作、产出什么确认结果”。两个层面配合使用，责任链条才完整。
| 阶段 | 甲方角色与动作 | 供应商角色与动作 | 阶段交付物 |
|---|---|---|---|
| 启动 | 提供需求背景、输入资料和环境准备计划；确认对接人与升级路径 | 确认理解需求，提交工作分解与责任矩阵初稿 | 责任矩阵、交付清单、沟通机制确认记录 |
| 执行 | 按约定提供输入，跟踪里程碑进展，处理依赖阻塞 | 按交付要求产出交付物，主动通报风险 | 阶段性交付物、进展报告、风险清单 |
| 评审 | 组织评审，给出通过或不通过的明确结论和修改意见 | 提交评审材料，按意见修改并复评 | 评审纪要、修改记录、复评结论 |
| 验收 | 按验收标准核对交付证据，出具验收结论 | 提交完整交付包与证据材料，配合问题闭环 | 验收报告、遗留问题清单及处理计划 |
每个阶段的确认动作要有明确的责任人签字或书面确认，口头确认不作为阶段完成的依据。人员调整时，交接内容包括：在办交付物的当前状态、未闭环的评审意见、待处理的异常事项、相关文档的访问权限。交接完成后由双方项目经理确认，责任矩阵同步更新。
变更、评审与异常如何处理
静态约定无法覆盖合作过程中的所有情况，变更、评审不通过和交付异常需要预先写好处理路径，否则每次都要临时协商，既拖时间也容易产生分歧。
变更处理：变更由提出方填写变更说明，写明变更内容、原因和期望时间；由双方对接人评估对交付物、时间节点和验收标准的影响；影响评估结论由双方项目经理确认后生效，确认后的变更同步更新责任矩阵和交付清单。未经确认的变更不进入执行，避免口头调整造成范围蔓延。
评审不通过：评审结论分为通过、有条件通过、不通过三类。不通过时，评审方在评审纪要中列出具体问题和修改要求，供应商在约定时限内完成修改并提交复评；复评仍不通过时，升级到双方项目经理协商处理方案，必要时调整时间节点并记录调整原因。
交付异常：交付延期或质量异常时，责任方在发现当日通报对方对接人和项目经理，说明异常情况、影响范围和初步处置计划；双方在约定时限内确认处置方案，包括补救措施、时间调整和责任认定。异常处理记录作为后续复盘和验收的参考材料。
- 变更提出、评估、确认各环节指定责任人，评估结论书面留痕。
- 评审意见逐条编号，修改与复评对应到具体条目。
- 异常通报设定时限，处置方案明确责任方和完成时间。
- 所有变更和异常记录归档，作为验收和复盘的依据。
示例：一个研发外包模块的责任与交付约定
以下为演示情景：甲方将某业务系统的用户权限模块委托供应商开发，合作周期 8 周，双方各指定一名项目经理和若干工程师参与。
交付物拆分：接口设计说明、权限模块代码与单元测试、模块测试报告、部署说明文档、上线支持记录，共五项。每项继续拆到可独立提交评审的粒度，例如接口设计说明拆为对外接口定义和内部数据结构说明两部分。
责任矩阵填写（节选）：接口设计说明主责为供应商开发负责人，配合为甲方架构师，评审为甲方技术负责人；权限模块代码主责为供应商开发负责人，配合为甲方后端工程师，评审为甲方技术负责人和测试负责人；模块测试报告主责为供应商测试负责人，评审为甲方质量负责人。每项均填写双方对接人姓名和升级路径。
交付要求填写（节选）：接口设计说明要求在开发启动前 3 个工作日提交 v1，覆盖全部对外接口的入参、出参和错误码，经甲方技术负责人评审通过，证据为文档提交记录和评审纪要；模块测试报告要求在提测后 5 个工作日内提交，覆盖全部功能点和约定性能指标，遗留缺陷无严重级别以上问题，证据为测试报告和缺陷清单。
变更与验收处理：执行第 4 周，甲方提出增加两个权限角色的需求。供应商填写变更说明，评估影响为增加约 3 人日工作量、测试报告提交时间顺延 2 个工作日，双方项目经理确认后更新交付清单和时间节点。验收阶段，甲方按验收标准逐项核对证据，测试报告中的一项性能指标未达标，供应商在 3 个工作日内优化并提交复测报告，复测通过后出具验收结论，遗留的两个低级别问题列入上线后处理计划。
启动、里程碑与验收节点的完成检查
约定写完不等于落地，需要在合作的关键节点逐项核对，确认责任和交付要求在实际执行中有效。以下清单可直接用于检查。
合作启动时：
- 责任矩阵是否覆盖全部交付物，每项是否只有一名主责。
- 每份交付物是否写清输入前提、完成标准、时间节点和交付证据。
- 双方对接人和升级路径是否确认，触发升级的条件是否写明。
- 变更、评审、异常处理规则是否双方确认并留存记录。
- 沟通节奏（例会频率、通报方式）是否确定。
里程碑节点：
- 本阶段交付物是否按约定时间提交，证据是否齐全。
- 评审意见是否逐条闭环，未闭环项是否有明确责任人和完成时间。
- 已发生的变更是否完成评估和确认，责任矩阵和交付清单是否同步更新。
- 风险清单是否更新，异常事项是否按通报路径处理。
验收与复盘阶段：
- 验收标准是否逐项核对，每项结论是否有对应证据支撑。
- 遗留问题是否形成清单，明确处理责任人和时间。
- 变更记录、异常记录、评审纪要是否完整归档。
- 复盘时核对责任矩阵的执行情况，识别悬空或重复的责任项，作为下一轮合作的改进输入。
通过标准可以统一为：每项交付物有明确主责和证据、每个变更和异常有书面记录和处置结论、每个阶段有双方确认的完成标志。三个条件同时满足，说明约定在实际执行中发挥了作用。
当合作涉及多个供应商、多个专业方向时，责任矩阵、交付清单和变更记录需要在双方共用的协作环境中承载，避免信息散落在各自的文档和邮件里。ONES 支持多角色、多专业及外部供应商参与的研发协作，需求分解、任务执行、测试反馈和变更处理可以在同一平台推进；围绕需求、基线、版本和变更建立统一管理对象，支撑变更影响分析和交付结果回溯；标准流程、评审节点和交付物模板可以沉淀为可复用资产，在后续项目中沿用。对于需求明确、交付周期固定的供应商合作，可按项目制管理里程碑和交付物，具体配置方式结合企业实际流程确认。
常见问题
供应商对接人中途换人，责任矩阵和交付清单怎么处理？
对接人变更时，责任矩阵中的人员字段要同步更新，并由原对接人完成在办事项的书面交接。交接内容至少包括：在办交付物的当前状态、未闭环的评审意见、待处理的异常事项、相关文档的访问权限。交接完成后由双方项目经理确认，更新后的责任矩阵和交付清单重新发给双方相关角色，避免后续沟通仍指向已离岗人员。
甲方输入资料延迟提供，供应商的交付时间怎么算？
在写交付要求时就要把输入前提和顺延规则一并约定。常见做法是：输入未按约定时间提供时，交付时间按实际延迟天数顺延，并由甲方对接人在交付清单中记录延迟原因和新的时间节点。顺延需要双方书面确认，避免供应商单方面推迟或甲方事后不认。如果延迟影响到里程碑，按变更流程评估后续节点是否需要调整。
评审结论写“有条件通过”时，后续怎么跟踪？
“有条件通过”意味着交付物可以进入下一环节，但遗留问题必须闭环。建议在评审纪要中逐条列出条件项，每项写明责任人和完成时间，并在下一次里程碑检查时核对闭环情况。条件项未按时闭环的，升级到双方项目经理协商处理。把条件项纳入交付清单跟踪，比留在会议纪要里更容易被遗漏。
合作周期短、交付物少的供应商项目，也要做完整的责任矩阵吗？
可以按比例简化，但主责、验收标准和交付证据三项建议保留。交付物少时，责任矩阵可以只列交付物、主责、评审和对接人四列，升级路径用一句话写明即可。简化的是表格字段和检查频次，不是责任归属本身。周期短的项目一旦出现争议，返工时间成本占比更高，基本的书面约定反而更有必要。
多个供应商同时参与一个研发项目，责任边界怎么划清？
先按交付物划清各供应商的产出范围，再标注交付物之间的依赖关系，明确哪份产物是另一方的输入前提。接口类交付物建议由甲方指定一方牵头定义、其他方评审确认，避免双方各写一套。跨供应商的依赖和联调事项，由甲方项目经理统一协调并在责任矩阵中指定协调责任人。责任矩阵、交付清单和变更记录放在双方共用的协作环境中，可以减少信息不对称。
