DACI no Jira: dê a cada decisão uma pessoa claramente responsável

Um item do Jira pode acumular uma longa discussão sem se aproximar de uma decisão. Engenharia tem uma recomendação, suporte tem outra, e a pessoa responsável pelo produto espera que alguém reúna as opções. Todos participam, mas ninguém sabe quem deve decidir.

DACI dá estrutura a essa conversa. Ele identifica quem faz a decisão avançar, quem decide, quais conhecimentos importam e quem precisa receber o resultado. Neste guia, usaremos uma equipe fictícia de portal do cliente para analisar uma decisão sobre o envio de notificações e registrar os papéis no Power Pack para Jira.

Entenda os quatro papéis de DACI

DACI significa Driver, Approver, Contributors e Informed. A prática DACI da Atlassian descreve Driver como a pessoa que organiza o processo decisório e Approver como a única pessoa que faz a escolha. Contributors fornecem conhecimento especializado; participantes Informed recebem o resultado. A fonte está indicada abaixo.

Mantenha a distinção entre quem conduz e quem aprova na conversa. Coordenar o trabalho não dá automaticamente a alguém a decisão final. Da mesma forma, escolher o resultado não significa que a pessoa que aprova precise reunir pessoalmente todas as evidências.

Escolha uma pergunta que exija uma decisão

Nosso portal fictício permite que clientes acompanhem atualizações de suas solicitações de suporte. A equipe precisa escolher como as notificações rotineiras de status chegarão aos clientes na próxima versão. As opções consideradas são e-mail imediato, resumo diário e uma caixa de entrada no portal.

Maya, responsável pelo produto, quer reduzir e-mails que distraem. Leo, engenheiro, se preocupa com a inclusão de um segundo sistema de notificações. Sam, líder de suporte, teme que os clientes percam atualizações de andamento. Priya, responsável pelos testes, precisa de uma abordagem definida antes de planejar as verificações da versão.

Escreva a pergunta no item relevante do Jira: “Como devemos enviar atualizações rotineiras das solicitações de suporte na primeira versão do portal?” Essa formulação delimita a discussão. Ela abrange mudanças rotineiras de status; não define o comportamento de redefinições de senha, avisos urgentes de segurança nem de todos os canais futuros de comunicação.

Adicione uma data prevista para a decisão na descrição do item usando o processo normal da equipe. Neste exemplo, a resposta é necessária antes da próxima sessão de planejamento. Essa data é um acordo de coordenação, não uma promessa de que a matriz enviará lembretes ou imporá um prazo.

Atribua os papéis em torno da dúvida real

A equipe escolhe Leo como condutor porque ele consegue reunir as opções de implementação e identificar evidências técnicas que faltam. Maya aprova porque a escolha entre as alternativas da versão está dentro de sua autoridade de produto acordada. Sam contribui com o contexto de suporte ao cliente. Priya contribui com a possibilidade de testar e com cenários de falha. Elena, que prepara as comunicações aos clientes, precisa receber o resultado final.

Antes de registrar essas atribuições, pergunte se cada pessoa consegue cumprir o papel. Leo precisa de tempo para comparar as opções. Maya precisa estar disponível antes do planejamento. Sam e Priya precisam de perguntas específicas, não de um convite aberto para comentar indefinidamente.

Se duas pessoas acreditam ter a autoridade final, resolva esse limite antes de declarar a matriz completa. Talvez a pergunta combine uma escolha de produto com uma decisão separada de orçamento. Separe essas decisões quando elas realmente exigirem aprovadores diferentes. Adicionar outro A para evitar a conversa mantém a dúvida original.

Dê aos colaboradores perguntas que possam responder

Leo pede que Sam traga três exemplos recentes em que clientes entenderam mal uma atualização de solicitação de suporte. Ele pede a Priya que identifique o que pode dar errado quando várias atualizações acontecem em sequência. Ele prepara uma breve comparação técnica baseada no sistema existente da equipe.

Essas são contribuições fictícias para o exemplo, não resultados medidos do produto. Seu objetivo é mostrar como uma contribuição útil pode ser. Cada contribuição conecta o conhecimento de uma pessoa à decisão em andamento.

A equipe combina avaliar as opções com base em três perguntas: os clientes conseguem perceber avanços úteis, a equipe consegue sustentar a abordagem com sua capacidade atual e a versão pode ser testada de forma convincente? Eles registram essas perguntas junto às opções no item do Jira para que todos avaliem o mesmo problema.

Evite fingir que toda consideração pode ser reduzida a uma pontuação precisa. Uma tabela pode organizar a conversa sem produzir uma resposta matematicamente correta. Se uma estimativa for incerta, explicite a incerteza e decida se uma investigação adicional mudaria a escolha.

Compare as opções antes de pedir uma escolha

Esta é a comparação de trabalho da equipe. Essas observações pertencem ao nosso portal ilustrativo, no qual o envio de e-mails já existe e uma caixa de entrada no portal exigiria trabalho novo.

Os exemplos de Sam indicam que os clientes valorizam uma atualização rápida quando uma solicitação muda de forma significativa. Priya observa que edições repetidas podem gerar mensagens duplicadas e confusas se o comportamento não for definido. Leo explica que um resumo exige trabalho adicional de agendamento e agrupamento nesse sistema específico.

Maya agora tem uma escolha concreta a avaliar. Ela escolhe e-mail imediato para mudanças significativas de status na primeira versão, com o tratamento de duplicatas especificado nos tickets de entrega. Pequenas edições internas não gerarão notificações aos clientes. A equipe reconsiderará um resumo se o retorno dos clientes mostrar que as atualizações úteis ainda chegam com frequência excessiva.

Esse resultado é intencionalmente mais preciso do que “usar e-mail”. Ele informa a implementação, os testes e o suporte sobre o significado da escolha. Também registra a circunstância que pode levar a equipe a reconsiderar.

Crie a matriz DACI no Power Pack

Abra o Power Pack no item do Jira e escolha a ferramenta RACI / DACI Matrix. Defina o seletor Model como DACI. A matriz passa a usar D, A, C e I como papéis disponíveis.

Comece pela lista de participantes e adicione as pessoas envolvidas na decisão. O Power Pack permite pesquisar usuários do Jira e incluir participantes externos. Uma entrada externa pode representar uma pessoa na matriz; ela não cria uma conta nem concede acesso ao item do Jira.

Na visualização de entregas, adicione uma linha para a pergunta da decisão. Embora a interface use entregas como estrutura das linhas, uma decisão com nome claro funciona bem neste exemplo DACI. Mantenha tarefas de implementação sem relação fora dessa primeira linha para que a atribuição continue fácil de interpretar.

Vá para a matriz e atribua D a Leo, A a Maya, C a Sam e Priya e I a Elena. Clicar em uma célula alterna entre os papéis disponíveis. Células em foco também aceitam os atalhos com letras de papéis exibidos na interface.

Revise os indicadores da linha. O Power Pack identifica a ausência de aprovadores, a existência de vários aprovadores e linhas que precisam de um condutor. Essas verificações ajudam a perceber um padrão incompleto de papéis. Elas não determinam se Maya tem autoridade organizacional para decidir nem se Leo realmente reuniu evidências suficientes.

Confira o indicador de salvamento antes de sair do item. Se a ferramenta indicar um estado local ou offline, não suponha que as atribuições mais recentes já estejam disponíveis aos colegas. O acordo útil é a versão que as pessoas conseguem encontrar e discutir juntas.

Encerre a discussão com um resultado utilizável

Uma matriz de papéis não contém toda a decisão. Registre a abordagem escolhida, o raciocínio e as consequências importantes na descrição do item ou no Decision Log do Power Pack. Inclua as opções seriamente consideradas para que outro colega consiga entender a escolha depois.

Leo então compartilha um resultado conciso com Elena pelo processo normal de comunicação da equipe. A atualização diz o que será lançado, quais mensagens estão incluídas, o que continua fora do escopo e onde encontrar o trabalho de implementação. Marcar Elena com I em uma matriz não envia essa mensagem.

Crie ou atualize os tickets de entrega necessários no Jira pelo fluxo de trabalho normal. Neste exemplo, eles abrangem a detecção de mudanças significativas de status, o tratamento de duplicatas e a verificação. Uma atribuição DACI registra um papel na decisão; ela não muda automaticamente a pessoa atribuída no Jira nem o status de um item.

Mantenha o modelo proporcional à necessidade

Use DACI quando uma escolha real estiver travada por falta de clareza sobre participação ou autoridade. Um detalhe rotineiro de implementação que um engenheiro já pode decidir talvez precise apenas de uma nota breve. Adicionar uma matriz completa a cada pequena escolha pode dificultar a manutenção do processo.

Revisite as atribuições quando a pergunta mudar. Se a equipe do portal considerar depois um fornecedor pago de notificações, outra pessoa talvez precise aprovar o gasto. A decisão original de produto não se amplia silenciosamente para incluir essa nova autoridade.

Escolha uma pergunta não resolvida no seu trabalho atual no Jira. Defina seus limites, combine quem conduz e uma pessoa que aprova e identifique as contribuições específicas necessárias. Use o Power Pack para manter esses papéis visíveis junto ao item; depois, registre e comunique a decisão quando ela for tomada.

• Atlassian Team Playbook: modelo de tomada de decisão DACI