规模化敏捷里，责任和交付要求最容易停在角色名称上：会上说“这个特性由A团队牵头”，散会后没人说得清谁对验收标准负责、跨团队依赖由谁推动、什么状态才算交付完成。本文给出一套可执行的机制设计方法：按团队、特性/项目集、职能三条线划分责任主体，用责任矩阵把角色落到具体交付物和决策权，用两级完成定义固定验收口径，再嵌入迭代评审与跨团队同步持续校验。ONES可作为承载工作项状态、验收标准与交付证据的平台，具体配置按组织实际开通能力确定。
要点总览（TL;DR）
- 按团队线、特性/项目集线、职能线三条线划分责任主体，先明确每条线的核心职责与接口对象，再讨论具体交付物。
- 用责任矩阵把角色落到交付物和决策权上：按交付物而非部门填写，每行只有一个负责角色，审批与执行分离。
- 交付要求写成团队级与项目集级两层完成定义，条目覆盖功能、质量、文档、评审与上线条件，每条对应可查阅的验收证据。
- 把检查动作嵌入迭代计划、每日同步、跨团队同步、迭代评审和特性验收等既有节奏，偏差按阈值升级并再承诺。
- 用责任矩阵覆盖度、完成定义可验收性、协同记录、偏差闭环和机制维护责任五项清单判断机制是否真正建立。
责任与交付要求先落到三条线上
责任说不清，通常源于把所有责任混在一个维度里：团队被要求对迭代交付负责，同时又被要求对跨团队特性结果负责，职能角色既提供专业能力又参与验收，边界一模糊，出问题时就只能追溯到“大家都有责任”。可行的做法是先按三条责任线拆开，每条线明确主体、核心职责和对外接口，再讨论具体交付物。
| 责任线 | 主体 | 核心职责 | 接口对象 |
|---|---|---|---|
| 团队线 | 各交付团队（含产品、设计、研发、测试角色） | 迭代内需求的拆分、实现与质量；对迭代承诺和团队级完成定义负责 | 特性/项目集线（交付承诺与依赖）、职能线（标准与评审支持） |
| 特性/项目集线 | 特性负责人或项目集管理角色 | 跨团队交付承诺的整合、依赖识别与协调、整体验收组织 | 团队线（排期与依赖）、职能线（跨团队评审）、上级决策层（升级） |
| 职能线 | 架构、质量、安全、运维等职能角色 | 能力供给、技术标准制定、专业评审与把关 | 团队线（标准落地与评审）、特性/项目集线（跨团队技术决策） |
三条线之间需要两个明确接口。一是承诺接口：团队向特性线承诺迭代内交付内容，特性线向业务方承诺特性整体交付时间，任何一方变更承诺都要走同一登记与再确认流程。二是升级路径：团队内部无法解决的依赖或标准冲突，先由特性负责人协调；涉及职能标准取舍或资源冲突的，升级到对应的项目集决策层。升级路径要写清触发条件、升级对象和响应时限，否则“升级”会变成情绪化投诉。
划分责任线时有一个常见误区：把职能线写成审批关卡。职能线的价值在于标准供给和专业评审，评审结论应作为交付要求的一部分提前进入完成定义，而不是在交付前临时增加否决点。团队线对迭代结果负责，前提是职能标准在迭代开始前已经明确。
用责任矩阵把角色和交付物对应起来
责任线解决“哪类主体负责哪类事”，责任矩阵解决“某个具体交付物上谁做什么决定”。矩阵按交付物填写，不按部门填写：一行是一个可识别的交付物或决策点，列是责任类型，这样能直接暴露“无人负责”和“多人审批”两类问题。
| 字段 | 填写含义 | 填写规则 |
|---|---|---|
| 交付物/决策点 | 可识别、可验收的对象，如“特性验收标准”“接口契约文档”“上线评审结论” | 用名词描述产物，避免写成“推进联调”这类动作 |
| 负责（R） | 对结果直接负责、推动完成的人 | 每行有且仅有一个负责角色，可以是角色而非具体人名 |
| 审批（A） | 对结果做最终确认或否决的人 | 尽量少设，审批点过多会拖慢交付；审批与执行分离 |
| 参与（C） | 提供输入、共同产出的人 | 写清参与方式，如“提供接口方案”“参与评审” |
| 知会（I） | 需要了解结果但不参与决策的人 | 控制范围，知会名单过长等于没有知会 |
填写时先列交付物清单，再逐行确认负责角色。决策权与执行权分离的处理方式是：负责角色对交付物的完成质量负责，审批角色只对关键判断点做确认，例如架构方案由架构师审批、验收标准由产品负责人审批，但具体编写与推动由负责角色完成。若同一人同时出现在负责和审批两列，说明该交付物缺少独立校验，需要补充评审角色或调整流程。
矩阵的维护时机有三个：迭代或项目集规划时新增交付物、复盘发现责任真空、组织角色调整。每次更新保留变更记录，注明变更原因和生效范围，避免矩阵变成一份过期文档。矩阵本身应放在团队可随时查阅的位置，并与工作项、文档的负责人字段保持一致。
交付要求写成可验收的完成定义
交付要求如果只写“功能可用、质量达标”，验收时必然产生分歧。可验收的完成定义分两层：团队级完成定义约束每个迭代产出的增量，项目集级完成定义约束跨团队特性的整体交付。两层共用同一套条目结构，但严格程度不同。
| 条目类别 | 团队级完成定义示例 | 项目集级完成定义示例 | 验收证据 |
|---|---|---|---|
| 功能 | 需求验收标准全部通过，异常路径已覆盖 | 端到端业务场景在集成环境跑通 | 验收记录、测试用例执行结果 |
| 质量 | 静态检查与自动化测试通过，无阻断级缺陷 | 跨团队接口联调通过，性能指标达到约定阈值 | 测试报告、联调记录 |
| 文档 | 接口说明、变更说明已更新 | 特性说明、上线方案与回滚方案齐备 | 文档链接与版本号 |
| 评审 | 团队内代码评审与需求验收完成 | 职能线专业评审（架构、安全等）结论已闭环 | 评审记录与结论 |
| 上线条件 | 具备可部署的增量，配置与数据变更已说明 | 上线窗口、监控与值守安排已确认 | 上线检查单 |
编写步骤可以按四步走：第一步，由特性负责人和团队代表一起列出该交付物必须满足的条目，逐条写成可判断真假的陈述；第二步，为每条指定证据形式，证据必须是他人可查阅的产物，口头确认不算；第三步，在迭代计划或特性启动会上评审完成定义，确认团队理解一致；第四步，交付前按条目逐项核对，未满足项登记为偏差并明确处理方式。
完成定义的变更要有流程：迭代内原则上不降低条目，确需调整的由负责角色提出、审批角色确认并记录原因；项目集级完成定义的变更影响多个团队，应在跨团队同步会上统一宣布。完成定义一旦成为验收依据，就不宜频繁改动，否则证据口径会随之漂移。
在协同节奏中校验责任与交付
责任矩阵和完成定义是设计产物，能否起作用取决于例行协同活动里有没有人检查、有没有记录。规模化敏捷通常已有迭代评审、跨团队同步和依赖协调等节奏，需要在这些节点上增加固定的检查动作，而不是另建一套会议。
| 协同活动 | 检查项 | 责任人 | 异常处理 |
|---|---|---|---|
| 迭代计划会 | 迭代承诺是否对应到具体需求与验收标准；完成定义是否确认 | 团队产品负责人与特性负责人 | 验收标准缺失的需求不进入迭代 |
| 每日同步 | 任务状态与阻塞是否更新；跨团队依赖是否登记 | 团队内各任务负责人 | 阻塞超过约定时长升级至特性负责人 |
| 跨团队同步会 | 依赖的提供方、需要时间、当前状态是否明确；承诺是否变化 | 特性负责人 | 承诺变更走再承诺流程并通知受影响团队 |
| 迭代评审 | 增量是否满足团队级完成定义；证据是否齐备 | 团队与业务方代表 | 未满足项登记偏差，明确补救责任人与时间 |
| 特性验收 | 项目集级完成定义逐条核对；职能评审结论是否闭环 | 特性负责人与职能评审角色 | 不满足项不进入上线，回到对应团队处理 |
依赖与承诺的登记要落到具体字段：依赖内容、提供方、需求方、需要时间、当前状态、承诺变更记录。登记之后要在每次跨团队同步会上过一遍状态，状态长期不变的依赖本身就是风险信号。交付偏差的升级与再承诺机制需要写清阈值，例如承诺内容变更、交付时间推迟超过约定天数、依赖阻塞超过约定时长，触发后由特性负责人组织再承诺，并把新承诺同步给所有受影响方。
度量指标可以选承诺达成率、返工率、依赖阻塞时长，用于发现机制问题，例如某类交付物反复返工，往往说明完成定义条目不清或评审缺位。这些指标适合团队和项目集层面做改进参考，直接用于个人考核会诱导虚报承诺或隐藏依赖，反而削弱责任机制的可信度。指标口径要在使用前定义清楚，包括统计范围、时间窗口和计算方式。
当责任矩阵、完成定义和协同检查都落到工作项与文档上时，状态和证据才能被持续追踪。ONES 敏捷研发管理方案将需求提出方、产品经理、研发、测试等角色连接在同一流程中，产品负责人可在迭代计划会上与团队就需求与验收标准达成一致，测试人员依据验收标准编写并执行用例，未通过用例可转为缺陷指派修复；迭代中团队通过敏捷看板对齐进度与风险。这些能力可以承载上述检查动作，跨团队依赖的登记方式与完成定义模板的承载形态需结合组织实际配置确定。
一个跨团队特性的责任与交付示例
以下为演示情景，用于说明方法如何串联，不代表任何真实项目。某组织要交付一个涉及订单、支付、通知三个团队的“订单状态实时通知”特性，特性负责人由项目集侧指定。
责任划分上，订单团队负责状态变更事件的产生与格式约定，支付团队负责支付结果回传，通知团队负责消息推送与失败重试；特性负责人负责整体承诺、依赖协调和特性验收；架构职能角色负责事件格式标准评审，运维职能角色参与上线方案评审。
责任矩阵填写结果示例：事件格式契约文档，负责为订单团队接口负责人，审批为架构师，参与为支付与通知团队代表，知会为特性负责人；特性验收标准，负责为特性负责人，审批为业务方代表，参与为三个团队的产品角色；上线方案，负责为通知团队运维接口人，审批为运维职能角色，参与为特性负责人。
两级完成定义的具体条目：团队级要求各团队增量通过自身验收标准与自动化测试、接口说明更新；项目集级要求三个团队在集成环境完成端到端场景验证、消息失败重试达到约定成功率、上线与回滚方案经运维评审通过，证据分别为联调记录、压测与重试测试报告、评审结论。
协同节点上的校验：跨团队同步会发现支付团队回传字段与契约不一致，登记为依赖问题并明确修复时间；迭代评审时通知团队的重试测试证据缺失，登记偏差并由通知团队补充；特性验收前架构师确认契约变更已同步三个团队。偏差处理的关键是每条问题都有负责人和关闭时间，而不是在验收会上集中暴露。
这个示例可迁移的规律是：先按交付物拆责任，再按两级完成定义定验收，最后把检查嵌入既有节奏。适用边界在于，特性涉及团队数量较少、依赖关系清晰时可以直接套用；团队数量多、依赖网状交叉时，需要更强的项目集层协调角色和更细的依赖登记粒度。
落地前的完成检查
判断责任与交付机制是否真正建立，可以逐项核对以下清单。每项都应有可查阅的产物或记录，仅凭会议口头确认不算完成。
- 责任矩阵覆盖了关键交付物与决策点：抽查三个近期交付物，均能查到负责角色和审批角色，且负责与审批不为同一人。
- 完成定义可验收、有证据：随机抽取若干需求或特性，其完成定义条目能判断真假，且每条对应可查阅的证据形式。
- 协同节点有人执行并记录：迭代计划、跨团队同步、迭代评审的检查项有明确责任人，最近若干次活动留有检查记录。
- 偏差有升级与复盘：抽查近期偏差，均有升级记录、处理结论和关闭时间；复盘中有对完成定义或责任矩阵的修订。
- 机制维护责任明确：责任矩阵和完成定义的维护人、更新时机、变更记录均已指定，且最近一次组织或角色调整后已同步更新。
检查中发现的问题应按影响面排序处理：责任真空和验收口径缺失优先修复，因为它们直接导致交付争议；记录不完整和指标口径不清可以随后补齐。机制建立后仍需在每次复盘中回看，确保责任矩阵与完成定义跟得上组织和交付方式的变化。
常见问题
团队同时承担迭代交付和跨团队特性结果，责任怎么分才不冲突？
把两类责任放到不同责任线上分别定义：团队线对迭代承诺和团队级完成定义负责，特性/项目集线对跨团队整体承诺、依赖协调和特性验收负责。冲突多发生在承诺变更时，因此需要一条统一的承诺接口——团队向特性线承诺迭代内容，特性线向业务方承诺整体交付时间，任何变更都走同一登记与再确认流程。团队不必同时对特性整体结果直接负责，但需要按约定时间提供依赖输出。
责任矩阵填完后，怎么判断它是否真的在起作用？
看三个可观察的信号：抽查近期交付物，能否查到唯一的负责角色和明确的审批角色；负责与审批是否由同一人兼任，若兼任说明缺少独立校验；矩阵最近一次更新是否与组织角色调整、复盘结论对应。矩阵长期不更新、或工作项负责人字段与矩阵不一致，通常说明它已经退化为文档。建议在每次复盘时回看矩阵，把新出现的责任真空补进去。
完成定义条目写多少合适，写太细会不会拖慢交付？
条目数量取决于交付物的风险，不追求统一条数。判断标准是每条能否判断真假、是否有可查阅的证据形式。功能、质量、文档、评审、上线条件五类中，与本次交付风险最相关的条目要写细，低风险条目可以引用既有标准而不重复展开。团队级完成定义保持稳定，项目集级完成定义按特性补充。条目过多导致每次核对成本过高时，优先合并同类项，而不是删掉证据要求。
度量指标用于考核团队后，承诺数据失真怎么办？
承诺达成率、返工率、依赖阻塞时长适合作为机制改进的参考，直接用于个人或团队考核容易诱导虚报承诺、隐藏依赖。若已经出现数据失真，可以先调整用途：指标只在团队和项目集层面复盘使用，统计口径提前定义清楚，包括统计范围、时间窗口和计算方式。同时检查完成定义是否条目不清导致反复返工，把改进重点放回验收口径和评审动作上。
跨团队依赖登记后长期没有进展，应该由谁推动？
按升级路径处理：依赖的日常跟踪由特性负责人负责，在跨团队同步会上逐条过状态；状态长期不变的依赖本身是风险信号，应触发升级，由特性负责人组织相关团队再承诺，并把新承诺同步给所有受影响方。升级路径要事先写清触发条件、升级对象和响应时限。若涉及职能标准取舍或资源冲突，升级到对应的项目集决策层，避免停留在团队间反复沟通。
