技术决策中的 DACI 与 RACI：唯一审批人，指名的贡献者

是什么

Atlassian 的 DACI 方法为一项决策定义了四种角色。推动者（driver）负责召集利益相关方、收集信息、界定范围，并推动决策在约定日期前完成。审批人（approver）是唯一做出决策的人；该方法特意强调“唯一”，是为了让审批成为一个主动的角色，而不是走过场的盖章。贡献者（contributors）提供专业知识和建议：他们有发言权，但没有表决权。知情方（informed）是受决策结果影响、并在决策做出后被告知的人。RACI 是更早出现的、面向任务的矩阵，通常被描述为：为每项活动指定一个负责执行的人（responsible）、恰好一个对其问责的人（accountable）、事前被咨询的人（consulted）和事后被告知的人（informed）；它是覆盖多项任务的矩阵，而不是针对单次决策的流程。

为什么重要

技术决策会以两种方式陷入停滞：要么没有人负责把决策推进到底，要么所有人都以为自己握有否决权。指定一名推动者可以解决第一个问题；指定唯一一名审批人可以解决第二个问题。把角色写清楚，也能让贡献者明白自己的意见是用来做什么的，从而降低讨论的火药味。

如何应用

• 对于影响不止一个团队的决策，新建一个以问题为标题的页面，按姓名列出 D、A、C、I 四类角色，并设定决策日期。该页面由推动者负责维护。
• 审批人的人选应看谁将承担决策后果：是将来运行该结果的系统的负责人，而不是在场级别最高的人。
• 贡献者应在任何会议之前，就把自己的建议和理由写在页面上；会议是用来处理分歧的，不是用来宣读材料的。
• 把最终决定、被否决的方案及其原因，记录进一份架构决策记录（architecture decision record，ADR）；当 ADR 写完、知情名单也已通知到位，DACI 流程就算结束。
• 当问题是经常性任务归属不清（谁负责轮换证书、谁负责评审依赖更新），而不是一次性的选择时，改用 RACI。

常见陷阱

设两名审批人，或者一名遇事就把决定权交给委员会的审批人，都会重新制造出这套框架本该消除的停滞。既是推动者又是审批人的人，会跳过收集信息的环节。把贡献者当作表决者对待，只会产生取最小公约数的决策。一行里有好几个“A”、或者每个人都标了“C”的 RACI 矩阵，只是摆设。框架分配的是角色，取代不了判断；一项没有记录理由的决定，日后还会被重新翻出来争论。