混合项目里，阶段门要审批、迭代内又要快速调整范围，决策权和交付责任很容易混在一起：审批人以为开发负责人已经确认，开发负责人以为需求变更由产品经理拍板。本文给出一套可直接填写的职责矩阵方法，从列行清单、判定RACI字母，到按阶段门与迭代节点落表、维护留痕和完成检查，帮助项目管理者把“谁拍板、谁交付、谁被咨询、谁知会”写清楚。
要点总览（TL;DR）
- 先列行清单：把瀑布侧阶段门与基线变更、敏捷侧迭代范围与优先级调整作为决策对象，把阶段成果物与迭代增量作为交付对象，只纳入有争议或跨角色的行。
- RACI判定抓住两条硬规则：每行有且仅有一个A（拍板人），每个交付对象至少有一个R（交付负责人）；A与R可以分离，但需写明R向A提交的交付标准与确认时点。
- 按节奏落表：阶段门决策行指定审批人A与成果物负责人R，迭代决策行指定产品侧A与开发侧R，跨方法交接点写成带咨询时点的C和只告知结果的I。
- 矩阵需要Owner维护：阶段门通过、迭代范围变更、角色调整时触发更新，变更记录关联具体决策，避免矩阵写完即失效。
- 用一次真实变更走查矩阵，再按检查清单逐项验收：无两个A、无R缺位、C有时点、I不越界、与评审记录可对应，全部通过再正式使用。
先分清混合项目里哪些决策权和交付责任需要写进矩阵
职责矩阵的第一项工作是把要管理的对象列出来。混合项目同时存在瀑布式的阶段管控和迭代式的增量交付，决策与交付各有两类来源，混在一起写会导致一行里塞进多个决策点，无法判定唯一拍板人。建议先按下面的分类整理行清单，再开始画表。
决策权的两类来源
- 瀑布侧决策：阶段门是否通过、需求基线是否变更、设计或测试成果物是否达到放行标准。这类决策通常影响后续阶段的启动条件，需要明确的审批人和审批依据。
- 敏捷侧决策：迭代范围是否调整、优先级如何排序、插入的需求是否替换现有条目。这类决策发生在迭代节奏内，强调响应速度，但同样需要明确由谁定。
交付责任的两类对象
- 阶段成果物：需求基线文档、设计说明、测试报告等，交付责任指向对成果物完成度和质量负责的人。
- 迭代增量：每个迭代末可交付的功能增量，交付责任指向对功能按验收标准完成负责的人。
协作接口的识别
跨方法交接点是混合项目最容易出现责任真空的地方，例如迭代增量如何汇入阶段验收、阶段基线的变更如何进入迭代待办。跨团队依赖（如接口联调、共享组件）和外部评审（如合规、安全评审）也属于接口对象，应单独成行，标明谁需要被咨询、谁只需知会。
行清单的取舍原则
矩阵不必覆盖项目中的所有事务，优先纳入有争议、跨角色或曾经出过问题的对象。判断标准可以是：这件事过去是否出现过“以为对方负责”的情况；是否涉及两个以上角色；是否影响基线或交付承诺。满足其中一条，就值得单独成行。行数控制在十几到二十几行，超出说明颗粒度太细，可以按成果物或决策类型合并。
完成这一步的产出是一份行清单，每行标注对象类型（决策、交付或接口）、所属节奏（阶段门或迭代）和涉及角色，作为后续填写RACI的基础。
RACI字段怎么定义：决策权与交付责任分别落在哪个字母上
RACI的四个字母在混合项目里需要重新校准判定标准，尤其是A与R的区分。常见错误是把审批领导填成R，把实际干活的人填成A，或者把凡是需要知道的人都填成C，导致矩阵失去约束力。下表给出每个字母的判定问句和典型反例。
| 字母 | 含义 | 判定问句 | 常见反例 |
|---|---|---|---|
| A | 拍板人 | 这件事最终由谁说了“可以”或“不可以”，并对结果承担决策责任？ | 把整个部门或委员会填为A，导致无人真正负责 |
| R | 交付负责人 | 谁对这项成果物或增量的完成度和质量直接负责，需要组织实际工作？ | 把只做审批不参与交付的领导填为R |
| C | 事前咨询 | 谁的输入必须在决策或交付前被听取，否则结论可能不成立？ | 把“相关方”全部列为C，实际从未咨询 |
| I | 事后知会 | 谁只需要在结果确定后被告知，不参与讨论？ | 把需要参与讨论的人降为I，造成信息脱节 |
A的唯一性与适用层级
每一行只能有一个A。阶段门是否通过，A通常是阶段负责人或项目发起人；迭代内的范围调整，A通常是产品负责人。当同一对象涉及两级审批时，应拆成两行，例如“基线变更申请”由产品负责人拍板是否提交，“基线变更批准”由阶段负责人拍板是否生效，避免一行两个A。
R的判定与A的关系
R是对交付结果直接负责的人，可以是开发负责人、测试负责人或文档撰写人。A与R可以是同一人，但在混合项目中更常见的是分离：A决定做不做、做到什么程度，R负责把它做出来。分离时需要在矩阵中写明R向A提交的交付标准和确认时点，否则A的决策缺少依据。
C的触发条件与I的边界
C不是固定名单，而是带触发条件的角色。填写时应写明咨询时点，例如“基线变更提交前咨询架构负责人”“迭代范围调整影响外部接口时咨询集成负责人”。I只用于结果知会，例如阶段门结论同步给运维团队。如果某人需要参与讨论、提出意见，就应归入C，不能放在I里。
校验规则有两条：每行有且仅有一个A；每个交付对象至少有一个R。填写完成后逐行核对，出现两个A或没有R的行必须当场修正。
按混合项目节奏填写矩阵：阶段门与迭代节点分别怎么落
有了行清单和字母判定标准，就可以按项目节奏逐行填写。建议按以下五步推进，每一步都留下可核对的产物。
步骤一：按阶段门列出决策行
输入是项目阶段计划和阶段门检查项。动作是为每个阶段门建立决策行，指定审批人A和成果物负责人R，例如“需求基线评审”一行，A为阶段负责人，R为需求负责人。输出是阶段门决策行集合，完成标志是每个阶段门至少有一行对应，且A、R均已确认。
步骤二：按迭代节奏列出范围与优先级决策行
输入是产品待办列表和迭代计划。动作是为迭代范围调整、优先级排序建立决策行，A通常为产品负责人，R为开发负责人或迭代负责人。输出是迭代决策行集合，完成标志是每个迭代至少覆盖范围调整和优先级变更两类决策。
步骤三：把跨方法交接点写成C/I关系
输入是步骤一、二识别出的交接点，例如迭代增量汇入阶段验收、基线变更进入迭代待办。动作是为每个交接点补充C和I，并写明咨询时点与知会方式，例如“迭代评审前咨询测试负责人”“阶段门结论通过周会知会”。输出是接口行及其C/I关系，完成标志是每个交接点都有明确的咨询时点和知会渠道。
步骤四：为每行补充输入、输出与完成标志
仅有角色字母不足以执行，每行还需要写清触发输入、期望输出和完成标志。例如“迭代范围插入”一行，输入是变更请求和影响评估，输出是更新后的迭代待办，完成标志是A确认且R已调整计划。这一步让矩阵从角色表变成可执行的决策记录。
步骤五：用一次真实变更走查矩阵
选取近期发生的一次需求插入或基线调整，按矩阵逐行核对：实际拍板人是否与A一致，交付负责人是否与R一致，被咨询的角色是否在决策前收到输入，知会是否在结果确定后发出。走查中发现的不一致，直接修订矩阵，而不是修改历史记录。走查完成后，矩阵才算通过第一次实战检验。
角色与交付物分工：谁维护矩阵、谁确认、谁在什么时点更新
矩阵写完即失效是常见问题，原因通常是没有人对矩阵本身负责。需要明确矩阵的Owner、确认方式和更新触发点，并把变更留痕。
| 职责 | 承担角色 | 具体动作 | 留痕方式 |
|---|---|---|---|
| 矩阵Owner | 项目经理或项目集协调人 | 维护矩阵版本，记录每次变更的原因和影响行 | 版本号加变更说明 |
| 决策边界确认 | 各行A角色 | 确认自己拍板的范围和前置条件 | 确认记录或评审纪要 |
| 交付范围确认 | 各行R角色 | 确认交付标准、交付时点和所需输入 | 交付标准说明或迭代计划 |
| 更新触发 | Owner牵头 | 阶段门通过、迭代范围变更、组织角色调整时修订矩阵 | 变更记录关联具体决策 |
更新触发点应写进项目例行活动：阶段门评审通过后检查相关行是否仍准确；迭代范围发生变更时同步更新范围决策行；项目成员角色调整时，由Owner发起一次矩阵复核。矩阵变更需要能追溯到具体决策，例如某次基线变更批准后，矩阵中“基线变更批准”一行的A发生调整，变更记录应关联该次批准记录。
矩阵落地需要承载工作项、评审记录和变更留痕的工具环境。ONES支持在工作项中配置角色字段和审批流转，评审结论与变更记录可以关联到对应工作项，便于在阶段门和迭代评审时按矩阵核对责任归属。对于需要跨阶段追溯决策的项目，可以把矩阵行作为工作项属性维护，使每次变更都有记录可查。
示例：一个混合项目的职责矩阵片段
以下示例为演示情景：某单项目采用瀑布阶段门管控需求基线和阶段验收，开发侧按两周迭代交付功能增量。矩阵片段选取三类对象，展示A、R、C、I的填写结果与理由。
| 对象 | 类型 | A | R | C | I | 填写理由 |
|---|---|---|---|---|---|---|
| 需求基线变更 | 决策 | 阶段负责人 | 需求负责人 | 架构负责人、测试负责人 | 运维团队 | 基线变更影响阶段放行，由阶段负责人拍板；需求负责人组织变更分析和文档更新；架构与测试在提交前提供影响评估 |
| 迭代范围插入 | 决策 | 产品负责人 | 开发负责人 | 测试负责人 | 阶段负责人 | 迭代内范围调整由产品负责人拍板；开发负责人调整计划并交付；测试负责人评估测试影响；阶段负责人知会结果 |
| 阶段验收报告 | 交付 | 阶段负责人 | 测试负责人 | 需求负责人、开发负责人 | 项目发起人 | 验收报告由测试负责人组织编写并对完成度负责；阶段负责人批准；需求与开发在编写前提供确认信息 |
走查发现的问题与修正
用一次真实的需求插入走查时，发现两个问题。第一，“迭代范围插入”最初把产品负责人和阶段负责人同时填为A，原因是插入需求影响了阶段基线。修正方式是拆成两行：迭代内是否插入由产品负责人拍板，插入后是否触发基线变更由阶段负责人拍板，两行各自唯一A。第二，“阶段验收报告”最初没有填R，默认由阶段负责人兼写，实际执行中报告质量无人把关。修正后明确测试负责人为R，并在行内补充交付标准：报告需覆盖验收项、测试结论和遗留问题清单。
修正后的矩阵在下一轮迭代中再次走查，确认每次范围插入都先经产品负责人确认，触发基线变更时再提交阶段负责人，两个决策点的记录可以分别追溯。
完成检查：矩阵可用的判断标准
矩阵填写完成后，用以下清单逐项检查。每项给出通过或不通过的判断依据，全部通过才建议正式投入使用。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 每行有且仅有一个A | 逐行核对，无两个A或A空缺 | 拆分决策层级或明确唯一拍板人 |
| 每个交付对象有明确R | R知晓交付标准、交付时点和所需输入 | 补充R并确认交付标准 |
| C的触发条件写明时点 | 每行C均标注在哪个节点前咨询，不停留在“相关方” | 补充咨询时点和输入要求 |
| I的范围合理 | I名单中的人只需结果知会，不参与讨论 | 将需参与讨论者调整为C |
| 矩阵与评审记录可对应 | 阶段门和迭代评审的结论能对应到矩阵行 | 补充行与评审节点的映射 |
| 最近一次变更已按矩阵执行并留痕 | 变更记录中有A的确认、R的交付调整和C的输入 | 复盘变更过程，修订矩阵并记录 |
检查通过后，矩阵应作为项目例会的对照材料：阶段门评审前核对决策行，迭代评审后核对范围决策行，角色调整时触发复核。矩阵的价值在于持续使用和及时更新，一次填写只能解决当下的责任划分，配合维护机制才能在混合项目的整个周期内保持决策权和交付责任清晰。
常见问题
矩阵里同一件事既涉及迭代范围调整又触发基线变更，A应该填谁？
拆成两行，不要在一行里放两个A。第一行是“迭代内是否插入该需求”，A为产品负责人，R为开发负责人；第二行是“插入后是否触发基线变更”，A为阶段负责人，R为需求负责人。两行各自唯一A，并通过C/I关系衔接：第二行的C可以包含产品负责人，第一行的I可以包含阶段负责人。这样两个决策点分别留痕，追溯时能看清是哪一级拍板导致了基线变化。
项目经理能不能同时担任多个行的A？
可以，但要看决策性质。项目经理适合担任跨团队协调、资源冲突裁决这类决策行的A；阶段门放行、基线变更批准通常应由阶段负责人或项目发起人拍板，迭代范围调整由产品负责人拍板。如果项目经理在多数行都是A，需要检查是否把审批职责集中到了一人身上，导致决策依据和交付标准无人独立确认。A的判定标准是“最终说可以或不可以并对结果承担决策责任”，而不是“谁在协调这件事”。
团队规模小、角色一人多岗时，RACI还能用吗？
能用，但需要额外标注兼任关系。一人多岗时，同一个人可能在不同行分别担任A和R，这本身不违反规则，前提是每行仍然只有一个A、交付对象有明确R。建议在矩阵中增加一列“兼任说明”，写清同一角色在不同行承担的不同职责，避免执行时把拍板与交付混为一谈。走查时重点核对：兼任者是否在决策前完成了C角色的输入，是否在交付后按R的标准确认完成度。
矩阵更新后，之前按旧矩阵执行的决策要不要追溯修改？
不修改历史记录，只修订矩阵并保留变更说明。正确做法是：在变更记录中写明哪一行、因何调整、从哪个时点生效，并把旧版本归档。已经发生的决策按当时的矩阵执行情况记录，复盘时对照新旧矩阵分析差异原因。这样既保持了决策记录的真实性，也能让后续阶段门和迭代评审按新矩阵执行。如果旧矩阵存在两个A或R缺位导致决策依据不足，应在变更说明中标注该风险，并在下一次同类决策时按新矩阵补齐确认环节。
阶段门评审和迭代评审的结论如何与矩阵行对应起来？
在矩阵每行增加“关联评审节点”字段，写明该行对应哪次阶段门或哪个迭代评审。评审纪要中记录本次涉及的矩阵行编号和实际执行角色，评审结束后由矩阵Owner核对：实际拍板人是否与A一致、交付负责人是否与R一致、C角色是否在决策前提供了输入。发现不一致时，区分是执行偏差还是矩阵设计问题，前者在例会上纠正，后者触发矩阵修订。这样矩阵与评审记录形成双向可查的关系，而不是两套各自独立的文档。
