GuidesPower Pack8 min læsning

DACI i Jira: giv hver beslutning en tydelig ansvarlig

Gør en fastlåst diskussion til en klar beslutningsproces med navngivne roller og et praktisk kundeportaleksempel.

Flere perspektiver bidrager til én beslutning med en tydelig vej frem.

En Jira-sag kan samle en lang diskussion uden at komme nærmere en beslutning. Udvikling har én anbefaling, support en anden, og produktejeren venter på, at nogen samler mulighederne. Alle deltager, men ingen ved, hvem der skal træffe afgørelsen.

DACI giver samtalen struktur. Den identificerer, hvem der driver beslutningen frem, hvem der beslutter, hvis ekspertise der er vigtig, og hvem der har brug for resultatet. I denne vejledning bruger vi et fiktivt kundeportalteam til at gennemgå en beslutning om notifikationslevering og registrere rollerne i Power Pack til Jira.

Forstå de fire DACI-roller

DACI står for Driver, Approver, Contributors og Informed. Atlassians DACI-øvelse beskriver Driver som den person, der organiserer beslutningsprocessen, og Approver som den ene person, der foretager valget. Contributors leverer ekspertise; informerede deltagere modtager resultatet. Kilden er linket nedenfor.

TovholderHolder beslutningen i gang og samler de nødvendige oplysninger.
GodkenderTræffer det endelige valg inden for det aftalte omfang.
BidragydereLeverer relevant ekspertise og anbefalinger.
InformeredeModtager resultatet, fordi det påvirker deres arbejde.

Hold tovholder og godkender adskilt i samtalen. At koordinere arbejdet giver ikke automatisk nogen den endelige beslutning. Tilsvarende betyder det at vælge resultatet ikke, at godkenderen personligt skal indsamle alt underlag.

Vælg et spørgsmål, der kræver en beslutning

Vores fiktive portal lader kunder følge opdateringer på deres supportanmodninger. Teamet skal vælge, hvordan almindelige statusnotifikationer når kunderne i næste udgivelse. De overvejer øjeblikkelig mail, en daglig opsummering og en indbakke inde i portalen.

Maya, produktejeren, vil have færre forstyrrende mails. Leo, udvikleren, er bekymret for at tilføje et andet notifikationssystem. Sam, supportlederen, frygter, at kunderne overser statusopdateringer. Priya, testeren, har brug for en fastlagt tilgang, før hun planlægger kontrollen af udgivelsen.

Skriv spørgsmålet på den relevante Jira-sag: ”Hvordan skal vi levere almindelige opdateringer om supportanmodninger i den første portaludgivelse?” Den formulering afgrænser diskussionen. Den omfatter almindelige statusændringer; den afgør ikke adfærden for nulstilling af adgangskoder, hastende sikkerhedsbeskeder eller alle fremtidige kommunikationskanaler.

Tilføj en måldato for beslutningen i sagsbeskrivelsen via teamets normale proces. I dette eksempel skal svaret være klar før næste planlægningsmøde. Datoen er en koordineringsaftale, ikke et løfte om, at matrixen sender påmindelser eller håndhæver en frist.

Tildel roller omkring den faktiske usikkerhed

Teamet vælger Leo som tovholder, fordi han kan samle implementeringsmulighederne og identificere manglende teknisk underlag. Maya er godkender, fordi afvejningen for udgivelsen ligger inden for hendes aftalte produktmandat. Sam bidrager med kundesupportens kontekst. Priya bidrager med testbarhed og fejlscenarier. Elena, som forbereder kundekommunikationen, har brug for det endelige resultat.

Vælg levering af almindelige notifikationerDACCI

Spørg, om hver person kan udfylde rollen, før tildelingerne indtastes. Leo skal have tid til at sammenligne mulighederne. Maya skal være tilgængelig før planlægningen. Sam og Priya skal have konkrete spørgsmål frem for en åben invitation til at kommentere uden ende.

Hvis to personer begge mener, at de har den endelige myndighed, skal I afklare grænsen, før matrixen erklæres færdig. Måske kombinerer spørgsmålet et produktvalg med en separat budgetbeslutning. Opdel beslutningerne, når de reelt kræver forskellige godkendere. At tilføje endnu et A for at undgå samtalen efterlader den grundlæggende usikkerhed.

Giv bidragyderne spørgsmål, de kan besvare

Leo beder Sam medbringe tre nylige eksempler, hvor kunder misforstod en opdatering af en supportanmodning. Han beder Priya identificere, hvad der kan gå galt, når flere opdateringer sker tæt på hinanden. Han udarbejder en kort teknisk sammenligning baseret på teamets eksisterende system.

Det er fiktive input til eksemplet, ikke målte produktresultater. Formålet er at vise, hvordan et nyttigt bidrag ser ud. Hvert input forbinder en persons ekspertise med beslutningen.

Teamet aftaler at vurdere mulighederne ud fra tre spørgsmål: kan kunderne opdage nyttig fremdrift, kan teamet understøtte tilgangen med den nuværende kapacitet, og kan udgivelsen testes overbevisende? De skriver spørgsmålene sammen med mulighederne i Jira-sagen, så alle vurderer det samme problem.

Lad være med at foregive, at alle hensyn kan reduceres til en præcis score. En tabel kan organisere samtalen uden at give et matematisk korrekt svar. Hvis et skøn er usikkert, skal usikkerheden nævnes, og I skal afgøre, om yderligere undersøgelse ville ændre valget.

Sammenlign mulighederne, før du beder om et valg

Her er teamets arbejdssammenligning. Observationerne gælder vores illustrative portal, hvor maillevering allerede findes, og en portalindbakke ville være nyt arbejde.

Øjeblikkelig mailBruger en eksisterende kanal og viser opdateringer hurtigt.Hyppige ændringer kan skabe for mange beskeder.
Daglig opsummeringSamler almindelige opdateringer i færre beskeder.Kunderne venter længere; gruppering kræver ekstra arbejde.
PortalindbakkeHolder opdateringer ved siden af supportanmodningen.Kunderne skal vende tilbage til portalen; en ny indbakke skal bygges.

Sams eksempler tyder på, at kunder værdsætter en hurtig opdatering, når en anmodning ændres væsentligt. Priya påpeger, at gentagne redigeringer kan skabe forvirrende dubletter, hvis adfærden ikke defineres. Leo forklarer, at en opsummering kræver yderligere planlægnings- og grupperingsarbejde i netop dette system.

Maya har nu en konkret afvejning at vurdere. Hun vælger øjeblikkelig mail ved væsentlige statusændringer i første udgivelse med dublethåndtering beskrevet i leveranceopgaverne. Små interne redigeringer udløser ikke kundenotifikationer. Teamet genovervejer en opsummering, hvis kundernes feedback viser, at nyttige opdateringer stadig kommer for ofte.

Resultatet er bevidst mere præcist end ”brug mail”. Det fortæller implementering, test og support, hvad valget betyder. Det registrerer også den omstændighed, der kan få teamet til at genoverveje.

Opbyg DACI-matrixen i Power Pack

Åbn Power Pack på Jira-sagen, og vælg værktøjet RACI / DACI Matrix. Sæt vælgeren Model til DACI. Matrixen bruger derefter D, A, C og I som tilgængelige roller.

Start med deltagerlisten, og tilføj personerne, der indgår i beslutningen. Power Pack understøtter søgning efter Jira-brugere og eksterne deltagerposter. En ekstern post kan repræsentere en person i matrixen; den opretter ikke en konto og giver ikke personen adgang til Jira-sagen.

Tilføj en række til beslutningsspørgsmålet i leverancevisningen. Selvom grænsefladen bruger leverancer som rækkestruktur, fungerer en tydeligt navngivet beslutning godt i dette DACI-eksempel. Hold uvedkommende implementeringsopgaver ude af den første række, så tildelingen er let at fortolke.

Gå til matrixen, og tildel Leo D, Maya A, Sam og Priya C samt Elena I. Klik på en celle skifter mellem de tilgængelige roller. Celler med fokus understøtter også de genveje med rollebogstaver, der vises i grænsefladen.

Gennemgå rækkeindikatorerne. Power Pack identificerer manglende godkendere, flere godkendere og rækker, der mangler en tovholder. Kontrollerne hjælper dig med at opdage et ufuldstændigt rollemønster. De kan ikke afgøre, om Maya har organisatorisk myndighed til at beslutte, eller om Leo faktisk har samlet nok underlag.

Kontrollér gemmeindikatoren, før du forlader sagen. Hvis værktøjet viser en lokal eller offline tilstand, må du ikke antage, at de seneste tildelinger allerede er tilgængelige for kollegerne. Den nyttige aftale er den version, folk kan finde og diskutere sammen.

Afslut diskussionen med et brugbart resultat

En rollematrix indeholder ikke hele beslutningen. Registrer den valgte tilgang, begrundelsen og vigtige konsekvenser i sagsbeskrivelsen eller Power Packs Decision Log. Medtag de muligheder, der blev seriøst overvejet, så en anden kollega kan forstå valget senere.

Leo deler derefter et kort resultat med Elena gennem teamets normale kommunikationsproces. Opdateringen siger, hvad der bliver leveret, hvilke beskeder der er omfattet, hvad der forbliver uden for omfanget, og hvor implementeringsarbejdet findes. At markere Elena med I i en matrix sender ikke beskeden.

Opret eller opdater de nødvendige leveranceopgaver i Jira gennem jeres normale arbejdsforløb. I dette eksempel dækker de registrering af væsentlige statusændringer, dublethåndtering og kontrol. En DACI-tildeling registrerer en rolle i beslutningen; den ændrer ikke automatisk en tildelt person i Jira eller en sags status.

Hold modellen proportional

Brug DACI, når et reelt valg er gået i stå på grund af uklar deltagelse eller myndighed. En almindelig implementeringsdetalje, som en udvikler allerede må afgøre, kræver måske kun en kort note. At tilføje en fuld matrix til hvert lille valg kan gøre processen sværere at vedligeholde.

Gense tildelingerne, når spørgsmålet ændres. Hvis portalteamet senere overvejer en betalt notifikationsleverandør, skal en anden person måske godkende udgiften. Den oprindelige produktbeslutning udvides ikke stiltiende til at dække den nye myndighed.

Vælg ét uafklaret spørgsmål i dit nuværende Jira-arbejde. Giv det en tydelig grænse, aftal en tovholder og én godkender, og identificer det konkrete input, der kræves. Brug Power Pack til at holde rollerne synlige ved siden af sagen, og registrer og kommuniker beslutningen, når den er truffet.

Relaterede artikler

Kontakt Os

Har du spørgsmål til artiklen? Lad os tale om jeres tekniske mål.

Dine Oplysninger