DACI en Jira: asigna un responsable claro a cada decisión

Una incidencia de Jira puede acumular una conversación extensa sin acercarse a una decisión. Ingeniería recomienda una cosa, soporte otra, y la responsable de producto espera a que alguien reúna las opciones. Todos participan, pero nadie sabe quién debe decidir.

DACI da estructura a esa conversación. Identifica quién impulsa la decisión, quién decide, qué conocimientos importan y quién necesita conocer el resultado. En esta guía utilizaremos un equipo ficticio de un portal de clientes para resolver una decisión sobre entrega de notificaciones y registrar los roles en Power Pack para Jira.

Comprende los cuatro roles de DACI

DACI significa Driver, Approver, Contributors e Informed. La dinámica DACI de Atlassian describe al Driver como la persona que organiza el proceso de decisión y al Approver como la única persona que elige. Los Contributors aportan conocimientos; los participantes Informed reciben el resultado. La fuente está enlazada al final.

Distingue entre quien impulsa y quien aprueba durante la conversación. Coordinar el trabajo no concede automáticamente la decisión final. Del mismo modo, elegir el resultado no significa que quien aprueba deba reunir personalmente todas las pruebas.

Elige una pregunta que necesite una decisión

Nuestro portal ficticio permite a los clientes seguir las novedades de sus solicitudes de soporte. El equipo debe elegir cómo recibirán las notificaciones rutinarias de estado en la próxima versión. Consideran el correo inmediato, un resumen diario y una bandeja de entrada dentro del portal.

Maya, responsable de producto, quiere reducir los correos que distraen. Leo, ingeniero, teme añadir un segundo sistema de notificaciones. Sam, responsable de soporte, teme que los clientes no vean las novedades. Priya, responsable de pruebas, necesita un enfoque acordado antes de diseñar las comprobaciones de la versión.

Escribe la pregunta en la incidencia de Jira correspondiente: «¿Cómo debemos entregar las actualizaciones rutinarias de solicitudes de soporte en la primera versión del portal?». Esa formulación delimita la conversación. Abarca los cambios rutinarios de estado; no decide el comportamiento del restablecimiento de contraseñas, los avisos urgentes de seguridad ni todos los futuros canales de comunicación.

Añade una fecha objetivo para la decisión en la descripción de la incidencia mediante el proceso habitual del equipo. En este ejemplo, se necesita una respuesta antes de la siguiente sesión de planificación. Esa fecha es un acuerdo de coordinación, no una promesa de que la matriz enviará recordatorios o impondrá un plazo.

Asigna los roles en torno a la incertidumbre real

El equipo elige a Leo como impulsor porque puede reunir las opciones de implementación e identificar las pruebas técnicas que faltan. Maya aprueba porque la elección de esta versión entra en su autoridad de producto acordada. Sam aporta contexto de atención al cliente. Priya aporta perspectivas sobre verificabilidad y escenarios de fallo. Elena, que prepara las comunicaciones a clientes, necesita conocer el resultado final.

Antes de introducir estas asignaciones, pregunta si cada persona puede cumplir su rol. Leo necesita tiempo para comparar las opciones. Maya debe estar disponible antes de la planificación. Sam y Priya necesitan preguntas concretas, en lugar de una invitación abierta a comentar indefinidamente.

Si dos personas creen tener la autoridad final, aclara ese límite antes de declarar completa la matriz. Quizá la pregunta combine una elección de producto con una decisión presupuestaria distinta. Sepáralas cuando necesiten realmente aprobadores diferentes. Añadir otra A para evitar la conversación deja intacta la incertidumbre de fondo.

Plantea a los colaboradores preguntas que puedan responder

Leo pide a Sam tres ejemplos recientes en los que los clientes malinterpretaron una actualización de una solicitud de soporte. Pide a Priya que identifique qué puede salir mal cuando se producen varias actualizaciones seguidas. Prepara una breve comparación técnica basada en el sistema existente del equipo.

Son aportaciones ficticias para el ejemplo, no resultados medidos del producto. Su propósito es mostrar cómo es una colaboración útil. Cada aportación conecta los conocimientos de una persona con la decisión que se está tomando.

El equipo acuerda evaluar las opciones con tres preguntas: ¿pueden los clientes percibir avances útiles?, ¿puede el equipo sostener el enfoque con su capacidad actual?, ¿puede verificarse la versión de forma convincente? Escriben estas preguntas junto a las opciones en la incidencia de Jira para que todos evalúen el mismo problema.

Evita fingir que todas las consideraciones pueden reducirse a una puntuación precisa. Una tabla puede organizar la conversación sin producir una respuesta matemáticamente correcta. Si una estimación es incierta, señala la incertidumbre y decide si investigar más cambiaría la elección.

Compara las opciones antes de pedir una decisión

Esta es la comparación de trabajo del equipo. Estas observaciones pertenecen a nuestro portal ilustrativo, donde el envío de correo ya existe y una bandeja dentro del portal sería un desarrollo nuevo.

Los ejemplos de Sam indican que los clientes valoran recibir información rápida cuando una solicitud cambia de forma significativa. Priya señala que las ediciones repetidas podrían generar mensajes duplicados y confusos si no se define el comportamiento. Leo explica que un resumen requiere trabajo adicional de programación y agrupación en este sistema concreto.

Maya dispone ahora de una elección concreta que valorar. Elige el correo inmediato para cambios significativos de estado en la primera versión, con el tratamiento de duplicados especificado en los tickets de entrega. Las ediciones internas menores no generarán notificaciones al cliente. El equipo reconsiderará un resumen si los comentarios de clientes muestran que las novedades útiles siguen llegando con demasiada frecuencia.

Ese resultado es deliberadamente más preciso que «usar correo». Explica a implementación, pruebas y soporte qué significa la elección. También registra la circunstancia que podría hacer que el equipo la reconsiderara.

Crea la matriz DACI en Power Pack

Abre Power Pack en la incidencia de Jira y elige RACI / DACI Matrix. Configura el selector Model en DACI. La matriz utilizará D, A, C e I como roles disponibles.

Empieza por la lista de participantes y añade a las personas implicadas en la decisión. Power Pack permite buscar usuarios de Jira y añadir participantes externos. Una entrada externa puede representar a alguien en la matriz; no crea una cuenta ni le concede acceso a la incidencia de Jira.

En la vista de entregables, añade una fila para la pregunta de decisión. Aunque la interfaz utiliza entregables como estructura de filas, una decisión con un nombre claro funciona bien en este ejemplo de DACI. Deja fuera de esta primera fila las tareas de implementación no relacionadas para que la asignación siga siendo fácil de interpretar.

Pasa a la matriz y asigna D a Leo, A a Maya, C a Sam y Priya e I a Elena. Al pulsar una celda se recorren los roles disponibles. Las celdas con foco también admiten los atajos de letras de rol que muestra la interfaz.

Revisa los indicadores de la fila. Power Pack identifica la falta de aprobadores, la existencia de varios y las filas que necesitan un impulsor. Estas comprobaciones ayudan a detectar un patrón de roles incompleto. No pueden determinar si Maya tiene autoridad organizativa para decidir o si Leo ha reunido realmente pruebas suficientes.

Comprueba el indicador de guardado antes de salir de la incidencia. Si la herramienta informa de un estado local o sin conexión, no des por hecho que las últimas asignaciones ya están disponibles para tus compañeros. El acuerdo útil es la versión que las personas pueden encontrar y debatir juntas.

Cierra la conversación con un resultado utilizable

Una matriz de roles no contiene toda la decisión. Registra el enfoque elegido, el razonamiento y las consecuencias importantes en la descripción de la incidencia o en Decision Log de Power Pack. Incluye las opciones consideradas seriamente para que otro compañero pueda entender la elección más adelante.

Leo comparte después un resultado conciso con Elena mediante el proceso habitual de comunicación del equipo. La actualización indica qué se entregará, qué mensajes se incluyen, qué queda fuera del alcance y dónde encontrar el trabajo de implementación. Marcar a Elena con I en una matriz no envía ese mensaje.

Crea o actualiza los tickets de entrega de Jira necesarios mediante tu flujo de trabajo habitual. En este ejemplo, abarcan la detección de cambios significativos de estado, el tratamiento de duplicados y la verificación. Una asignación DACI registra un rol en la decisión; no cambia automáticamente la persona asignada en Jira ni el estado de una incidencia.

Mantén el marco proporcionado

Utiliza DACI cuando una decisión real esté bloqueada por dudas sobre la participación o la autoridad. Un detalle rutinario de implementación que un ingeniero ya puede decidir quizá solo necesite una nota breve. Añadir una matriz completa a cada elección pequeña puede hacer más difícil mantener el proceso.

Revisa las asignaciones cuando cambie la pregunta. Si más adelante el equipo del portal considera un proveedor de notificaciones de pago, quizá deba aprobar el gasto otra persona. La decisión de producto original no se amplía silenciosamente para abarcar esa nueva autoridad.

Elige una pregunta pendiente en tu trabajo actual de Jira. Delimítala con claridad, acuerda un impulsor y un único aprobador, e identifica las aportaciones concretas necesarias. Utiliza Power Pack para mantener esos roles visibles junto a la incidencia y registra y comunica la decisión cuando se tome.

• Atlassian Team Playbook: marco de toma de decisiones DACI