混合项目里职责容易打架，往往不是角色不配合，而是瀑布与敏捷交界处的协作接口没有定义清楚：谁批准需求变更、谁对迭代交付负责、评审结果交给谁。本文给出一套可执行的做法：先把项目切成若干协作接口，再对每个接口用RACI标注执行、批准、咨询和知会，并明确输入、输出、触发时点与完成标志。矩阵中的接口和角色，可以借助ONES的项目计划与文档协作能力承载。
要点总览（TL;DR）
- 先按协作接口建行，再填RACI：把需求交接、计划对齐、评审验收、变更决策、发布交接等交界事项列成接口清单，作为矩阵的行。
- 每个接口只设一个A，并让R与A分离：批准权归对该接口结果负责的角色，执行者单独标注，出现双A或无人R时按业务目标归属修正。
- 瀑布侧阶段负责人与敏捷侧角色写在同一接口行上，同时写清输入、输出、触发时点和完成标志，接口两端才能对齐。
- 矩阵由项目经理牵头编制、逐接口过会确认，并在阶段切换、迭代边界和人员变动时更新；发布前核对接口全覆盖、唯一A、两端角色齐全。
- 矩阵中的接口与角色可落到ONES的项目计划、里程碑和知识库文档中承载，使矩阵条目与执行中的工作项对应。
先定接口，再填矩阵：混合项目的划分顺序
职责矩阵填不清楚，常见原因是行没选对。按部门或按人名建行，得到的是组织架构图，无法回答“这件事谁拍板、谁交付”。混合项目的职责冲突集中发生在瀑布与敏捷的衔接处，因此矩阵的行应当是协作接口，即两个角色或两条工作流之间需要交接、确认或共同决策的事项。
识别接口的输入有三类：一是阶段划分，明确瀑布侧的需求、设计、开发、测试、验收各阶段边界；二是迭代节奏，明确迭代起止、评审与回顾时点；三是交付物清单，明确每个阶段或迭代产出什么、交给谁。三者对齐后，接口自然浮现。
混合项目中常见的协作接口类型包括：
- 需求交接：瀑布侧完成需求定义后，交给敏捷侧进入迭代池。
- 计划与排期对齐：阶段计划与迭代计划在时间、资源、依赖上的协调。
- 评审与验收：迭代产出提交阶段评审或验收，形成通过或退回结论。
- 变更决策：需求或范围变更由谁评估影响、谁批准、如何回写计划。
- 发布与上线交接：迭代成果移交发布流程，明确发布窗口与回滚责任。
按接口建行有三个好处：每个接口天然对应一次跨边界交接，责任边界清晰；接口数量有限，矩阵规模可控；接口可以挂上触发时点和完成标志，便于后续检查。识别完成后输出一份接口清单，包含接口名称、涉及的两端角色、触发时点，这份清单就是矩阵的行。
| 接口名称 | 瀑布侧角色 | 敏捷侧角色 | 触发时点 |
|---|---|---|---|
| 需求交接 | 需求负责人 | 产品负责人 | 需求基线确认后 |
| 计划与排期对齐 | 阶段负责人 | 迭代负责人 | 每轮迭代规划前 |
| 评审与验收 | 阶段评审人 | 迭代负责人 | 迭代评审会 |
| 变更决策 | 项目负责人 | 产品负责人 | 变更申请提出时 |
| 发布与上线交接 | 发布负责人 | 迭代负责人 | 迭代完成、进入发布窗口前 |
RACI怎么标：决策权、交付责任与协作接口的对应规则
RACI的价值在于把“谁干活”和“谁拍板”分开。在接口场景下，四个字母的判定标准如下：
- R（执行）：实际完成该接口动作的人，产出接口约定的交付物。一个接口可以有多个R，但每个R的交付内容要写清。
- A（批准）：对该接口结果承担最终责任、拥有否决或批准权的人。每个接口只设一个A。
- C（咨询）：在接口动作完成前需要被征求意见的人，其意见影响方案但不拥有批准权。
- I（知会）：接口完成后需要被告知结果的人，不参与决策。
每个接口只设一个A，是避免双头决策的关键。当出现两个角色都认为自己该批准时，处理方式是回到接口定义：这个接口的最终产出归谁的业务目标负责，A就归谁；另一方降为C，在动作完成前提供意见。R与A分离同样重要：如果同一个人既是R又是A，说明该接口缺少独立把关，应补充评审角色承担A，或明确该接口无需批准、直接由R完成并知会相关方。
瀑布侧阶段负责人与敏捷侧角色要出现在同一接口行上。写法上，左侧列角色，右侧按接口逐列标注字母。例如需求交接接口，瀑布侧需求负责人标R，敏捷侧产品负责人标A，测试负责人标C，项目经理标I。这样一行之内就能看出两端如何对接，而不是把瀑布和敏捷拆成两张表各说各话。
常见冲突及修正方式：
| 冲突现象 | 识别方法 | 修正方式 |
|---|---|---|
| 双A | 同一接口行出现两个A | 按业务目标归属确定唯一A，另一方改为C |
| 无人R | 接口行只有A、C、I，没有执行者 | 指定具体角色承担交付，写清交付物 |
| C过多 | 一行中C超过三个，决策周期拉长 | 区分“必须咨询”和“知会即可”，将部分C降为I |
| R与A同一人 | 执行者同时是批准者 | 补充独立评审角色，或确认该接口免批准并记录理由 |
角色与交付物：谁填矩阵、谁确认、谁维护
矩阵本身也是一项需要分工的交付物。编制阶段由项目经理或项目负责人牵头，负责汇总接口清单、组织填写、处理冲突。瀑布侧阶段负责人提供阶段划分、交付物清单和阶段评审安排；敏捷侧产品负责人和迭代负责人提供迭代节奏、需求池状态和迭代产出。两端信息汇齐，矩阵才有填写依据。
确认阶段由项目负责人组织评审，参与方至少包括瀑布侧阶段负责人、敏捷侧产品负责人和关键接口的A角。确认方式建议采用逐接口过会：每个接口核对是否有唯一A、是否有明确R、两端角色是否齐全、触发时点是否可执行。确认结果形成版本记录，作为后续变更的基线。
维护责任归项目经理或指定的矩阵管理员。更新触发条件包括：阶段切换时，检查接口两端角色是否随阶段变化；迭代边界处，核对计划对齐接口的触发时点是否仍然成立；人员变动时，及时替换角色对应人员，避免矩阵停留在旧人名上。每次更新记录变更原因和生效时间。
| 角色 | 编制阶段交付物 | 确认阶段职责 | 维护阶段职责 |
|---|---|---|---|
| 项目经理/项目负责人 | 接口清单、矩阵初稿 | 组织评审、裁定冲突 | 维护矩阵版本、触发复查 |
| 瀑布侧阶段负责人 | 阶段划分、交付物清单 | 确认阶段相关接口 | 阶段切换时提出更新 |
| 敏捷侧产品负责人 | 需求池状态、验收标准 | 确认需求与变更接口 | 迭代边界时核对接口 |
| 敏捷侧迭代负责人 | 迭代节奏、迭代产出清单 | 确认评审与发布接口 | 迭代计划调整时同步 |
填一张示例：需求交接与变更决策两个接口的矩阵
下面用两个接口示范填写方式。示例为演示情景，角色名称可按实际项目替换。
需求交接接口：瀑布侧完成需求基线后，将需求移交敏捷侧进入迭代池。输入是已确认的需求文档和验收标准；输出是进入迭代池的需求条目及交接记录；触发时点是需求基线评审通过；完成标志是敏捷侧产品负责人确认接收并纳入需求池。
| 角色 | R | A | C | I |
|---|---|---|---|---|
| 瀑布侧需求负责人 | R | |||
| 敏捷侧产品负责人 | A | |||
| 测试负责人 | C | |||
| 项目经理 | I |
变更决策接口：需求或范围发生变更时，由提出方发起，评估影响后决定是否纳入。输入是变更申请及影响分析；输出是变更决策结论和更新后的计划；触发时点是变更申请提交；完成标志是A角签署决策并回写项目计划与迭代计划。
| 角色 | R | A | C | I |
|---|---|---|---|---|
| 变更提出方 | R | |||
| 项目负责人 | A | |||
| 敏捷侧产品负责人 | C | |||
| 瀑布侧阶段负责人 | C | |||
| 迭代负责人 | I |
两个示例体现了同一原则：执行者（R）负责产出，批准者（A）唯一且独立，两端角色同处一行。需求交接中瀑布侧执行、敏捷侧批准，变更决策中提出方执行、项目负责人批准，敏捷侧以咨询身份参与影响评估。这样的写法让决策权和交付责任各归其位，接口两端都清楚自己在什么时候做什么。
在ONES中，这类接口可以落到具体承载物上：用项目计划按阶段或交付物分解工作，并为关键节点设置里程碑标记决策点；需求、任务与迭代可以在项目下关联管理，接口的交接记录和矩阵文档则可通过知识库文档关联对应任务，使矩阵条目与执行中的工作项对应起来。
矩阵落地与完成检查
矩阵确认后需要发布和宣贯，否则容易停留在文档里。发布动作包括：将矩阵定稿版本放入项目共享文档，在项目启动会或阶段切换会上逐接口说明A角和R角，确保每个角色知道自己参与的接口、触发时点和交付物。宣贯的重点是A角和R角，C和I可以随接口说明一并告知。
接口在协作工具或文档中的承载方式建议统一：每个接口对应一条记录或一个工作项，记录接口名称、两端角色、触发时点、完成标志和矩阵版本；矩阵文档与这些记录相互关联，避免两处信息不一致。接口状态随项目推进更新，完成标志达成后标记关闭。
矩阵发布前逐项核对以下检查项：
- 接口全覆盖：需求交接、计划对齐、评审验收、变更决策、发布交接等关键接口均有对应行。
- 每行唯一A：不存在双A，也不存在无A的接口。
- R与A分离：执行者与批准者不是同一角色，或已记录免批准理由。
- 两端角色齐全：瀑布侧与敏捷侧角色同时出现在接口行上。
- 触发时点明确：每个接口都有可执行的触发条件和完成标志。
矩阵失效的信号包括：接口频繁在会议外被临时协调、变更找不到批准人、评审结论无人接收、人员调整后矩阵未更新。出现这些信号时，应在最近一次阶段切换或迭代边界安排复查，重点核对A角归属和两端角色是否仍然有效。复查不必等到项目结束，按阶段和迭代节奏定期检查，矩阵才能持续可用。
常见问题
接口数量很多时，矩阵要不要每个接口都单独一行？
建议按“一次跨边界交接”为单位建行，而不是按每个任务建行。判断标准是：这个事项是否需要两端角色交接、确认或共同决策，并且有明确的触发时点和完成标志。满足就单独成行；只是同一接口下的不同交付物，可以合并为一行并在交付物栏列出。接口行过多时，优先保留影响决策和交付的关键接口，其余按类型归并，避免矩阵变成任务清单。
瀑布侧和敏捷侧对同一个接口都认为自己该批准，怎么处理？
回到接口定义判断最终产出的业务目标归谁负责，A就归谁，另一方降为C，在动作完成前提供意见。如果双方业务目标确实交叉，说明接口本身需要拆成两个：一个负责方案确认，一个负责纳入执行，各自设唯一A。处理结果要写入矩阵版本记录，并在宣贯时说明，避免会后再次出现双头决策。
矩阵确认后人员发生调整，接口责任怎么衔接？
人员变动属于矩阵的更新触发条件。做法是替换角色对应人员而非改动接口结构，保留接口名称、触发时点和完成标志不变，只更新承担R、A、C、I的具体人员，并记录变更原因和生效时间。新任A角需要单独确认其负责的接口清单，避免只更新文档而未完成交接。若变动涉及阶段负责人或产品负责人这类关键角色，建议在最近一次阶段切换或迭代边界安排一次接口复查。
矩阵和项目计划、迭代计划是什么关系，需要各维护一份吗？
矩阵回答“谁在接口上做什么”，计划回答“什么时候做”，两者应相互引用而非各自独立维护。可行做法是让每个接口对应计划中的一条记录或一个工作项，记录接口名称、两端角色、触发时点和完成标志，矩阵文档与这些记录关联。在ONES中，可用项目计划按阶段或交付物分解工作、用里程碑标记决策点，并通过知识库文档关联对应任务，减少两处信息不一致。
小团队或接口较少的项目，也需要完整填RACI吗？
可以简化，但保留两条底线：每个接口有唯一A，执行者与批准者能区分开。接口少时，C和I可以合并说明，甚至只在接口清单中注明知会对象，不必逐行列全。简化后仍要写清触发时点和完成标志，否则接口在推进中容易退回口头协调。团队规模、项目复杂度不同，矩阵的详细程度可以调整，判断标准是接口两端能否据此确认各自的动作和时点。
