DACI i Jira: gi hver beslutning en tydelig ansvarlig

En Jira-sak kan samle en lang diskusjon uten å komme nærmere en beslutning. Utvikling har én anbefaling, kundestøtte en annen, og produkteieren venter på at noen skal samle alternativene. Alle deltar, men ingen vet hvem som skal avgjøre saken.

DACI gir samtalen struktur. Den identifiserer hvem som driver beslutningen fremover, hvem som bestemmer, hvem sin kompetanse som trengs, og hvem som trenger resultatet. I denne veiledningen bruker vi et fiktivt kundeportalteam til å gå gjennom en beslutning om varslingslevering og registrere rollene i Power Pack for Jira.

Forstå de fire DACI-rollene

DACI står for Driver, Approver, Contributors og Informed. Atlassians DACI-øvelse beskriver Driver som personen som organiserer beslutningsprosessen, og Approver som den ene personen som tar valget. Contributors gir kompetanse; informerte deltakere mottar resultatet. Kilden er lenket nedenfor.

Skill mellom pådriver og godkjenner i samtalen. Å koordinere arbeidet gir ikke automatisk noen den endelige beslutningen. Å velge resultatet betyr heller ikke at godkjenneren personlig må samle hvert bevis.

Velg et spørsmål som trenger en beslutning

Den fiktive portalen lar kunder følge oppdateringer på støttehenvendelsene sine. Teamet må velge hvordan vanlige statusvarsler skal nå kundene i neste utgivelse. De vurderer umiddelbar e-post, et daglig sammendrag og en innboks i portalen.

Maya, produkteieren, ønsker færre forstyrrende e-poster. Leo, utvikleren, er bekymret for å legge til et andre varslingssystem. Sam, lederen for kundestøtte, frykter at kunder overser fremdriftsoppdateringer. Priya, testeren, trenger en avklart tilnærming før hun planlegger utgivelseskontrollene.

Skriv spørsmålet på den relevante Jira-saken: «Hvordan skal vi levere vanlige oppdateringer om støttehenvendelser i den første portalutgivelsen?» Formuleringen avgrenser diskusjonen. Den dekker vanlige statusendringer, ikke atferden for tilbakestilling av passord, viktige sikkerhetsvarsler eller alle fremtidige kommunikasjonskanaler.

Legg til en måldato for beslutningen i saksbeskrivelsen gjennom teamets vanlige prosess. I eksemplet trengs svaret før neste planleggingsmøte. Datoen er en samordningsavtale, ikke et løfte om at matrisen sender påminnelser eller håndhever en frist.

Tilordne roller rundt den faktiske usikkerheten

Teamet velger Leo som pådriver fordi han kan samle implementeringsalternativer og identifisere manglende teknisk underlag. Maya er godkjenner fordi avveiningen for utgivelsen ligger innenfor hennes avtalte produktmyndighet. Sam bidrar med kontekst fra kundestøtte. Priya bidrar med testbarhet og feilscenarioer. Elena, som forbereder kundekommunikasjonen, trenger sluttresultatet.

Spør om hver person kan fylle rollen før tilordningene registreres. Leo trenger tid til å sammenligne alternativene. Maya må være tilgjengelig før planleggingen. Sam og Priya trenger konkrete spørsmål, ikke en åpen invitasjon til å kommentere uten ende.

Hvis to personer begge mener at de har endelig myndighet, avklar grensen før matrisen erklæres komplett. Kanskje spørsmålet kombinerer et produktvalg med en separat budsjettbeslutning. Del beslutningene når de faktisk trenger ulike godkjennere. Å legge til enda en A for å unngå samtalen lar den underliggende usikkerheten bestå.

Gi bidragsyterne spørsmål de kan svare på

Leo ber Sam ta med tre ferske eksempler der kunder misforsto en oppdatering av en støttehenvendelse. Han ber Priya identifisere hva som kan gå galt når flere oppdateringer skjer tett. Han lager en kort teknisk sammenligning basert på teamets eksisterende system.

Dette er fiktive innspill til eksemplet, ikke målte produktresultater. Formålet er å vise hvordan nyttige bidrag ser ut. Hvert innspill kobler en persons kompetanse til beslutningen som skal tas.

Teamet avtaler å vurdere alternativene mot tre spørsmål: kan kundene merke nyttig fremdrift, kan teamet støtte løsningen med dagens kapasitet, og kan utgivelsen testes overbevisende? De skriver spørsmålene ved siden av alternativene i Jira-saken, slik at alle vurderer samme problem.

Ikke lat som alle hensyn kan reduseres til en presis poengsum. En tabell kan organisere samtalen uten å gi et matematisk riktig svar. Hvis et anslag er usikkert, angi usikkerheten og avgjør om mer undersøkelse ville endret valget.

Sammenlign alternativene før du ber om et valg

Her er teamets arbeidssammenligning. Observasjonene gjelder eksempelportalen, der e-postlevering allerede finnes, mens en portalinnboks ville vært nytt arbeid.

Sams eksempler tyder på at kundene verdsetter en rask oppdatering når en henvendelse endres vesentlig. Priya påpeker at gjentatte redigeringer kan skape forvirrende duplikater hvis atferden ikke defineres. Leo forklarer at et sammendrag krever mer arbeid med planlegging og gruppering i akkurat dette systemet.

Maya har nå en konkret avveining å vurdere. Hun velger umiddelbar e-post for vesentlige statusendringer i første utgivelse, med duplikathåndtering beskrevet i leveranseoppgavene. Små interne redigeringer skal ikke utløse kundevarsler. Teamet vil vurdere et sammendrag igjen hvis tilbakemeldinger viser at nyttige oppdateringer fortsatt kommer for ofte.

Resultatet er bevisst mer presist enn «bruk e-post». Det forteller implementering, testing og kundestøtte hva valget betyr. Det registrerer også omstendigheten som kan få teamet til å revurdere.

Lag DACI-matrisen i Power Pack

Åpne Power Pack på Jira-saken, og velg RACI / DACI Matrix. Sett Model til DACI. Matrisen bruker da D, A, C og I som tilgjengelige roller.

Start med deltakerlisten og legg til personene som deltar i beslutningen. Power Pack støtter søk etter Jira-brukere og eksterne deltakeroppføringer. En ekstern oppføring kan representere en person i matrisen; den oppretter ingen konto og gir ikke tilgang til Jira-saken.

Legg til en rad for beslutningsspørsmålet i leveransevisningen. Selv om grensesnittet bruker leveranser som radstruktur, fungerer en tydelig navngitt beslutning godt i dette DACI-eksemplet. Hold uvedkommende implementeringsoppgaver utenfor den første raden, slik at tilordningen er lett å forstå.

Gå til matrisen og tilordne Leo D, Maya A, Sam og Priya C og Elena I. Et klikk i en celle veksler mellom tilgjengelige roller. Celler med fokus støtter også hurtigtastene med rollebokstaver som vises i grensesnittet.

Gå gjennom radindikatorene. Power Pack identifiserer manglende godkjennere, flere godkjennere og rader som trenger en pådriver. Kontrollene hjelper med å oppdage et ufullstendig rollemønster. De kan ikke avgjøre om Maya har organisatorisk myndighet, eller om Leo faktisk har samlet nok underlag.

Kontroller lagringsindikatoren før du forlater saken. Hvis verktøyet viser en lokal eller frakoblet tilstand, må du ikke anta at kollegene allerede har de nyeste tilordningene. Den nyttige avtalen er versjonen folk kan finne og diskutere sammen.

Avslutt diskusjonen med et brukbart resultat

En rollematrise inneholder ikke hele beslutningen. Registrer valgt tilnærming, begrunnelse og viktige konsekvenser i saksbeskrivelsen eller Power Packs Decision Log. Ta med alternativene som ble seriøst vurdert, slik at en kollega kan forstå valget senere.

Leo deler så et kort resultat med Elena gjennom teamets vanlige kommunikasjonsprosess. Oppdateringen sier hva som skal leveres, hvilke meldinger som inngår, hva som ligger utenfor omfanget, og hvor implementeringsarbeidet finnes. Å markere Elena med I i en matrise sender ikke meldingen.

Opprett eller oppdater nødvendige leveranseoppgaver i Jira gjennom vanlig arbeidsflyt. I eksemplet dekker de oppdagelse av vesentlige statusendringer, duplikathåndtering og kontroll. En DACI-tilordning registrerer en rolle i beslutningen; den endrer ikke automatisk tilordnet person i Jira eller sakens status.

Hold modellen forholdsmessig

Bruk DACI når et reelt valg har stoppet opp på grunn av uklar deltakelse eller myndighet. En vanlig implementeringsdetalj som en utvikler allerede kan avgjøre, trenger kanskje bare en kort merknad. En full matrise for hvert lite valg kan gjøre prosessen vanskeligere å vedlikeholde.

Gå gjennom tilordningene igjen når spørsmålet endres. Hvis portalteamet senere vurderer en betalt varslingsleverandør, må kanskje en annen person godkjenne utgiften. Den opprinnelige produktbeslutningen utvides ikke stilltiende til å omfatte den nye myndigheten.

Velg ett uavklart spørsmål i det nåværende Jira-arbeidet. Gi det en tydelig grense, avtal en pådriver og én godkjenner, og identifiser de konkrete innspillene som trengs. Bruk Power Pack til å holde rollene synlige ved siden av saken, og registrer og kommuniser beslutningen når den er tatt.

• Atlassian Team Playbook: DACI-modellen for beslutningstaking