研发治理权责矩阵模板是一张以“治理事项×治理角色”为主体的空白表，单元格填写R/A/C/I四类权责代码，并配套事项定义、角色授权、升级与例外规则三张附表。填写顺序建议为：先列全治理事项，再为每个事项确定唯一A（最终负责），然后分配R（执行）、C（被咨询）、I（被通知），最后补齐升级路径与评审节点。下文给出可直接复制到文档或表格工具中的四张空白表、逐字段填写口径、必填与选填清单、一条完整示例，以及矩阵落地后的维护方法。
要点总览（TL;DR）
- 模板由四张表组成：治理事项×治理角色主表，以及事项定义、角色授权、升级与例外规则三张附表，可直接复制到文档或表格工具中填写。
- 填写顺序是先列全治理事项，再为每个事项确定唯一A（最终负责），然后分配R（执行）、C（被咨询）、I（被通知），最后补齐升级路径与评审节点。
- 最低可用标准是每个事项都有名称、类别和唯一A，且该A在附表二中有对应授权说明；C、I、决策层级等可按成熟度逐步补充。
- 文中以“研发重大技术方案变更的评审与批准”为例，演示主表行与三张附表对应行的完整填法，可对照验证字段口径是否一致。
- 矩阵落地后由PMO负责维护，人员变动只更新附表二的岗位与代理人，组织调整或连续出现同类升级时触发专项复核，并保留版本记录。
可复制空白模板
以下四张表构成一套完整模板。主表用于日常查阅“谁对什么事负什么责”，三张附表分别回答“事项指什么”“角色有什么权”“出问题找谁批”。建议将四张表放在同一文档中，主表在前，附表依次附后，便于评审时对照使用。
主表：治理事项×治理角色权责矩阵
角色列可按组织实际设置增减，下表列出常见治理角色作为起点。单元格填写R、A、C、I中的一个或多个代码，多个代码用“/”分隔，A必须且只能出现一次。
| 序号 | 治理事项 | 事项类别 | 决策层级 | 触发时点 | 治理委员会 | PMO | 产品负责人 | 技术负责人 | 质量负责人 | 财务/法务接口 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||||
| 2 | ||||||||||
| 3 | ||||||||||
| 4 | ||||||||||
| 5 |
附表一：治理事项定义表
每个治理事项在主表中只占一行，其完整定义放在本表。事项名称需与主表逐字一致，便于交叉检索。
| 事项编号 | 治理事项名称 | 事项类别 | 定义与边界 | 触发条件 | 决策层级 | 关联流程/制度 | 输出物 |
|---|---|---|---|---|---|---|---|
附表二：治理角色与授权说明表
本表说明每个角色“能定什么、不能定什么”，是判断R/A/C/I分配是否合理的依据。同一角色在不同事项上授权范围可以不同，按事项类别分行填写。
| 角色名称 | 适用事项类别 | 授权范围 | 授权上限/限制条件 | 对应岗位 | 代理人 |
|---|---|---|---|---|---|
附表三：升级与例外处理规则表
用于规定“A无法决断时怎么办”“超出授权怎么办”。每条规则对应一类情形，写明升级条件、升级对象、时限与例外审批人。
| 规则编号 | 适用事项/情形 | 升级条件 | 升级对象 | 升级时限 | 例外审批人 | 记录要求 |
|---|---|---|---|---|---|---|
字段说明：每个列名填什么
字段口径不统一是权责矩阵最常见的失效原因：同一列在不同人手里填出不同含义，矩阵就失去对照价值。下表逐字段给出含义、填写口径与常见错误，主表与三张附表一并覆盖。
主表字段
| 字段名 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 治理事项 | 需要明确权责的一项治理活动 | 用“动作+对象”命名，如“重大技术方案变更的评审与批准”；一事一行，不合并 | 写成部门名或岗位名；把多个事项塞进一行 |
| 事项类别 | 事项所属的治理分类 | 按组织既有分类填写，如技术决策、质量门禁、资源投入、合规审查；类别用于批量分配角色 | 类别过多过细，导致每类只有一条 |
| 决策层级 | 该事项最终在哪一层拍板 | 填写层级名称，如项目级、项目集级、公司级；与附表二授权范围对应 | 层级名称与组织实际层级不一致 |
| 触发时点 | 什么情况下启动该事项的治理动作 | 写具体节点或事件，如“方案进入开发前”“里程碑评审前”“变更影响范围超出基线时” | 写“需要时”“定期”等无法执行的表述 |
| 角色列 | 承担权责的治理角色 | 填角色而非人名；角色与附表二角色名称一致；单元格填R/A/C/I代码 | 直接填人名，人员变动后矩阵失效 |
R/A/C/I四类权责代码
四个代码回答的是不同问题：A回答“谁最终拍板并承担结果”，R回答“谁动手做”，C回答“决策前必须听谁的意见”，I回答“结果出来后要告知谁”。判定时先定A，再定R，最后区分C与I。
| 代码 | 定义 | 判定要点 | 数量约束 |
|---|---|---|---|
| A（Accountable） | 对事项结果最终负责、拥有批准权 | 问“这件事做砸了谁负责”“谁签字才算通过”，答案指向的角色即A | 每个事项有且只有一个A |
| R（Responsible） | 实际执行、产出交付物的角色 | 问“谁动手写方案、做评审材料、推进流程”，可多人分担但需明确分工 | 至少一个，可多个 |
| C（Consulted） | 决策前需被咨询、意见需被记录的角色 | 问“不问谁会出问题”，双向沟通；意见进入决策记录但不拥有否决权（除非另有规定） | 按需，宜少不宜多 |
| I（Informed） | 结果确定后需被通知的角色 | 问“谁需要知道结果但不必参与过程”，单向告知 | 按需 |
需要提醒的是，C与I的边界容易混淆。判断标准是时间与方向：决策发生前需要征求意见的填C，决策完成后只需知晓的填I。把大量角色填成C会让评审会变成意见收集会，决策效率下降；把该咨询的角色降为I，则可能在执行阶段返工。
角色列的填写口径
角色列应填组织内真实存在、有明确授权来源的治理角色。常见角色及填写口径如下：治理委员会填集体决策角色，适用于跨部门重大事项；PMO填流程组织与信息汇总角色，通常承担R或C；产品负责人填业务价值与需求优先级相关事项的A或C；技术负责人填技术方案、架构相关事项的A；质量负责人填质量门禁、发布标准相关事项的A或C；财务/法务接口填预算、合同、合规相关事项的C，涉及合规否决权时在附表二中单独写明。
附表字段
| 字段名 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 授权范围 | 角色可自主决定的事项边界 | 写“可决定什么”与“超出什么需上报”，用金额、影响范围、变更类型等可判断的条件描述 | 只写“负责技术工作”这类无法判断边界的表述 |
| 升级条件 | 触发向上汇报或转交决策的情形 | 写可观察的条件，如“A在约定时限内未决断”“影响范围超出本层级授权”“跨两个以上部门无法达成一致” | 写“情况严重时”，缺乏判断标准 |
| 例外审批人 | 常规授权之外情形的批准角色 | 填角色名称，并注明可批准的例外类型；与升级对象区分，例外审批针对规则外情形 | 例外审批人与升级对象混为一谈 |
必填与选填：哪些格子不能空
模板不要求一次填满。先达到“最低可用”标准，让矩阵能够支撑一次真实评审，再逐步补充。最低可用的判定标准是：每个治理事项都有名称、类别和唯一A，且该A在附表二中有对应授权说明。满足这三条，矩阵即可投入使用。
必填项
- 主表：治理事项名称、事项类别、唯一A角色。三项缺一，该行不具备执行意义。
- 主表：每个事项至少一个R角色，否则事项无人推进。
- 附表一：事项编号、事项名称、定义与边界、触发条件。定义与边界用于区分相邻事项，避免同一件事被两个流程重复治理。
- 附表二：角色名称、授权范围。没有授权范围的角色无法判断其A是否成立。
- 附表三：适用情形、升级条件、升级对象。至少覆盖“A逾期未决”和“超出授权”两类高频情形。
选填项
- 主表：C与I角色、决策层级、触发时点。C与I可按事项成熟度逐步补充；决策层级在组织层级简单时可暂不填。
- 附表一：关联流程/制度、输出物。用于与现有制度对接，可在矩阵运行一段时间后补齐。
- 附表二：授权上限/限制条件、对应岗位、代理人。代理人字段在角色由多人轮值时填写。
- 附表三：升级时限、例外审批人、记录要求。时限可按事项紧急程度差异化设置。
唯一A的约束
每个事项只能有一个A，这是矩阵有效性的核心约束。出现两个A时，决策责任被稀释，争议时无人拍板；出现零个A时，事项在流程中悬空。若确实存在共同决策场景，处理方式是将A设为一个集体角色（如治理委员会），并在附表二中写明该集体的表决规则与召集人，而不是在同一行填两个A。R可以多人，但应在附表一输出物中写清各自负责的交付部分。
填写示例：一条治理事项的完整填法
以下示例演示“研发重大技术方案变更的评审与批准”这一事项从定义到矩阵再到升级规则的完整填法。示例中的角色设置为演示情景，组织可按实际调整角色名称与授权边界。
主表对应行
| 序号 | 治理事项 | 事项类别 | 决策层级 | 触发时点 | 治理委员会 | PMO | 产品负责人 | 技术负责人 | 质量负责人 | 财务/法务接口 |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 研发重大技术方案变更的评审与批准 | 技术决策 | 项目集级 | 变更影响范围超出既定技术基线时 | I | R | C | A | C | I |
这一行的读法是：技术负责人对该变更最终负责并批准；PMO负责组织评审、汇总材料并推进流程；产品负责人与质量负责人在决策前必须被咨询，意见进入评审记录；治理委员会与财务/法务接口在结果确定后被告知。A只有一个，落在技术负责人。
附表一对应行
| 事项编号 | 治理事项名称 | 事项类别 | 定义与边界 | 触发条件 | 决策层级 | 关联流程/制度 | 输出物 |
|---|---|---|---|---|---|---|---|
| GOV-01 | 研发重大技术方案变更的评审与批准 | 技术决策 | 涉及架构调整、核心组件替换、对外接口变更的方案变更；不含缺陷修复与配置参数微调 | 变更影响范围超出既定技术基线，或影响两个以上系统 | 项目集级 | 技术评审管理办法 | 变更评审记录、批准结论、回退预案 |
附表二对应行
| 角色名称 | 适用事项类别 | 授权范围 | 授权上限/限制条件 | 对应岗位 | 代理人 |
|---|---|---|---|---|---|
| 技术负责人 | 技术决策 | 可批准不改变对外接口、不新增外部依赖的技术方案变更 | 涉及对外接口变更或新增外部依赖时，须提交治理委员会 | 技术总监 | 架构师（轮值） |
附表三对应行
| 规则编号 | 适用事项/情形 | 升级条件 | 升级对象 | 升级时限 | 例外审批人 | 记录要求 |
|---|---|---|---|---|---|---|
| ESC-01 | GOV-01 技术方案变更 | 技术负责人在收到完整评审材料后三个工作日内未给出结论，或变更超出其授权上限 | 治理委员会 | 触发后两个工作日内上会 | 治理委员会主任 | 升级原因、各方意见、最终结论记入变更评审记录 |
示例与字段说明的对应关系
回看示例可以验证字段口径：主表的“触发时点”与附表一的“触发条件”表述一致，均指向影响范围超出基线；“决策层级”在主表与附表一中同为项目集级；附表二的授权上限直接决定了附表三中“超出授权”这一升级条件的成立；主表中技术负责人为A，附表二随即给出其授权范围与限制，二者互为支撑。若某行在附表中找不到对应授权说明，说明该A的设定尚不成立，应回到附表二补充或调整角色。
调整与维护方法：矩阵怎么随组织变化更新
权责矩阵失效通常不是一次填错，而是组织变化后无人更新。维护机制要解决三个问题：谁有权改、什么时候改、改了什么留痕。建议指定PMO作为矩阵的维护责任人，负责收集变更、组织复核与发布新版本，各角色负责人对本角色相关行提出修改建议。
事项增删规则
- 新增事项：由提出方填写附表一的事项定义，明确边界与触发条件，经维护责任人确认不与现有事项重叠后，再在主表增加一行并分配R/A/C/I。
- 撤销事项：先确认该事项对应的流程或制度已废止，再在主表标注“已撤销”并注明日期，保留历史行而非直接删除，便于追溯。
- 合并事项：两个事项边界重叠时合并为一条，原编号在附表一中保留并注明合并去向。
角色与人员变动
矩阵填角色不填人名，因此人员变动只需更新附表二中的“对应岗位”与“代理人”，主表通常无需改动。角色本身调整（如新设或撤销某治理角色）时，需同步检查所有引用该角色的事项行，确认A是否仍然唯一、R是否仍然有人承担。更新时点为任命生效前完成，避免出现权责空档期。
定期复核与触发条件
建议每半年进行一次常规复核，逐行确认事项是否仍存在、A是否仍匹配授权、升级规则是否仍可执行。出现以下情形时应立即触发专项复核：组织架构调整、重大流程或制度变更、连续出现两次以上同类升级或例外审批、审计或合规检查提出权责不清问题。复核结论需记录在版本记录中，无变化也记录“复核无变更”。
版本记录表头
| 版本号 | 生效日期 | 变更类型 | 变更内容摘要 | 涉及事项/角色 | 提出人 | 批准人 | 备注 |
|---|---|---|---|---|---|---|---|
变更类型可设为新增、修订、撤销、复核无变更四类。每次发布新版本时保留上一版本，矩阵文档标注当前生效版本号，避免评审时引用过期版本。
与评审会议、审批流程的衔接
矩阵只有嵌入实际流程才有效。做法是把主表中的治理事项与现有评审会议议程、审批节点逐一对应：每个评审会议应能指出它处理的是矩阵中的哪几行，每个审批节点应能指出审批人对应哪个A或C。衔接检查可以按季度做一次，发现会议议题在矩阵中找不到对应事项，或矩阵中的事项从未在任何会议或审批中出现，都属于需要修正的信号。
当评审、审批与变更记录分散在多个文档和沟通工具中时，矩阵的维护成本会明显上升。ONES 的文档与工作项协作能力可用于承载评审记录、审批结论与变更留痕，使矩阵中的事项与实际的评审、审批过程保持对应；具体支持范围与版本要求建议结合组织实际部署情况核验。矩阵本身作为治理规则文档，仍建议以独立文档维护并纳入版本管理。
常见问题
组织里已经有审批流程和会议机制，还需要单独维护这张权责矩阵吗？
需要，但两者分工不同。审批流程规定“怎么走”，权责矩阵回答“谁对什么负最终责任”。当流程节点上的审批人与矩阵中的A不一致时，争议往往出在责任归属而非流程本身。建议把矩阵作为规则文档独立维护，再逐项对应到现有评审会议议程和审批节点：每个会议能指出处理矩阵中哪几行，每个审批节点能指出对应哪个A或C。对应不上的地方，就是需要修正的权责缺口。
一个事项涉及多个部门共同决策，A只能填一个角色，怎么处理？
把A设为一个集体角色，例如治理委员会，并在附表二中写明该集体的召集人、表决规则和有效决议条件。主表该行只出现一个A，避免责任稀释；各部门代表作为C参与决策前咨询，意见进入决策记录。若集体在约定时限内无法形成决议，由附表三的升级规则规定转交对象，例如上级治理机构或指定负责人。
矩阵填完后，怎么判断它是否真的在起作用？
可以从三个可观察的信号判断：一是评审会议议题能否在矩阵中找到对应事项，找不到说明事项清单不全；二是矩阵中的事项是否在实际审批和会议中出现，长期不出现说明该行可能已失效；三是升级与例外规则是否被真实触发并留下记录，从未触发可能是规则定得过松或无人执行。建议按季度做一次衔接检查，把发现的问题记入版本记录并修订。
小团队角色少，一个人同时承担多个角色，矩阵还有必要填吗？
有必要，但可以简化。角色少时，主表角色列可合并为少数几列，同一人在不同事项上可能同时是A和R，此时在单元格填“A/R”即可，关键是每个事项仍只有一个A。附表二可只保留角色名称与授权范围两列，附表三至少覆盖“A逾期未决”和“超出授权”两类情形。团队扩张或职责拆分时，再按维护规则补充角色列和授权说明。
矩阵中的事项和项目集、项目组合的管理内容如何划分边界？
本文模板聚焦组织层面的治理权责分配，即“谁对哪类治理事项负什么责”。项目集的日常运行与状态监控、项目组合的投资决策机制属于另外的管理主题，不在本模板范围内展开。实际操作中，项目集层面的进度与依赖协调可作为矩阵中的一个事项类别纳入，但其具体运行方法仍由对应的项目集管理机制承载，矩阵只规定该类事项的A、R、C、I归属。
