角色协作约定要解决的是团队在真实交付中“谁来做、做到哪一步、交给谁、卡住找谁”的问题。制定时先收集近期协作摩擦，再围绕关键工作项写清主责角色、职责边界、交接接口和升级路径，经评审后试运行并定期修订。本文给出五步流程、角色分工、填写示例和完成检查清单，适合需要把口头默契变成可执行规则的团队参考。
要点总览（TL;DR）
- 角色协作约定围绕关键工作项展开：先收集近期协作摩擦、返工和等待，再确定覆盖的角色与工作项范围，避免写成空泛的团队公约。
- 制定分五步：梳理工作项与角色清单、用责任矩阵标注主责/协作/知会、写清接口的输入物输出物与交接时点、约定决策与升级规则、评审发布并设定复盘周期。
- 起草由团队负责人定范围并主持评审，各角色代表提供本角色的输入输出与边界事实，维护人负责整理表格、记录变更和跟踪复盘，避免单人闭门编写。
- 约定表填写时，交接物写到可核对的粒度，交接时点写到可判断的节点；示例片段展示了需求评审到上线的连续流程与升级路径。
- 发布前用五项标准检查：关键工作有唯一主责、接口有具体交接物和时点、争议有升级路径、使用者已确认、设定了复盘与修订机制。
先定约定要解决哪些协作问题
制定协作约定的第一步是收集问题，明确这份约定要解决什么。团队可以回顾最近一个交付周期内的协作摩擦、返工和等待，把具体事件写下来，再判断它属于哪类问题。这样形成的约定针对真实场景，评审时也容易判断是否有效。
建议从三个来源收集素材：一是近期出现返工的任务，记录返工原因和涉及角色；二是出现明显等待的交接环节，记录等待时长和卡点；三是团队内反复讨论却没有结论的分歧，记录争议点和各方立场。每个事件写成一条问题记录，注明发生时间、涉及角色和造成的后果。
收集到的问题按三类归并，便于后续分别设计规则：
| 问题类型 | 典型表现 | 约定中对应的内容 |
|---|---|---|
| 职责边界 | 同一件事多人做或无人做；角色之间对“做到什么程度算完成”理解不一致 | 责任矩阵中的主责、协作、知会标注 |
| 交接接口 | 上游交付物不完整导致下游等待；交接时点不明确，工作堆积在某个环节 | 接口说明中的输入物、输出物和交接时点 |
| 决策权限 | 分歧无人拍板；小问题层层上报；决策后执行口径不一致 | 决策与升级规则 |
问题清单整理完成后，确定约定的覆盖范围。角色范围写明这份约定约束哪些角色，包括直接交付角色和需要参与评审、知会的支持角色；工作项范围写明覆盖哪些关键工作项，通常选取对交付结果影响大、跨角色交接多的环节。范围之外的协作问题可以记录在案，留待后续版本处理，避免第一版约定铺得过大而难以执行。
本节交付物是一份协作问题清单，每条问题标注类型、涉及角色和期望的解决方向。这份清单是后续步骤的输入，也是评审时判断约定是否回应了真实问题的依据。
核心答案与操作步骤：五步形成角色协作约定
五步流程的核心逻辑是：先明确工作和角色，再逐项标注责任，然后写清交接和决策规则，最后评审发布并建立复盘机制。每一步都有明确的输入、动作、输出和完成标志，团队可以按顺序推进，也可以根据规模合并部分步骤。
第一步：梳理工作项与角色清单
输入是上一节的协作问题清单和团队当前的实际交付流程。动作是把选定范围内的关键工作项逐条列出，按交付顺序排列，同时列出参与这些工作的全部角色。工作项写到可以判断“完成”的粒度，例如“需求评审”“接口设计”“测试验收”，避免写成“研发”“测试”这类笼统阶段。角色清单写明角色名称和当前承担该角色的人员，一个人员承担多个角色时分别标注。
输出是一份工作项清单和一份角色清单。完成标志是：团队对工作项的数量和顺序没有异议，每个工作项都能对应到至少一个角色。
第二步：用责任矩阵标注每项工作的主责、协作与知会角色
输入是第一步的工作项清单和角色清单。动作是建立一张矩阵表，行是工作项，列是角色，每个交叉格标注该角色在这项工作中的身份：主责、协作或知会。主责角色对结果负责，每项工作只设一个主责；协作角色提供输入或参与执行；知会角色接收结果信息但不参与执行。
标注时重点处理两类情况：一是同一工作项出现多个主责，需要拆分工作项或明确其中一人对最终结果负责；二是某项工作没有主责，需要补充角色或调整范围。输出是完成标注的责任矩阵。完成标志是每项工作都有且只有一个主责角色，协作和知会角色标注完整。
第三步：写清角色间接口，包括输入物、输出物和交接时点
输入是责任矩阵。动作是沿着工作项的交付顺序，逐对检查相邻角色之间的交接，为每个交接点写明三件事：上游提供什么输入物、下游产出什么输出物、交接在什么时点完成。交接物写到可核验的粒度，例如“需求评审纪要，含结论和待办项”，时点写到可判断的节点，例如“评审会结束后一个工作日内”。
接口说明可以与责任矩阵放在同一份文档中，也可以单独成表。输出是接口说明表。完成标志是每个跨角色交接都有对应的接口条目，且上下游角色对交接物和时点的理解一致。
第四步：约定决策与升级规则
输入是问题清单中归为决策权限类的条目，以及责任矩阵中的主责标注。动作是逐类写明：哪些事项由主责角色直接决定，哪些事项需要相关角色共同评审，出现分歧时由谁拍板，什么情况下升级、升级到哪一层、升级后多久给出结论。规则要具体到角色和情形，例如“接口设计分歧由技术负责人拍板；影响交付时间的变更升级到项目负责人，两个工作日内答复”。
输出是决策与升级规则条目。完成标志是问题清单中的决策类问题都有对应规则，且每条规则都能指出拍板角色和升级路径。
第五步：评审发布并设定复盘周期
输入是前四步形成的责任矩阵、接口说明和决策规则。动作是组织评审会，由团队负责人主持，各角色代表逐项确认与自己相关的内容，争议当场记录并明确处理方式。评审通过后发布约定，同时确定试运行期限和复盘周期，例如试运行一个交付周期后复盘一次，之后按季度或按项目节点复盘。
输出是发布版的角色协作约定表和评审记录。完成标志是约定已发布、使用者已确认，复盘时间和负责人已明确。
角色及交付物：谁负责起草、评审和维护
协作约定由多人分工完成，单人闭门编写容易遗漏实际交接中的细节，也难以获得使用者认可。制定过程中涉及四类角色，各自承担不同的输入和产出。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 团队负责人 | 确定约定覆盖的角色和工作项范围，主持评审会，对争议事项拍板 | 范围确认结论、评审决议 |
| 各角色代表 | 提供本角色的实际输入输出、职责边界和交接痛点，核对矩阵中与自己相关的标注 | 角色事实说明、核对意见 |
| 协作约定维护人 | 整理问题清单和矩阵表格，记录评审意见与变更，跟踪复盘待办 | 约定文档、变更记录、复盘记录 |
| 约定使用者 | 在真实任务中按约定执行，反馈执行中的冲突和遗漏 | 执行反馈、修订建议 |
维护人通常由团队内熟悉交付流程的成员兼任，职责是保持约定文档与实际执行一致，而不是代替各角色做判断。评审时，每个角色代表需要明确表态是否认可与自己相关的条目，认可方式可以是会上确认并记入评审记录，也可以是会后书面回复。使用者确认的重点是：约定中的交接物和时点在自己日常工作中可以做到，升级路径在需要时能找到对应的人。
约定发布后，维护人负责收集执行反馈，把冲突和遗漏记录为待修订项，在复盘会上逐条处理。变更同样需要相关角色确认，避免约定在无人知晓的情况下被改动。这套分工让约定从一次性文档变成持续维护的协作依据。
示例：一个需求交付团队的协作约定片段
以下片段取自一个需求交付团队从需求评审到上线的连续流程，用于示范约定表的填写方式。团队角色包括产品负责人、开发负责人、测试负责人和项目负责人，实际使用时按本团队角色名称替换。
| 工作项 | 主责 | 协作 | 知会 | 输入物 | 输出物 | 交接时点 |
|---|---|---|---|---|---|---|
| 需求评审 | 产品负责人 | 开发负责人、测试负责人 | 项目负责人 | 需求说明文档 | 评审纪要，含结论和待办项 | 评审会后一个工作日内发出 |
| 接口设计 | 开发负责人 | 测试负责人 | 产品负责人 | 评审通过的需求说明 | 接口设计说明 | 开发启动前完成，测试负责人确认可测性 |
| 测试验收 | 测试负责人 | 开发负责人 | 产品负责人、项目负责人 | 可测试的构建版本、接口设计说明 | 测试报告，含遗留问题清单 | 提测后两个工作日内给出首轮结论 |
| 上线发布 | 开发负责人 | 测试负责人 | 产品负责人、项目负责人 | 测试报告、发布清单 | 发布记录与回滚方案 | 发布前一个工作日完成发布清单确认 |
对应的升级路径示例：接口设计阶段开发负责人与测试负责人对可测性判断不一致时，由开发负责人在一个工作日内组织两人对齐；仍无法达成一致，升级到项目负责人拍板，项目负责人两个工作日内给出结论并记入评审记录。需求范围变更影响上线时间时，由产品负责人提出，升级到项目负责人确认，确认结果同步给全部知会角色。
填写这份片段时注意两点：交接物写到可以核对的粒度，例如“评审纪要，含结论和待办项”，而不是“评审结果”；交接时点写到可以判断的节点，例如“评审会后一个工作日内”，而不是“尽快”。这两点决定了约定在执行中能否被检验。
完成检查：约定是否可执行
约定发布前，用以下清单逐项检查。每项都通过，才说明约定达到了可执行状态；有未通过项，回到对应步骤补充后再评审。
| 检查项 | 通过标准 |
|---|---|
| 关键工作有明确主责 | 范围内每项关键工作都有且只有一个主责角色，没有主责空缺或多人主责 |
| 接口有具体交接物和时点 | 每个跨角色交接都写明输入物、输出物和可判断的交接时点 |
| 争议有升级路径 | 决策类问题都能指出拍板角色、升级条件和答复时限 |
| 约定已评审并被使用者确认 | 评审记录完整，各角色代表对与自己相关的条目明确表态认可 |
| 设定了复盘与修订机制 | 明确了试运行期限、复盘周期、维护人和变更确认方式 |
检查通过后，约定进入试运行。试运行期间，维护人记录执行中出现的冲突和遗漏，复盘会上逐条判断是约定本身需要修订，还是执行偏差需要纠正。修订后的版本重新经过相关角色确认，并更新变更记录。
协作约定的日常维护需要让文档、工作项和评审记录保持对应。在ONES中，团队可以把约定文档与具体工作项关联，交接物作为工作项的交付内容记录，评审意见和变更留存在文档版本中，复盘时按工作项回溯执行情况。这样约定不只是一份静态文档，而是随任务推进持续被引用和修订的协作依据。
常见问题
团队规模较小、角色由一人兼任时，协作约定还需要写吗？
需要，但可以简化。人员兼任多个角色时，约定重点从“谁交给谁”转向“同一人在不同角色间切换时，哪些交接物和判断节点不能省略”。例如一人同时承担产品负责人和项目负责人，需求评审的结论仍需形成纪要并同步给开发、测试，升级路径可以缩短层级，但拍板角色要写清楚。工作项和角色清单可以合并，责任矩阵中同一人出现在多列时，注明其在每项工作中的身份，避免自己与自己交接时遗漏确认环节。
约定试运行期间出现约定里没写到的情况，应该怎么处理？
先按现有规则中最近似的条目处理，同时由维护人把该情况记录为待修订项，注明发生场景、涉及角色和临时处理方式。复盘会上逐条判断：属于约定遗漏的，补充对应条目；属于执行偏差的，明确纠正方式并同步给相关角色。试运行期的临时处理方式如果反复出现，说明它已经具备写入约定的价值，应在下一版中固化。修订后的条目同样需要相关角色确认，并更新变更记录。
协作约定和岗位职责说明书有什么区别，能否互相替代？
两者作用不同。岗位职责说明书描述一个岗位长期承担的职责范围，相对稳定；协作约定针对具体工作项，写清每项工作的主责、协作、知会角色以及交接物、交接时点和升级路径，随交付流程调整而修订。岗位职责说明书无法回答“需求评审纪要由谁在什么时点发出”这类问题，协作约定也无法替代岗位的任职要求。实践中可以让协作约定引用岗位名称，但接口和时点仍需在约定中单独写清。
约定发布后，如何让新成员快速理解并遵守？
把协作约定纳入新人交接材料，并在其参与第一个真实任务时，由维护人或带教角色对照约定逐项说明与其相关的条目，重点是本角色的输入物、输出物、交接时点和升级联系人。新人执行中出现疑问，先查约定，查不到再向维护人反馈，反馈内容记录为待修订项。这样新人既是约定的使用者，也成为发现遗漏的来源。约定版本更新后，向全体使用者同步变更点，避免按旧版本执行。
跨团队协作时，一份角色协作约定应该由哪个团队牵头制定？
由对交付结果负主要责任的一方牵头，通常是与最终交付物直接相关的团队负责人。牵头方确定约定覆盖的跨团队工作项和接口范围，主持联合评审，各参与团队派角色代表提供本团队的输入输出和边界事实。争议事项由牵头方负责人与参与方负责人共同确认拍板方式，写入升级规则。约定发布后，各团队各自指定维护联系人，变更需经双方确认，避免一方单独修改导致执行口径不一致。
