DACI a Jira: doneu a cada decisió un responsable clar

Un tiquet de Jira pot recollir una llarga discussió sense apropar-se a una decisió. L'enginyeria té una recomanació, l'assistència en té una altra i el responsable del producte està esperant que algú ajunti les opcions. Tothom hi participa, però ningú sap qui ha de prendre la decisió.

DACI dóna una estructura a aquesta conversa. Identifica qui fa avançar la decisió, qui decideix, l'experiència de qui és important i qui necessita el resultat. En aquesta guia, utilitzarem un equip de portal de clients fictici per treballar amb una decisió de lliurament de notificacions i registrar les funcions a Power Pack per a Jira.

Entendre els quatre rols DACI

DACI significa Driver, Approver, Contributors and Informed. L'obra DACI de Atlassian descriu el conductor com la persona que organitza el procés de decisió i l'aprovador com la persona única que fa l'elecció. Els col·laboradors proporcionen experiència; els participants informats reben el resultat. La font està enllaçada a continuació.

Mantingueu el conductor i l'aprovador diferents en la vostra conversa. La coordinació del treball no dóna automàticament a algú la decisió final. De la mateixa manera, triar el resultat no vol dir que l'aprovador hagi de reunir personalment totes les proves.

Trieu una pregunta que necessiti una decisió

El nostre portal de ficció permet als clients seguir les actualitzacions de les seves sol·licituds d'assistència. L'equip ha de triar com les notificacions d'estat rutinàries arriben als clients en la propera versió. Estan considerant un correu electrònic immediat, un resum diari i una bústia d'entrada dins del portal.

Maya, la responsablea del producte, vol menys correus electrònics que distreuen. En Leo, l'enginyer, li preocupa afegir un segon sistema de notificació. Sam, el responsable de l'assistència, li preocupa que els clients es perdin actualitzacions de progrés. Priya, el provador, necessita un enfocament clar abans de dissenyar les comprovacions de llançament.

Escriviu la pregunta sobre el tiquet rellevant de Jira: "Com hem d'oferir actualitzacions rutinàries de sol·licitud de suport a la primera versió del portal?" Aquesta redacció dóna un límit a la discussió. Cobreix els canvis d'estat rutinaris; no decideix el comportament de restabliment de contrasenyes, avisos de seguretat urgents o qualsevol canal de comunicació futur.

Afegiu una data de decisió objectiu a la descripció del tiquet mitjançant el procés normal de l'equip. En aquest exemple, la resposta és necessària abans de la següent sessió de planificació. Aquesta data és un acord de coordinació, no una promesa que la matriu enviarà recordatoris o farà complir un termini.

Assigna rols al voltant de la incertesa real

L'equip tria Leo com a impulsor perquè pot reunir les opcions d'implementació i identificar proves tècniques que falten. Maya és l'aprovadora perquè la compensació del llançament es troba dins de la seva autoritat de producte acordada. Sam contribueix al context d'atenció al client. Priya aporta escenaris de provabilitat i fracàs. Elena, que prepara les comunicacions amb els clients, necessita el resultat final.

Abans d'introduir aquestes tasques, pregunteu si cada persona pot complir la funció. Leo necessita temps per comparar les opcions. Maya ha d'estar disponible abans de planificar. Sam i Priya necessiten preguntes específiques, en lloc d'una invitació oberta per comentar indefinidament.

Si dues persones creuen que tenen l'autoritat final, establiu aquest límit abans de declarar la matriu completa. Potser la pregunta combina una elecció de producte amb una decisió pressupostària independent. Dividiu aquestes decisions quan realment requereixin aprovadors diferents. Afegir una altra A per evitar la conversa deixa intacta la incertesa subjacent.

Feu preguntes als col·laboradors que puguin respondre

Leo demana a Sam que porti tres exemples recents en què els clients van malinterpretar una actualització de sol·licitud d'assistència. Li demana a la Priya que identifiqui què pot sortir malament quan es produeixen diverses actualitzacions juntes. Prepara una breu comparació tècnica basada en el sistema existent de l'equip.

Aquestes són entrades de ficció per a l'exemple, no resultats de productes mesurats. El seu propòsit és mostrar quina és la contribució útil. Cada entrada connecta l'experiència d'una persona amb la decisió que es pren.

L'equip accepta avaluar les opcions en funció de tres preguntes: poden els clients notar un progrés útil, l'equip pot donar suport a l'enfocament amb la seva capacitat actual i es pot provar el llançament de manera convincent? Escriuen aquestes preguntes juntament amb les opcions del tiquet de Jira perquè tothom avaluï el mateix problema.

Eviteu fingir que totes les consideracions es poden reduir a una puntuació precisa. Una taula pot organitzar la conversa sense produir una resposta matemàticament correcta. Si una estimació és incerta, poseu un nom a la incertesa i decidiu si una investigació addicional canviaria l'elecció.

Compareu les opcions abans de demanar una opció

Aquí teniu la comparació de treball de l'equip. Aquestes observacions pertanyen al nostre portal il·lustratiu, on el lliurament de correu electrònic ja existeix i una bústia d'entrada al portal seria un treball nou.

Els exemples de Sam suggereixen que els clients valoren una actualització ràpida quan una sol·licitud canvia de manera significativa. Priya assenyala que les edicions repetides podrien generar missatges duplicats confusos tret que es defineixi el comportament. Leo explica que un resum requereix un treball addicional de programació i agrupació en aquest sistema en particular.

Maya ara té un compromís concret per jutjar. Ella tria el correu electrònic immediat per a canvis d'estat significatius a la primera versió, amb la gestió de duplicats especificada als tiquets d'entrega. Les modificacions internes menors no generaran notificacions als clients. L'equip revisarà un resum si els comentaris dels clients mostren que les actualitzacions útils encara arriben amb massa freqüència.

Aquest resultat és deliberadament més precís que "utilitzar el correu electrònic". Explica la implementació, les proves i el suport del que significa l'elecció. També registra la circumstància que podria fer que l'equip es reconsideri.

Creeu la matriu DACI a Power Pack

Obriu Power Pack al tiquet de Jira i trieu l'eina RACI / DACI Matrix. Estableix el selector de model a DACI. Aleshores, la matriu utilitza D, A, C i I per als seus rols disponibles.

Comenceu amb la llista i afegiu les persones implicades en la decisió. Power Pack admet la cerca d'usuaris Jira i les entrades de participants externs. Una entrada externa pot representar una persona a la matriu; no crea un compte ni dóna accés a aquesta persona al tiquet de Jira.

A la vista de lliuraments, afegiu una fila per a la pregunta de decisió. Tot i que la interfície utilitza els lliurables com a estructura de fila, una decisió clarament anomenada funciona bé per a aquest exemple de DACI. Manteniu les tasques d'implementació no relacionades fora d'aquesta primera fila perquè l'assignació sigui fàcil d'interpretar.

Passeu a la matriu i assigneu a Leo D, Maya A, Sam i Priya C i Elena I. Si feu clic a una cel·la, passeu per les funcions disponibles. Les cel·les enfocades també admeten les dreceres de lletres de rol que es mostren a la interfície.

Reviseu els indicadors de fila. Power Pack identifica els aprovadors que falten, diversos aprovadors i les files que necessiten un impulsor. Aquestes comprovacions us ajuden a detectar un patró de rol incomplet. No poden dir si Maya té l'autoritat organitzativa per decidir o si en Leo ha reunit prou proves.

Comproveu l’indicador de desament abans de sortir del tiquet. Si l'eina informa d'un estat local o fora de línia, no assumeixis que les últimes tasques ja estan disponibles per als companys d'equip. L'acord útil és la versió que la gent pot trobar i discutir junts.

Tanqueu la discussió amb un resultat útil

Una matriu de rols no conté tota la decisió. Anoteu l'enfocament seleccionat, el raonament i les conseqüències importants a la descripció del tiquet o al registre de decisions de Power Pack. Incloeu les opcions que s'han considerat seriosament perquè un altre company pugui entendre l'elecció més endavant.

Aleshores, en Leo comparteix un resultat concís amb l'Elena a través del procés de comunicació normal de l'equip. L'actualització diu què s'enviarà, quins missatges s'inclouen, què queda fora de l'abast i on trobar el treball d'implementació. Marcar Elena I en una matriu no envia aquest missatge.

Creeu o actualitzeu els tiquets de lliurament Jira necessaris mitjançant el vostre flux de treball normal. Per a aquest exemple, aquestes entrades cobreixen la detecció significativa de canvis d'estat, la gestió i la verificació de duplicats. Una tasca DACI registra un paper en la decisió; no canvia automàticament un assignat de Jira ni fa la transició d'un tiquet.

Mantenir el marc proporcionat

Utilitzeu DACI quan una opció real s'atura per una participació o autoritat poc clares. Un detall d'implementació rutinària que un enginyer ja pot decidir pot necessitar només una nota breu. Afegir una matriu completa a cada petita elecció pot fer que el procés sigui més difícil de mantenir.

Reviseu les tasques quan canviï la pregunta. Si més tard l'equip del portal considera un proveïdor de notificacions de pagament, és possible que una altra persona hagi d'aprovar la despesa. La decisió del producte original no s'amplia en silenci per cobrir aquesta nova autoritat.

Trieu una pregunta no resolta al vostre treball actual de Jira. Doneu-li un límit clar, acordeu un impulsor i un aprovador i identifiqueu l'entrada específica necessària. Utilitzeu Power Pack per mantenir aquests rols visibles al costat del tiquet i, a continuació, enregistreu i comuniqueu la decisió quan es prengui.

• Guia d’equips d’Atlassian: marc DACI per prendre decisions