研发项目启动阶段，职责空缺常常以三种方式暴露：关键交付物没人认领、同一件事多人争着拍板、名字挂在分工表上却交不出东西。本文围绕两条主线展开：先用责任矩阵把空缺找出来并按五步补齐，再用“输入—动作—输出—交接对象”四要素把角色接口写清楚，最后给出启动会后可逐项核对的完成检查。方法本身不依赖特定工具，若团队在协作平台中维护矩阵与接口清单，可自然衔接ONES的文档与工作项协作能力。
要点总览（TL;DR）
- 职责空缺按三种形态判定：无人负责、多人争责、挂名不交付；单任务缺指派和人员技能不足属于相邻问题，分开处理。
- 用责任矩阵按“交付物×角色”建表，逐格标注负责、审批、协作、知会，查空时同时看空白格、双主责格和挂名格，输出带影响的空缺清单。
- 补齐按五步走：空缺分级排序、确定承接角色（内部兼任、跨组协调、临时指定）、确认责任类型、更新矩阵并登记接口、复核走查。
- 角色接口按“输入—动作—输出—交接对象”四要素定义，每个接口指定唯一对接人和响应时限，跨组接口另约定升级路径。
- 启动会后一周内做走查验证：抽查接口是否按时交接、核对主责角色产出进度，未通过则回到分级承接或重新约定接口。
先明确：什么算职责空缺，什么不算
职责空缺指的是“关键交付物在角色维度上没有形成完整责任闭环”的状态。判断时看交付物，不看人名；看责任类型是否唯一，不看谁更忙。启动阶段先把判定标准统一，后面查矩阵才不会把各种问题混在一起。
三种典型形态
- 无人负责：某个启动阶段交付物在矩阵中没有任何角色被标为负责，或只标了“协作”“知会”而没有主责人。例如接口协议文档只有架构师“参与评审”，没有人负责定稿。
- 多人争责：同一交付物出现两个及以上“负责”或“审批”角色，且未约定谁最终拍板。典型表现是需求范围由产品经理和项目经理同时签字，出现分歧时无人能定。
- 挂名不交付：矩阵上有人负责，但该角色没有对应的时间投入、权限或产出物定义，实际交付落空。例如测试负责人被列为测试计划主责，但启动阶段并未安排其参与排期。
与相邻问题的边界
单任务负责人缺失，是某一条具体任务在任务列表里没有指派执行人，属于任务分配层面的问题，用任务看板即可解决；人员技能不足，是角色已明确但能力或人手不够，属于资源与技能匹配问题。这两类问题都会影响交付，但处理路径不同：前者补指派，后者补资源或调整范围。把它们混入职责空缺清单，会让补齐动作失焦。
启动阶段优先检查的范围
研发项目启动阶段通常只有几周，检查范围应聚焦在决定后续能否顺利推进的交付物上：项目目标与范围说明、需求基线或需求清单、总体技术方案与架构决策、开发与测试计划、环境与工具准备、里程碑与验收标准、跨团队接口约定、风险清单。范围之外的事项可以留到规划阶段再细化，不必在启动会上一次查完。
用责任矩阵识别空缺的四个动作
责任矩阵的作用是把“交付物—角色—责任类型”三者的对应关系摆到一张表上，让空缺以空格和重叠的形式显性化。以下四个动作按顺序执行，产出物是一张矩阵表和一份空缺清单。
动作一：列出启动阶段关键交付物清单
输入是项目立项材料、上一阶段交接内容和启动会拟讨论议题。动作是把交付物写成“可验收的名词”，例如“需求范围说明书（含优先级）”，避免写成“需求沟通”这类动作。输出是一份10至20项的交付物清单，每项标注计划完成时间和验收人候选。完成标志是清单经项目负责人确认，无重复项。
动作二：按交付物×角色建表并标注责任类型
行是交付物，列是启动阶段涉及的角色，如项目负责人、产品经理、架构师、开发负责人、测试负责人、运维接口人、质量或流程角色。责任类型建议控制在四类：负责（R，实际产出）、审批（A，最终拍板）、协作（C，提供输入或共同完成）、知会（I，需要同步结果）。每格只填一个字母，一格多字母即视为需要复核的信号。
动作三：逐格检查空缺、重叠与挂名格
检查按行推进：每行是否恰好有一个R和一个A；是否存在整行为空；是否存在两个A；标了R的角色是否在启动阶段有实际投入安排。挂名格往往表现为“R在高层管理者名下”，此时应追问其是否真的产出文档或做决策，若答案为否，转为A或I更准确。
动作四：输出空缺清单并标注影响
空缺清单至少包含四列：交付物、空缺类型（无人负责/多人争责/挂名不交付）、影响的后续环节、建议补齐时限。影响一栏写具体后果，例如“接口协议无人定稿，联调排期无法确定”，这决定后续补齐的先后顺序。
| 交付物 | 项目负责人 | 产品经理 | 架构师 | 测试负责人 | 检查结论 |
|---|---|---|---|---|---|
| 需求范围说明书 | A | R | C | I | 完整 |
| 总体技术方案 | A | C | R | C | 完整 |
| 接口协议文档 | A | I | C | C | 无人负责（缺R） |
| 测试计划 | A | C | C | R | 完整 |
| 验收标准 | A | R | — | R | 多人争责（两个R） |
补齐职责空缺的五步操作
补齐不是简单填名字，而是让每个空缺格落到一个有投入、有权限、能交付的角色上，并把结果回写到矩阵。建议按影响面排序处理，避免在低影响事项上消耗启动会时间。
第一步：空缺分级与排序
输入是空缺清单。动作是按两个维度分级：是否位于关键路径、是否跨团队。阻塞关键路径且跨团队的空缺优先，例如接口协议主责；仅影响内部协作的空缺靠后。输出是带优先级的补齐顺序表。完成标志是项目负责人确认排序，明确本次启动阶段必须补完的条目。
第二步：确定承接角色
承接方式有三种，按优先级选择：
- 内部兼任：团队内已有角色具备权限和知识，直接承接，成本最低。适用于与原职责相邻的交付物。
- 跨组协调：交付物涉及其他小组，由对方指定接口人承接，本方保留审批权。适用于接口协议、环境准备等跨边界事项。
- 临时指定：短期内无人具备条件时，由项目负责人指定临时负责人并写明期限与移交条件。适用于启动阶段必须推进但长期归属待定的事项。
输出是每个空缺格的承接角色与承接方式。完成标志是承接人本人确认，而非仅由其上级同意。
第三步：补齐后的责任类型确认
承接人确定后，回到矩阵确认该格的责任类型：承接实际产出的标R，保留拍板权的标A，提供输入或评审的标C。特别注意把原先的挂名格改为真实责任类型，避免“补了名字但责任类型没变”。输出是修订后的矩阵草稿。
第四步：矩阵更新与接口登记
把修订内容写入正式矩阵，同时把新增的跨角色交接登记到接口清单（见下一节）。输出是更新后的责任矩阵和初版接口清单。完成标志是矩阵版本号与更新时间可追溯。
第五步：复核与走查
由项目负责人或质量角色按行复核：每行是否恰好一个R、一个A；承接人是否知晓自己的交付物与时限。输出是复核记录。完成标志是复核无遗留空缺，或遗留项已明确责任人和关闭时间。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 空缺分级 | 空缺清单 | 按关键路径与跨团队程度排序 | 补齐顺序表 | 项目负责人确认排序 |
| 确定承接角色 | 顺序表、角色信息 | 选择兼任、跨组协调或临时指定 | 承接角色与方式 | 承接人本人确认 |
| 责任类型确认 | 承接结果 | 逐格标注R/A/C/I | 矩阵草稿 | 无挂名格残留 |
| 矩阵更新与接口登记 | 矩阵草稿 | 写入正式矩阵、登记接口 | 更新矩阵、初版接口清单 | 版本可追溯 |
| 复核走查 | 更新矩阵 | 逐行核对R/A唯一性 | 复核记录 | 无遗留空缺或已定关闭时间 |
角色接口怎么安排：四要素与接口清单
空缺补上后，最常见的断档发生在交接处：上游以为已经交付，下游以为还没开始。角色接口就是把每一次交接写成可核对的约定，核心是四要素。
接口四要素
- 输入：上游提供什么，格式与质量要求是什么，例如“接口协议文档，含字段定义与错误码”。
- 动作：接收方拿到输入后做什么，例如“评审协议并确认联调环境可用”。
- 输出：动作完成后产出什么，例如“评审意见与联调排期”。
- 交接对象：输出交给谁，是角色而非泛指的“相关方”。
唯一对接人与响应时限
每个接口指定一名唯一对接人，负责接收、转达和反馈，避免多头沟通导致信息失真。同时约定响应时限，例如“收到评审请求后两个工作日内反馈”。时限按启动阶段节奏设定，写进接口清单，作为后续走查依据。
接口清单的字段与维护
建议字段包括：接口编号、上游角色、下游角色、输入、动作、输出、唯一对接人、响应时限、状态、最近更新日期。清单随矩阵一同维护，任何一方变更对接人或时限，需在清单中更新并通知对方，状态可设为“待确认、已确认、变更中”。
跨角色、跨小组接口的处理
跨小组接口额外增加两项：双方各自确认一名对接人，以及约定升级路径——当时限内未响应时，由哪一级角色介入协调。升级路径写清楚，可以避免启动阶段的小延误演变成排期冲突。
| 接口编号 | 上游角色 | 下游角色 | 输入 | 动作 | 输出 | 唯一对接人 | 响应时限 |
|---|---|---|---|---|---|---|---|
| IF-01 | 架构师 | 开发负责人 | 接口协议文档 | 评审并确认可实现性 | 评审意见与联调排期 | 开发负责人 | 2个工作日 |
| IF-02 | 产品经理 | 测试负责人 | 需求范围说明书 | 梳理测试范围与验收点 | 测试计划初稿 | 测试负责人 | 3个工作日 |
角色与交付物分工表：谁负责、交付什么、交给谁
责任矩阵用于查空，接口清单用于管交接，启动会上还需要一张合并视图让所有人一次看清自己的位置。分工表以角色为行，把交付物、责任类型和接口对接人放在同一行呈现。
| 角色 | 负责的交付物 | 责任类型 | 主要接口 | 接口对接人 |
|---|---|---|---|---|
| 产品经理 | 需求范围说明书 | R | 向测试负责人交付需求基线（IF-02） | 测试负责人 |
| 架构师 | 总体技术方案、接口协议文档 | R | 向开发负责人交付接口协议（IF-01） | 开发负责人 |
| 开发负责人 | 开发计划、环境准备清单 | R | 接收接口协议并反馈评审意见 | 架构师 |
| 测试负责人 | 测试计划、验收标准 | R | 接收需求基线并输出测试计划 | 产品经理 |
| 项目负责人 | 项目计划、风险清单 | A | 审批各交付物、协调升级事项 | 各角色对接人 |
责任类型与接口对接人是两个不同维度：责任类型说明该角色对交付物承担什么性质的责任，接口对接人说明交接时找谁。一个角色可以负责多个交付物，但每个接口只保留一名对接人。分工表在启动会上逐行确认，由各角色当场确认自己的交付物、时限和对接人，确认结果记入会议记录，作为后续走查的基准。
当团队在协作平台中推进时，分工表与接口清单可以作为项目文档维护，交付物对应的工作项挂上负责人和截止时间，接口状态随工作项进展更新。ONES支持文档与工作项在同一项目空间内协作，适合把矩阵、清单和任务状态放在一处，减少启动阶段的信息分散；具体字段与权限配置以团队实际使用为准。
一个研发项目启动阶段的填写示例
以下为演示情景，用于说明填写过程，不代表特定企业实际项目。
示例背景与关键交付物
某研发项目启动，团队包含产品、架构、开发、测试四个小组，计划六周完成启动阶段。关键交付物包括：需求范围说明书、总体技术方案、接口协议文档、开发计划、测试计划、验收标准、环境准备清单。
查出的空缺格及补齐动作
- 接口协议文档：矩阵中架构师标C、开发负责人标C，无R。判定为无人负责。补齐动作：由架构师承接R，开发负责人保持C，项目负责人保留A。承接方式为内部兼任。
- 验收标准：产品经理与测试负责人同时标R。判定为多人争责。补齐动作：产品经理改为A，测试负责人为R，明确验收标准由测试负责人起草、产品经理审批。
- 环境准备清单：运维接口人标R，但启动阶段未安排其参与排期。判定为挂名不交付。补齐动作：改为开发负责人R、运维接口人C，并登记接口。
接口清单填写示例
以接口协议为例：输入为架构师提供的接口协议文档，动作为开发负责人评审可实现性，输出为评审意见与联调排期，交接对象为架构师，唯一对接人为开发负责人，响应时限两个工作日。验收标准相关接口：输入为需求范围说明书，动作为测试负责人梳理验收点，输出为验收标准初稿，交接对象为产品经理，响应时限三个工作日。
示例可迁移的规律
三个空缺分别对应三种形态，补齐动作都遵循同一逻辑：先确认交付物，再确认唯一主责，最后登记接口。挂名格的处理尤其值得注意——把挂名者转为审批或协作角色，比强行要求其产出更符合实际。团队迁移时可按此顺序检查自己的矩阵，重点看标R的格子是否都有真实投入安排。
完成检查：补齐是否真的到位
补齐动作完成不等于职责到位。启动会结束后，用以下清单做一次整体验收，任一项未通过即视为未完成，需回退处理。
矩阵检查
- 每项关键交付物恰好有一个R和一个A，无空白行。
- 不存在两个及以上A同时拍板同一交付物的情况。
- 标R的角色均有启动阶段的时间投入安排，无挂名格。
- 矩阵版本、更新时间和确认人可追溯。
接口检查
- 每个跨角色交接均有对应接口条目，四要素填写完整。
- 每个接口有唯一对接人，且对接人本人已确认。
- 响应时限已写入清单，跨组接口的升级路径已约定。
启动会后一周内的验证动作
启动会后一周，由项目负责人做一次走查：抽查三到五个接口，确认上游是否按约定时间提供输入、下游是否按时反馈；核对矩阵中R角色的实际产出进度；收集各角色对接口时限是否可行的反馈。走查结果记入项目记录，作为下一阶段调整依据。
未通过时的回退处理
若发现新的空缺格，回到补齐五步中的分级与承接环节处理；若接口对接人未确认或时限不可行，重新约定并更新清单；若挂名格反复出现，说明该角色的投入安排需要与资源负责人重新协商。回退处理应设定关闭时间，避免检查流于形式。
常见问题
启动阶段时间紧，责任矩阵要覆盖所有交付物吗？
不必。启动阶段通常只有几周，矩阵只需覆盖决定后续能否推进的关键交付物，例如需求范围、技术方案、接口协议、开发与测试计划、验收标准、环境准备、风险清单，一般控制在10至20项。其余事项留到规划阶段细化。范围收窄后，查空和补齐都能在启动会前后完成，不会因为表格过大而流于形式。
空缺格由内部兼任还是跨组协调承接，怎么选？
先看交付物是否跨团队边界。与原职责相邻、团队内已有权限和知识的，优先内部兼任，成本最低；涉及其他小组的，由对方指定接口人承接、本方保留审批权；短期无人具备条件又必须推进的，由项目负责人临时指定并写明期限与移交条件。无论哪种方式，都要由承接人本人确认，仅由其上级同意不算落实。
接口对接人和责任矩阵里的主责人是同一个人吗？
不一定，两者回答不同问题。主责人说明谁对交付物承担产出责任，接口对接人说明交接时找谁接收、转达和反馈。一个交付物的主责人可能把交接事务交给组内另一名成员对接，但每个接口只能有一名对接人。分工表上把两列分开写，可以避免“责任在A、消息却发给B”造成的断档。
启动会后发现新的职责空缺，需要重做整个矩阵吗？
不需要。回到补齐五步中的分级与承接环节处理即可：先判断新空缺是否阻塞关键路径、是否跨团队，再确定承接角色、确认责任类型并更新矩阵和接口清单。若反复出现挂名格，说明相关角色的投入安排需要与资源负责人重新协商。每次回退处理设定关闭时间，避免检查停在发现问题这一步。
接口响应时限设多长比较合适？
按启动阶段的节奏设定，以“不影响下游排期”为准，常见做法是两个到三个工作日，并在清单中写明起算点，例如“收到评审请求后两个工作日内反馈”。时限过短会让评审流于形式，过长则拖住联调等后续动作。跨组接口同时约定升级路径：时限内未响应时由哪一级角色介入协调，写清楚才能在小延误演变成排期冲突前处理掉。
