团队责任界定要落到可执行的角色清单和责任矩阵上：先按业务环节拆出角色，为每个角色写明职责范围、决策权、交付物和交接对象，再用RACI或类似矩阵把关键活动与角色对应起来，最后通过评审、试运行和例外复盘把边界固化。判断是否界定清楚，看一项工作出问题时能否直接找到唯一负责角色，跨角色交接是否有明确输入和输出。本文按角色清单、矩阵填写、接口规则、落地步骤、示例和完成检查依次展开。
要点总览（TL;DR）
- 责任界定的起点是按业务环节和交付物反推角色，为每个角色写清职责范围、决策权、交付物和交接对象四项，形成可查阅的角色清单。
- 用RACI矩阵把关键活动与角色对应，每项活动只设一个A（最终负责），多人同为A或角色过多都会让矩阵失效。
- 跨角色扯皮集中在交接处，用角色接口卡写明交接物、时点、验收标准和升级路径，并提前指定临时决策人。
- 按起草、评审、试运行、固化四阶段推进，试运行期专门收集边界冲突并回写到矩阵与接口卡。
- 判断标准是：每项关键活动有唯一负责角色，每个交接有明确输入输出和验收人，新成员能凭文档找到对接人。
责任界定先定什么：角色清单与边界口径
责任界定的起点是角色清单，产出物是一份团队能直接查阅的角色说明。拆角色的依据是业务环节和交付物，从“这件事最终要交出什么、经过哪些环节”反推需要哪些角色，避免照现有人员头衔逐一罗列。按头衔罗列容易把组织架构当成责任结构，出现某个环节无人对应、或一个头衔覆盖过多环节的情况。
每个角色至少写清四项内容，缺一项都会在协作中留下模糊地带：
- 职责范围：这个角色对哪些环节的结果负责，做到什么程度算完成。
- 决策权：在职责范围内可以自行决定什么，哪些事项需要提交他人确认。
- 交付物：向谁交出什么，以什么形态交付。
- 交接对象：上游从谁接收输入，下游向谁移交输出。
三项口径需要在起草时统一。角色与岗位不同：岗位是组织编制，角色是围绕业务环节的责任集合，一个人可以承担多个角色，一个角色也可能由多人分担，但责任归属必须唯一。角色与单任务负责人也不同：角色描述的是持续性的职责边界，单任务负责人是在具体任务上的一次指派，前者稳定、后者随任务变化。角色清单只解决“谁在什么范围内负责”，具体任务的指派与跟踪属于另一层管理动作。
角色清单可按以下结构填写，作为后续矩阵和接口卡的共同底稿：
| 角色名 | 职责范围 | 决策权 | 交付物 | 交接对象 |
|---|---|---|---|---|
| 需求提出方 | 说明业务问题与期望结果 | 确认需求价值与优先级 | 需求说明 | 下游：需求分析角色 |
| 需求分析角色 | 把业务问题转为可交付的需求 | 确定需求范围与验收口径 | 需求文档、验收标准 | 上游：需求提出方；下游：交付角色 |
| 交付角色 | 按验收标准完成交付物 | 确定实现方式 | 可验收的交付成果 | 上游：需求分析角色；下游：验收角色 |
| 验收角色 | 按验收标准判定是否通过 | 判定通过或不通过 | 验收结论 | 上游：交付角色；下游：需求提出方 |
表格中的角色名应使用团队内部通用叫法，避免同一角色在不同文档中出现多个名称。职责范围写到能判断“这件事归不归它”的程度即可，不必写成岗位说明书。
用责任矩阵把活动与角色对应起来
角色清单回答“有哪些角色、各自管什么”，责任矩阵回答“每项关键活动由谁最终负责、谁参与”。矩阵的行取关键活动或交付物，列取角色清单中的角色，单元格填写RACI字母。行不宜过细，取到能区分责任的粒度即可；列不宜过多，角色数量超过十个时矩阵会失去可读性，通常需要先合并相近角色。
RACI四个字母的含义与填写规则如下：
| 字母 | 含义 | 填写规则 |
|---|---|---|
| R（执行） | 实际完成该活动的人 | 可以多人，需明确各自负责的部分 |
| A（最终负责） | 对该活动结果负最终责任的人 | 每行有且只有一个A |
| C（咨询） | 在活动完成前需要被征求意见的人 | 按需填写，双向沟通 |
| I（知会） | 活动完成或变更后需要被告知的人 | 按需填写，单向通知 |
“每项活动唯一A”是矩阵有效的核心规则。多人同为A等于无人最终负责，出问题时容易出现互相等待或互相推责。若一项活动确实涉及两个部门的最终确认，应把它拆成两项活动，各自设A，再用接口规则连接，而不是在一行里并列两个A。
常见填写错误有三类。一是把A填成“领导”，导致所有活动最终负责人都指向同一人，矩阵失去区分度；二是把C和I混用，把只需知会的人拉进事前讨论，拖慢决策；三是矩阵只填一次就归档，活动调整后不再更新，实际执行与文档脱节。空白矩阵可按以下结构搭建：
| 关键活动/交付物 | 角色一 | 角色二 | 角色三 | 角色四 |
|---|---|---|---|---|
| 活动1 | A | R | C | I |
| 活动2 | I | A | R | — |
| 活动3 | C | I | A/R | — |
矩阵填写完成后，逐行检查三件事：每行是否只有一个A；每个R是否清楚自己交付什么；每个C和I是否确有必要。检查通过的矩阵应与角色清单放在同一处维护，作为评审和新人入职的共同依据。
角色间接口与交接规则怎么定
矩阵解决的是静态对应关系，实际协作中的扯皮多发生在角色交接处：上游认为已经交清，下游认为输入不完整；或者交接时点没有约定，下游等到需要时才追问。处理办法是为每对主要交接关系建立角色接口卡，把交接写成可验收的动作。
接口卡至少包含五项内容：上游角色、下游角色、交接物、验收标准、升级路径。交接物要写清形态和内容范围；验收标准要写到下游能据此判断“收没收到、能不能开工”；升级路径写明交接无法达成一致时找谁裁决。交接还需要约定时点，即时点在什么事件之后、以什么方式通知下游。
| 字段 | 填写内容 |
|---|---|
| 上游角色 | 交出方 |
| 下游角色 | 接收方 |
| 交接物 | 名称、形态、内容范围 |
| 交接时点 | 在什么事件之后、以什么方式通知 |
| 验收标准 | 下游判断可以接收并开工的条件 |
| 验收人 | 由谁确认接收 |
| 升级路径 | 交接争议时的裁决人和时限 |
争议升级路径需要提前指定临时决策人。交接双方对输入是否完整、标准是否达到存在分歧时，先由临时决策人在约定时限内作出可执行的判断，避免事项停滞；判断结果在事后复盘时回写到接口卡或矩阵中，形成规则沉淀。临时决策人应是与该交接无直接执行利益、且了解业务目标的角色。
接口变更时的同步机制同样要写进规则：上游调整交接物内容或时点，需提前通知下游并说明影响；涉及验收标准变化的，由双方共同确认后更新接口卡，并同步给矩阵中相关的C和I。变更记录保留在接口卡上，便于追溯某次争议的规则依据。
责任界定的落地步骤与角色分工
责任界定按起草、评审、试运行、固化四个阶段推进，每个阶段有明确的输入、动作、输出和完成标志。牵头人通常由团队负责人或项目管理者担任，负责组织起草和推动评审；各角色代表参与评审并确认自己承担的边界；最终由团队负责人确认固化。
| 阶段 | 负责人 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|---|
| 起草 | 团队负责人牵头，各环节代表参与 | 业务环节清单、现有交付物 | 按环节反推角色，填写四项要素，初搭矩阵 | 角色清单初稿、矩阵初稿 | 关键活动均有对应角色 |
| 评审 | 团队负责人组织，各角色代表评审 | 角色清单与矩阵初稿 | 逐行核对唯一A，确认决策权与交接对象 | 评审意见与修订稿 | 各角色代表确认自己的边界 |
| 试运行 | 各角色按新边界执行，团队负责人收集冲突 | 修订稿、接口卡 | 按新规则协作，记录边界冲突与交接争议 | 冲突记录清单 | 试运行期内冲突均有记录和处理结论 |
| 固化 | 团队负责人确认 | 冲突记录、修订稿 | 回写矩阵与接口卡，发布正式版本 | 正式角色清单、矩阵、接口卡 | 文档发布并可被新成员直接使用 |
试运行期是收集边界冲突的关键窗口。团队负责人可指定一个记录入口，要求各角色在遇到“这件事该谁做”“这个交接算不算完成”时当场记录，注明涉及的活动、角色和分歧点。试运行结束时逐条处理：属于角色划分不清的，修订角色清单；属于活动归属不明的，调整矩阵；属于交接标准模糊的，补充接口卡。处理结论要回写到文档，不能只停留在会议纪要里。
责任矩阵和接口卡需要在团队日常协作中有稳定的承载位置，否则容易停留在文档里。ONES 支持将工作项类型、字段和流转规则配置为与角色、活动对应的结构，矩阵中的活动可以作为工作项类型管理，决策权与交接对象可以落到字段和流转条件上，接口卡中的验收标准可以作为状态流转的确认依据。这样责任界定从一份静态文档变成协作过程中的可查规则，评审和试运行收集到的调整也能直接反映到配置中。具体配置方式需结合团队现有流程设计，以实际使用条件为准。
示例：一次需求交付的责任界定
以下为演示情景，不对应任何真实组织或项目。某团队要界定一次需求从提出到上线的责任，涉及需求提出方、需求分析角色、交付角色、验收角色四个角色。
角色清单片段：需求提出方负责说明业务问题与期望结果，拥有确认需求价值的决策权，交付需求说明；需求分析角色负责把业务问题转为可交付需求，拥有确定范围与验收口径的决策权，交付需求文档和验收标准；交付角色负责按标准完成交付物，拥有确定实现方式的决策权；验收角色负责按标准判定是否通过，拥有通过与否的决策权。
矩阵片段如下：
| 关键活动 | 需求提出方 | 需求分析角色 | 交付角色 | 验收角色 |
|---|---|---|---|---|
| 提出需求 | A/R | C | I | I |
| 编写需求文档与验收标准 | C | A/R | C | C |
| 完成交付物 | I | C | A/R | I |
| 验收判定 | I | C | C | A/R |
接口卡片段：上游为需求分析角色，下游为交付角色，交接物为需求文档与验收标准，交接时点为需求评审通过后一个工作日内，验收标准为文档覆盖范围、验收口径和边界条件且交付角色确认无疑问，验收人为交付角色，升级路径为交接争议时由团队负责人在一个工作日内裁决。
一次交接争议的处理：交付角色认为需求文档未写明异常场景的处理口径，无法开工；需求分析角色认为文档已覆盖主要场景。按接口卡，交付角色在接收时提出疑问，验收人暂不确认接收，双方在一个工作日内未能达成一致，提交团队负责人裁决。负责人判定异常场景口径属于验收标准的一部分，需求分析角色补充文档后重新交接。事后该口径被写入接口卡的验收标准，同类争议不再重复发生。
完成检查：责任界定是否真的清楚
责任界定是否完成，可以用以下清单逐项核对。全部通过，说明角色清单、矩阵和接口卡已经形成可执行的规则；存在未通过项，回到对应章节补充。
- 每项关键活动在矩阵中有且只有一个A，且该A是具体角色而非笼统的“领导”。
- 每个角色的职责范围、决策权、交付物、交接对象四项均已填写，无空缺。
- 每个主要交接关系都有接口卡，写明输入、输出、时点、验收标准和验收人。
- 交接争议有明确的升级路径和临时决策人，并约定了裁决时限。
- 接口变更时有同步机制，变更记录可追溯。
- 新成员仅凭角色清单和接口卡就能找到每类事项的对接人。
- 试运行期收集的边界冲突均已处理并回写到文档。
- 矩阵与角色清单为同一版本，活动调整后已同步更新。
清单核对通过后，责任界定进入日常维护：业务环节或角色发生变化时，同步修订角色清单、矩阵和接口卡，并在团队内同步变更内容。责任边界随业务演进持续校准，界定工作才算真正落地。
常见问题
团队规模较小，也需要做完整的角色清单和RACI矩阵吗？
小团队可以简化形式，但核心规则不宜省略。角色清单可以合并相近角色，例如需求提出方与验收角色由同一人承担，但要在清单中注明一人多角色；矩阵的行也可以只保留关键交付物，不必覆盖所有活动。
需要保留的是“每项活动唯一A”这条规则。小团队里常见的情况是大家默认互相补位，出问题时反而找不到最终负责的人。把A明确到具体角色，比追求矩阵的完整度更重要。
试运行期一般需要多长，冲突记录到什么程度算够？
试运行期没有统一时长，取决于业务节奏：以需求交付为例，通常覆盖一到两个完整交付周期，让主要交接关系都实际走一遍。判断标准是主要角色之间的交接都发生过至少一次，而不是按固定天数计算。
冲突记录写到能定位问题即可：涉及哪项活动、哪两个角色、分歧点是什么、当时怎么处理的。试运行结束时逐条归类，分别回写到角色清单、矩阵或接口卡，处理结论要落到文档里，不能只留在会议纪要中。
一项活动确实需要两个部门共同最终确认，矩阵里怎么填？
不要在一行里并列两个A。做法是把这项活动拆成两项：例如“完成方案”和“确认方案”，各自设一个A，再用接口规则把两者连接起来，写明交接物、验收标准和升级路径。
拆分后，两个部门的最终责任各自清晰，衔接处由接口卡约束。如果拆分后仍出现职责重叠，说明角色边界本身没划清，应回到角色清单修订职责范围，而不是在矩阵里妥协。
角色清单、矩阵和接口卡由谁维护，多久更新一次？
通常由团队负责人或项目管理者牵头维护，各角色代表负责确认自己那部分内容。更新时机跟随业务变化触发，例如新增业务环节、角色调整、交接标准变化，以及试运行期冲突处理结论的回写。
建议把三份文档放在同一处维护并保持版本一致，避免矩阵更新了而接口卡还是旧版。每次变更记录变更内容和影响范围，并在团队内同步，这样争议发生时能追溯到当时的规则依据。
责任界定和具体任务的负责人指派是什么关系？
角色清单描述的是持续性的职责边界，回答“这类事归谁管”；单任务负责人是在具体任务上的一次指派，回答“这件事这次由谁做”。两者层次不同，不能互相替代。
实际操作中，先有角色边界，再在边界内指派任务负责人。如果某项任务找不到合适的角色承接，说明角色清单存在缺口，应先补角色，再指派任务。任务层面的指派与跟踪属于另一层管理动作，本文不展开。
