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.
- 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.
- 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:
| Tarefa | Product owner | Líder de engenharia | Desenvolvedor | Líder de QA | Release manager |
|---|---|---|---|---|---|
| Definir o escopo da release | A/R | C | I | C | I |
| Escrever e revisar o código | I | A | R | C | I |
| Testar a candidata a release | I | A | C | R | I |
| Aprovar a qualidade | A | C | I | R | I |
| Implantar em produção | I | C | R | I | A |
| Anunciar a release | A/R | I | I | I | C |
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
- Stakeholder management and the RACI matrix, Project Management Institute
- DACI: a framework for group decisions, Atlassian Team Playbook
- Who Has the D? How Clear Decision Roles Enhance Organizational Performance, Harvard Business Review, Rogers e Blenko, 2006