团队责任不清，先别急着开会强调“大家要主动”。更有效的做法是把模糊的责任变成可核对的分工：先列出团队要交付的关键结果和跨角色交接点，再用责任矩阵把每个环节的负责人、执行人、被咨询人和知会人写清楚，最后把分工落到日常协作工具的工作项和评审节点上，用一次真实任务验证边界是否可行。
要点总览（TL;DR）
- 先用最近三次扯皮或返工事件反查，判断责任不清属于角色缺失、边界重叠还是交接断点，避免直接重写全部职责。
- 用责任矩阵把关键交付物与角色对齐，每个交付物只设一个负责人，其余角色用执行、被咨询、知会表达参与。
- 把矩阵转写成角色职责说明和交接规则，写明触发条件、交付标准、接收人以及争议升级路径。
- 选一个跨角色、近期发生的真实任务试点，记录责任模糊点和交接延误，复盘后修订矩阵再推广。
- 用五项检查判断分工是否落地：负责人唯一、交接可执行、争议有出口、新成员能看懂、文档有维护机制。
先定位责任不清发生在哪一层
责任不清是一个笼统的说法，落到具体事件上，通常只有三种形态。先分清是哪一种，才能决定改角色、改边界还是补交接，避免一上来就重写全部职责说明书。
第一种是角色缺失：某类事情在团队里没有明确归属，出了问题才发现“以为有人在管”。第二种是边界重叠：两个或更多角色都认为自己该管，或者都认为对方该管，决策时互相等待。第三种是交接断点：每个角色单独看职责都清楚，但两段工作之间的传递没有约定，任务在缝隙里停住。
判断方法不必依赖问卷，用最近三次扯皮或返工事件反查即可。每次事件问四个问题：这件事本该由谁对结果负责？当时实际是谁在做？决策卡在谁那里？信息在哪一步断掉？把答案记下来，就能看出问题集中在哪一类。
| 问题类型 | 典型信号 | 反查时关注 |
|---|---|---|
| 角色缺失 | 事情无人认领，临时抓人顶上 | 是否有工作从未出现在任何人的职责里 |
| 边界重叠 | 多人表态负责，方案反复推翻 | 同一决策是否有两个以上拍板人 |
| 交接断点 | 上游已完成，下游迟迟未启动 | 交接是否有触发条件和接收人 |
还要区分角色职责问题与单任务负责人问题。前者是长期性的分工结构问题，需要调整职责说明和责任矩阵；后者是某一次任务没有指定负责人，属于任务分配范畴，指定即可解决。把单次任务问题误判为角色问题，会导致职责文档越写越厚却解决不了实际推诿。
本步的输入是近期扯皮、返工、延期事件的记录；动作是逐件反查责任归属和断点位置；输出是一份责任断点清单，每条标注问题类型、涉及角色和发生环节。完成标志是：清单中的事件能归入三类之一，且能指出具体断在哪两个角色之间。
用责任矩阵把角色和交付物对齐
责任矩阵的作用是把“谁负责”从口头共识变成可核对的表格。填写时以关键交付物为行，以角色为列，而不是罗列所有日常工作。关键交付物的判定标准是：它出错会直接影响团队对外结果，或者它需要两个以上角色配合完成。
列交付物时同步标出跨角色接口，即这份交付物从谁手里交到谁手里。接口往往就是断点高发区，提前标出来，后面写交接规则时可以直接对应。
RACI 四类角色的判定口径需要统一，否则填出来的矩阵仍然模糊：
- 负责人（A）：对结果最终拍板，对交付物的成败负责。每个交付物只设一个，这是矩阵能否执行的关键。
- 执行人（R）：实际完成工作的人，可以有一个或多个，但要有主次。
- 被咨询人（C）：在决策前需要提供意见的角色，意见要被听取，但不拥有否决权。
- 知会人（I）：结果确定后获知即可，不参与决策。
“共同负责”是最常见的填写误区。两个人都写 A，冲突时谁拍板仍然不明，推诿只是从会前转移到会上。遇到确实需要多方参与的情况，把其中一方定为 A，其余放入 C，用咨询关系表达参与，而不是用共同负责表达重视。
| 关键交付物 | 输入 | 动作 | 输出 | A | R | C | I |
|---|---|---|---|---|---|---|---|
| 示例：季度需求优先级清单 | 各业务方需求池、上季度交付数据 | 汇总、评估、排序、确认 | 经确认的优先级清单 | 产品负责人 | 需求分析岗 | 技术负责人、运营负责人 | 销售团队 |
| 示例：版本上线评审结论 | 测试报告、变更清单 | 评审、判定、记录结论 | 上线或延期的明确结论 | 技术负责人 | 测试负责人 | 产品负责人 | 客服团队 |
表中示例仅用于说明填写结构，实际填写时替换为本团队的真实交付物。每行都要能回答：输入从哪来、谁做、产出交给谁。如果某行的输出找不到接收方，说明这个交付物可能不必要，或者交接对象还没明确。
本步的输入是责任断点清单和团队的关键结果清单；动作是列交付物、标接口、逐行填 RACI；输出是一张覆盖关键交付物的责任矩阵初稿。完成标志是：每个交付物只有一个 A，每个接口两侧的角色都能在矩阵中找到。
把分工写进协作规则和日常流程
责任矩阵解决“谁对什么负责”，协作规则解决“什么时候、按什么标准交接和拍板”。矩阵停留在文档里，日常协作仍会回到口头协调，所以需要把矩阵中的关键行转写成两类文本：角色职责说明和交接规则。
角色职责说明按角色撰写，每个角色写清三部分：职责范围（负责哪些交付物和环节）、决策权限（哪些事可以自己定，哪些需要上报）、交接对象（上游从谁接收、下游交给谁）。写法上尽量用可核对的名词和动作，例如“负责版本上线评审结论的判定”，而不是“负责把控质量”。
交接规则针对矩阵中标注的每个接口，写明三项内容：
- 触发条件：上游做到什么状态才算可以交接，例如“测试报告完成且遗留缺陷已分级”。
- 交付标准：交接物包含哪些内容、达到什么完整度，例如“变更清单需列明影响范围与回滚方案”。
- 接收人：具体角色而非“相关同事”，并约定接收后的确认动作和时限。
评审与升级路径同样要写进规则：常规分歧在哪个评审节点解决、谁拍板；评审仍无法达成一致时找谁，升级的时限是多久。没有升级路径，责任矩阵在真正冲突时会失效，因为双方都可以援引自己的职责条款。
规则写好后，把负责人和评审人落到日常使用的协作工具中。以 ONES 为例，可以在工作项上设置负责人字段对应矩阵中的 A 和 R，用状态流转表达交接的触发条件，把评审结论记录在评审节点上，使分工在任务层面可查。具体字段配置需结合团队实际使用的工具版本核验。
本步的输入是责任矩阵初稿；动作是撰写角色职责说明、交接规则和升级路径，并在工具中配置对应字段；输出是角色职责说明和交接规则清单。完成标志是：矩阵中每个接口都能在交接规则中找到对应条目，每个角色说明都能对应到至少一个交付物。
用一次真实任务试运行分工
新分工是否可执行，靠讨论判断不了，要用一次真实任务检验。试点任务的选择标准是：跨两个以上角色、近期确定会发生、结果可观察。避开过于简单的单角色任务，也避开周期过长的大项目，前者检验不出交接问题，后者反馈太慢。
试点过程中安排一个人做记录，重点记两类信息：责任模糊点，即执行中出现的“这事该谁定”“这个该交给谁”；交接延误，即上游完成到下游启动之间的实际间隔和原因。记录要落到具体环节和角色，不停留在“沟通不畅”这类描述。
试点结束后做一次复盘，逐条对照记录修订矩阵：模糊点对应的行补充或调整 A 和 C；交接延误对应的接口补充触发条件或更换接收人；出现矩阵未覆盖的交付物则新增行。修订后的矩阵再进入下一轮使用。
在 ONES 中承载试点时，可以把试点任务拆成工作项，为每个工作项指定负责人，用状态流转记录交接发生的时点，把评审意见留在评审记录中。这样复盘时可以直接回看每个环节的责任人和流转时间，减少凭记忆还原过程的偏差。工具的具体能力以团队实际使用版本为准。
本步的输入是责任矩阵、角色职责说明和一份选定的试点任务；动作是执行任务、记录模糊点和延误、组织复盘；输出是试点复盘记录和修订后的责任矩阵。完成标志是：记录中的每个模糊点和延误都能对应到矩阵或规则的具体修订项。
责任分工的完成检查
分工机制是否真正落地，可以用一张检查表逐项核对。以下条目全部通过，才适合在更大范围推广；有未通过项，回到对应章节补齐，而不是靠开会重申。
| 检查项 | 通过标准 | 未通过时的处理 |
|---|---|---|
| 关键交付物负责人唯一 | 每个交付物只有一个 A，无“共同负责” | 回到责任矩阵，指定唯一拍板人，其余转为 C |
| 交接点可执行 | 每个接口有触发条件、交付标准和具体接收人 | 补充交接规则，明确接收后的确认动作 |
| 争议有出口 | 分歧有指定评审节点和升级对象，含时限 | 补充升级路径并告知全体角色 |
| 新成员可自行理解 | 新成员在无人解释的情况下能看懂自己的职责和交接对象 | 改写职责说明，用具体交付物和动作替换抽象描述 |
| 文档有维护机制 | 明确维护责任人和更新节奏，例如每次组织调整或试点复盘后更新 | 指定维护人，把更新动作写入固定流程 |
其中“新成员可自行理解”这一项最容易被忽略，也最能反映分工文档的质量。检验方法很简单：请一位未参与编写的成员阅读职责说明，让他说出自己负责哪些交付物、向谁交接、遇到分歧找谁。说不清楚的地方，就是文档需要改写的地方。
维护机制决定分工能维持多久。组织调整、业务变化、试点复盘都会让原有矩阵过时，因此要指定维护责任人，并约定更新触发条件，例如新增关键交付物、角色变动或连续出现同类扯皮事件时启动修订。检查表本身也应随修订同步更新，保持与矩阵一致。
本步的输出是责任分工落地检查表及核对结论。完成标志是：五项检查全部通过，且维护责任人和更新节奏已明确到人。
常见问题
团队里大家都说“这事我也有责任”，反而没人拍板，该怎么处理？
这属于典型的边界重叠。处理方式是在责任矩阵中把该交付物的负责人收敛为一个人，其他原本自认负责的角色转为被咨询人，在决策前提供意见。需要说明的是，被咨询人的意见要被听取，但不拥有否决权。如果确实存在两个角色都需要深度参与的情况，可以按环节拆分交付物，让每个环节各有唯一负责人，而不是让两个人在同一交付物上共同负责。
责任矩阵填完后，日常协作还是靠口头协调，怎么让它真正用起来？
矩阵本身只是分工底稿，落地还需要两步。第一步是把矩阵中的每个接口转写成交接规则，写明上游做到什么状态可以交接、交接物包含什么、由谁接收并确认。第二步是把负责人和评审人落到团队日常使用的工作项上，让任务层面的责任人、状态流转和评审结论与矩阵保持一致。规则和工具字段同时到位，口头协调才会逐步减少。
试点任务选多大合适？周期太长会不会影响推广？
试点任务以跨两个以上角色、近期确定发生、结果可观察为标准。单角色任务检验不出交接问题，周期过长的大项目反馈太慢。如果近期没有合适的完整项目，可以选一个包含两到三次跨角色交接的阶段性任务，例如一次版本评审或一份优先级清单的确认过程。试点目的是暴露边界问题，任务规模够用即可，不必追求覆盖面。
组织调整后，原来的责任矩阵和职责说明要怎么维护？
在检查表中明确维护责任人和更新触发条件。常见触发条件包括新增关键交付物、角色发生变动、连续出现同类扯皮事件，以及每次试点复盘之后。维护人负责在触发时修订矩阵和职责说明，并同步更新交接规则与检查表，保持几份文档一致。把更新动作写入固定流程，比依赖临时提醒更可靠。
单次任务没人负责，也需要改责任矩阵吗？
通常不需要。单次任务没有指定负责人属于任务分配问题，指定负责人即可解决。责任矩阵处理的是长期性的角色分工结构，例如某类交付物长期没有归属、多个角色反复争夺同一决策权、交接处反复停摆。把单次任务问题误判为角色问题，会让职责文档越写越厚，实际推诿却依然存在。判断标准是看这个问题是否重复出现、是否涉及角色之间的边界。
