跨职能协作反复推诿时，直接重写职责清单往往收效有限，因为问题常出在角色边界、责任接口和交接规则没有被逐项定义。本文给出一套可执行步骤：先锁定反复推诿的具体协作事项，拆出五类角色，再为交接点写明输入物、输出物、完成标志和超时升级路径，最后用真实事项试跑并复核。
要点总览（TL;DR）
- 推诿的根源多在角色边界和交接点没有定义，先收集近1–2个月反复推诿的具体事项，按频次和影响选出3–5个接口优先处理。
- 为每个接口划分发起、主责、协同、审批、知会五类角色，用“对结果负责、有权调动资源、承担延期说明”三问确认主责唯一。
- 交接点写明输入物、输出物、可观察的完成标志、响应时限和超时升级对象，并把规则写进工作项模板或评审检查项。
- 规则建设本身要指定制定者、执行者和复核者，用真实事项试运行，观察退回次数、平均等待时长和升级闭环情况。
- 规则未生效时回到接口清单重新定位卡点，按季度复核角色与边界，避免只增加职责条目。
先定位推诿发生在哪些协作接口
处理推诿的第一步，是把“责任不清”这句笼统判断收敛成一份可处理的具体接口清单。接口指两个或多个角色之间发生交接、需要一方交付、另一方接收并继续推进的节点。规则设计针对的是这些节点，职责清单只是后续记录规则的载体。
收集范围建议覆盖近1–2个月。信息来源可以是群聊记录、邮件往来、评审会议纪要、项目延期说明，也可以请各角色分别列出“最近一次等别人”的事项。每条记录至少包含四项：事项名称、涉及角色、卡住的环节、当时的处理方式。
记录完成后，把推诿归入四类，便于后续对症处理：
- 无人认领：事项出现后没有任何角色主动接手，常见于跨部门之间的“缝隙工作”。
- 双方都认为归对方：两个角色各自有一套理解，都认为对方应先动作。
- 交接标准模糊：有人交付了，但接收方认为不完整、不可用，来回返工。
- 审批链过长：事项本身清楚，但卡在多个审批节点，无人推动。
随后按发生频次和影响程度排序。影响程度可看是否导致延期、返工或升级到上级。选出优先处理的3–5个接口作为第一批工作对象，数量控制在一次能试跑完的范围。产出一份跨职能协作接口清单，字段包括：事项、涉及角色、卡点、推诿类型、优先级。
为每个接口定义五类角色与责任边界
针对清单中的每个接口，用五类角色重新划分责任。五类角色回答的问题不同，缺一类就会留下模糊地带：
| 角色 | 回答的问题 | 典型动作 |
|---|---|---|
| 发起 | 这件事由谁提出、为什么现在做 | 提交需求或问题，说明背景与期望时间 |
| 主责 | 谁对最终结果负责 | 组织推进、协调资源、对外说明进度与延期原因 |
| 协同 | 谁提供专业输入或配合动作 | 在约定时点给出反馈、数据或方案 |
| 审批 | 谁有权确认结果可以进入下一环节 | 按标准检查并给出通过或退回意见 |
| 知会 | 谁需要了解结果但不必参与决策 | 接收结果通知，必要时提出异议 |
主责必须唯一。判定方法可以问三个问题：谁对结果好坏负责？谁有权调动完成这件事所需的资源？延期时由谁作出说明？三个答案指向同一角色，主责才算落定。若指向不同角色，说明接口本身还没拆清楚，应继续拆分而不是让多人共同主责。
边界写法要同时写“负责什么”和“不负责什么”。例如“主责在产品：负责需求目标、范围与验收标准的完整性；不负责技术方案选型与排期承诺”。把不负责的部分写明，能减少两个角色对同一事项的重复主张。
协同角色需要明确义务时点：在哪个节点之前必须给出反馈，超时如何处理。两种处理方式可选其一并写清：超时视为无异议、默认同意，或超时自动升级到指定角色。选择哪种取决于事项风险，涉及质量与合规的接口更适合升级而非默认同意。
把交接点写成可验收的输入输出规则
角色划分解决“谁负责”，交接规则解决“凭什么算完成”。每个交接点定义三项内容：输入物、输出物、完成标志。完成标志要可观察，避免“基本清楚”“大致可用”这类无法核对的表述。
| 要素 | 写法要求 | 示例 |
|---|---|---|
| 输入物 | 接收方开始工作前必须拿到的东西 | 含目标、范围、验收标准字段的需求文档 |
| 输出物 | 本环节结束时交付的具体产物 | 技术可行性评估意见、排期建议 |
| 完成标志 | 可观察的通过条件 | 文档评审通过、必填字段完整、测试报告已签字 |
| 响应时限 | 从接收到给出反馈的最长时间 | 2个工作日内给出可行性反馈 |
| 升级路径 | 超时后由谁处理、多久内处理 | 超时升级至双方共同上级，1个工作日内裁定 |
规则要写进工作项模板或评审检查项，让交接在流程里发生，而不是靠人提醒。具体做法是把输入物和完成标志设为必填字段或准入门槛：字段不完整则无法进入下一状态，评审检查项未勾选则无法通过。这样责任从“人”落到“物”，推诿时可以直接对照缺了哪一项。
在工具承载上，ONES 的工作项类型、自定义字段和状态流转可以把上述规则固化下来：输入物与完成标志作为字段或准入门槛，交接动作对应状态变更，评审意见与退回记录留在工作项中，便于事后核对。是否采用工具承载取决于团队已有的协作平台，规则本身的字段设计应先于工具配置完成。
角色与规则的落地分工：谁制定、谁执行、谁复核
规则建设过程本身也需要分工，否则容易变成一份无人维护的文档。建议按下表明确三类角色和对应交付物：
| 角色 | 职责 | 交付物 | 时点 |
|---|---|---|---|
| 规则制定者 | 通常由协作双方共同上级或流程负责人牵头，裁定争议接口，确认五类角色划分 | 角色责任表、交接规则表 | 试运行前 |
| 执行者 | 各接口主责人，按规则完成交接，记录退回、超时与异常 | 试运行记录 | 试运行期间持续 |
| 复核者 | 试运行结束后核对推诿是否减少，收集未覆盖的接口，提出修订 | 复核结论、修订说明 | 试运行结束后 |
制定者不宜由单一部门兼任，否则规则容易偏向本方流程。争议接口的裁定权要写清归属，避免规则制定阶段再次出现“都认为归对方”。执行者的记录动作要尽量轻，例如在工作项中标记退回原因，而不是另建一套台账。复核者与制定者可以是同一角色，但复核结论需要基于试运行记录，而非主观感受。
示例：一次需求评审推诿如何按规则澄清
以下为演示情景，用于说明规则如何落地，不作为真实案例引用。
原始状况：产品提出需求，研发认为需求描述不清、无法评估工作量，测试认为验收标准缺失、无法设计用例。三方互相等待，需求在评审前停留超过一周。
第一步，识别接口。该事项属于“交接标准模糊”类型，卡点在需求文档进入评审之前。影响为评审延期，优先级高。
第二步，划分五类角色。发起为业务方；主责为产品，对需求目标、范围与验收标准的完整性负责，不负责技术方案与排期承诺；协同为研发，需在收到需求后2个工作日内给出可行性反馈；审批为测试，负责确认验收标准可测；知会为项目管理者。
第三步，写交接规则。输入物为含验收标准字段的需求文档；输出物为研发可行性意见与测试可测性确认；完成标志为必填字段完整且评审检查项通过；缺失验收标准则退回产品并记录退回原因；研发反馈超时则升级至产品与研发的共同上级，1个工作日内裁定。
第四步，试运行与观察。规则写入需求工作项模板后试运行两周，观察三个指标：需求被退回次数、从提交到评审通过的平均时长、超时升级事件数量及处理结果。若退回次数短期上升但评审时长下降，通常说明标准变严、返工前移，属于正常现象；若退回集中在同一字段，说明该字段的填写指引需要补充。
完成检查：规则是否真的减少了推诿
规则是否生效，用可核对的条目判断，而不是看文档是否写完。逐项检查：
- 每个高频接口是否都有唯一主责，且主责的判定三问答案一致；
- 每个交接点是否有书面的输入物、输出物与完成标志；
- 是否约定了响应时限与超时升级路径，升级对象是否明确到角色；
- 规则是否已进入工作项模板或评审检查项，而非只存在于文档中；
- 试运行记录是否包含退回、超时与升级事件的处理结果。
验证信号看三项：同类推诿的复发次数是否下降；事项从发起到完成的平均等待时长是否缩短；升级事件是否都在约定时限内闭环。三项中若只有文档完成度提升而指标无变化，说明规则停留在纸面，需要检查是否真正嵌入了流程节点。
维护机制建议按季度复核一次角色与边界，新接口出现时随时补充，补充时沿用同一套字段：五类角色、输入输出、完成标志、时限与升级对象。若某项规则未达标，回到接口清单重新定位卡点，判断是角色划分有误、完成标志不可观察，还是升级路径无人执行，针对原因修订；继续增加职责条目通常只会让清单变长，推诿依旧。
常见问题
跨职能协作中，两个部门都认为某件事归对方，应该先找谁裁定？
先看这件事是否已经列入接口清单。若已列入，按规则由协作双方共同上级或流程负责人裁定，裁定结果写入角色责任表，明确主责和协同的边界。若尚未列入，先补充接口记录，再走同样的裁定路径。裁定前可以先用主责判定三问自查：谁对结果负责、谁有权调动资源、延期由谁说明，三个答案指向同一角色时通常不需要上级介入。
主责人已经确定，但协同方迟迟不反馈，规则应该怎么设计？
在交接规则里为协同方写明反馈时点和超时处理方式，两种方式选其一并写清：超时视为无异议、默认同意，或超时自动升级到指定角色。涉及质量、合规或验收标准的接口更适合升级而非默认同意，因为默认同意会把风险留到下游。升级对象要写到角色而非个人，并约定处理时限，例如1个工作日内裁定。规则写入工作项后，超时可以自动触发状态变更或通知，减少靠人提醒。
规则试运行后，退回次数反而上升，是不是说明规则设计失败？
不一定。退回次数上升同时评审时长下降，通常说明完成标志变严、返工前移到了评审之前，属于规则起作用的信号。需要进一步看退回是否集中在同一字段或同一环节：若集中，说明该字段的填写指引或模板需要补充；若分散且评审时长没有改善，则要检查完成标志是否可观察、升级路径是否有人执行。判断依据是试运行记录中的退回原因分布，而非单看总数。
团队规模较小、跨部门接口不多时，也需要五类角色和完整交接表吗？
可以按接口数量裁剪。接口少时，优先为发生频次最高的1–2个接口填写角色责任表和交接规则表，知会角色可以合并或省略，审批与主责在低风险事项上可由同一角色承担。需要保留的是主责唯一性判定和完成标志的可观察性，这两项决定责任能否被验收。规则运行一个周期后再决定是否扩展到其他接口，避免一次性铺开导致执行负担过重。
分工规则写进工具后，如何避免规则随人员变动而失效？
把规则放在工作项模板、字段和状态流转里，而不是放在个人文档或聊天记录中，人员变动时新成员按模板操作即可延续。同时指定复核者按季度核对角色与边界，新接口出现时随时补充，补充沿用同一套字段：五类角色、输入输出、完成标志、时限与升级对象。复核结论基于试运行或运行记录中的退回、超时与升级数据，便于判断规则是否仍然匹配当前协作方式。
