如何在 Jira 中建立 RACI 矩阵：明确责任归属

Jira 事项即使已经分配执行人，也可能仍有重要责任没有确定。谁对最终结果负责？谁需要在完成前审查？谁只需收到消息，而不必参与每次讨论？

当工作跨越产品、开发、测试和客户支持时，这些问题会更复杂。执行人可能负责实现变更，但不意味着所有相关沟通都由其负责。

RACI 矩阵让这些期望清晰可见。它将少量交付成果与参与者对应起来，记录每个人的参与方式。

本指南以一个虚构的客户门户发布为例，介绍如何建立矩阵并在 Power Pack for Jira 中组织它。目标是形成简短、实用的约定，让大家能够有把握地行动。

RACI 是什么意思？

RACI 描述参与一项工作的四种方式：

每行设一位最终负责人，并至少分配一位执行负责人。共同执行的职责也应明确。咨询需要双向交流，而告知可能只需一条简短消息。

这些定义与 Atlassian 对 RACI 图的说明一致。下文将它们应用于一个示例 Jira 工作流程。

执行责任与最终责任的区分尤其有用。工程师可以实现通知偏好，而产品负责人仍需对约定的客户结果负责。两种角色都不能替代技术判断与协作。

从真实的协调问题开始

虚构团队正准备更新客户门户，让客户选择接收哪些账户邮件。变更还需要测试和一份简短的支持指南。

团队包括产品负责人 Maya、工程师 Leo、测试人员 Priya，以及支持负责人 Sam。这些姓名与职责只是示例，并非规定的人员配置。

建立矩阵前，团队发现了混乱的根源：大家都认为需要开发偏好设置界面，却没人明确负责支持说明。测试也依赖一项产品决定：哪些邮件必须继续发送。

这正是使用 RACI 的好理由。如果任务简单且负责人明确，团队未必需要矩阵。应在讨论责任能够实际改变工作方式的地方使用它。

选择一个适合承载讨论的 Jira 事项，描述共同结果并链接相关实施工作。告诉团队矩阵在哪里，让它融入日常规划。

写出大家能辨认的交付成果

从输出结果出发，而不是笼统的部门或模糊阶段。“工程部门”是一群人，“实现邮件偏好控件”才是可以完成的工作。

示例团队选择了四行：

• 约定客户可以更改哪些通知偏好。
• 实现邮件偏好控件。
• 验证偏好变更对邮件发送的影响。
• 发布新控件的支持说明。

每行应足够具体，以便明确负责人，也应足够重要，值得讨论。罗列每一个细小步骤，会让行政负担掩盖真正的协调问题。

如果某行总需要两位最终负责人，应检查其范围。“构建并发布整个体验”可能包含多个负责人不同的结果。按照真实责任边界拆分，再确认各部分仍覆盖整体目标。

建立矩阵初稿

下面是团队的初步约定。破折号表示该成果未分配特定角色。

最后一行需要解释：Sam 对说明的准确性和实用性负责，Leo 撰写技术步骤。这是该团队的实际约定；其他团队可能由支持专员起草。

矩阵应反映真实工作约定，不要仅凭职位填写。某人可能有专业知识却没有执行时间，职级高也不自动意味着适合对结果负责。

逐行读出来。测试行的意思是：Priya 验证，Leo 提供技术意见，Maya 对结果负责，Sam 接收结果。如果有人感到意外，应先解决分歧，再将矩阵视为已达成共识。

将约定放入 Power Pack

在 Jira 事项中打开 Power Pack，使用 RACI / DACI Matrix。责任模型标为 RA(S)CI，包含四种 RACI 角色及可选的 Support 角色。这个示例只需 R、A、C、I，不必使用 S。

依次使用参与者、交付成果和矩阵视图。先添加人员。名单支持搜索 Jira 用户，也支持非 Jira 或外部参与者条目。外部条目只是记录人员，不会创建 Jira 账户或授予事项访问权。

再添加约定的成果。Import Subtasks 可将现有子任务加入可用成果池。进入矩阵前检查选中的成果，确保行与计划讨论的内容一致。

在相关交叉单元格分配角色。点击单元格会循环切换角色，获得焦点的单元格也支持角色字母快捷键。某人没有相关责任时，可以留空。

工具会提示缺少负责人、存在多位负责人，以及没有执行人的行。这些提示用于检查分配。行格式有效不代表人员已同意、有足够时间或已经完成工作。

变更保存在 Jira 事项上。离开或请别人审查前，检查保存状态。本地或离线状态不能证明同事已经能看到最新版本。

既检查行，也检查人员

逐行合理的矩阵仍可能把太多工作集中到一个人身上。检查交付成果后，再纵向查看每个人的列。

示例中，Leo 要约定行为、实现控件并起草支持说明。小变更可能可行，大型发布则可能形成瓶颈，应在承诺交付日期前处理。

询问每个人是否理解角色、能否履行。明确何时需要咨询、反馈时限以及知情者应收到什么。时间和沟通细节应按团队日常 Jira 流程记录在工作旁。

单元格中的 C 不会安排审查，I 也不会发送更新。矩阵只是表达期望，团队仍需落实。

将责任与 Jira 工作流区分开

RACI 描述围绕交付成果的参与方式，不等于 Jira 执行人字段、事项权限或工作流状态。

修改责任单元格不能替代分配实施任务、授予访问权或转换事项状态。应通过正常工作流让这些操作与约定一致。

Power Pack 可以导出 Markdown 表格或 CSV，供其他场合讨论。分享副本时，应注明以 Jira 事项为当前分配的来源，否则计划改变后旧表仍可能流传。

范围变化、人员不可用或出现新审查要求时，应重看矩阵。在关键变化时做简短检查，比将第一版视为永久安排更有用。

避免三种常见 RACI 错误

把所有人都列为咨询对象

咨询应回答具体问题。每行都让所有人参与，会重新造成矩阵本想减轻的会议负担。明确所需专业知识，只需结果的人应列为知情者。

默认把最终责任当作额外工作分配

最终负责人需要足够的背景信息和权限来解决结果相关问题。不要只因某人职级最高或参加会议最多就选择他。

用 RACI 解决决策归属问题

有时未解决的不是谁交付，而是谁在竞争方案中做选择。DACI 更适合这种讨论：确定推动者、一位决策者、贡献者和知情者。先作决定，再按需要用 RACI 明确实施责任。

与团队尝试一个小矩阵

选择责任跨团队的 Jira 事项，找出三到五个有意义的成果，加入相关人员，并共同约定分配。

用 Power Pack 的 RACI / DACI Matrix 将约定放在事项旁。检查责任提示、确认保存状态，并和被列出的人员一起过一遍结果。

从解决真实不确定性的矩阵开始。对门户团队而言，价值很简单：大家知道谁开发、谁验证、谁对结果负责，以及谁确保支持就绪。

• Atlassian 对 RACI 图的说明