角色协作约定要把“谁在什么环节负责什么、交付什么、找谁确认”写成一份可执行的文档，让跨角色协作有据可依。本文提供一份虚构团队的完整填写示例，覆盖角色、职责边界、关键交付物、协作接口与确认升级路径，并逐项解释填写理由，方便你改成自己团队的版本。
要点总览（TL;DR）
- 角色协作约定要写清六类信息：角色清单、职责边界、关键交付物、协作接口、确认与升级路径、生效与复盘节奏。
- 示例团队为虚构的八人产品团队，按角色组织条目，每个角色包含一句话定位、做什么与不做什么、交付物时点、上下游交接方式。
- 职责边界写“不做什么”是为了把预判的越界行为提前写明；交付物写到接收方能判断“可以开始下一步”的颗粒度即可。
- 换团队套用时保留“角色—边界—交付物—接口—确认”的结构，按工作流替换环节、按团队规模调整角色颗粒度，并做三项自检。
- 流程尚未稳定、强矩阵组织或高度标准化流水线作业的情形需要改造后再用；约定应随角色和工作流变化定期修订。
这份示例要解决什么问题
角色协作约定的核心用途，是把团队里容易含糊的三件事写清楚：每个角色负责哪些工作、在什么时点交出什么成果、遇到分歧找谁拍板。它服务于日常协作，而不是替代岗位说明书或绩效考核文件。一份可用的约定，至少要覆盖角色清单、职责边界、关键交付物、协作接口、确认与升级路径、生效与复盘节奏六类信息。
本文示例设定一个虚构的八人产品团队（示例）：产品经理一名、研发工程师三名、测试工程师一名、设计师一名、运营一名、团队负责人一名。团队以两周一个迭代的方式推进一个面向内部用户的工具产品。所有角色、人名、交付物均为演示情景，不代表任何真实组织，也不是客户案例。
填写前需要先准备三类输入，否则约定容易写成空话：
- 团队目标：当前阶段团队要达成什么，例如“本季度把核心流程的可用性稳定下来”。目标决定哪些角色需要重点写清边界。
- 主要工作流：从需求提出到上线运营经过哪些环节，每个环节的输入和输出是什么。工作流是划分协作接口的依据。
- 现有角色清单：团队实际有哪些人、各自当前承担哪些工作。先如实记录，再讨论调整，避免按理想编制填写。
需要区分的是：本文示例是演示情景，用于说明填写方法；真实客户案例会包含具体组织背景和实际成效，本文不提供这类内容，也不编造量化效果。
完整示例：一份已填写的角色协作约定
以下为示例团队的角色协作约定全文（示例）。约定按角色组织条目，每个角色包含一句话定位、职责边界、关键交付物、协作接口四部分；确认与升级路径、生效与复盘节奏作为团队级条款单列。
角色清单与一句话定位
| 角色 | 一句话定位 |
|---|---|
| 产品经理 | 对需求价值和优先级负责，把业务问题转化为可开发的需求说明 |
| 研发工程师 | 对技术方案和功能实现负责，按约定时点交付可测试的版本 |
| 测试工程师 | 对质量把关负责，给出可上线的质量结论 |
| 设计师 | 对交互与视觉方案负责，保证方案在开发前完成评审 |
| 运营 | 对上线后的使用推广和反馈收集负责 |
| 团队负责人 | 对目标、资源和跨团队协调负责，承担最终拍板 |
职责边界、交付物与协作接口
| 角色 | 做什么 | 不做什么 | 关键交付物与时点 | 协作接口（上下游、交接内容、方式） |
|---|---|---|---|---|
| 产品经理 | 梳理需求、确定优先级、编写需求说明、组织需求评审 | 不直接决定技术实现方案；不跳过评审直接向研发口头派活 | 迭代需求说明，迭代启动前2个工作日；需求变更记录，变更当天更新 | 上游接运营和用户反馈；下游向研发、测试、设计交付需求说明，通过需求评审会交接并留会议记录 |
| 研发工程师 | 技术方案设计、编码、自测、修复缺陷 | 不擅自扩大需求范围；不绕过测试直接上线 | 技术方案说明，开发启动前1个工作日；可测试版本，提测日当天；缺陷修复记录，随修随记 | 上游接产品需求说明和设计稿；下游向测试交付提测版本，附自测结论和已知问题清单，通过提测单交接 |
| 测试工程师 | 编写测试用例、执行测试、跟踪缺陷、给出上线质量结论 | 不替研发修改代码；不在质量结论未出时默认放行 | 测试用例，提测前完成；测试报告与质量结论，上线评审前1个工作日 | 上游接提测版本；下游向产品和团队负责人交付质量结论，通过上线评审会交接 |
| 设计师 | 交互与视觉方案设计、设计走查 | 不在开发中途大改方案；不代替产品做需求取舍 | 设计稿与交互说明，开发启动前2个工作日；走查问题清单，提测后2个工作日内 | 上游接产品需求说明；下游向研发交付设计稿，通过设计评审会交接，走查问题以清单形式反馈 |
| 运营 | 上线推广、使用培训、收集用户反馈 | 不直接承诺用户需求排期；不绕过产品向研发提需求 | 上线推广方案，上线前3个工作日；反馈汇总，每迭代结束前提交 | 上游接上线版本和质量结论；下游向产品交付反馈汇总，通过迭代复盘会交接 |
| 团队负责人 | 确定迭代目标、协调资源、处理升级事项、主持复盘 | 不代替角色做日常执行决策；不越过确认人直接改交付物 | 迭代目标说明，迭代启动会当天；升级事项处理结论，收到升级后1个工作日内 | 接收各角色的升级请求；向跨团队或上级协调资源，通过升级记录交接 |
确认与升级路径
- 需求范围确认：产品经理提出，团队负责人在迭代启动会上拍板。研发或测试对范围有异议，在启动会当场提出；会后提出的，走升级路径。
- 技术方案确认：研发工程师提出，产品经理和测试工程师共同确认；涉及跨团队依赖的，由团队负责人确认。
- 上线放行确认：测试工程师给出质量结论，产品经理确认业务就绪，团队负责人最终放行。
- 升级规则：分歧在对应确认环节内未解决，由提出方在1个工作日内书面提交团队负责人；团队负责人1个工作日内给出结论；仍无法解决的，升级至上级或跨团队协调会。
生效与复盘节奏
本约定经团队会议确认后生效，适用于当前迭代及之后各迭代。每个迭代复盘会留出10分钟检查约定执行情况，记录偏离项；连续两个迭代出现同类偏离，或团队角色、工作流发生变化的，触发修订。修订由团队负责人组织，修订后重新确认生效。
约定落地时，可以把角色与交付物对应到协作工具的工作项上：每个交付物建为工作项并指定负责人，交接通过状态流转体现，确认结论和评审记录留存在对应工作项下。ONES 可以承载这类工作项负责人、状态流转与评审记录的管理，让约定中的时点和确认人有可查的执行痕迹。
逐项解释：每个字段为什么这样填
示例中的每个字段都对应一类协作风险。理解填写理由，比照抄表格更重要。
职责边界为什么要写“不做什么”
只写“做什么”，边界仍然模糊，因为很多越界行为在字面上并不违反职责描述。写“不做什么”，是把团队已经踩过或预判会踩的坑提前写明。示例中“产品经理不跳过评审直接向研发口头派活”，针对的是需求未经确认就进入开发的风险。常见错误是把“不做什么”写成对其他角色的贬低，例如“不干涉研发内部事务”，这类表述无法执行；应写成具体行为，如“不直接修改研发提交的代码”。
交付物如何写到可验收的颗粒度
可验收的交付物要能回答三个问题：是什么、什么时候交、交给谁。示例中“测试报告与质量结论，上线评审前1个工作日”，明确了内容、时点和接收场景。常见错误是写成“及时提供测试支持”这类无法判断是否完成的话；另一种错误是颗粒度过细，把每个文档的章节结构都写进约定，导致维护成本过高。判断标准是：接收方能否据此判断“可以开始下一步了”。
协作接口与交接内容的具体写法
协作接口要写清上下游是谁、交接什么、通过什么方式交接。示例中研发向测试交接时“附自测结论和已知问题清单，通过提测单交接”，接收方拿到的东西是确定的，交接动作也有载体。常见错误是只写“研发与测试密切配合”，没有交接物和交接方式，出问题时双方各执一词。另一个常见问题是交接方式写了多个渠道，例如“邮件或群里说一声”，导致记录分散；建议每个接口约定一个主渠道。
确认人与升级路径的设置逻辑
确认人应当是能为该决策承担后果的角色，而不是职位最高的人。示例中技术方案由产品经理和测试工程师共同确认，因为方案影响需求实现和质量验证；上线放行由团队负责人最终确认，因为涉及对外承诺。升级路径要写清触发条件、提交时限和处理时限，否则升级会变成情绪化投诉。常见错误是只写“有分歧找领导”，没有说明找哪位领导、多久内响应。
复盘节奏与修订触发条件
约定写完就会过时，复盘节奏是让它保持有效的机制。示例采用“每迭代检查、连续两次同类偏离触发修订”的规则，兼顾轻量和敏感度。常见错误是把复盘写成季度走形式，偏离积累到无法执行才修订；另一种错误是频繁修订，导致团队刚适应又换规则。修订触发条件应聚焦结构性变化，例如角色增减、工作流调整、反复出现的协作卡点。
可迁移规律：换一个团队怎么改
套用这份示例时，改的是条目组织方式和颗粒度，保留的是“角色—边界—交付物—接口—确认”的结构。
- 按工作流组织角色条目：先列出团队的主要工作流环节，再为每个环节标注负责角色和交接物。示例按迭代流程展开，换成客服、销售支持等团队时，把环节替换为对应流程即可。按部门罗列职责容易写成岗位说明书，无法指导具体交接。
- 角色数量随团队规模调整：五人以下团队可以合并角色条目，例如产品与运营由一人承担时，写清该角色在两个环节的不同职责和确认人；二十人以上团队建议按工作流拆成多份子约定，避免一份文档过长无人维护。角色合并时，确认人不能合并到同一人，否则失去制衡。
- 跨职能协作接口用统一句式：推荐“上游接什么—下游交什么—通过什么方式交接”的三段式。跨团队接口额外写明对接人和响应时限，例如“对接对方团队接口人，2个工作日内回复”。
- 区分约定与任务负责人、技能配置的边界：角色协作约定回答“这类工作由哪个角色负责、怎么交接”；具体某个任务派给谁、某人具备哪些技能适合承担什么工作，属于任务分配与人员技能匹配的范畴，不在本约定中展开。约定中写角色，任务层面再落到具体的人。
调整后建议做一次自检：每个交付物是否都有明确接收方；每个确认环节是否都有唯一拍板人；每条升级路径是否都有时限。三项都满足，约定基本可用。
适用边界与使用注意
这份示例适合跨角色协作频繁、职责容易重叠的团队，例如产品、研发、测试、设计、运营共同推进一个迭代的团队，或经常出现“这事该谁做”争议的项目组。团队处于流程稳定期、需要把既有默契固化成文字时，套用效果最好。
以下情形需要改造或不适用：
- 流程尚未稳定：团队还在探索工作方式，过早写细约定会限制调整空间，可先写角色定位和确认人，交付物时点留待流程稳定后补充。
- 强矩阵或项目制组织：成员同时服务多个项目时，单份团队约定无法覆盖跨项目优先级冲突，需要补充项目间的资源协调规则。
- 高度标准化的流水线作业：职责已由作业标准或系统流程固定，再写一份协作约定容易重复，可只保留确认与升级路径部分。
使用时有两点注意。其一，本文示例为演示情景，角色设定、交付物时点和升级时限均为说明填写方法而设，不代表任何真实组织的做法，直接套用前应结合本团队实际工作流调整。其二，约定需要随组织和流程变化定期修订，角色增减、工作流调整或同类协作问题反复出现时，应主动触发修订并重新确认，避免文档与实际协作脱节。
常见问题
团队只有五六个人，角色条目要不要合并？
可以合并，但要注意合并的方式。产品与运营由一人承担时，在约定中写清该角色在两个环节的不同职责、各自交付物和确认人，避免用一句“负责产品和运营”带过。角色合并后，确认人不宜再合并到同一人，否则需求提出与范围拍板落在同一角色身上，确认环节就失去制衡作用。
约定写好后，怎么判断它真的在起作用？
看三个可观察的信号：交接时接收方是否需要反复追问“这东西能不能用”；确认环节是否经常出现没人拍板或多人拍板；升级事项是否在约定时限内得到回复。每个迭代复盘时留出固定时间检查偏离项，连续两个迭代出现同类偏离，就说明相关条目需要修订，而不是继续靠口头提醒维持。
成员同时参与多个项目时，这份约定还够用吗？
单份团队约定覆盖的是团队内部的角色与交接，跨项目的优先级冲突不在其中。强矩阵或项目制组织需要在团队约定之外补充项目间的资源协调规则，明确当两个项目同时需要同一角色时由谁裁决、依据什么排序。团队约定中的升级路径可以作为跨项目协调的入口，但裁决规则要单独写。
约定和岗位说明书、绩效考核是什么关系？
三者服务的目的不同。岗位说明书描述岗位的长期职责与任职要求，绩效考核衡量结果，角色协作约定聚焦具体工作流中的交接与确认，颗粒度更细、更新更频繁。约定不应替代岗位说明书，也不宜直接作为考核依据；它的作用是让日常协作中的“谁来做、交给谁、谁确认”有明确答案。
约定中的交付物时点经常被突破，怎么调整？
先区分是时点定得不合理还是执行问题。如果多数迭代都突破同一时点，说明该时点与上游环节的实际耗时脱节，应回到工作流重新核算，而不是继续加催促。如果只是个别情况，按升级路径处理并在复盘中记录原因。调整时点要同步检查下游环节是否受影响，避免把压力简单转移到下一个角色。
