角色协作约定要解决的是跨角色交接时“谁在什么环节、拿什么输入、产出什么、交给谁、怎样算完成”的问题。把这几项写成可执行、可评审、可修订的条目，约定才能真正落地。本文给出约定的字段结构、制定步骤、角色分工、填写示例和完成检查清单，帮助团队从场景梳理走到定稿生效。
要点总览（TL;DR）
- 角色协作约定按“场景、角色、输入、动作、输出、交接对象、完成标志、负责人”八个字段逐条填写，每条只描述一个跨角色交接动作。
- 制定按五步推进：圈定高频场景与参与角色、识别交接点与易错边界、逐条填写并组织确认、确定生效方式与存放位置、用一次真实协作走查验证后定稿。
- 制定过程需要发起者、各角色代表、约定维护人、评审批准角色和使用者分工协作，小团队可兼任但职责要分开写明。
- 约定定稿前从负责人与完成标志、输入输出具体程度、与现有流程的冲突、复盘与变更方式、新成员可理解性五个方面检查。
- 约定发布后设定复盘周期和修订触发条件，场景变化较大时重新走一遍梳理与确认流程，避免在原文档上零散追加。
一份可执行的角色协作约定包含哪些内容
角色协作约定的基本单位是“一条交接条目”，每条只描述一个跨角色交接动作。条目写完后，参与双方应当能据此判断：自己什么时候开始做、需要拿到什么、做完交给谁。字段结构建议如下。
| 字段 | 含义 | 填写要求 |
|---|---|---|
| 场景 | 这条约定适用的协作情境 | 写清触发条件，如“需求评审通过后”“版本提测前”，避免写成“日常协作” |
| 角色 | 参与该交接的双方或多方角色 | 用团队内通用的角色名称，写清哪一方发起、哪一方接收 |
| 输入 | 发起方开始动作前必须具备的材料或信息 | 具体到可观察的对象，如“已确认的需求说明”“接口字段清单” |
| 动作 | 发起方在该环节要完成的工作 | 用动词开头，说明做到什么程度，避免“跟进”“支持”这类无法判断完成与否的表述 |
| 输出 | 动作完成后形成的交付物 | 写明交付物的名称和形态，如“评审记录”“测试用例集” |
| 交接对象 | 输出交给谁、以什么方式交付 | 写明接收角色和交付渠道，如“提交至需求文档并通知开发负责人” |
| 完成标志 | 判定该环节结束的客观依据 | 用可核验的状态描述，如“接收方确认无异议”“评审结论已记录” |
| 负责人 | 对该条目执行情况负责的人 | 每条约定指定一名负责人，负责解释条目、处理偏离和发起修订 |
这些字段之间存在对应关系：输入决定动作能否开始，动作决定输出是否成立，输出和交接对象决定下一环节能否接续，完成标志则把“做完了”变成双方都能确认的状态。缺少任何一个字段，条目就容易退化成一句职责口号，执行时仍需反复口头确认。
角色协作约定与岗位说明书、任务分配承担不同职能。岗位说明书描述一个角色的长期职责范围；任务分配确定某件具体工作由谁负责、何时完成；协作约定聚焦跨角色交接处的条件与标准，说明两个角色之间如何衔接。它不替代单任务的责任安排，也不规定人员技能如何配置，只把交接环节写清楚。
制定步骤：从场景梳理到约定生效
制定过程建议按五步推进，每一步都有明确的输入、动作和产出，完成标志是下一步可以开始的条件。
第一步：列出高频协作场景与参与角色
输入是团队近期的协作记录、项目复盘中的摩擦点和各角色的日常工作清单。动作是召集相关角色，列出反复出现且容易产生等待或返工的协作场景，标注每个场景涉及的角色，据此确定本次约定的范围。产出是一份场景清单和范围说明。完成标志是参与角色对“这次约定覆盖哪些场景、不覆盖哪些场景”达成一致。范围宜小不宜大，先覆盖两三个高频场景，比一次性写完整套协作规范更容易执行。
第二步：识别交接点与易出错的边界
输入是第一步的场景清单。动作是逐个场景拆解工作流，标出角色之间的交接点，并记录历史上出过问题的边界，例如输入不完整就开工、输出标准不一致、交接后无人确认。产出是待约定条目清单，每条对应一个交接点。完成标志是清单中的每个交接点都能指出具体的发起方和接收方。
第三步：逐条填写字段并组织确认
输入是待约定条目清单。动作是按字段表逐条填写，为每条指定负责人，然后组织相关角色逐条过一遍，重点确认输入是否可得、完成标志是否可判断、交接方式是否可行。产出是填写完成的约定草案。完成标志是相关角色代表对草案中的每条约定表示认可，或有明确的修改意见记录在案。
第四步：约定生效方式与存放位置
输入是确认后的草案。动作是确定约定的发布方式、存放位置和引用方式，例如放入团队文档库的固定目录、在项目启动时引用、在新成员入职时告知。同时写明生效日期和适用范围。产出是已发布、可检索的协作约定文档。完成标志是相关角色知道去哪里查、在什么场景下引用这份约定。约定条目需要长期存放、被工作项引用并保留变更记录时，可以借助文档与工作项管理工具承载，把条目与对应的项目、任务关联起来，具体能力按团队实际使用的工具版本确认。
第五步：用一次真实协作走查验证
输入是已发布的约定。动作是选取一个正在进行的真实协作场景，按约定逐条对照执行，记录哪些条目顺畅、哪些条目在实际操作中卡住或产生歧义。产出是走查记录和修订清单。完成标志是修订后的条目经过相关角色确认并更新到文档中，约定进入正式使用状态。
角色与交付物分工：谁写、谁确认、谁维护
约定如果由单人闭门编写，执行时往往无人认领。制定过程需要几类角色各司其职，每类角色都有对应的交付物。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 发起者 | 确定约定范围和推进节奏，组织场景梳理与确认会议 | 场景清单、范围说明、推进计划 |
| 各角色代表 | 提供本环节的输入输出事实，确认交接条件是否可行 | 交接点说明、对草案的确认或修改意见 |
| 约定维护人 | 汇总条目、统一格式、管理版本与变更记录 | 约定文档、版本记录、变更说明 |
| 评审与批准角色 | 检查条目是否可执行、是否与现有流程冲突 | 评审意见、批准结论 |
| 使用者 | 按约定交接，在偏离或条目失效时反馈 | 执行反馈、偏离记录 |
发起者通常由团队负责人或流程负责人担任，负责让制定过程有明确的起点和截止时间。各角色代表是约定的实际执行人，他们对交接条件的确认决定了约定能否落地，因此确认环节不能省略。维护人负责文档的持续可用，包括格式统一、版本更新和变更留痕。评审角色可以由未直接参与编写的资深成员担任，从外部视角检查条目是否存在冲突或遗漏。使用者的反馈是约定修订的主要来源，偏离发生时应当记录具体情形，而不是仅口头提醒。
角色可以兼任，例如小团队中发起者与维护人由同一人承担，但职责要分开写明，避免确认环节被跳过。
示例：一条跨角色协作约定怎么写
以下示例以“需求评审通过后，需求负责人向开发负责人交接需求”为背景，演示一条约定的完整填写。示例为演示情景，团队可根据自身流程调整。
| 字段 | 填写内容 |
|---|---|
| 场景 | 需求评审会结束并形成评审结论后 |
| 角色 | 需求负责人（发起方）、开发负责人（接收方） |
| 输入 | 评审通过的需求说明、评审会记录的修改意见、相关原型或界面说明 |
| 动作 | 需求负责人根据评审意见更新需求说明，逐条标注修改点，确认无遗留待定项 |
| 输出 | 更新后的需求说明（含修改记录） |
| 交接对象 | 提交至项目需求文档，并通知开发负责人查阅 |
| 完成标志 | 开发负责人确认需求说明无歧义，或提出待澄清问题并得到答复 |
| 负责人 | 需求负责人 |
这条示例中，输入、输出和完成标志是必须写清的部分，它们决定了交接能否被双方独立判断。动作的描述要具体到“更新并标注修改点”，而不是“完善需求”。交接方式可以按团队习惯调整，例如改为在评审会上当面确认，但完成标志仍需保留可核验的确认动作。
示例的适用边界在于：它描述的是需求评审到开发接手这一段交接，不覆盖需求提出、优先级排序和开发排期。其他场景应参照字段结构重新填写，不宜直接套用本条内容。
完成检查：约定是否可执行、可维护
约定定稿前，用以下清单逐项检查。检查项未通过时，应先修订再发布。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 负责人与完成标志 | 每条约定都有明确的负责人，完成标志可由接收方独立判断 | 存在无负责人的条目，或完成标志依赖主观感受 |
| 输入输出与交接对象 | 输入、输出和交接对象都具体到可观察的文档、记录或状态 | 条目中出现“相关资料”“及时沟通”等无法核验的表述 |
| 与现有流程的关系 | 已核对现有流程，无冲突条目，重复条目已合并 | 同一交接点存在两条相互矛盾的约定 |
| 复盘与变更方式 | 写明复盘周期、触发修订的条件和变更记录方式 | 没有约定修订入口，条目失效后无人处理 |
| 新成员可理解性 | 新成员仅凭约定即可理解交接方式，无需额外口头解释 | 条目依赖未写明的背景知识或内部简称 |
维护方面，建议在约定发布时同时确定复盘节奏，例如每个项目阶段结束时对照执行情况检查一次，或在出现两次以上同类偏离时触发修订。修订由维护人记录变更内容、原因和生效日期，并通知相关角色。约定条目与具体项目、任务关联存放时，变更记录可以随文档版本一并保留，便于追溯某条约定在特定时期的要求。
当团队规模扩大或协作场景变化时，约定需要重新走一遍场景梳理和确认流程，而不是在原文档上零散追加。保持条目数量可控、每条都能被执行人看懂，是约定长期可用的前提。
常见问题
团队刚开始制定协作约定，应该先覆盖多少场景？
建议先覆盖两三个高频且容易产生等待或返工的协作场景，把范围写清楚，明确这次约定覆盖什么、不覆盖什么。范围小、条目少，参与角色更容易逐条确认，也更容易在真实协作中走查验证。等这几条稳定运行后，再按同样的字段结构和步骤扩展到其他场景。
约定条目发布后，什么情况下需要修订？
常见触发条件有两类：一是同一交接点出现两次以上同类偏离，说明条目与实际做法不匹配；二是项目阶段结束复盘时发现条目已不适用。修订由维护人记录变更内容、原因和生效日期，并通知相关角色。如果团队规模扩大或协作场景整体变化，建议重新走一遍场景梳理和确认流程，而不是在原文档上零散追加条目。
小团队成员少，制定时还需要区分这么多角色吗？
角色可以兼任，例如发起者与维护人由同一人承担，但职责要分开写明。关键在于保留确认环节：编写条目的人不能同时跳过各角色代表的确认，否则约定容易变成单方面的要求。评审角色也可以由未直接参与编写的成员临时担任，从外部视角检查条目之间是否存在冲突或遗漏。
协作约定和岗位说明书、任务分配之间如何衔接？
三者承担不同职能：岗位说明书描述一个角色的长期职责范围，任务分配确定某件具体工作由谁负责、何时完成，协作约定聚焦两个角色交接处的条件与标准。制定时可以先引用岗位说明书中的角色名称，保证称呼一致；具体任务的负责人安排仍按任务分配流程处理，协作约定只写清交接时需要的输入、输出和完成标志。
约定条目放在哪里，才能让相关角色真正查得到、用得上？
存放位置要满足三个条件：相关角色知道去哪里查、在什么场景下引用、变更后能追溯到历史版本。常见做法是放入团队文档库的固定目录，在项目启动或新成员入职时明确告知引用方式。当条目需要与具体项目、任务关联并保留变更记录时，可以借助文档与工作项管理工具承载，具体能力按团队实际使用的工具版本确认。
