DACI et RACI pour les décisions techniques : un seul approbateur, des contributeurs nommés

Ce que c'est

La méthode DACI d'Atlassian définit quatre rôles pour une décision. Le pilote (driver) rassemble les parties prenantes, réunit l'information, fixe le périmètre et fait en sorte que la décision soit prise au plus tard à la date convenue. L'approbateur (approver) est une seule personne, qui prend la décision ; la méthode insiste sur « one » (un seul), pour que l'approbation soit un rôle actif et non une simple formalité. Les contributeurs apportent leur connaissance du sujet et leurs recommandations : ils ont voix au chapitre, mais pas de droit de vote. Les personnes informées sont concernées par le résultat et en sont averties une fois la décision prise. RACI, matrice plus ancienne centrée sur les tâches, est généralement décrite comme attribuant à chaque activité une personne responsable de son exécution (responsible), exactement une personne devant en rendre compte (accountable), des personnes consultées en amont et des personnes informées en aval ; c'est une matrice appliquée à des tâches, plutôt qu'un processus pour une décision unique.

Pourquoi c'est important

Les décisions techniques s'enlisent de deux façons : soit personne n'a la charge de les mener à leur terme, soit chacun croit détenir un droit de veto. Désigner un pilote règle le premier problème ; désigner un unique approbateur règle le second. Consigner les rôles indique aussi aux contributeurs à quoi sert leur apport, ce qui apaise la discussion.

Comment l'appliquer

• Pour une décision touchant plusieurs équipes, ouvrir une page dont le titre est la question posée, y nommer les personnes correspondant aux rôles D, A, C et I, et fixer une date de décision. Le pilote est responsable de la page.
• Choisir l'approbateur en fonction de qui assumera les conséquences : le responsable du système dans lequel le résultat sera mis en œuvre, pas la personne présente la plus haut placée dans la hiérarchie.
• Les contributeurs rédigent leur recommandation et leur raisonnement sur la page avant toute réunion ; la réunion sert à traiter les désaccords, pas à lire le contenu.
• Consigner la décision, les options rejetées et les raisons de leur rejet dans un document de décision d'architecture (ADR) ; le processus DACI se termine quand l'ADR est rédigé et que les personnes de la liste des informés ont été averties.
• Utiliser plutôt RACI lorsque le problème est une responsabilité mal définie pour des tâches récurrentes (qui assure la rotation des certificats, qui examine les mises à jour de dépendances), et non un choix ponctuel.

Pièges

Deux approbateurs, ou un approbateur qui s'en remet à un comité, recréent le blocage que ce cadre est censé supprimer. Un pilote qui est aussi l'approbateur saute l'étape de collecte de l'information. Des contributeurs traités comme des votants produisent des décisions au plus petit dénominateur commun. Une matrice RACI avec plusieurs « A » par ligne, ou un « C » attribué à tout le monde, n'est que décorative. Ces cadres attribuent des rôles ; ils ne remplacent pas le jugement, et une décision consignée sans sa justification sera remise en discussion.