研发项目启动阶段最常见的卡点，是几个关键交付物在计划表里找不到明确负责人，或者同一件事几个人都能拍板、却没人真正执行。本文给出一套可操作的方法：先用责任矩阵逐格扫描缺口，再按接口优先的顺序补齐，把结果落到角色—交付物分工表，最后用检查清单在启动评审上把关。
要点总览（TL;DR）
- 用一张覆盖关键交付物的责任矩阵逐格扫描，把缺口归为整格空白、同一交付物多个 A、有 A 无 R 三类，输出带影响排序的缺口清单。
- 补齐按“先定接口、再定角色、最后定人”的顺序推进：先确认需求到发布主链路上每个接口的双方责任人，再为无主交付物指定临时承接角色并写明期限与转正条件，然后收敛多 A 冲突。
- 把矩阵结果落到角色—交付物分工表，补齐交接物与交接时点，并区分临时承接与正式任命的记录方式。
- 启动评审以证据把关：每个关键交付物有唯一 A 且有可执行 R、关键接口双方已确认、临时承接有期限与转正条件；关键交付物无 A 或发布回滚类职责空缺未处置时不宜进入执行阶段。
先用责任矩阵把职责空缺扫出来
识别职责空缺最有效的载体是一张启动阶段责任矩阵。它把“谁负责什么”从口头约定变成可逐格检查的表格，让空白和冲突显性化。建议用一到两次工作坊完成初版，参与人应覆盖项目经理、技术负责人、产品/需求负责人、测试负责人和发布/运维接口人。
行与列怎么确定
行是启动阶段必须有人对结果负责的关键交付物或活动，例如需求基线、技术方案、接口定义、测试策略、发布与回滚预案、环境准备。行的颗粒度以“能独立验收”为准，过粗会掩盖缺口，过细会让矩阵难以维护。列是承担职责的角色，按项目实际设置，通常包括项目经理、技术负责人、产品/需求负责人、开发负责人、测试负责人、发布/运维接口人。
R/A/C/I 的判定含义
矩阵格内标注角色在该交付物上的职责类型，判定规则如下：
| 字母 | 含义 | 判定要点 |
|---|---|---|
| A（最终负责） | 对交付物结果负最终责任，拥有决策权 | 每个关键交付物有且仅有一个 A |
| R（执行） | 实际动手完成交付物的人 | 每个 A 至少对应一个可执行的 R |
| C（咨询） | 在交付前需被征询意见的角色 | 关键接口两侧应有明确的 C |
| I（知会） | 需要被告知结果的角色 | 用于保证信息同步，不承担决策 |
若团队使用 RASCI，可增加 S（支持）表示提供资源或协助的角色，但唯一 A 原则不变。唯一 A 是整套方法的判定核心：多个 A 意味着决策权冲突，零个 A 意味着无人对结果负责。
三类典型空缺
逐格扫描时，把问题归入以下三类，便于后续按不同方式处置：
- 整格空白：某交付物整行没有任何角色标注，说明这件事在启动阶段被整体遗漏。
- 同一交付物多个 A：两个及以上角色都标了 A，决策权不清，容易在关键节点互相等待或重复决策。
- 有 A 无 R：有人对结果负责，但没有明确的执行角色，落地时会出现“负责人自己干”或“谁都不动”的情况。
缺口清单的字段
扫描的输出应是一份缺口清单，与责任矩阵配套使用。建议字段包括：交付物、缺失角色、缺口类型（空白/多 A/无 R）、影响（对进度、质量或发布的风险）、待定承接人。清单按影响排序，作为下一步补齐的输入。
按接口优先的顺序补齐职责
发现缺口后直接抓人填坑，容易造成接口错位：某个交付物有人了，但它上下游的交接仍然断着。更稳妥的顺序是先定接口、再定角色、最后定人，每一步都有明确的输入、动作和输出。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：梳理跨角色接口 | 缺口清单、项目范围说明 | 沿需求→设计→开发→测试→发布的主链路，逐个确认接口双方的责任人 | 接口责任清单 | 每个关键接口两侧都有明确责任人并互相确认 |
| 第二步：为无主交付物指定临时承接角色 | 缺口清单中的空白项 | 指定临时承接角色，写明承接期限与转正条件 | 临时承接记录 | 每个空白项都有承接角色、期限和转正条件 |
| 第三步：收敛多 A 冲突 | 缺口清单中的多 A 项 | 按决策权归属确定唯一 A，其余角色改为 C 或 S | 收敛后的责任归属 | 每个交付物只剩一个 A |
| 第四步：回写并同步 | 前三步的输出 | 更新责任矩阵版本，同步到项目计划与会议机制 | 新版责任矩阵、更新后的计划 | 矩阵版本更新，计划与例会中体现新分工 |
第一步之所以优先，是因为接口责任往往横跨两个角色的边界，先确认接口能避免后续补人时把责任压到单侧。第二步的临时承接要写清期限和转正条件，例如“由技术负责人临时承接接口定义，两周内或开发负责人到位后转正”，避免临时安排变成长期模糊状态。第三步收敛多 A 时，判断依据是决策权而非工作量：谁对结果承担考核责任，谁就是 A。第四步把结果回写矩阵并同步到计划和例会，确保分工不只停留在文档里。
角色与交付物分工表怎么落地
责任矩阵解决“有没有人负责”，分工表解决“交接怎么发生”。两者可以合并为一张角色—交付物分工表，作为启动阶段的正式记录。
| 字段 | 填写说明 |
|---|---|
| 交付物 | 启动阶段需产出的关键交付物名称 |
| 负责角色 | 承担该交付物的角色名称 |
| A 角 | 最终负责的角色，唯一 |
| R 角 | 实际执行的角色的 |
| 咨询方 | 交付前需征询意见的角色 |
| 知会方 | 需被告知结果的角色 |
| 交接物 | 交给下游的具体产物，如接口文档、测试用例集 |
| 交接时点 | 交接发生的里程碑或时间点 |
启动阶段常见角色的职责边界可参照以下划分：项目经理对整体计划、风险与评审组织负责；技术负责人对技术方案、架构决策与接口定义负责；产品/需求负责人对需求基线与验收标准负责；测试负责人对测试策略与准入准出标准负责；发布/运维接口人对发布流程、回滚预案与环境准备负责。边界清晰后，交接物和交接时点才有落点。
角色空缺时，临时承接与正式任命要区分记录：临时承接写明期限、转正条件和交接方式；正式任命在启动评审中确认并更新矩阵版本。分工表落地后，可借助协作工具把交付物对应到工作项，用负责人字段和角色字段承载 A 角与 R 角，让分工在任务流转中保持可见。这里只处理角色职责与接口安排，单任务派工和人员技能匹配属于另外的管理动作，不在本文展开。
一个启动会的示例：从缺口清单到责任确认
以下为演示情景，用于说明方法如何串联，不代表特定项目。
某研发项目召开启动会，参与角色包括项目经理、技术负责人、产品负责人、测试负责人和发布接口人。会前，项目经理按关键交付物列出矩阵行：需求基线、技术方案、接口定义、测试策略、发布与回滚预案、环境准备。
扫描发现两处缺口：发布与回滚预案整行空白，无人标注 A；联调接口在开发与测试两侧都标了 A，双方责任不清。此外，接口定义有 A 但无 R，技术负责人被标为 A，却没有执行角色。
补齐动作按接口优先展开：先确认联调接口两侧责任人，开发侧由开发负责人承接、测试侧由测试负责人承接，双方在接口责任清单上互相确认；再为发布与回滚预案指定发布接口人临时承接，期限为两周，转正条件为运维接口人到位；接口定义的多 A 问题收敛为技术负责人唯一 A，开发负责人改为 R。最后回写矩阵并同步到项目计划。
启动会结束时，责任确认结果为：六个关键交付物均有唯一 A 和可执行 R，联调接口双方已确认，发布与回滚预案处于临时承接状态并记录期限。遗留项是运维接口人到岗时间待定，列入下次例会跟踪。
启动阶段职责补齐的完成检查
职责补齐是否完成，以证据判断而非口头确认。启动评审可逐项核对以下清单：
| 检查项 | 通过标准 | 所需证据 |
|---|---|---|
| 每个关键交付物有唯一 A | 矩阵中无空白行、无多 A | 责任矩阵当前版本 |
| 每个 A 有可执行 R | 无“有 A 无 R”项 | 责任矩阵当前版本 |
| 关键接口双方已确认 | 接口责任清单两侧均有责任人和确认记录 | 接口确认记录 |
| 临时承接有期限与转正条件 | 每项临时承接均记录期限、转正条件和交接方式 | 临时承接记录 |
| 多 A 冲突已收敛 | 冲突项均已确定唯一 A | 启动会纪要 |
阻断项需要单独强调：关键交付物无 A，或发布、回滚类职责空缺未处置时，不宜进入执行阶段。这两类缺口直接影响交付结果和线上风险，应在启动评审中作为不通过条件处理。评审通过后，责任矩阵版本、启动会纪要和接口确认记录一并归档，作为后续变更的基线。
常见问题
启动阶段时间紧，责任矩阵要一次做全吗？
不必一次覆盖所有活动。先锁定启动阶段必须有人对结果负责的关键交付物，例如需求基线、技术方案、接口定义、测试策略、发布与回滚预案、环境准备，把这几行做完整即可。颗粒度以“能独立验收”为准，过粗会掩盖缺口，过细会让矩阵难以维护。后续随项目推进再按里程碑补充行，并更新矩阵版本。
临时承接人一直没转正，怎么处理？
临时承接记录里应写明期限和转正条件，到期未转正时把它作为遗留项提交例会跟踪，而不是默认延续。处理方式有两种：条件已满足的，在评审中确认正式任命并更新矩阵版本；条件未满足的，重新指定承接人或调整交付物范围，同时评估对下游接口的影响。关键是让临时状态有明确的到期检查点。
多个角色都认为自己该是 A，怎么收敛？
判断依据是决策权而非工作量：谁对交付物结果承担考核责任，谁就是 A，其余角色改为 C（咨询）或 S（支持）。如果确实存在两个部门共同考核的情况，可把交付物拆成两个可独立验收的子项，各设一个 A，再明确两者之间的交接物和交接时点。收敛结果要回写矩阵并同步到项目计划，避免会上确认、会后复原。
接口双方都确认了责任人，执行中还是出现推诿怎么办？
常见原因是接口责任清单只写了人名，没写交接物和交接时点。可在分工表中为每个接口补充具体产物（如接口文档、联调环境、测试用例集）和交接发生的里程碑，让“交接完成”有可判断的依据。另外把接口确认记录纳入例会跟踪项，出现争议时回到记录核对，而不是重新口头协商。
这套方法和单任务派工、人员技能匹配是什么关系？
本文处理的是角色层面的职责与接口安排，回答“每个关键交付物由哪个角色最终负责、上下游怎么交接”。具体到某个任务派给谁、人员技能是否匹配，属于任务分配与资源匹配的管理动作，可以在角色职责确定之后进行。先补齐角色职责，再派工和配人，能减少因接口不清导致的返工。
