角色协作约定把“谁负责、谁配合、谁拍板、何时交接、交付什么”写成团队共同遵守的规则，用来减少职责重叠、交接遗漏和临时协调。本文给出一条可执行的制定路径：梳理角色与协作场景、用责任矩阵划定边界、定义交接接口，再通过评审、试运行和复盘让约定进入日常运作。适用于需要跨岗位或跨团队配合的团队；约定内容应结合自身工作流裁剪。
要点总览（TL;DR）
- 角色协作约定至少写清五类内容：角色清单与职责边界、协作场景与责任类型、角色间交接接口、决策与升级路径、生效变更与复盘方式。
- 制定路径分三步：按工作流或交付物反推角色并识别值得约定的场景，用负责、审批、配合、知会四类责任填责任矩阵，再为每个交接场景写明交接物、完成标准、时点与确认动作。
- 责任矩阵中每个场景只设一个最终负责角色，审批与配合要分开写；填完后逐列检查职责空白和多头审批，冲突按场景目标、现有职责、上级裁定的顺序消解。
- 约定发布后先选一到两个高频场景试运行一个完整工作循环，观察交接时点、退回原因和升级响应，再按季度或触发条件复盘修订。
- 定稿前用检查清单逐项核对，重点看条款能否被第三方对照执行记录判断是否遵守，出现“否”就回到对应步骤补充。
角色协作约定要写清哪几件事
一份可用的角色协作约定，读完后团队成员应当能回答：这件事归谁负责、我需要向谁交付什么、卡住时找谁决策。围绕这个标准，约定至少包含五类内容。
- 角色清单与职责边界。列出团队涉及的常设角色和临时角色，用一两句话说明每个角色管什么、不管什么。边界写到具体对象，例如“负责需求验收标准的确认”，比“负责需求质量”更容易执行。
- 协作场景与责任类型。按具体协作事项列出参与角色，并标注每个角色在该场景中的责任类型：负责、审批、配合、知会。同一个角色在不同场景中的责任类型可以不同。
- 角色间接口。对存在交接的场景，写明交接物、完成标准、交接时点和触发条件、接收方的确认动作。接口是约定中最容易被省略、也最容易在执行中出问题的部分。
- 决策与升级路径。明确哪些事项由谁拍板，意见不一致时升级到哪一级、在多长时间内给出结论。升级路径要写到具体角色，避免只写“上报领导”。
- 生效、变更与复盘方式。写明约定从何时生效、由谁批准变更、多久复盘一次、出现哪些情况触发修订。没有变更机制的约定，往往在团队调整后逐渐失效。
这五项构成约定的基本框架。规模较小的团队可以合并章节，但角色边界、责任类型和交接接口三项建议保留，它们直接决定约定能否被检查。
第一步：梳理角色与协作场景
梳理的起点是现有工作，而不是组织架构图。按职级罗列角色，容易得到一份岗位说明书；按工作流或交付物反推，才能找到真正需要约定的协作关系。
从交付物反推角色
选取团队近期实际完成的几项工作，沿着从输入到交付的过程，记录每一步由谁完成、产出什么、交给谁。把反复出现的动作归并，就能得到角色清单。这样识别出的角色与实际工作对应，也便于发现“名义上有人管、实际无人承接”的环节。
区分常设角色与临时角色
常设角色在多个场景中稳定出现，例如产品负责人、开发负责人、测试负责人；临时角色只在特定阶段或特定项目中存在，例如某次上线协调人、外部供应商对接人。临时角色同样需要写进约定，并注明其存续时间和退出方式，否则项目结束后容易出现职责悬空。
识别值得约定的协作场景
不必为所有协作写规则，优先选择三类场景：发生频率高的日常交接；历史上反复出现分歧或返工的事项；涉及两个以上团队、靠口头协调维持的环节。场景描述写到具体动作和对象，例如“版本发布前，开发负责人向测试负责人提交可测试的构建包”，避免写成“研发与测试配合”。
梳理完成后输出一张角色—协作场景对照表，作为后续填写责任矩阵的输入。
| 协作场景 | 涉及角色 | 触发时点 | 主要交接物 | 备注 |
|---|---|---|---|---|
| 需求进入开发前 | 产品负责人、开发负责人、测试负责人 | 需求评审通过后 | 需求说明与验收标准 | 高频场景 |
| 版本发布 | 开发负责人、测试负责人、发布协调人 | 测试通过后 | 构建包与测试报告 | 跨团队 |
| 线上问题处理 | 值班人、开发负责人、产品负责人 | 问题确认后 | 问题记录与处理结论 | 易扯皮 |
第二步：用责任矩阵划定职责边界
责任矩阵把角色—场景对照表转成可检查的职责分配。常用做法是为每个场景标注四类责任：负责、审批、配合、知会。四类责任的含义需要在约定中统一定义，避免各角色理解不一。
| 责任类型 | 含义 | 使用规则 |
|---|---|---|
| 负责 | 组织完成该场景的工作，对结果承担责任 | 每个场景只设一个最终负责角色 |
| 审批 | 对关键结论或交付物作出同意、退回的决定 | 明确审批对象和时限，避免多头审批 |
| 配合 | 按要求提供输入、参与评审或协助处理 | 写明配合内容和响应时限 |
| 知会 | 接收结果信息，不参与决策 | 控制范围，避免无关角色被拉入流程 |
每个场景只设一个最终负责角色
最终负责角色是场景结果的第一责任人，负责组织推进、协调分歧并在无法解决时发起升级。设置两个“共同负责”，在顺利时看不出问题，出现延误时容易互相等待。需要多人参与时，用配合角色承接具体工作，责任仍归最终负责角色。
区分审批与配合
审批角色对特定结论行使决定权，例如验收标准变更、发布放行；配合角色提供输入或执行动作，不承担放行决定。把两者混在一起，会出现“参与讨论的人被默认为同意放行”的情况。约定中应写明审批的具体对象，例如“审批发布申请”，而不是笼统的“审批发布”。
识别职责空白与重叠
填完矩阵后逐列检查：某个场景是否没有任何角色被标为负责，这是空白；某个场景是否出现多个审批角色且未说明先后，这是重叠。空白通常出现在跨团队交界处，重叠多发生在质量把关和变更确认环节。发现后当场明确归属，无法当场决定的列入评审议题。
矩阵评审与冲突消解
矩阵初稿由各角色共同评审，重点确认三件事：被标为负责的角色是否具备相应权限和资源；审批环节是否必要且数量可控；配合角色的工作量是否被低估。冲突消解按“先看场景目标、再看现有职责、最后由上级角色裁定”的顺序进行，裁定结果回写矩阵并注明生效时间。
第三步：定义角色间的交接接口
责任矩阵回答“谁负责”，接口说明回答“怎么交”。对每个存在交接的场景，至少写明五项内容，形成角色接口说明表。
- 交接物与完成标准。写清交付的具体对象及其合格条件，例如“构建包及对应版本的测试报告，测试报告需包含通过项与遗留问题清单”。完成标准要能被接收方直接判断，避免使用“基本完成”“大致可用”这类表述。
- 交接时点与触发条件。说明是定时交接还是事件触发，例如“测试通过当日提交发布申请”。触发条件写明由谁判断、依据什么判断。
- 接收方确认动作。接收方需要在约定时限内确认接收或退回，并说明退回原因。确认动作是交接完成的标志，没有确认的交接视为未完成。
- 信息不全或延迟时的处理。约定缺项时的补交时限、延迟时的通知对象和替代安排。例如“交接物缺少必要信息时，接收方当日退回并说明缺项，交付方在一个工作日内补齐”。
- 接口变更的记录方式。交接物、时点或标准发生变化时，由谁提出、谁确认、记录在哪里。变更记录保留版本，便于复盘时追溯。
接口字段不宜过多，以接收方能够判断“能否开始下一步工作”为准。字段过多会增加填写负担，反而导致约定被绕过。
角色分工与交付物一览
约定的制定和运行涉及不同角色，下表汇总各阶段的主要职责和产出，团队可据此分配工作。角色名称按团队实际情况替换。
| 阶段 | 角色 | 主要职责 | 交付物 |
|---|---|---|---|
| 制定 | 团队负责人 | 发起约定制定，确定范围和节奏，裁定争议 | 制定计划、裁定结论 |
| 制定 | 各角色代表 | 提供本角色工作输入，参与场景梳理和矩阵填写 | 角色—场景对照表、矩阵初稿 |
| 制定 | 约定维护人 | 汇总初稿，组织评审，维护版本 | 约定文档、评审记录 |
| 制定 | 评审参与者 | 检查职责空白与重叠，确认接口可执行 | 评审意见 |
| 运行 | 各场景最终负责角色 | 按约定组织协作，发起升级 | 场景工作结果、升级记录 |
| 运行 | 约定维护人 | 接收变更申请，组织复盘，更新约定 | 变更记录、复盘纪要 |
| 运行 | 团队负责人 | 批准发布与重大变更 | 批准记录 |
评审与批准归属需要在约定中单独写明：日常条款调整可由维护人确认，涉及责任归属和审批权限的变更由团队负责人批准。明确批准层级，可以避免约定被随意修改而失去约束力。
示例：一个跨角色协作场景的约定写法
以下为演示情景，用于说明写法，不代表任何具体团队的真实案例。
场景背景与涉及角色
某产品团队每月进行一次版本发布，涉及产品负责人、开发负责人、测试负责人和发布协调人。过去的问题集中在：测试报告信息不全导致发布判断反复、发布申请提交时间不固定、线上问题出现后责任不清。
责任矩阵填写示例
| 协作场景 | 产品负责人 | 开发负责人 | 测试负责人 | 发布协调人 |
|---|---|---|---|---|
| 发布范围确认 | 负责 | 配合 | 配合 | 知会 |
| 测试通过判定 | 知会 | 配合 | 负责 | 知会 |
| 发布放行 | 审批 | 配合 | 配合 | 负责 |
| 线上问题定级 | 审批 | 负责 | 配合 | 知会 |
交接接口与完成标准
测试负责人向发布协调人交接时，交接物为测试报告和遗留问题清单；完成标准为报告包含测试范围、通过项、遗留问题及影响判断；交接时点为测试结论形成当日；发布协调人需在一个工作日内确认接收或退回。
异常情况的处理约定
测试报告缺少遗留问题影响判断时，发布协调人当日退回并列出缺项，测试负责人次日补齐。发布申请延迟超过约定时点，发布协调人通知产品负责人，由产品负责人决定顺延或调整范围。线上问题定级出现分歧时，开发负责人提出定级建议，产品负责人当日裁定。
示例可迁移的写法规律
这个示例的写法可以概括为：场景写到具体动作，矩阵保证每个场景只有一个负责角色，接口写明交接物、标准、时点和确认动作，异常处理写到具体角色和时限。换到其他场景时，按同样结构替换对象即可。
让约定落地的运行机制
约定发布只是开始，能否进入日常运作取决于四件事：评审是否充分、试运行是否观察到真实问题、人员变动时是否同步、复盘是否有固定节奏。
评审与发布
评审重点检查职责空白、重叠和接口可执行性，评审意见逐条记录处理结果。发布时说明生效日期、适用范围和与旧做法的衔接方式，例如“新约定生效后，原口头交接方式停止使用，过渡期两周内两种方式并行”。
试运行与观察点
选择一到两个高频场景先行试运行，周期建议覆盖一个完整工作循环。观察点包括：交接是否按约定时点完成、退回原因集中在哪些字段、升级是否在约定时限内得到回应。试运行期间发现的问题记录后统一修订，避免边跑边改导致版本混乱。
新成员与角色变动时的同步
新成员加入时，将约定作为入职材料的一部分，并指定一名角色代表解释其所在角色的职责和接口。角色人员更换时，由原角色与新角色完成一次交接确认，更新约定中的角色名单，避免约定仍指向已离岗人员。
定期复盘与修订触发条件
建议按季度或按项目阶段复盘一次，检查职责空白是否重新出现、接口退回率是否偏高、升级是否频繁集中在同一环节。出现组织调整、工作流变化或连续出现同类协作问题时，触发临时修订。修订保留版本记录，注明变更内容和生效时间。
与日常协作工具的衔接
约定要落到日常工作中，需要与团队使用的协作工具对应起来：角色在工具中有明确的责任人设置，交接物对应到具体的工作项或文档，交接时点对应到状态流转和截止时间，异常与升级对应到可追踪的记录。以ONES为例，团队可以在项目中按约定设置工作项类型与状态流转，把交接物作为工作项附件或关联文档留存，交接确认和升级过程留下操作记录，复盘时据此核对约定执行情况。工具承载的是约定的执行痕迹，约定本身的条款仍需团队评审确认。
完成检查：约定是否可执行
约定定稿前，用以下清单逐项核对。每项都能给出明确答案，才说明约定达到了可执行标准。
| 检查项 | 判断标准 | 核对结果 |
|---|---|---|
| 角色与场景覆盖 | 主要协作场景均已列出，常设与临时角色均有说明 | 是 / 否 |
| 唯一最终负责角色 | 每个场景只有一个负责角色，无“共同负责”表述 | 是 / 否 |
| 审批与配合区分 | 审批对象具体，配合内容与时限明确 | 是 / 否 |
| 接口完整性 | 交接物、完成标准、时点、确认动作均已写明 | 是 / 否 |
| 异常与升级路径 | 信息不全、延迟、分歧均有处理角色和时限 | 是 / 否 |
| 变更与复盘安排 | 写明变更提出与批准方式、复盘周期和修订触发条件 | 是 / 否 |
| 可检查性 | 条款能被第三方对照执行记录判断是否遵守 | 是 / 否 |
核对中出现“否”的条目，回到对应步骤补充，而不是在文档中增加原则性表述。约定通过检查后即可发布试运行，并在首个复盘周期根据执行记录修订。
常见问题
团队规模很小，角色协作约定可以简化到什么程度？
小团队可以合并章节，把角色清单、责任矩阵和接口说明压缩到一页以内，但建议保留三项核心内容：角色边界、每个场景的唯一负责角色、交接物与确认动作。这三项直接决定约定能否被检查。决策与升级路径可以简化为“分歧由团队负责人当日裁定”，复盘周期可以拉长到半年一次，但变更记录仍要保留，否则人员调整后约定容易失效。
约定试运行期间发现问题，应该立即修改还是等复盘时统一修订？
建议先记录、后统一修订。试运行期间边跑边改，容易出现不同角色执行不同版本的情况，反而增加协调成本。可以设一个固定的问题记录位置，把交接延迟、退回原因、升级未响应等情况记下来，在试运行结束的复盘会上一次性修订并发布新版本。例外情况是出现职责空白导致工作无人承接，这类问题可以当场明确临时负责人，并在复盘时正式回写矩阵。
角色人员更换后，约定需要做哪些同步动作？
至少完成三件事：原角色与新角色做一次交接确认，逐项核对本角色负责的场景和接口；更新约定中的角色名单和责任人设置；由约定维护人通知与该角色有交接关系的其他角色。如果更换的是审批角色，还要确认审批权限是否同步转移，避免出现“名单已更新、审批仍走旧人”的情况。新成员加入时，把约定作为入职材料的一部分，并指定一名角色代表解释其职责和接口。
责任矩阵里出现两个角色都认为自己该负责同一个场景，怎么处理？
先回到场景目标判断：这个场景的结果最终由谁组织推进、协调分歧并在无法解决时发起升级，谁就是最终负责角色。另一个角色通常应改为配合或审批，并在矩阵中写明其具体动作和时限。如果两个角色都有合理依据，按“先看场景目标、再看现有职责、最后由上级角色裁定”的顺序处理，裁定结果回写矩阵并注明生效时间。处理完后检查同一列是否还有其他场景存在类似重叠，避免逐个救火。
约定和日常使用的协作工具之间应该怎么对应？
对应关系落在四个地方：角色在工具中有明确的责任人设置；交接物对应到具体的工作项或关联文档；交接时点对应到状态流转和截止时间；异常与升级对应到可追踪的记录。以ONES为例，团队可以在项目中按约定设置工作项类型与状态流转，把交接物作为工作项附件或关联文档留存，交接确认和升级过程留下操作记录，复盘时据此核对执行情况。工具承载的是执行痕迹，条款本身仍需团队评审确认，工具配置也应随约定修订同步调整。
