角色协作约定要解决的是团队协作中“谁在什么环节做什么、交付什么、交给谁、什么算完成”的问题。它适合跨岗位衔接频繁、交接容易遗漏或职责边界反复争议的团队。下面按字段结构、四步起草、制定与维护分工、完整示例和完成检查展开，帮助你把约定写成可执行、可维护的规则文档。
要点总览（TL;DR）
- 角色协作约定要写清五类字段：角色清单与职责边界、输入动作输出、交接对象与时点、完成标志与评审方式、冲突与例外处理路径。
- 起草按四步推进：盘点协作链路与角色、填写职责边界与交付物、定义交接时点与确认方式、约定冲突升级与例外处理。
- 约定本身要分工：发起人定范围，主笔人写初稿，各角色代表逐条确认，评审人批准，并指定维护责任人和变更触发条件。
- 用一条近期真实任务试跑，重点检查交接时点是否可观察、确认方式是否留痕，试跑后修订一轮再发布正式版本。
一份可执行的角色协作约定包含哪些内容
角色协作约定是一份小型规则文档，核心是把协作链路上的角色、动作和交接写清楚。它不需要覆盖团队所有工作，只需覆盖当前最容易出现职责模糊和交接断点的链路。一份可执行的约定通常包含五类字段，可以直接作为文档骨架使用。
| 字段 | 要写清的内容 | 填写示例 |
|---|---|---|
| 角色清单与职责边界 | 链路上有哪些角色，每个角色负责什么、不负责什么 | 需求分析由产品经理负责，技术方案由开发负责人负责 |
| 输入、动作、输出 | 每个角色接收什么材料，执行什么动作，产出什么交付物 | 开发接收已确认的需求说明，产出技术方案与排期 |
| 交接对象与交接时点 | 交付物交给谁，在什么时间点或什么状态下交接 | 技术方案评审通过后一个工作日内交给测试负责人 |
| 完成标志与评审方式 | 什么条件算完成，由谁以什么方式确认 | 评审会通过并留下确认记录，视为方案完成 |
| 冲突与例外处理路径 | 职责争议、交付延误、临时变更时找谁、按什么顺序处理 | 先由双方负责人协商，未果提交项目负责人裁定 |
字段填写时有两个常见问题值得注意。职责边界只写“负责需求”这类笼统表述，执行时仍会产生争议，应写到具体动作和交付物，例如“负责整理需求说明并组织确认”。交接时点只写“及时交接”，无法判断是否延误，应写成可观察的条件，例如“评审通过后一个工作日内”或“上一环节交付物确认后”。
约定覆盖的范围也要有边界。建议一次只覆盖一条主要协作链路，例如从需求提出到上线，或从客户问题受理到修复发布。链路之外的协作可以后续补充，避免第一版约定过长而难以执行。
按四步起草：从角色盘点写到交接规则
起草过程按四步推进，每步都有明确的输入、动作、输出和完成标志。四步完成后，应得到一份可以直接试用的约定初稿。
第一步：盘点协作链路与角色
输入是现有流程说明、近期任务清单和实际参与人员名单。动作是选出一条主要协作链路，按时间顺序列出每个环节的参与角色，并标注当前交接发生在哪里、哪些交接经常出问题。输出是一张链路角色清单，包含角色名称和所处环节。完成标志是链路首尾明确，每个环节都有对应角色，没有无人承接的环节。
第二步：为每个角色填写职责边界与交付物
输入是第一步的角色清单。动作是逐个角色填写负责的动作、接收的输入、产出的交付物，以及明确不归该角色负责的事项。输出是每个角色的职责条目。完成标志是每个角色至少有一项可检查的交付物，且相邻角色的输出与输入能够对应，不出现某角色产出的材料无人接收的情况。
第三步：定义交接时点、评审与确认方式
输入是第二步的职责与交付物清单。动作是为每次交接写明触发条件、交接对象和确认方式，例如评审会、书面确认或系统状态变更。输出是交接规则表。完成标志是每次交接都能回答“什么时候交、交给谁、对方如何确认”三个问题，且确认方式不依赖口头约定。
第四步：约定冲突升级与例外处理
输入是前三步形成的初稿。动作是补充职责争议、交付延误、紧急变更等情况的处理路径，写明第一处理人、升级顺序和最终裁定人。输出是例外处理条款。完成标志是每个可能出现的争议场景都有对应路径，且路径上的角色在约定中已有定义。
四步不必严格串行，但建议按顺序完成，因为后一步依赖前一步的产出。初稿完成后进入试跑和确认环节，具体分工见下一节。
谁负责写、谁确认、谁维护
约定本身也需要角色分工，否则容易出现“写的人不执行、执行的人没参与”的情况。制定过程通常涉及四类角色，各自承担不同职责和交付物。
| 角色 | 职责 | 交付物 | 确认方式 |
|---|---|---|---|
| 发起人 | 提出制定需求，确定覆盖的协作链路和推进节奏 | 制定任务说明与时间安排 | 在启动时向参与角色说明范围 |
| 主笔人 | 完成四步起草，整理各方意见并形成初稿和修订稿 | 约定文档初稿、修订记录 | 初稿提交评审 |
| 各角色代表 | 确认本角色的职责边界、交付物和交接方式是否符合实际 | 书面确认意见或修改建议 | 逐条确认或提出异议 |
| 评审人与批准人 | 检查约定是否完整可执行，做出批准决定 | 评审意见与批准结论 | 评审通过后批准发布 |
主笔人通常由熟悉该链路日常运作的人担任，例如项目负责人或流程负责人。各角色代表应由实际承担该角色工作的人参与确认，管理者代为确认容易遗漏执行细节。评审人可以是跨链路的负责人，重点检查职责重叠、交接空白和例外路径是否完整。
约定发布后需要维护。建议明确一个维护责任人，通常由主笔人或流程负责人继续承担。变更触发条件包括：链路新增或取消环节、角色调整、交接频繁出现延误或争议、工具或系统状态发生变化。每次变更保留版本记录，写明修改内容和生效时间，并通知所有受影响角色。约定不宜频繁改动，但也不能长期不更新，建议在每次试跑或阶段性复盘后检查一次是否需要修订。
示例：一条需求从提出到上线的角色约定
以下为演示情景，用于说明约定如何落到具体交接动作，不作为真实案例引用。假设一条需求从提出到上线涉及产品经理、开发负责人、测试负责人和发布负责人四个角色。
| 环节 | 角色 | 输入 | 动作与输出 | 交接时点与确认 |
|---|---|---|---|---|
| 需求提出 | 产品经理 | 业务方需求描述 | 整理需求说明，明确范围与验收标准 | 需求说明完成后交给开发负责人，由开发负责人书面确认可进入方案设计 |
| 方案设计 | 开发负责人 | 已确认的需求说明 | 产出技术方案与排期 | 方案评审通过后一个工作日内交给测试负责人 |
| 测试准备 | 测试负责人 | 技术方案与需求说明 | 产出测试用例与测试计划 | 开发提测时确认用例已覆盖验收标准 |
| 发布上线 | 发布负责人 | 测试通过记录与发布说明 | 执行发布并记录结果 | 发布完成后通知产品经理确认上线结果 |
异常情况的处理也写进约定。例如测试发现需求说明存在歧义时，由测试负责人提交产品经理澄清，产品经理在两个工作日内给出书面答复；答复影响范围的，同步通知开发负责人调整排期。开发提测延误时，开发负责人提前告知测试负责人并说明新的提测时间，测试负责人据此调整测试计划。发布过程中出现回滚，由发布负责人记录原因并通知产品经理和开发负责人，是否重新发布由产品经理与开发负责人共同确认。
这份示例片段可以直接参照填写。实际使用时替换角色名称和交付物，保留“输入—动作—输出—交接确认”的结构即可。
落地前的完成检查
约定初稿完成后，用一份检查清单判断它是否可执行。检查以逐条核对的方式进行，每条都有明确的通过标准。
| 检查项 | 通过标准 |
|---|---|
| 每个角色是否都有明确交付物 | 每个角色至少列出一项可检查的产出，且能被下一环节使用 |
| 交接是否都有时点与确认人 | 每次交接都能回答何时交、交给谁、如何确认，确认方式可留痕 |
| 是否存在职责重叠或空白 | 同一动作只有一个主要负责角色；链路每个环节都有承接角色 |
| 例外与冲突是否有处理路径 | 职责争议、交付延误、紧急变更均有第一处理人和升级顺序 |
| 是否经过一次真实任务试跑 | 选取一条近期真实任务按约定走一遍，记录卡点并完成修订 |
试跑是检查中最关键的一步。试跑时按约定逐环节执行，记录每次交接是否按时发生、确认是否留痕、是否有角色对职责提出异议。试跑结束后集中修订一轮，再发布正式版本。试跑中发现的问题通常集中在交接时点模糊和确认方式依赖口头沟通两类，修订时优先补齐这两处。
约定发布后，角色、交付物和交接状态需要有稳定的承载位置，避免规则写在文档里、执行却散落在聊天记录中。ONES 可以在工作项和文档中记录角色分工、交付物与交接状态，让约定中的交接确认有对应的记录位置，便于试跑复盘和后续版本维护。工具承载的是约定的执行痕迹，约定本身仍需按上述步骤起草、确认和检查。
常见问题
团队规模小、角色一人多岗时，这份约定还要写吗？
要写，但可以合并角色。一人多岗时，把同一人承担的角色合并成一条，写清该人在不同环节分别交付什么、交给谁。关键保留两处：每个环节有明确承接人，每次交接有可观察的时点和确认方式。角色合并后容易出现自己交给自己、确认环节缺失的情况，试跑时重点核对这类交接是否仍有独立确认人。
约定写好后，交接仍然靠口头沟通、没有留痕，怎么处理？
先检查约定里的确认方式是否写成了“通知一下”“说一声”这类表述，改成可留痕的动作，例如书面确认、评审记录或状态变更。再把交接状态放到团队日常使用的承载位置，让每次交接有对应记录。约定发布后定期抽查几次交接，看确认记录是否完整，缺失的补进修订清单。
链路中途新增角色或环节，约定怎么更新？
把新增角色或环节当作一次变更处理：由维护责任人更新角色清单、输入输出和交接规则，写明修改内容和生效时间，通知所有受影响角色确认。新增环节要同时补齐它上游的交接对象和下游的接收确认，避免只在中间插入一个角色、两头交接悬空。更新后保留版本记录，便于回溯。
职责争议在约定里写了处理路径，实际执行时还是扯不清，问题出在哪？
常见原因是职责边界写得太笼统，例如只写“负责需求”，没有写到具体动作和交付物。另一种是处理路径上的角色在约定中没有定义，争议发生时找不到第一处理人。修订时把争议最多的两三个角色边界写到可检查的交付物层面，并核对升级路径上的每个角色都已在约定中出现。
约定覆盖多条协作链路时，是一次写完还是分批推进？
建议分批推进。第一版只覆盖一条最主要的链路，试跑通过后再补充下一条。多条链路一次写完，文档变长、确认人变多，试跑时难以定位问题，修订也更慢。分批推进时，各条链路共用同一套字段结构和检查清单，保持写法一致，后续合并成一份完整约定即可。
