外部伙伴协作要明确责任和交付要求，关键是把“谁负责、交什么、何时交、按什么标准算完成”写成可核对的责任矩阵与交付清单，并在启动前逐项确认、过程中按节点复核。本文聚焦外部工作协同，不涉及采购招标与合同法律条款，给出可直接套用的拆分方法、表格字段、变更约定与核对清单。
要点总览（TL;DR）
- 先把协作范围拆成能指派单一主责人的工作包，每个工作包写清边界、接口方和初步主责方，作为责任矩阵的行来源。
- 用 RACI 责任矩阵标注每项工作的主责执行、最终审批、事前咨询与事后知会，内部角色与伙伴方角色同表呈现，每个工作包只设一个最终审批人。
- 交付要求逐条写成可验收条目，包含内容范围、格式与提交方式、时间节点、验收标准、验收人与返工约定，验收标准要能被客观判定。
- 启动前约定变更提出与审批方式、逾期和质量问题的升级路径、争议对接层级与处理时限，执行中按里程碑用同一份清单复核。
- 启动前核对主责唯一、标准可判定、接口人明确；验收时核对交付物与清单一致、验收记录留存，未通过项当场补齐或按返工约定处理。
先拆工作包：把协作范围切成可分配的责任单元
责任划分的第一步是拆范围。协作范围如果停留在“伙伴负责内容生产”“供应商负责系统实施”这类整块描述，就无法指派主责人，也无法验收。拆工作包的目标是得到一份清单：每个工作包边界清楚、接口方明确、能落到一个主责人身上。
拆分有两种常用切法。按交付物拆，适合结果形态清晰的合作，例如把一次联合市场活动拆成主视觉设计、活动页面、宣传文案、现场物料四个工作包。按业务环节拆，适合流程型合作，例如把供应商交付拆成需求确认、方案设计、开发实现、联调测试、上线支持。两种切法可以混用，但同一层级内尽量保持一种口径，避免清单结构混乱。
每个工作包需要标注三项信息。边界说明该工作包从哪里开始、到哪里结束，以及明确不包含什么；接口方说明它与哪些内部团队或其他工作包发生输入输出关系；初步主责方给出一个候选责任人或责任团队。拆分粒度以“能指派单一主责人”为准：如果一个工作包需要两个人共同对结果负责，通常说明它还可以继续拆。
| 工作包名称 | 边界（含不包含项） | 接口方 | 初步主责方 |
|---|---|---|---|
| 示例：产品宣传视频 | 从脚本定稿到成片交付；不含投放渠道执行 | 品牌组提供脚本，法务组审核表述 | 伙伴方视频制作负责人 |
| 示例：数据迁移脚本 | 从源数据梳理到测试环境验证通过；不含生产环境执行 | 内部运维组提供环境，业务组确认字段口径 | 供应商实施顾问 |
完成标志是这份清单能直接进入下一步：每一行都有唯一的主责候选方，接口关系没有悬空。清单本身也是后续责任矩阵的行来源，两者保持同一套工作包编号，后续变更时同步更新。
用责任矩阵写清主责、审批、协作与知会
工作包清单回答“有哪些事”，责任矩阵回答“每件事上各方是什么角色”。推荐使用 RACI 四类角色：R（主责执行）负责实际完成工作；A（最终审批）对结果负最终责任，拥有确认权；C（事前咨询）在决策或执行前提供意见；I（事后知会）在结果确定后获得通知。判定口径要统一：R 看谁动手做，A 看谁签字确认，C 看谁的输入会影响做法，I 看谁需要知道结果但不必参与过程。
内部角色与外部伙伴角色放在同一张表里标注，才能看出责任衔接。常见做法是列头写角色名称并注明所属方，例如“内部项目经理”“伙伴方交付负责人”“内部法务接口人”。这样一眼能看出某个工作包的审批权在内部还是在伙伴方，避免出现双方都以为对方在把关的情况。
| 工作包 | 内部业务负责人 | 内部项目经理 | 伙伴方对接人 | 伙伴方交付责任人 |
|---|---|---|---|---|
| 需求确认 | A | R | C | I |
| 方案设计 | C | A | R | R |
| 成果验收 | A | R | C | I |
填写时守住一条规则：每个工作包只设一个 A。A 是最终拍板的人，出现两个 A 意味着出了问题没人能定论。R 可以有多人，但要在备注里写清各自负责的部分，例如伙伴方对接人负责需求梳理、交付责任人负责方案成稿。C 和 I 的数量不宜过多，否则沟通成本会吞掉协作效率。
责任矩阵填写完成后，建议与伙伴方开一次逐行确认会，把每个工作包的 R 和 A 当面读一遍，请对方确认或提出修正。确认结果记录在矩阵的版本说明里，作为后续争议时的依据。
把交付要求写成可验收的条目
责任矩阵解决“谁负责”，交付要求清单解决“交什么、怎么算完成”。每个交付物单独一行，字段固定，填写时不留模糊表述。建议字段如下：
- 交付物名称：用名词性短语，避免“相关材料”这类笼统说法。
- 内容范围：包含哪些部分、覆盖什么范围、明确不包含什么。
- 格式与提交方式：文件格式、命名规则、提交到哪个位置、是否需要同时提供源文件。
- 交付时间与里程碑：具体日期或相对节点，例如“方案评审通过后 5 个工作日内”。
- 验收标准：可判定的条件，例如“覆盖全部 12 个功能点，每个功能点附操作截图”。
- 验收人与验收方式：谁验收、用什么方式验收（文档评审、演示、抽样测试）。
- 不合格返工约定：返工触发条件、返工时限、返工次数上限及超出后的处理方式。
验收标准是最容易写虚的字段。“质量良好”“符合要求”无法判定，应改成可观察的条件：数量、覆盖率、通过率、评审签字、演示通过等。验收方式与验收标准要匹配，标准写“功能可用”，验收方式就应安排实际操作演示，而不是只看文档。
| 交付物 | 内容范围 | 时间节点 | 验收标准 | 验收人/方式 | 返工约定 |
|---|---|---|---|---|---|
| 示例：接口联调报告 | 全部 8 个接口的联调记录与问题清单 | 开发完成后 3 个工作日内 | 8 个接口全部联调通过，遗留问题有责任人与计划时间 | 内部技术负责人，文档评审加抽测 | 未通过项 2 个工作日内返工，最多两轮 |
交付要求清单与责任矩阵使用同一套工作包编号，验收人应与矩阵中的 A 或 A 指定的代表一致。清单定稿后作为协作附件随启动会发出，双方各留一份版本记录。
约定变更、逾期与争议的处理路径
静态约定无法覆盖执行中的变化，变更与异常规则要在启动前写清，否则每次调整都要重新谈判。变更约定至少包含四项：谁可以提出变更、谁审批、变更何时生效、通知范围有多大。常见做法是伙伴方对接人或内部项目经理提出书面变更申请，说明变更内容、影响的工作包与交付物、对时间和成本的影响，由内部业务负责人审批，审批通过后更新责任矩阵与交付清单版本并通知全部 I 角色。
逾期与质量不达标需要预设升级路径。可以按对接层级逐级设定：第一级由双方对接人在约定时限内协商解决；第二级升级到双方项目负责人，明确补救方案与新的时间点；第三级由双方业务负责人决策，包括调整范围、更换资源或终止该工作包。每一级写明触发条件和处理时限，例如“逾期超过 3 个工作日自动升级至第二级”。
争议处理同样要落到人和时限。约定双方各自的争议对接人、书面提出的方式、对方回复的时限，以及超过时限未解决时的上级介入机制。争议期间不影响其他工作包正常推进，避免一个分歧拖住整个协作。
角色分工与各阶段交付物
责任矩阵按工作包展开，角色与阶段对照表则按时间线汇总，便于各方知道自己什么时候该交什么。内部通常涉及三类角色：业务负责人对结果负责并行使审批权，项目经理统筹计划、跟踪进度和处理变更，接口人负责日常对接、信息传递和材料汇总。伙伴方通常涉及对接人与交付责任人：对接人负责需求理解、进度同步和问题上报，交付责任人对交付物质量负责。
| 阶段 | 内部业务负责人 | 内部项目经理 | 内部接口人 | 伙伴方对接人 | 伙伴方交付责任人 |
|---|---|---|---|---|---|
| 启动 | 确认协作目标与验收口径 | 输出工作包清单与责任矩阵 | 整理接口人与沟通规则 | 确认责任分工与交付清单 | 确认资源与排期 |
| 执行 | 参加关键节点评审 | 跟踪里程碑、处理变更 | 汇总进度与问题清单 | 同步进度、上报风险 | 按清单提交交付物 |
| 验收 | 签署验收结论 | 组织验收、记录结果 | 归档验收材料 | 配合答疑与补充材料 | 按返工约定完成整改 |
这张表的价值在于把“谁在什么时候交什么”固定下来。启动阶段的核心产出是工作包清单、责任矩阵和交付要求清单三份文件；执行阶段的核心产出是进度记录、变更记录和阶段性交付物；验收阶段的核心产出是验收记录与遗留问题清单。每个阶段结束时对照一次，缺项当场补齐。
当协作涉及多个伙伴、多个工作包并行推进时，责任矩阵、交付清单和变更记录需要在同一处持续维护，避免版本散落在邮件和聊天记录里。ONES 可围绕需求、任务、测试与变更建立统一管理对象，支撑过程状态追踪和交付结果回溯；在涉及多角色协同的研发类合作中，也可将评审节点、交付物模板和过程数据沉淀为可复用资产，让责任与交付要求在项目执行中保持可查。
示例：一次外部内容合作的责任与交付约定
以下为演示情景，用于说明前述方法的填写结果，不代表真实案例。某内部团队与一家外部内容机构合作完成一份产品白皮书，周期六周。
工作包拆分结果为四个：选题与大纲、初稿撰写、设计与排版、终稿审核与交付。选题与大纲的接口方是内部产品团队，初稿撰写依赖大纲确认，设计与排版依赖初稿定稿，终稿审核涉及内部法务对表述的检查。
| 工作包 | 内部内容负责人 | 内部项目经理 | 伙伴方对接人 | 伙伴方撰稿人 | 伙伴方设计师 |
|---|---|---|---|---|---|
| 选题与大纲 | A | R | C | I | I |
| 初稿撰写 | C | A | R | R | I |
| 设计与排版 | C | A | R | C | R |
| 终稿审核与交付 | A | R | C | I | I |
交付要求条目示例：初稿的交付物名称为“白皮书初稿”，内容范围覆盖大纲确认的全部五章、每章不少于约定字数并附数据来源说明，格式为可编辑文档并按约定命名，交付时间为大纲确认后 10 个工作日内，验收标准为五章齐全、数据来源可追溯、无未标注的引用，验收人为内部内容负责人并以文档评审方式验收，不合格时在 3 个工作日内返工、最多两轮。设计与排版的验收标准写为“按品牌规范完成排版，输出可印刷文件与源文件，页码与目录一致”，验收方式为内部项目经理对照品牌规范逐项核对。
变更约定写明：任一方对接人可提出书面变更，内部项目经理评估影响后由内部内容负责人审批，审批通过后更新清单版本并通知双方全部相关人员。逾期超过 2 个工作日升级至双方项目负责人，超过 5 个工作日由双方业务负责人决策调整范围或更换资源。
完成检查：启动前与验收时的核对项
启动前用一套清单判断责任与交付要求是否已经明确到位，逐项打勾，未通过项当场修正后再启动。
- 每个工作包只有一个主责人，且主责人本人已知晓并确认。
- 每个工作包只有一个最终审批人，审批权限没有重叠。
- 每个交付物的验收标准可以客观判定，验收人与验收方式已写明。
- 双方接口人、升级路径上的各级对接人已明确到姓名或岗位。
- 变更提出人、审批人和生效方式已写入约定。
- 责任矩阵与交付清单使用同一版本号，双方各持一份。
验收时用另一套清单核对执行结果。
- 实际提交的交付物与清单条目一一对应，没有清单外的临时追加或遗漏。
- 每项验收结论有记录，包含验收人、验收时间、结论和依据。
- 返工项记录了触发原因、完成时间和复验结果。
- 执行期间的变更均有审批记录，清单版本与最终交付一致。
- 遗留问题已登记责任人与计划完成时间。
核对未通过时的处理动作要事先说清：启动前发现主责不唯一或标准不可判定，暂停启动，由项目经理组织双方补齐后再发出版本；验收时发现交付物与清单不一致，按变更约定补办变更或按不合格返工处理，验收记录中注明差异原因。核对清单本身随协作结束归档，作为下一次外部合作的模板起点。
常见问题
伙伴方坚持由他们的项目负责人做最终审批，与内部审批权冲突怎么办？
先区分两类审批：伙伴方项目负责人对其内部资源和排期做审批，内部业务负责人对交付结果做验收确认，两者可以并存，但要在责任矩阵里分别标注，避免同一个工作包出现两个 A。如果双方都要求对同一交付物拍板，建议在启动会上明确“结果验收以内部业务负责人为准，伙伴方内部审批作为其提交前的自检环节”，并写入矩阵备注。这样既尊重伙伴的内部管理，也让验收结论只有一个出口。
交付物在过程中被临时追加，原清单没有覆盖，应该走什么流程？
按变更约定处理，不直接口头接下。由提出方书面说明追加内容、影响的工作包与交付物、对时间和资源的影响，经约定的审批人确认后，更新责任矩阵与交付清单版本并通知相关人员。如果追加内容超出原协作范围较大，可以单独立一个工作包，指定主责人和验收人，避免混入原有条目导致验收口径不清。验收时以最新版本清单为准，历史版本留存备查。
验收标准写成了“符合品牌规范”，执行中双方理解不一致，如何补救？
把抽象标准拆成可逐项核对的条件，例如“使用指定色值与字体、页边距符合规范文件、输出可印刷文件与源文件、页码与目录一致”，并约定验收方式为对照规范文件逐项核对。补救时由验收人列出不符合项清单，双方确认后按返工约定处理，同时把这次拆解后的条件补进清单，作为后续同类交付物的模板。验收标准越具体，返工争议越少。
多个外部伙伴并行参与同一项目，责任矩阵和交付清单怎么维护才不混乱？
保持一套编号体系：工作包编号贯穿责任矩阵、交付清单和变更记录，每个伙伴只出现在与其相关的工作包行中。版本管理上指定一个维护人，通常是内部项目经理，任何变更由维护人统一更新并发布版本号，其他渠道的修改视为无效。协作涉及多个伙伴、多个工作包并行时，可以把责任矩阵、交付清单和变更记录放在同一处持续维护，减少版本散落在邮件和聊天记录里的情况。ONES 可围绕需求、任务、测试与变更建立统一管理对象，支撑过程状态追踪和交付结果回溯。
协作周期很短，只有两三周，还需要做完整的责任矩阵和交付清单吗？
可以简化，但不宜省略。短周期协作至少保留三项：每个工作包的唯一主责人与唯一审批人、每个交付物的验收标准和验收人、变更与逾期的对接人。字段可以合并，例如把内容范围与验收标准写在同一行，把升级路径简化为一级对接人和一级负责人。周期越短，返工的时间余量越小，验收标准可判定反而更重要。
