DACI in Jira: Für jede Entscheidung eine klare Verantwortung

Ein Jira-Vorgang kann eine lange Diskussion enthalten, ohne einer Entscheidung näherzukommen. Die Entwicklung empfiehlt das eine, der Support das andere, und die Produktverantwortliche wartet darauf, dass jemand die Optionen zusammenführt. Alle beteiligen sich, aber niemand weiß, wer entscheiden soll.

DACI gibt diesem Gespräch Struktur. Es klärt, wer die Entscheidung voranbringt, wer entscheidet, wessen Fachwissen zählt und wer das Ergebnis benötigt. In dieser Anleitung trifft ein fiktives Kundenportal-Team eine Entscheidung zum Benachrichtigungsversand und hält die Rollen in Power Pack für Jira fest.

Die vier DACI-Rollen verstehen

DACI steht für Driver, Approver, Contributors und Informed. Atlassians DACI-Anleitung beschreibt den Driver als die Person, die den Entscheidungsprozess organisiert, und den Approver als die einzige Person, die entscheidet. Contributors bringen Fachwissen ein; informierte Beteiligte erhalten das Ergebnis. Die Quelle ist unten verlinkt.

Unterscheiden Sie im Gespräch zwischen Koordination und Entscheidung. Wer die Arbeit koordiniert, erhält dadurch nicht automatisch die letzte Entscheidungsbefugnis. Ebenso muss die entscheidende Person nicht sämtliche Belege selbst zusammentragen.

Wählen Sie eine Frage, die eine Entscheidung braucht

In unserem fiktiven Portal verfolgen Kunden Änderungen an ihren Support-Anfragen. Das Team muss entscheiden, wie gewöhnliche Statusbenachrichtigungen in der nächsten Veröffentlichung ankommen sollen. Zur Wahl stehen sofortige E-Mails, eine tägliche Zusammenfassung und ein Posteingang im Portal.

Maya, die Produktverantwortliche, möchte weniger ablenkende E-Mails. Leo, der Entwickler, sorgt sich um den Aufbau eines zweiten Benachrichtigungssystems. Sam, der Support-Leiter, befürchtet, dass Kunden Fortschrittsmeldungen übersehen. Priya, die Testerin, benötigt einen festgelegten Ansatz, bevor sie die Prüfungen für die Veröffentlichung entwirft.

Schreiben Sie die Frage in den passenden Jira-Vorgang: „Wie sollen wir gewöhnliche Aktualisierungen von Support-Anfragen in der ersten Portalversion zustellen?“ Diese Formulierung grenzt die Diskussion ein. Sie betrifft gewöhnliche Statusänderungen, entscheidet aber nicht über Passwortzurücksetzungen, dringende Sicherheitshinweise oder jeden künftigen Kommunikationskanal.

Tragen Sie im üblichen Teamprozess ein angestrebtes Entscheidungsdatum in die Vorgangsbeschreibung ein. In diesem Beispiel wird die Antwort vor der nächsten Planung benötigt. Das Datum ist eine Abstimmungsvereinbarung, keine Zusage, dass die Matrix Erinnerungen versendet oder eine Frist durchsetzt.

Verteilen Sie Rollen anhand der tatsächlichen Unklarheit

Das Team wählt Leo als Driver, weil er die Umsetzungsoptionen zusammentragen und fehlende technische Belege erkennen kann. Maya wird Approver, weil die Abwägung für die Veröffentlichung in ihre vereinbarte Produktzuständigkeit fällt. Sam liefert den Support-Kontext. Priya bringt Testbarkeit und Fehlerszenarien ein. Elena, die die Kundenkommunikation vorbereitet, benötigt das Endergebnis.

Fragen Sie vor dem Eintragen, ob jede Person ihre Rolle erfüllen kann. Leo braucht Zeit zum Vergleichen. Maya muss vor der Planung verfügbar sein. Sam und Priya brauchen konkrete Fragen statt einer unbefristeten Einladung zu beliebigen Kommentaren.

Wenn zwei Personen beide die letzte Entscheidungsbefugnis beanspruchen, klären Sie diese Grenze, bevor Sie die Matrix als vollständig ansehen. Vielleicht verbindet die Frage eine Produktentscheidung mit einer separaten Budgetentscheidung. Teilen Sie Entscheidungen auf, wenn tatsächlich unterschiedliche entscheidende Personen erforderlich sind. Ein zusätzliches A, das das Gespräch vermeiden soll, lässt die Unklarheit bestehen.

Stellen Sie Mitwirkenden beantwortbare Fragen

Leo bittet Sam um drei aktuelle Beispiele, bei denen Kunden eine Aktualisierung ihrer Support-Anfrage missverstanden haben. Priya soll mögliche Probleme benennen, wenn mehrere Änderungen kurz hintereinander erfolgen. Leo erstellt einen kurzen technischen Vergleich auf Basis des vorhandenen Systems.

Das sind erfundene Beiträge für dieses Beispiel, keine gemessenen Produktergebnisse. Sie zeigen, wie hilfreiche Mitwirkung aussehen kann. Jeder Beitrag verbindet das Fachwissen einer Person mit der anstehenden Entscheidung.

Das Team bewertet die Optionen anhand von drei Fragen: Erkennen Kunden hilfreichen Fortschritt? Kann das Team den Ansatz mit der vorhandenen Kapazität betreiben? Lässt sich die Veröffentlichung überzeugend testen? Diese Fragen stehen neben den Optionen im Jira-Vorgang, damit alle dasselbe Problem bewerten.

Tun Sie nicht so, als ließe sich jede Überlegung auf einen genauen Punktwert reduzieren. Eine Tabelle kann das Gespräch ordnen, ohne eine mathematisch richtige Antwort zu liefern. Benennen Sie unsichere Schätzungen und entscheiden Sie, ob weitere Untersuchungen die Wahl verändern würden.

Vergleichen Sie Optionen vor der Entscheidung

Hier ist der Arbeitsvergleich des Teams. Die Beobachtungen beziehen sich auf unser Beispielportal, in dem E-Mail-Versand bereits besteht und ein Portal-Posteingang neu entwickelt werden müsste.

Sams Beispiele deuten darauf hin, dass Kunden eine zeitnahe Nachricht bei einer bedeutsamen Änderung schätzen. Priya weist darauf hin, dass wiederholte Bearbeitungen ohne klar festgelegtes Verhalten verwirrende doppelte Nachrichten erzeugen könnten. Leo erklärt, dass eine Zusammenfassung in diesem System zusätzliche Zeitsteuerung und Gruppierungslogik benötigt.

Maya kann nun eine konkrete Abwägung treffen. Für die erste Veröffentlichung wählt sie sofortige E-Mails bei bedeutsamen Statusänderungen; der Umgang mit Duplikaten wird in den Umsetzungstickets festgelegt. Kleine interne Bearbeitungen lösen keine Kundennachrichten aus. Das Team prüft eine Zusammenfassung erneut, wenn Kundenrückmeldungen zeigen, dass hilfreiche Meldungen weiterhin zu häufig eintreffen.

Dieses Ergebnis ist bewusst genauer als „E-Mail verwenden“. Es erklärt Entwicklung, Tests und Support, was die Wahl bedeutet. Außerdem hält es fest, unter welchen Umständen das Team neu nachdenken sollte.

Erstellen Sie die DACI-Matrix in Power Pack

Öffnen Sie Power Pack im Jira-Vorgang und wählen Sie RACI / DACI Matrix. Stellen Sie im Auswahlfeld Model den Wert DACI ein. Anschließend stehen in der Matrix die Rollen D, A, C und I zur Verfügung.

Beginnen Sie mit der Personenliste und fügen Sie die an der Entscheidung Beteiligten hinzu. Power Pack unterstützt die Suche nach Jira-Nutzern und externe Personeneinträge. Ein externer Eintrag bildet eine Person in der Matrix ab; er erstellt kein Konto und gewährt keinen Zugriff auf den Jira-Vorgang.

Fügen Sie in der Ansicht für Arbeitsergebnisse eine Zeile für die Entscheidungsfrage hinzu. Obwohl die Oberfläche ihre Zeilen als Arbeitsergebnisse organisiert, eignet sich eine klar benannte Entscheidung für dieses DACI-Beispiel gut. Halten Sie nicht zugehörige Umsetzungsaufgaben aus dieser ersten Zeile heraus, damit die Zuweisung leicht verständlich bleibt.

Wechseln Sie zur Matrix und weisen Sie Leo D, Maya A, Sam und Priya C sowie Elena I zu. Ein Klick auf eine Zelle wechselt durch die verfügbaren Rollen. Fokussierte Zellen unterstützen auch die in der Oberfläche angezeigten Rollenbuchstaben als Tastenkürzel.

Prüfen Sie die Zeilenhinweise. Power Pack erkennt fehlende oder mehrere entscheidende Personen sowie Zeilen ohne Driver. Diese Prüfungen helfen, unvollständige Rollenmuster zu finden. Sie können nicht feststellen, ob Maya organisatorisch entscheidungsbefugt ist oder ob Leo tatsächlich genügend Belege gesammelt hat.

Prüfen Sie vor dem Verlassen des Vorgangs die Speicheranzeige. Meldet das Werkzeug einen lokalen oder Offline-Status, gehen Sie nicht davon aus, dass die neuesten Zuweisungen bereits für andere verfügbar sind. Hilfreich ist die Vereinbarung, die alle gemeinsam finden und besprechen können.

Schließen Sie die Diskussion mit einem nutzbaren Ergebnis ab

Eine Rollenmatrix enthält nicht die gesamte Entscheidung. Halten Sie den gewählten Ansatz, die Begründung und wichtige Folgen in der Vorgangsbeschreibung oder im Decision Log von Power Pack fest. Nennen Sie die ernsthaft erwogenen Optionen, damit andere die Wahl später nachvollziehen können.

Leo teilt Elena anschließend das Ergebnis knapp über den üblichen Kommunikationsweg des Teams mit. Die Nachricht erklärt, was veröffentlicht wird, welche Meldungen enthalten sind, was außerhalb des Umfangs bleibt und wo die Umsetzung zu finden ist. Ein I für Elena in der Matrix versendet diese Nachricht nicht.

Erstellen oder aktualisieren Sie die benötigten Jira-Umsetzungstickets über Ihren normalen Workflow. In diesem Beispiel betreffen sie die Erkennung bedeutsamer Statusänderungen, den Umgang mit Duplikaten und die Prüfung. Eine DACI-Zuweisung hält eine Entscheidungsrolle fest; sie ändert weder automatisch die zugewiesene Jira-Person noch den Vorgangsstatus.

Halten Sie den Aufwand angemessen

Nutzen Sie DACI, wenn eine echte Wahl durch unklare Beteiligung oder Befugnisse stockt. Ein gewöhnliches Umsetzungsdetail, das ein Entwickler bereits selbst entscheiden darf, benötigt vielleicht nur eine kurze Notiz. Eine vollständige Matrix für jede Kleinigkeit kann den Prozess unnötig schwer pflegbar machen.

Prüfen Sie Zuweisungen erneut, wenn sich die Frage verändert. Erwägt das Portal-Team später einen kostenpflichtigen Benachrichtigungsanbieter, muss möglicherweise eine andere Person die Ausgaben genehmigen. Die ursprüngliche Produktentscheidung erweitert sich nicht stillschweigend um diese neue Befugnis.

Wählen Sie eine offene Frage in Ihrer aktuellen Jira-Arbeit. Grenzen Sie sie klar ein, vereinbaren Sie einen Driver und genau einen Approver und benennen Sie die benötigten Beiträge. Halten Sie diese Rollen mit Power Pack beim Vorgang sichtbar. Dokumentieren und kommunizieren Sie anschließend die getroffene Entscheidung.

• Atlassian Team Playbook: DACI-Modell für Entscheidungen