GuiderPower Pack8 min läsning

DACI i Jira: ge varje beslut en tydlig ansvarig

Förvandla en avstannad diskussion till en tydlig beslutsprocess med namngivna roller och ett praktiskt kundportalexempel.

Flera perspektiv bidrar till ett beslut med en tydlig väg framåt.

Ett Jira-ärende kan samla en lång diskussion utan att komma närmare ett beslut. Utveckling har en rekommendation, support en annan och produktägaren väntar på att någon ska sammanställa alternativen. Alla deltar, men ingen vet vem som ska avgöra frågan.

DACI ger samtalet en struktur. Det identifierar vem som driver beslutet framåt, vem som bestämmer, vems kunskap som behövs och vem som behöver resultatet. I den här guiden använder vi ett fiktivt kundportalteam för att arbeta igenom ett beslut om aviseringsleverans och dokumentera rollerna i Power Pack för Jira.

Förstå de fyra DACI-rollerna

DACI står för Driver, Approver, Contributors och Informed. Atlassians DACI-övning beskriver Driver som personen som organiserar beslutsprocessen och Approver som den enda person som gör valet. Contributors bidrar med kunskap; informerade deltagare får resultatet. Källan finns länkad nedan.

Drivande personDriver beslutet framåt och samlar den information som behövs.
BeslutsfattareGör det slutliga valet inom den överenskomna omfattningen.
BidragsgivareBidrar med relevant kunskap och rekommendationer.
InformeradeFår resultatet eftersom det påverkar deras arbete.

Skilj på den drivande personen och beslutsfattaren i samtalet. Att samordna arbetet ger inte automatiskt någon det slutliga beslutet. På samma sätt betyder det att välja resultatet inte att beslutsfattaren personligen måste samla varje underlag.

Välj en fråga som behöver ett beslut

Vår fiktiva portal låter kunder följa uppdateringar av sina supportärenden. Teamet måste välja hur vanliga statusaviseringar ska nå kunderna i nästa release. De överväger omedelbara mejl, en daglig sammanfattning och en inkorg i portalen.

Maya, produktägaren, vill ha färre störande mejl. Leo, utvecklaren, oroar sig för att lägga till ett andra aviseringssystem. Sam, supportansvarig, befarar att kunder missar uppdateringar om framsteg. Priya, testaren, behöver ett fastställt tillvägagångssätt innan hon planerar releasekontrollerna.

Skriv frågan på det relevanta Jira-ärendet: ”Hur ska vi leverera vanliga uppdateringar av supportärenden i portalens första release?” Formuleringen ger diskussionen en gräns. Den omfattar vanliga statusändringar, men avgör inte beteendet för lösenordsåterställningar, brådskande säkerhetsmeddelanden eller alla framtida kommunikationskanaler.

Lägg till ett måldatum för beslutet i ärendebeskrivningen genom teamets vanliga process. I det här exemplet behövs svaret före nästa planeringsmöte. Datumet är en samordningsöverenskommelse, inte ett löfte om att matrisen skickar påminnelser eller upprätthåller en tidsgräns.

Tilldela roller kring den faktiska osäkerheten

Teamet väljer Leo som drivande person eftersom han kan sammanställa implementationsalternativen och identifiera saknat tekniskt underlag. Maya är beslutsfattare eftersom releaseavvägningen ligger inom hennes överenskomna produktmandat. Sam bidrar med kundsupportens sammanhang. Priya bidrar med testbarhet och felscenarier. Elena, som förbereder kundkommunikation, behöver slutresultatet.

Välj leverans för vanliga aviseringarDACCI

Fråga om varje person kan fullfölja sin roll innan ni registrerar tilldelningarna. Leo behöver tid att jämföra alternativen. Maya behöver vara tillgänglig före planeringen. Sam och Priya behöver specifika frågor, inte en öppen inbjudan att kommentera utan slut.

Om två personer båda tror att de har slutligt mandat ska ni reda ut gränsen innan ni förklarar matrisen färdig. Kanske kombinerar frågan ett produktval med ett separat budgetbeslut. Dela upp besluten när de faktiskt behöver olika beslutsfattare. Att lägga till ytterligare ett A för att undvika samtalet lämnar den underliggande osäkerheten kvar.

Ge bidragsgivarna frågor de kan besvara

Leo ber Sam ta med tre färska exempel där kunder missförstod en uppdatering av ett supportärende. Han ber Priya identifiera vad som kan gå fel när flera uppdateringar sker tätt. Han förbereder en kort teknisk jämförelse utifrån teamets befintliga system.

Detta är fiktiva bidrag till exemplet, inte uppmätta produktresultat. Syftet är att visa hur användbara bidrag kan se ut. Varje bidrag kopplar en persons kunskap till beslutet som ska fattas.

Teamet kommer överens om att bedöma alternativen utifrån tre frågor: kan kunderna märka användbara framsteg, kan teamet stödja lösningen med nuvarande kapacitet och kan releasen testas övertygande? De skriver frågorna intill alternativen i Jira-ärendet så att alla bedömer samma problem.

Låtsas inte att varje hänsyn kan reduceras till en exakt poäng. En tabell kan organisera samtalet utan att ge ett matematiskt korrekt svar. Om en uppskattning är osäker, ange osäkerheten och avgör om vidare undersökning skulle ändra valet.

Jämför alternativen innan du ber om ett val

Här är teamets arbetsjämförelse. Observationerna gäller vår exempelportal, där e-postleverans redan finns och en inkorg i portalen skulle vara nytt arbete.

Omedelbara mejlAnvänder en befintlig kanal och visar uppdateringar snabbt.Täta ändringar kan skapa för många meddelanden.
Daglig sammanfattningSamlar vanliga uppdateringar i färre meddelanden.Kunderna får vänta längre; gruppering kräver extra arbete.
Inkorg i portalenHåller uppdateringarna intill supportärendet.Kunderna måste återvända till portalen; en ny inkorg måste byggas.

Sams exempel tyder på att kunder värdesätter en snabb uppdatering när ett ärende förändras på ett meningsfullt sätt. Priya påpekar att upprepade redigeringar kan skapa förvirrande dubbletter om beteendet inte definieras. Leo förklarar att en sammanfattning kräver extra schemaläggning och gruppering i just detta system.

Maya har nu en konkret avvägning att bedöma. Hon väljer omedelbara mejl för betydelsefulla statusändringar i första releasen, med dubbletthantering specificerad i leveransärendena. Små interna redigeringar ska inte skapa kundaviseringar. Teamet återkommer till en sammanfattning om kundernas återkoppling visar att användbara uppdateringar ändå kommer för ofta.

Resultatet är avsiktligt mer precist än ”använd mejl”. Det berättar för implementation, testning och support vad valet innebär. Det dokumenterar också den omständighet som kan få teamet att tänka om.

Bygg DACI-matrisen i Power Pack

Öppna Power Pack på Jira-ärendet och välj verktyget RACI / DACI Matrix. Sätt väljaren Model till DACI. Matrisen använder då D, A, C och I som tillgängliga roller.

Börja med deltagarlistan och lägg till personerna som deltar i beslutet. Power Pack stöder sökning efter Jira-användare och externa deltagarposter. En extern post kan representera en person i matrisen; den skapar inget konto och ger inte tillgång till Jira-ärendet.

Lägg till en rad för beslutsfrågan i leveransvyn. Även om gränssnittet använder leveranser som radstruktur fungerar ett tydligt namngivet beslut bra i detta DACI-exempel. Håll orelaterade implementationsuppgifter utanför den första raden så att tilldelningen är lätt att tolka.

Gå till matrisen och tilldela Leo D, Maya A, Sam och Priya C samt Elena I. När du klickar i en cell växlar den mellan tillgängliga roller. Fokuserade celler stöder också genvägarna med rollbokstäver som visas i gränssnittet.

Granska radindikatorerna. Power Pack identifierar saknade beslutsfattare, flera beslutsfattare och rader som behöver en drivande person. Kontrollerna hjälper dig upptäcka ett ofullständigt rollmönster. De kan inte avgöra om Maya har organisatoriskt mandat att besluta eller om Leo faktiskt har samlat tillräckligt med underlag.

Kontrollera sparindikatorn innan du lämnar ärendet. Om verktyget visar ett lokalt eller offline-läge ska du inte anta att kollegorna redan har tillgång till de senaste tilldelningarna. Den användbara överenskommelsen är den version som människor kan hitta och diskutera tillsammans.

Avsluta diskussionen med ett användbart resultat

En rollmatris innehåller inte hela beslutet. Dokumentera den valda lösningen, resonemanget och viktiga konsekvenser i ärendebeskrivningen eller Power Packs Decision Log. Ta med alternativen som övervägdes seriöst så att en annan kollega kan förstå valet senare.

Leo delar sedan ett kortfattat resultat med Elena genom teamets vanliga kommunikationsprocess. Uppdateringen säger vad som ska levereras, vilka meddelanden som ingår, vad som ligger utanför omfattningen och var implementationsarbetet finns. Att markera Elena med I i en matris skickar inte meddelandet.

Skapa eller uppdatera nödvändiga leveransärenden i Jira genom ert vanliga arbetsflöde. I exemplet omfattar de upptäckt av betydelsefulla statusändringar, dubbletthantering och kontroll. En DACI-tilldelning dokumenterar en roll i beslutet; den ändrar inte automatiskt tilldelad person i Jira eller flyttar ett ärende till en annan status.

Håll modellen proportionerlig

Använd DACI när ett verkligt val har stannat av på grund av otydligt deltagande eller mandat. En vanlig implementationsdetalj som en utvecklare redan får bestämma kan bara behöva en kort anteckning. En fullständig matris för varje litet val kan göra processen svårare att underhålla.

Se över tilldelningarna när frågan förändras. Om portalteamet senare överväger en betald aviseringsleverantör kan en annan person behöva godkänna utgiften. Det ursprungliga produktbeslutet utökas inte tyst till att omfatta det nya mandatet.

Välj en olöst fråga i ditt nuvarande Jira-arbete. Ge den en tydlig gräns, kom överens om en drivande person och en beslutsfattare och identifiera vilka specifika synpunkter som behövs. Använd Power Pack för att hålla rollerna synliga intill ärendet och dokumentera och kommunicera sedan beslutet när det fattas.

Relaterade artiklar

Kontakta Oss

Frågor om artikeln? Låt oss diskutera era tekniska mål.

Dina Uppgifter