Ir para o conteúdo
gorkha.io

Como construir uma matriz RACI

Um método que funciona para construir uma matriz de atribuição de responsabilidades: o que cada letra significa de fato, como dimensionar as linhas, as duas regras que a tornam útil e as quatro formas pelas quais ela costuma falhar.

A equipe Gorkha9 min de leitura

Matriz RACI → Defina quem é Responsável, Aprovador, Consultado e Informado em cada tarefa, e encontre as lacunas.

Uma matriz RACI responde a uma única pergunta para cada pedaço de trabalho: quem está fazendo isso e quem responde por isso quando dá errado. É uma grade. Cada coluna é uma pessoa ou um papel, cada linha é uma tarefa ou uma entrega, e cada célula contém uma letra.

O formato é antigo e muito rodado: o Project Management Institute descreve o diagrama RACI como um exemplo de matriz de atribuição de responsabilidades, a categoria geral de grade que mapeia pessoas sobre o trabalho. A maioria dos times conhece essa ideia como uma planilha que alguém fez uma vez e ninguém abriu de novo. Essa versão é inútil. Este guia é sobre a versão que não é.

O que significam as quatro letras

As letras são fáceis de recitar e fáceis de errar, porque duas delas soam como a mesma coisa.

  • R: Responsible (responsável pela execução). As pessoas que fazem o trabalho. Podem ser várias.
  • A: Accountable (responsável final). A única pessoa que responde pelo resultado e tem autoridade para aprová-lo. É exatamente uma.
  • C: Consulted (consultado). Pessoas cuja opinião é buscada antes de o trabalho terminar. Via de mão dupla: são perguntadas e respondem.
  • I: Informed (informado). Pessoas a quem se conta depois. Mão única.

A distinção que sustenta todo o método é entre R e A. Responsible é esforço. Accountable é autoridade. Se a pessoa que você marcou como A não pode de fato rejeitar o trabalho, você marcou a pessoa errada, e a matriz está descrevendo a hierarquia que você gostaria de ter em vez da que você tem.

Uma mesma pessoa pode ser as duas coisas. Uma célula marcada A/R é normal e comum em times pequenos: a mesma pessoa é dona do resultado e faz o trabalho. O que nunca é aceitável são duas pessoas diferentes marcadas A na mesma linha.

As duas regras

Todo o resto neste guia é conselho. Estas duas são regras, e uma matriz que quebra qualquer uma delas não merece ser distribuída.

  1. Exatamente um A por linha. Accountable significa um único ponto de decisão. Duas pessoas accountable significam que, quando discordarem, nada poderá ser resolvido sem escalar, que é precisamente a falha que uma RACI existe para evitar. Zero pessoas accountable significa que a tarefa não tem dono, e ela será descoberta tarde por quem tiver azar.
  2. Pelo menos um R por linha. Se ninguém é responsável, ninguém está fazendo o trabalho. Linhas assim normalmente são desejos que acabaram digitados num plano.

O construtor de matriz RACI verifica as duas enquanto você digita e marca as linhas que as quebram, porque são exatamente os erros invisíveis quando você lê a sua própria grade.

Construindo uma, na ordem

A ordem importa. Quase toda matriz ruim é ruim porque foi preenchida da esquerda para a direita, uma linha por vez, o que silenciosamente se transforma em atribuir trabalho a quem está mais perto.

1. Liste as linhas antes das pessoas

Escreva primeiro as entregas e as decisões, sem o nome de ninguém em lugar algum. Você está descrevendo o trabalho, não o time. Se começar pelo time, vai produzir uma matriz que justifica a distribuição atual em vez de examiná-la.

Mire no nível de entregas e decisões, não de atividades. "Escrever e revisar o código" é uma linha. "Abrir um pull request" não é. Um teste útil: se uma linha teria exatamente as mesmas letras da linha acima, as duas linhas são uma só.

Matrizes reais quase sempre ficam entre seis e vinte linhas. Passando de trinta, ninguém lê, e é melhor dividir por fase.

2. Adicione as colunas como papéis, não como nomes

Use Líder de engenharia, não Priya. Papéis sobrevivem à saída de pessoas; nomes não. Onde um papel é ocupado por uma pessoa e todos sabem disso, acrescente o nome entre parênteses.

3. Atribua o A primeiro, em todas as linhas

Percorra a coluna A de cima a baixo antes de tocar em qualquer outra coisa. Esta é a passada que traz as discussões reais à superfície: as linhas em que duas pessoas presumem que decidem, e as linhas em que todos olham para todos. Resolva isso agora. É o motivo pelo qual você está fazendo a matriz.

4. Depois o R, e então C e I

Responsible vem em seguida, porque normalmente fica óbvio depois que a responsabilidade final está resolvida. Depois consultados e informados, e seja econômico aqui. Cada C é uma pessoa que pode travar o trabalho. Uma linha com cinco C não é criteriosa; é uma linha que vai levar três semanas.

5. Leia por coluna, não por linha

Agora gire a grade noventa graus. Uma coluna com A em quase todas as linhas é um gargalo, e essa pessoa é a razão pela qual seu projeto está lento. Uma coluna só com I é alguém que não precisa estar nesta matriz. Uma coluna sem letra alguma é uma pergunta que vale fazer em voz alta.

Um exemplo trabalhado

Seis linhas de uma release de software, com cinco papéis:

TarefaProduct ownerLíder de engenhariaDesenvolvedorLíder de QARelease manager
Definir o escopo da releaseA/RCICI
Escrever e revisar o códigoIARCI
Testar a candidata a releaseIACRI
Aprovar a qualidadeACIRI
Implantar em produçãoICRIA
Anunciar a releaseA/RIIIC

Leia a coluna A de cima a baixo e a estrutura do time fica visível em cerca de quatro segundos: o product owner é dono do escopo e da comunicação, o líder de engenharia é dono de como aquilo é construído, o release manager é dono do ato de publicar. Ninguém é dono de tudo. É assim que se parece uma matriz que funciona.

Essa mesma grade é o modelo Release de software do construtor, nos sete idiomas.

As quatro formas de dar errado

Todo mundo é consultado. A falha mais comum e a mais cara. C é um compromisso de esperar por alguém. Se você não consegue dizer o que faria de diferente com base na resposta dessa pessoa, ela é I.

A pessoa accountable não tem autoridade. Marcar um gerente de projeto como A de uma decisão que na prática só uma diretoria pode tomar não transfere a autoridade; só torna a linha uma ficção. Marque quem pode dizer não.

É granular demais. Uma matriz de quarenta linhas cobrindo atividades individuais é um documento que ninguém vai manter atualizado, o que significa que estará errado em um mês e enganoso em dois.

É escrita uma única vez. Uma matriz feita no kickoff e nunca revisada fica errada em silêncio: as pessoas mudam de papel e a grade não. Anexe-a ao documento que ela descreve e revise quando revisar esse documento. Se nada dispara uma revisão, nada vai disparar uma revisão.

Quando usar outra coisa

Uma RACI descreve trabalho continuado: quem faz o quê, em muitas tarefas, ao longo do tempo. Ela encaixa mal numa decisão única tomada uma vez. Para isso existem alternativas feitas de propósito: DACI (Driver, Approver, Contributor, Informed), que a Atlassian publica como uma play do seu Team Playbook, e RAPID®, desenvolvida pela Bain and Company e exposta no artigo de 2006 da Harvard Business Review "Who Has the D?", de Paul Rogers e Marcia Blenko, que separa quem decide de quem executa e torna o direito de veto explícito.

As duas estão disponíveis como modos do construtor, e vale entender as diferenças antes de escolher: RACI, DACI ou RAPID: qual o seu time realmente precisa.

Exportar para onde as pessoas vão ler

Uma matriz só funciona se morar onde o trabalho mora. O construtor exporta para Excel e Google Sheets, Word, PowerPoint como tabela editável em vez de imagem, PDF, CSV, Markdown para Notion e HTML na área de transferência, que cola no OneNote ou no Google Docs com a tabela intacta.

O conselho prático: coloque-a no documento que ela governa (o plano de projeto, o runbook, o termo de abertura) e não num arquivo separado. Uma matriz em arquivo próprio é uma matriz que ninguém abre.

Fontes

  1. Stakeholder management and the RACI matrix, Project Management Institute
  2. DACI: a framework for group decisions, Atlassian Team Playbook
  3. Who Has the D? How Clear Decision Roles Enhance Organizational Performance, Harvard Business Review, Rogers e Blenko, 2006