DACI dans Jira : donner un responsable clair à chaque décision

Un ticket Jira peut accumuler une longue discussion sans se rapprocher d’une décision. Le développement recommande une chose, le support une autre, et la responsable produit attend que quelqu’un rassemble les options. Tout le monde participe, mais personne ne sait qui doit trancher.

DACI structure cette conversation. Il précise qui fait avancer la décision, qui décide, quelle expertise compte et qui doit recevoir le résultat. Dans ce guide, une équipe fictive de portail client choisit un mode d’envoi des notifications et enregistre les rôles dans Power Pack pour Jira.

Comprendre les quatre rôles DACI

DACI signifie Driver, Approver, Contributors et Informed. Le guide DACI d’Atlassian décrit le Driver comme la personne qui organise le processus de décision et l’Approver comme l’unique personne qui choisit. Les Contributors apportent leur expertise ; les participants informés reçoivent le résultat. La source est indiquée ci-dessous.

Distinguez bien le pilote et le décideur dans vos échanges. Coordonner le travail ne donne pas automatiquement le dernier mot. De même, choisir le résultat ne signifie pas que le décideur doit recueillir personnellement chaque élément de preuve.

Choisissez une question qui nécessite une décision

Notre portail fictif permet aux clients de suivre les mises à jour de leurs demandes de support. L’équipe doit choisir comment leur transmettre les notifications courantes dans la prochaine version. Elle envisage un e-mail immédiat, un récapitulatif quotidien et une boîte de réception dans le portail.

Maya, responsable produit, souhaite moins d’e-mails distrayants. Leo, développeur, s’inquiète de l’ajout d’un second système de notification. Sam, responsable du support, craint que les clients manquent les nouvelles sur l’avancement. Priya, testeuse, a besoin d’une approche arrêtée avant de concevoir les vérifications de la version.

Écrivez la question dans le ticket Jira concerné : « Comment transmettre les mises à jour courantes des demandes de support dans la première version du portail ? » Cette formulation délimite la discussion. Elle couvre les changements de statut courants, sans décider du comportement des réinitialisations de mot de passe, des alertes de sécurité urgentes ou de tous les futurs canaux.

Ajoutez une date cible de décision dans la description du ticket selon le processus habituel de l’équipe. Ici, la réponse est nécessaire avant la prochaine planification. Cette date est un accord de coordination, pas une promesse que la matrice enverra des rappels ou imposera une échéance.

Attribuez les rôles selon l’incertitude réelle

L’équipe choisit Leo comme pilote, car il peut rassembler les options de réalisation et identifier les preuves techniques manquantes. Maya décide, car l’arbitrage de la version relève de son autorité produit convenue. Sam apporte le contexte du support. Priya examine la testabilité et les scénarios de panne. Elena, chargée de la communication client, a besoin du résultat final.

Avant d’enregistrer ces attributions, vérifiez que chaque personne peut assumer son rôle. Leo a besoin de temps pour comparer. Maya doit être disponible avant la planification. Sam et Priya ont besoin de questions précises plutôt que d’une invitation ouverte à commenter indéfiniment.

Si deux personnes pensent détenir l’autorité finale, clarifiez cette frontière avant de déclarer la matrice complète. La question combine peut-être un choix produit et une décision budgétaire distincte. Séparez les décisions lorsqu’elles exigent réellement des décideurs différents. Ajouter un second A pour éviter la conversation laisse l’incertitude intacte.

Posez aux contributeurs des questions auxquelles ils peuvent répondre

Leo demande à Sam trois exemples récents de clients ayant mal compris une mise à jour de leur demande. Il demande à Priya ce qui peut mal se passer lorsque plusieurs mises à jour surviennent rapidement. Il prépare un bref comparatif technique fondé sur le système existant.

Ces contributions sont fictives et illustrent l’exemple ; ce ne sont pas des résultats produit mesurés. Elles montrent à quoi ressemble une contribution utile. Chacune relie l’expertise d’une personne à la décision à prendre.

L’équipe convient d’évaluer les options selon trois questions : les clients peuvent-ils remarquer les progrès utiles, l’équipe peut-elle prendre en charge l’approche avec sa capacité actuelle et la version peut-elle être testée de façon convaincante ? Elle inscrit ces questions avec les options dans Jira afin que tous évaluent le même problème.

Ne faites pas comme si toute considération pouvait devenir une note précise. Un tableau peut structurer la conversation sans produire une réponse mathématiquement exacte. Si une estimation est incertaine, nommez cette incertitude et déterminez si une investigation supplémentaire changerait le choix.

Comparez les options avant de demander un choix

Voici le comparatif de travail de l’équipe. Ces observations concernent notre portail d’exemple, où l’envoi d’e-mails existe déjà et où une boîte de réception serait un nouveau développement.

Les exemples de Sam suggèrent que les clients apprécient une mise à jour rapide lorsqu’une demande change de façon significative. Priya souligne que des modifications répétées pourraient créer des doublons confus sans comportement défini. Leo explique qu’un récapitulatif exige, dans ce système, du travail supplémentaire de planification et de regroupement.

Maya dispose maintenant d’un arbitrage concret. Elle choisit l’e-mail immédiat pour les changements de statut significatifs de la première version, avec la gestion des doublons précisée dans les tickets de réalisation. Les petites modifications internes ne produiront pas de notifications client. L’équipe réexaminera le récapitulatif si les retours montrent que les mises à jour utiles restent trop fréquentes.

Ce résultat est volontairement plus précis que « utiliser l’e-mail ». Il explique au développement, aux tests et au support ce que signifie le choix. Il consigne aussi les circonstances qui pourraient amener l’équipe à le revoir.

Construisez la matrice DACI dans Power Pack

Ouvrez Power Pack sur le ticket Jira et choisissez RACI / DACI Matrix. Réglez le sélecteur Model sur DACI. La matrice propose alors les rôles D, A, C et I.

Commencez par la liste des participants et ajoutez les personnes concernées. Power Pack permet de rechercher des utilisateurs Jira et d’ajouter des participants externes. Une entrée externe représente une personne dans la matrice ; elle ne crée pas de compte et ne lui donne pas accès au ticket.

Dans la vue des livrables, ajoutez une ligne pour la question de décision. Même si l’interface structure les lignes en livrables, une décision clairement nommée convient à cet exemple DACI. N’ajoutez pas les tâches de réalisation sans rapport dans cette première ligne afin de garder l’attribution lisible.

Passez à la matrice et attribuez D à Leo, A à Maya, C à Sam et Priya, et I à Elena. Cliquer sur une cellule fait défiler les rôles disponibles. Les cellules sélectionnées acceptent aussi les raccourcis par lettre affichés dans l’interface.

Vérifiez les indicateurs des lignes. Power Pack repère les décideurs absents ou multiples et les lignes sans pilote. Ces contrôles aident à détecter un schéma incomplet. Ils ne peuvent pas établir l’autorité réelle de Maya ni déterminer si Leo a recueilli suffisamment de preuves.

Vérifiez l’indicateur d’enregistrement avant de quitter le ticket. Si l’outil indique un état local ou hors ligne, ne supposez pas que les dernières attributions sont déjà visibles par vos collègues. L’accord utile est la version que chacun peut retrouver et discuter ensemble.

Terminez la discussion par un résultat exploitable

Une matrice de rôles ne contient pas toute la décision. Consignez l’approche retenue, les raisons et les conséquences importantes dans la description du ticket ou le Decision Log de Power Pack. Incluez les options sérieusement envisagées pour qu’un collègue puisse comprendre le choix plus tard.

Leo communique ensuite un résultat concis à Elena selon le processus habituel de l’équipe. Le message précise ce qui sera livré, les messages inclus, ce qui reste hors périmètre et où trouver le travail de réalisation. Attribuer I à Elena dans la matrice n’envoie pas ce message.

Créez ou actualisez les tickets Jira nécessaires dans votre workflow habituel. Ici, ils couvrent la détection des changements significatifs, la gestion des doublons et la vérification. Une attribution DACI enregistre un rôle dans la décision ; elle ne change pas automatiquement la personne assignée ni le statut du ticket.

Gardez une démarche proportionnée

Utilisez DACI lorsqu’un vrai choix est bloqué par une participation ou une autorité ambiguë. Un détail courant qu’un développeur peut déjà décider peut ne nécessiter qu’une courte note. Ajouter une matrice complète à chaque petit choix peut rendre le processus difficile à entretenir.

Réexaminez les attributions lorsque la question change. Si l’équipe envisage ensuite un fournisseur payant de notifications, une autre personne devra peut-être autoriser la dépense. La décision produit initiale ne s’étend pas silencieusement à cette nouvelle autorité.

Choisissez une question ouverte dans votre travail Jira actuel. Délimitez-la clairement, convenez d’un pilote et d’un décideur unique, et identifiez les contributions précises attendues. Utilisez Power Pack pour rendre ces rôles visibles à côté du ticket, puis consignez et communiquez la décision lorsqu’elle est prise.

• Atlassian Team Playbook : le cadre de décision DACI