内外部研发团队分工，关键是把“谁负责、交付什么、交给谁、按什么标准验收”写成可核对的字段，避免只留一句笼统的职责描述。本文给出一个假设情景下的完整分工示例：甲方产品负责人、甲方研发负责人、外部供应商项目经理、外部开发与测试人员，围绕需求确认、接口联调、提测验收、上线交接四个环节，逐项填写职责边界、成果接口、交接物和验收口径，并说明每个字段的填写理由，以及换到其他项目时哪些可以照搬、哪些需要按实际调整。分工表落地后，工作项、交接状态与验收记录可以在ONES中承接。
要点总览（TL;DR）
- 分工表的核心字段是职责边界、成果接口、交接物和验收口径，四组字段缺一项，分工就容易停留在口头约定。
- 示例覆盖需求确认、接口联调、提测验收、上线交接四个环节，每个环节标注甲方与外部方的分界点，并写明返工责任归属。
- 职责边界写到动作级别，验收口径写成可判断的通过条件，交接对象写到具体角色，交接物写明名称与存放位置。
- 字段结构、环节划分和交接物要求可以照搬；角色数量、验收标准和交付节奏需要按项目实际调整，硬件场景的交接物形式另有差异。
- 分工表要随需求变更和角色调整更新版本，采购招标与合同法律条款不在本表示例范围内。
这份分工示例要解决什么问题
先交代示例的情景设定。假设甲方有一个内部研发团队，正在推进一个版本迭代，其中部分模块由外部供应商承担开发与测试。双方需要共同完成从需求确认到上线交接的全过程。这个情景是虚构的，用于演示分工表的填写方式，不代表任何真实客户案例。
参与角色及归属方如下：
| 角色 | 归属方 | 主要关注点 |
|---|---|---|
| 产品负责人 | 甲方 | 需求范围、优先级、验收口径 |
| 研发负责人 | 甲方 | 技术方案、接口约定、代码合并与上线 |
| 供应商项目经理 | 外部 | 交付计划、人员安排、进度与风险同步 |
| 外部开发人员 | 外部 | 模块开发、自测、提测 |
| 外部测试人员 | 外部 | 测试用例执行、缺陷提交与回归 |
分工表要回答四个问题：一是职责边界，即每项工作由谁做、做到哪一步；二是成果接口，即上游交给下游的输入是什么、下游产出什么；三是交接物，即每次交接留下什么可核对的材料；四是验收口径，即用什么条件判断这一环节完成。这四个问题对应表中的四组字段，缺一项，分工就容易停留在口头约定。
完整分工示例：一张表填完四个环节
下表按四个环节逐行填写。每个环节标注甲方与外部方的分界点，交接物给出命名与存放位置示例，异常与返工责任单独写明。
| 环节 | 责任角色 | 具体动作 | 产出物 | 交接对象 | 验收标准 | 分界点与返工责任 |
|---|---|---|---|---|---|---|
| 需求确认 | 甲方产品负责人（主责）；供应商项目经理（配合） | 产品负责人整理需求清单与优先级；供应商项目经理组织外部开发人员评估工作量与依赖，提出疑问 | 需求确认单，含范围、优先级、待确认问题清单 | 甲方研发负责人、供应商项目经理 | 需求清单中每条需求有明确优先级；待确认问题全部关闭或有明确答复期限 | 分界点：需求范围由甲方确认，外部方只提评估意见。返工：需求变更由甲方发起，外部方据此调整工作量，双方在确认单上更新版本号 |
| 接口联调 | 甲方研发负责人（主责接口约定）；外部开发人员（主责外部侧实现） | 甲方输出接口文档与联调环境；外部开发人员按文档实现并自测；双方在联调环境完成对接 | 接口文档（含字段、错误码、调用示例）、联调记录 | 双方开发人员，抄送双方项目经理 | 接口文档字段与实现一致；联调记录中每个接口标注通过或待修复，待修复项有责任人和期限 | 分界点：接口定义由甲方研发负责人确认，外部方按定义实现。返工：因接口定义变更导致的返工由甲方承担排期调整；因外部实现与文档不符导致的返工由外部方负责修复 |
| 提测验收 | 外部测试人员（主责提测材料）；甲方研发负责人（主责验收） | 外部测试人员执行测试用例、提交缺陷并回归；甲方研发负责人按验收标准逐项核对 | 提测说明（含测试范围、已知问题）、缺陷清单、验收记录 | 甲方研发负责人、甲方产品负责人 | 提测说明列明测试范围与已知问题；验收记录中每条验收项标注通过或不通过，不通过项有整改期限 | 分界点：提测质量由外部方负责，验收结论由甲方给出。返工：验收不通过项由外部方整改后重新提测，整改轮次记录在验收记录中 |
| 上线交接 | 甲方研发负责人（主责上线）；供应商项目经理（配合交接） | 甲方执行上线与回滚预案；外部方移交代码、配置说明与运维注意事项 | 上线清单、交接确认单（含代码版本、配置项、已知遗留问题） | 甲方运维或值班人员、供应商项目经理 | 上线清单逐项打勾；交接确认单中代码版本与配置项可追溯，遗留问题有处理计划 | 分界点：上线操作由甲方执行，外部方提供交接材料。返工：上线后因外部交付物缺失导致的问题由外部方补充；因上线操作导致的问题由甲方处理 |
交接物的命名与存放位置建议统一约定。例如需求确认单命名为“项目名_需求确认_v1.0_日期”，存放在双方可访问的项目文档目录；接口文档与联调记录放在同一目录下的“接口”子目录；提测说明与验收记录按版本号归档。命名规则和存放位置写进表头说明，避免每次交接靠口头找文件。
逐项解释：每个字段为什么这样填
职责边界写到动作级别，是因为岗位名称无法判断工作是否完成。“供应商项目经理负责协调”这样的描述，在出现延期时双方都可以解释为已协调。写成“组织外部开发人员评估工作量与依赖，提出疑问”，就有了可核对的动作和产出。动作级别不等于事无巨细，标准是能判断“做了没有、做到什么程度”。
成果接口要写清输入与输出两端。接口联调环节中，甲方的输出是接口文档与联调环境，外部方的输入是这份文档，输出是实现与联调记录。只写“双方完成联调”，无法定位问题出在文档不清还是实现不符。把两端写出来，返工时才能按字段判断责任。
验收口径写成可判断的通过条件。“质量达标”“基本可用”这类描述无法在验收时形成一致结论。示例中写成“每条验收项标注通过或不通过，不通过项有整改期限”，验收人只需逐项核对，减少反复沟通。条件可以简单，但要能得出通过或不通过的结论。
交接对象写到具体角色，是因为部门名称无法指向具体的人。写“交给甲方研发部”，实际执行时可能无人认领；写“交给甲方研发负责人”，责任就落到角色上。角色在项目启动时对应到人，人员变动时更新对应关系即可。
返工责任与升级路径要提前写。示例中按“定义变更”和“实现不符”区分返工责任，并写明由谁承担排期调整或修复。升级路径可以写成：环节内问题由双方直接责任人协商，超过约定期限未关闭的，提交双方项目经理，仍无法解决的提交甲方产品负责人与供应商负责人。路径写清楚，争议时按顺序走，避免临时找人。
换到你的项目：哪些能照搬，哪些要改
可以照搬的部分包括字段结构、环节划分和交接物要求。四个环节——需求确认、接口联调、提测验收、上线交接——覆盖了大多数内外部共同交付的版本迭代。四组字段——职责边界、成果接口、交接物、验收口径——换到其他项目仍然适用。交接物要求“有名称、有存放位置、有版本”，这条规则不随项目变化。
需要按实际调整的部分包括角色数量、验收标准和交付节奏。角色方面，如果甲方没有独立测试角色，提测验收环节的验收动作可以并入甲方研发负责人；如果外部方只派一名接口人，供应商项目经理与外部开发人员的职责可以合并，但动作仍要分开写。验收标准方面，涉及性能或安全的项目，需要在验收条件中增加对应的检查项和判定方法。交付节奏方面，迭代周期短的团队可以把四个环节压缩到更短的时间窗内，但每个环节的交接物不能省略。
硬件与软件合作场景存在差异。硬件项目中，接口联调可能对应结构件与电子件的配合，交接物包括图纸版本、物料清单和样机测试记录；验收标准需要写明测试环境与测试方法。软件项目的接口文档和联调记录，在硬件场景中对应为版本受控的图纸与测试报告。字段结构不变，交接物的具体形式按行业惯例调整。
外部团队只承担测试时，分工表可以简化为三个环节：需求确认、提测验收、上线交接。外部测试人员的职责集中在提测说明、缺陷清单与回归记录，甲方研发负责人保留验收结论。外部团队只承担部分模块时，接口联调环节需要增加模块边界说明，明确哪些接口由外部方实现、哪些由甲方实现，避免边界处的接口无人负责。
适用边界与常见填写误区
这份示例聚焦外部工作协同中的职责与交接，不覆盖采购招标流程，也不涉及合同法律条款与商务谈判。这些内容由采购与法务环节处理，分工表只承接已经确定的合作范围。关联项目计划的整体排期管理属于项目集管理的范畴，不在本表示例范围内；分工表关注单个版本迭代内的交接，跨项目的资源与优先级协调另行处理。
常见误区有三个。第一，只写岗位不写动作，导致职责无法核对，出现问题时双方各执一词。第二，验收标准写成主观描述，验收时无法形成一致结论，反复沟通消耗时间。第三，交接物没有存放位置，文件散落在聊天记录和邮件中，交接时找不到对应版本。这三个问题都可以通过本文示例中的字段写法规避：动作写到可判断，验收写成通过条件，交接物写明名称与位置。
分工表需要随协作阶段更新。需求变更、角色调整、验收标准补充时，更新对应字段并保留版本号，避免用旧版本对照新情况。一次填完就固定不变的表，往往在第二个迭代就与实际脱节。把更新动作纳入每个环节的交接确认中，分工表才能持续可用。在ONES中，这些分工字段可以落到工作项的责任人、状态与验收记录上，交接物作为文档关联到对应工作项，版本更新留痕，便于双方按同一份记录核对进度与验收结果。
常见问题
甲方和外部供应商的职责边界，写到什么颗粒度才够用？
写到能判断“做了没有、做到什么程度”即可。岗位名称加一句笼统描述，在出现延期或质量问题时双方都能解释为已履职；换成具体动作加产出物，核对时就有依据。例如把“供应商项目经理负责协调”改成“组织外部开发人员评估工作量与依赖，提出疑问”，配合需求确认单这一产出物，是否完成一目了然。颗粒度不必细到每一步操作，标准是每个动作都能对应一个可检查的结果。
外部团队只承担测试，分工表要怎么简化？
可以压缩为三个环节：需求确认、提测验收、上线交接，接口联调环节按实际是否涉及外部实现决定保留与否。外部测试人员的职责集中在提测说明、缺陷清单与回归记录，验收结论仍由甲方研发负责人给出。简化的是环节数量和角色数量，四组字段不能省：谁提测、提测材料包含什么、甲方按什么条件判定通过、不通过项由谁在什么期限内整改，这些仍要逐项写清。
接口联调出现返工，责任怎么在表里提前约定？
按原因区分，不按环节笼统归属。示例中的写法是：因接口定义变更导致的返工，由甲方承担排期调整；因外部实现与接口文档不符导致的返工，由外部方负责修复。这样约定的前提是接口文档本身写清字段、错误码和调用示例，并有版本记录，否则无法判断是实现不符还是文档变更。联调记录中每个接口标注通过或待修复，待修复项写明责任人和期限，返工时直接对照记录。
分工表填完一次，后续迭代还要维护吗？
需要维护。需求变更、角色调整、验收标准补充时，更新对应字段并保留版本号，避免用旧版本对照新情况。可以把更新动作纳入每个环节的交接确认：交接双方确认当前版本号，变更内容记录在确认单上。一次填完就固定不变的表，通常在第二个迭代就与实际脱节，反而增加核对成本。
硬件合作项目套用这份示例，交接物要改哪些？
字段结构不变，交接物的具体形式按行业惯例替换。软件场景中的接口文档与联调记录，在硬件项目中对应版本受控的图纸、物料清单和样机测试记录；验收标准需要写明测试环境与测试方法，因为硬件问题的复现条件比软件更依赖环境描述。需求确认、提测验收、上线交接的环节划分仍然适用，只是上线交接对应为量产或交付前的确认。
