研发治理权责不清时，团队往往能感到“事情卡住了”，却说不清卡在谁那里。本文从可观察的症状入手，把模糊的权责问题归入决策权、评审权、交付责任、例外处置四类，再用证据区分规则缺失、规则冲突与规则未执行，给出分原因的处置动作和验证指标。讨论范围限于组织管理机制层面的权责划分，项目集运行监控与投资决策不在本文展开。
要点总览（TL;DR）
- 研发治理权责不清的可观察症状集中在四类：决策无人拍板或多人拍板、评审结论含糊且无人跟进、跨团队交付互相等待、变更与例外靠私下沟通。
- 排查时先把权责拆成决策权、评审权、交付责任、例外处置四类，再判断是规则缺失、规则冲突还是规则未执行，三类根因的处置成本差别很大。
- 处置按根因对应：规则缺失补研发治理权责表，规则冲突确定唯一裁决口径与升级路径，规则未执行固化决策记录并设置超时默认升级。
- 调整权责前保留原流程备份，避免一次同时改动多个环节；观察期内决策时效恶化或争议上升时应停止调整、回到原因排查。
- 用决策平均等待时长、评审返工次数、跨团队等待事项数量、责任归属争议次数验证恢复，并把权责表纳入变更管理防止复发。
研发治理权责不清有哪些典型症状
判断权责是否清晰，先看组织中是否反复出现同一类“悬空”现象。症状之所以有价值，是因为它们能被记录、被计数，也能被不同角色共同观察到。以下四类症状可作为对照清单使用。
四类可观察症状
| 症状类别 | 典型表现 | 常见出现场景 |
|---|---|---|
| 决策类 | 同一事项多人拍板且结论不一致；或会议开完无人拍板，事项挂起等待“上面定” | 跨团队项目的优先级调整、资源投入取舍 |
| 评审类 | 评审会上意见分散，通过结论含糊；评审通过后无人跟进落实，问题在下一环节才暴露 | 技术方案评审、架构评审、版本准入评审 |
| 交付类 | 上下游团队互相等待对方先交付；接口或依赖出问题时，双方都认为责任在对方 | 跨团队版本发布、多团队联合交付 |
| 变更与例外类 | 需求中途变更无人正式批准；紧急上线走“特事特办”，事后无人补记录、无人复核 | 版本发布前的需求插入、线上故障的紧急修复 |
这些症状在跨团队项目、版本发布和技术方案评审三类场景中最容易集中出现，因为这三类场景都涉及多个角色对同一事项表态，任何一处权责模糊都会被放大成等待或返工。
本文的讨论边界
本文聚焦组织管理机制层面的权责划分，即“谁对什么事项有决定权、谁承担交付结果、例外如何被批准”。项目集的运行状态监控、投资决策与项目组合治理属于另一层机制，出现相关问题时需要单独排查，不能与本文的权责诊断混为一谈。
先分清四类权责：决策权、评审权、交付责任、例外处置
症状只是表象，排查需要一个统一的分类对象。把权责拆成四类，是为了让每个症状都能对应到具体的权责类型，避免笼统地说“大家职责不清”。
四类权责的定义与典型角色
| 权责类型 | 定义与边界 | 典型角色 | 常见失衡表现 |
|---|---|---|---|
| 决策权 | 对事项做出最终选择并承担后果的权力，边界是“谁签字谁负责” | 业务负责人、技术负责人 | 多人共同拍板导致责任分散；或决策权上收过度，一线只能等待 |
| 评审权 | 对方案、设计、版本准入给出通过或不通过结论的权力，边界是结论必须明确且可追溯 | 技术负责人、架构角色、质量角色 | 评审只提意见不下结论；评审人与执行人重合，缺少独立把关 |
| 交付责任 | 对交付结果和时间承诺负责，边界是责任落到具体团队与具体人 | 项目经理、各交付团队负责人 | 跨团队交付责任共担，实际无人牵头；依赖方互相等待 |
| 例外处置 | 对偏离常规流程的事项进行批准与记录，边界是例外有明确入口和事后复核 | 业务负责人、技术负责人、质量角色 | 例外无入口，只能靠私下沟通；或例外常态化，流程形同虚设 |
权责重叠与权责真空
四类权责的失衡通常表现为两种形态。权责重叠是同一事项有多个角色都认为自己有权决定或都有义务把关，结果是结论互相抵消、决策周期拉长；权责真空是某类事项没有任何角色明确承接，结果是事项在团队之间流转却始终无人收口。两种形态可能同时存在于不同权责类型中，例如决策权重叠而例外处置真空，这也是为什么需要分类排查而不是整体判断。
原因假设与排除证据：规则缺失、规则冲突还是规则未执行
看到症状后直接下结论，容易把“执行不到位”误判为“制度不健全”，从而做出错误的处置。更稳妥的做法是先提出三类原因假设，再用证据逐一排除。
三类原因假设与判断线索
| 原因假设 | 判断线索 | 典型证据 |
|---|---|---|
| 规则缺失 | 找不到任何书面规定说明该事项由谁决定、由谁验收 | 制度文件中无对应条款；访谈中各方都表示“没有明确规定” |
| 规则冲突 | 存在多份规定，但对同一事项的决定人或流程要求不一致 | 两份制度对同一评审的审批层级要求不同；新旧流程文件并存 |
| 规则未执行 | 规则本身清晰，但实际流转中未被遵循，或记录缺失 | 评审记录缺失、上线审批未留痕、会议纪要与制度要求不符 |
可采集的证据与交叉验证
证据采集应围绕同一事件的多方记录展开，常用来源包括会议纪要、评审记录、需求与缺陷流转记录、上线审批记录。交叉验证的关键是就同一事件分别查看提议方、决定方、执行方和验收方的记录，看四者对“谁定的、什么时候定的、依据是什么”的描述是否一致。若多方说法互相矛盾，往往说明规则本身存在冲突或未被共同理解；若各方说法一致但都指向“没有规定”，则更可能是规则缺失。
排查顺序
建议按以下顺序推进，每一步都以证据作为进入下一步的前提：
- 先查是否存在明文规则：调取制度文件与流程说明，确认该事项是否有书面规定。
- 再查规则之间是否矛盾：比对多份文件的适用对象与审批要求，找出冲突条款。
- 最后查执行偏差：在规则清晰且无冲突的前提下，核对实际记录与规则要求的差距。
这个顺序的意义在于，规则缺失和规则冲突需要修改制度，规则未执行需要调整执行机制，三者的处置成本与影响范围差别很大，顺序颠倒会导致反复返工。
按原因处置：补权责表、定决策记录、开例外通道
处置动作应与已确认的根因对应，避免一次性改动过多环节。以下按三类原因分别给出动作，并说明风险边界与停止条件。
规则缺失：编制研发治理权责表
针对确认无明文规定的事项，编制研发治理权责表，逐项写明事项名称、提议人、决定人、会签人、执行人和验收人。编制时以已发生的真实事项为样本，先覆盖高频且争议集中的事项，再逐步扩展。完成标志是每个纳入范围的事项都能在表中找到唯一的决定人。风险边界在于，权责表一旦发布就会改变现有习惯，建议先在单个项目或单个版本周期内试行，确认无重大阻塞后再推广。
规则冲突：确定唯一裁决口径与升级路径
针对多份规定互相矛盾的情况，逐条梳理冲突条款，明确哪一份文件在什么范围内优先适用，并为无法在现有层级解决的争议设定升级路径，指明升级到哪一级、由谁做最终裁决。完成标志是冲突条款清单归零，且每个争议都有明确的裁决人。风险边界在于，裁决口径的调整可能影响既有审批习惯，调整前应保留原流程文件作为备份，并设定一个观察期，观察期内出现新的冲突应立即暂停推广并回到梳理环节。
规则未执行：固化记录与超时升级
针对规则清晰但执行不到位的情况，把关键决策与评审固化为可追溯的记录，要求每次决策留下决定人、决定时间、依据和结论；同时为关键节点设置超时默认升级，即事项在规定时限内未完成决策时自动提交上一级处理。完成标志是关键决策与评审的记录完整率在观察期内稳定达标。风险边界在于，超时升级会改变决策节奏，设置时限时应参考历史实际耗时，避免时限过短导致升级泛滥。
处置中的共同风险控制
调整权责前保留原流程备份，是处置阶段最基本的保护措施。同时应避免在一次调整中同时改动决策、评审、交付和例外四类环节，因为多环节同时变化会让问题归因变得困难。若观察期内出现决策时效明显恶化或争议数量上升，应停止后续调整，回到原因排查环节重新确认根因。
在把决策与评审固化为记录的过程中，ONES 可以承接部分管理动作：系统中的工作项与评审流转会留下操作记录，ONES 效能管理自动收录系统内日常流转的研发数据并形成分析指标，其预置的仪表盘模板可供管理人员和项目经理直接使用，也支持共享给其他用户。需要说明的是，权责表本身如何编制、裁决口径如何确定，仍属于组织机制设计的工作，工具承载的是记录与数据呈现。
验证恢复与防止复发
处置是否有效，需要用一段时间的观察数据来判断，而不是凭一次会议上的共识。验证的重点是权责清晰后应出现的可观察变化：决策更快、返工更少、等待更短、争议更少。
验证指标
| 指标 | 观察内容 | 恢复的参考信号 |
|---|---|---|
| 决策平均等待时长 | 从事项提出到形成明确结论的平均时间 | 在观察期内趋于稳定并较处置前缩短 |
| 评审返工次数 | 同一方案因结论不清或问题遗漏而重复评审的次数 | 重复评审次数下降，评审结论一次明确的比例上升 |
| 跨团队等待事项数量 | 因等待其他团队响应而停滞的事项数量 | 等待事项数量减少，等待原因集中在外部依赖而非内部权责 |
| 责任归属争议次数 | 出现问题后对责任归属产生分歧的次数 | 争议次数下降，且争议能在既定升级路径内解决 |
观察周期与复盘方式
建议以一个完整的版本周期或一个季度作为观察周期，周期结束时组织一次复盘，由参与处置的角色共同核对上述指标的变化，并对照权责表检查是否仍有事项找不到唯一决定人。复盘的重点是找出指标未改善的事项，回到原因排查环节重新验证假设，而不是简单追加规定。
把权责表纳入变更管理
权责划分会随组织调整而变化，权责表应作为受控文件纳入变更管理：组织架构调整、角色职责变化、流程修订时同步更新权责表，并记录变更原因与生效时间。这样做的目的是让权责表始终反映当前实际，避免出现制度与实际两张皮。
复发信号与再次排查的触发条件
出现以下信号时，应触发新一轮排查：同一类决策再次出现多人拍板或长期悬置；评审通过后再次出现无人跟进；跨团队等待事项数量回升；例外事项重新回到私下沟通。触发后不必推翻已有权责表，而是按“先查规则是否存在、再查规则是否冲突、最后查执行偏差”的顺序重新验证，定位是哪一类权责再次失衡，再做针对性调整。
常见问题
权责表编制完成后，如何避免它变成一份没人看的文件？
权责表的价值取决于它是否被实际使用。可行的做法是把权责表与具体事项绑定：每次决策或评审时，记录中注明依据权责表的哪一条、由谁决定；复盘时对照权责表检查是否有事项找不到唯一决定人。若连续出现表中有规定但实际未按表执行的情况，说明问题已从规则缺失转为规则未执行，应转向固化记录与超时升级，而不是继续扩充表格条目。
跨团队交付出现互相等待时，应该先改权责表还是先改流程？
先确认等待的原因属于哪一类。若双方团队都说不清谁对联合交付结果负责，属于交付责任真空，应先在权责表中明确牵头团队与验收人；若权责表已明确牵头方，但依赖排期与接口约定仍靠临时沟通，则属于执行机制问题，应补充依赖确认节点与超时升级规则。两类原因可能同时存在，建议先处理责任归属，再处理排期协同，避免在责任未定的情况下反复调整流程。
例外通道开放后，如何防止“特事特办”变成常态？
例外通道需要同时具备入口、记录和复核三个要素。入口指明确谁可以发起例外、向谁申请；记录指每次例外都留下批准人、原因和影响范围；复核指在固定周期内统计例外数量与类型，判断是否集中在某一环节。若某类例外反复出现，说明常规流程在该环节存在不合理限制，应回到规则层面修订，而不是继续依赖例外放行。例外数量持续上升本身就是一个复发信号。
观察期内指标没有明显改善，应该继续等待还是重新排查？
先区分是指标口径问题还是处置未生效。核对指标取数是否覆盖了处置涉及的事项范围，若口径本身不一致，先统一口径再观察一个周期。若口径无误而指标仍无改善，应回到原因排查环节，按“先查规则是否存在、再查规则是否冲突、最后查执行偏差”的顺序重新验证假设。常见情况是原判定的根因不准确，例如把规则冲突当成规则缺失处理，只补了新规定却未废止旧规定，冲突依然存在。
组织架构调整后，权责表应该整体重编还是逐项修订？
通常以逐项修订为主。整体重编会丢失历史变更记录，也不利于对照调整前后的差异。建议在权责表中保留变更原因与生效时间字段，组织调整时只修订受影响的角色与事项，并在修订后检查是否存在因角色撤销而产生的权责真空。若调整涉及多个部门合并或职责重新划分，受影响事项较多时，可分批次修订，每批完成后观察一段时间再推进下一批。
