Stakeholders, Comunicação e Liderança
Matriz RACI em projetos ágeis: como adaptar aos papéis
A matriz RACI em projetos ágeis costuma gerar um de dois desconfortos. Ou o time recebe uma planilha que distribui tarefas por pessoa, o que contradiz a ideia de um time autogerenciável, ou a organização abandona qualquer definição de papéis e descobre, na hora de colocar algo em produção, que ninguém sabe quem aprova. As duas saídas são ruins, e há um caminho no meio.
A ideia central: dentro do time ágil, os papéis já estão definidos pelo framework e o trabalho se organiza sozinho; a RACI serve nas fronteiras, onde o time depende de gente de fora para decidir, aprovar ou ser consultado. Se você precisa revisar o significado de cada letra antes, veja matriz RACI: significado e diferença entre R e A.
Formação relacionada
Como estruturar comunicação e relacionamento com as pessoas envolvidas no projeto.
Por que a RACI tradicional bate de frente com o ágil
A RACI nasceu para projetos em que o trabalho é conhecido de antemão e pode ser dividido em tarefas com dono. Três características do ágil quebram essa lógica:
- O trabalho emerge. As tarefas da Sprint são definidas pelo time no planejamento e mudam ao longo dela. Uma matriz de tarefas fica velha em dias.
- O time responde junto. O Guia do Scrum diz que o Scrum Team inteiro responde por criar um incremento valioso a cada Sprint. A regra clássica da RACI, um único A por linha, aplicada a tarefas internas, cria hierarquia dentro de um time que deveria se autogerenciar.
- Os papéis já estão escritos. Product Owner, Scrum Master e Developers têm responsabilidades definidas no próprio Guia. Refazer isso numa matriz só cria uma segunda fonte de verdade, geralmente pior.
O que o Guia do Scrum já define
Antes de montar qualquer matriz, vale saber o que já está resolvido. O Guia do Scrum de 2020 fala em responsabilidades (accountabilities), não em cargos:
| Papel | Responde por |
|---|---|
| Product Owner | Maximizar o valor do produto e gerenciar o Product Backlog: meta do produto, itens, ordem e transparência |
| Developers | Plano da Sprint (Sprint Backlog), qualidade conforme a Definição de Pronto, adaptação diária rumo à meta da Sprint |
| Scrum Master | Estabelecer o Scrum como definido no Guia e a eficácia do Scrum Team |
| Scrum Team | Criar um incremento valioso e útil a cada Sprint |
Nada disso precisa de RACI. Se aparecer uma linha "priorizar o backlog" com R para o gerente de projetos e A para um diretor, a matriz está contradizendo o framework, e o problema é de governança, não de preenchimento.
Onde a matriz RACI em projetos ágeis ainda ajuda
O time ágil não vive isolado. Ele depende de decisões e entregas que estão fora dele, e é aí que a confusão de papéis custa caro. Exemplos de fronteira:
- liberar uma versão em produção quando há uma área de operações ou de mudanças de TI;
- aprovar requisitos de conformidade, segurança da informação ou proteção de dados;
- homologar entregas com o cliente, em projetos contratados;
- mudar orçamento, prazo contratual ou escopo do contrato;
- priorizar entre times que disputam a mesma dependência;
- comunicar status para a diretoria e o comitê do portfólio.
Nessas linhas, a pergunta "quem decide, quem faz, quem precisa ser ouvido, quem só precisa saber" continua valendo. Muitos desses atores são stakeholders externos ao time, e mapear o envolvimento deles é parte do trabalho descrito em stakeholders em projetos ágeis.
Como adaptar a matriz RACI ao ágil: cinco regras
- Linhas são decisões e resultados, não tarefas. "Aprovar a política de retenção de dados" é linha; "criar a tabela de logs" não é.
- Colunas são papéis, não pessoas. Product Owner, Developers, Scrum Master, área de segurança, operações, patrocinador. Pessoas mudam; papéis duram.
- O time aparece como coletivo. Os Developers entram como uma coluna só. Quem do time faz o quê é decisão deles.
- Um A por linha continua valendo nas fronteiras. É justamente onde a ambiguidade trava: duas áreas achando que aprovam a mesma coisa.
- A matriz é revisada pelo time. Quando surgir conflito sobre quem decide, o assunto vai para a retrospectiva e a matriz é ajustada ali, não por e-mail do PMO.
Exemplo de matriz RACI num projeto ágil
O exemplo é ilustrativo: um time Scrum desenvolve o aplicativo de agendamento de uma rede de clínicas. A empresa tem área de segurança da informação, uma área de operações que publica versões e um comitê de produto.
| Decisão ou resultado | Product Owner | Developers | Scrum Master | Segurança da informação | Operações | Patrocinador |
|---|---|---|---|---|---|---|
| Meta do produto para o trimestre | A/R | C | I | I | I | C |
| Requisitos de proteção de dados do paciente | C | R | I | A | I | I |
| Cumprir a Definição de Pronto, incluindo testes de segurança | C | A/R | C | C | C | I |
| Liberar versão em produção | C | R | I | C | A | I |
| Mudança de orçamento ou prazo do contrato com o fornecedor | R | C | I | I | I | A |
| Remover impedimento entre o time e operações | I | C | R | I | C | A |
| Status para o comitê de produto | R | C | C | I | I | A |
Repare em três escolhas. Cumprir a Definição de Pronto é dos Developers, como diz o Guia do Scrum, mas segurança e operações são consultadas porque dependem dela. Liberar versão em produção tem operações como A porque, nessa empresa, é quem responde pelo ambiente. E o Scrum Master é R para remover o impedimento entre áreas, mas o A é o patrocinador, que tem autoridade sobre as duas.
Para montar a sua com essa estrutura, use a matriz RACI online da Projeto Diário, substituindo as tarefas por decisões e as pessoas por papéis.
RACI, DACI ou acordo de trabalho?
Nem toda fronteira pede RACI. Se o problema é quem decide numa escolha pontual (qual fornecedor de nuvem, qual arquitetura), a DACI organiza melhor: um condutor, um aprovador, contribuidores e informados. A comparação está em RACI, RASCI e DACI. Para regras de convivência dentro do time (horário de reuniões, revisão de código, quem atende o plantão), um acordo de trabalho escrito pelo próprio time funciona melhor do que qualquer matriz.
E o gerente de projetos, onde fica?
Em organizações híbridas, o gerente de projetos convive com o Scrum. Na matriz, ele costuma aparecer nas fronteiras: contrato, orçamento, comunicação com o portfólio, dependências com outros projetos. Ele não deve aparecer como A da ordem do backlog nem do plano da Sprint. Os limites desse papel estão em o papel do gerente de projetos em times ágeis.
Erros comuns
- Matriz de tarefas por pessoa do time. Contraria a auto-organização e envelhece na primeira Sprint.
- Product Owner como R de tudo. Ele vira gargalo e o time para de decidir sobre como fazer.
- Diretor como A do backlog. Esvazia o Product Owner. Se a diretoria precisa decidir prioridades, o lugar é a meta do produto ou o portfólio, não o backlog item a item.
- Ninguém de fora na matriz. Justamente onde ela seria útil.
Monte a sua pelas fronteiras
Liste as cinco decisões em que o seu time mais esperou alguém de fora no último trimestre. Elas são as linhas da sua matriz. Preencha com papéis, valide numa conversa curta com cada área envolvida e leve para a próxima retrospectiva. A ferramenta de matriz RACI da Projeto Diário monta a tabela em minutos e exporta para compartilhar. Para entender como essas definições se encaixam no trabalho mais amplo com partes interessadas, veja o guia de gestão de stakeholders.
