Skip to main content

É novo em um time, que tal usar a matriz RACI?

É novo em um time e não entendeu ainda o que você é responsável por entregar e o que cabe a outras pessoas? Que tal usar a matriz RACI e levar clareza para o contexto? 

Sempre quando entramos em uma empresa existe um desconforto inicial, por isso é importante alinhar o que cabe a cada um. Em uma situação recente, sugeri de criarmos a matriz RACI para as funções que existem no time (Product Manager, Product Owner, Business Analyst, Scrum Master e Tech Lead). A seguir explico um pouco como essa ferramenta funciona e suas vantagens em utilizar. No final, deixo também um link de uma planilha modelo para você aplicar aí no seu dia a dia (ah, não esquece de duplicar para o seu Google Drive antes de utilizar)🚀

Utilizada tanto na gestão de projetos quanto na dinâmica de times, essa ferramenta é essencial para delimitar e formalizar as funções de cada profissional envolvido no processo. Imagine ter em um único lugar as informações cruciais para a execução das tarefas, de forma concisa e didática, facilitando a comunicação dentro do seu time? Pois é, essa ferramenta serve exatamente para isso! 🚀

O que é a matriz RACI?

A Matriz RACI propõe 4 atribuições, representadas pelas letras do acrônimo:

🔸 R – Responsible (responsável)

🔸 A – Accountable (autoridade)

🔸 C – Consulted (consultado)

🔸 I – Informed (informado)

Cada letra reflete um papel vital desempenhado por cada membro da equipe. 

É importante ressaltar que não existe certo e errado para as tarefas e suas classificações, cada empresa tem um jeito de operar, mas claro que existem recomendações, como por exemplo: a gestão do backlog ser uma responsabilidade do Product Owner e em uma mudança no produto ele deve ser autoridade, ou seja, vai ser quem bate o martelo final.

Quais as vantagens em usar?

Destaco também algumas vantagens em utilizar a Matriz RACI:

1️⃣ Melhora na comunicação

2️⃣ Alinhamento de expectativas

3️⃣ Redução do risco de retrabalho

4️⃣ Redução da sobrecarga de trabalho

5️⃣ Maior autonomia dos colaboradores

Link para o template (não esquece de duplicar para o seu Google Drive antes de utilizar):

https://docs.google.com/spreadsheets/d/1lecBX1Q9xYtyhk4VQURnojxOhY3N50gU/edit?usp=sharing&ouid=114501598657194175582&rtpof=true&sd=true

E aí, curtiu essa técnica, já usou? Me conta aí nos comentários  ✨ 

Qual a principal diferença entre POC e MVP?

Esses dias me perguntaram qual seria a principal diferença entre POC e MVP, respondi que o MVP (Minimum Viable Product) seria uma versão utilizável do produto com um número mínimo de funcionalidades, enquanto o POC (Proof of Concept) estaria em um estágio anterior, sendo uma prova de conceito interna da equipe, para o verificar a viabilidade técnica. 

Resolvi pesquisar melhor sobre o assunto para me aprofundar e separei algumas coisas interessantes:

  • A POC mitiga os riscos técnicos, já o MVP mitiga os riscos de negócio;
  • Startups normalmente começam com a POC para convencer os stakeholders sobre o real valor da solução a ser desenvolvida;
  • A melhor forma de criar uma POC é no estilo de hackathon;
  • Algumas vantagens do MVP são ter feedback dos usuários (early-adopters) antes do produto oficialmente lançado, reduzir custos/tempo e atrair investidores;
  • Alguns benefícios da POC são atrair investidores iniciais, descobrir se as pessoas precisam do seu produto e escolher a tecnologia mais adequada antes do desenvolvimento;
  • Existe ainda a prototipação, que também é rápida como a POC e permite visualizar como o usuário final irá interagir com o produto, entendendo seus fluxos e recursos necessários.
  • Não necessariamente é preciso passar por todos esses passos, cabe avaliar em qual o momento você se encontra, tanto a nível de produto como na equipe e empresa.

Fontes:

https://www.plainconcepts.com/mvp-poc-differences-use-cases/ 

https://thinkingthrough.substack.com/p/what-we-get-wrong-about-proof-of 

https://keytotech.com/2020/05/15/poc-prototype-mvp-difference/ 

https://spdload.com/blog/poc-vs-prototype-vs-mvp/ 

Comece pelo WIP

Recentemente comecei o curso Software Zen, que foi super recomendado por pessoas conhecidas. O formato é bem diferente de outros cursos, usando o conceito de sprint, retrospectiva, review e princípios lean. São vários conteúdos interessantes, vídeos, artigos e trocas de informações no fórum e grupo no Telegram, ou seja, uma experiência bem rica em termos de aprendizado.

Na última aula foi abordado de forma completa a questão do trabalho em progresso, ou o famoso, work in progress (WIP). Fiz algumas anotações sobre o processo:

  • No WIP está a chave para diminuir o tempo de entrega e aumentar a qualidade. É no Work in Progress que as coisas acontecem.
  • Selecione o que é mais importante, por que você não vai suportar fazer coisas que são menos importantes, isso é ineficácia. A capacidade do time não vai aguentar.
  • Só dá para administrar o WIP se o líder tangibilizar um grande mapa em conjunto das demandas da equipe. Até por que o WIP é muito dinâmico e o Kanban é um mapa/board de um jogo.
  • Quanto mais WIP mais baixa será a qualidade e maior o lead time (Little’s law). Para melhorar a qualidade reduza a quantidade de trabalho em progresso.
  • Lead times curtos geram confiança entre o fornecedor e cliente, ou seja, gerar entregas com frequência.
  • Entregáveis grandes são desmotivadores para o desenvolvedor
  • Coloque o cliente para pensar no business e não na feature, ou seja, ele deve pensar no real problema dele e cabe a nós solucionarmos através de uma feature.

Na minha experiência como PO e coordenadora de projetos, a entrega constante gera uma motivação tanto na equipe, como equipe de outros setores e clientes (usuários do sistema). O importante é priorizar com os principais envolvidos os itens de business, para depois criar as histórias de usuário (produto) e com isso o time criar as tarefas (trabalho).