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/ 

As 4 melhores técnicas de priorização de backlogs

O backlog do produto deve ser uma lista de todas os épicos, features, histórias e tarefas relacionadas ao produto que a equipe precisa desenvolver, incluindo a divisão de responsabilidades e estimativas. Ele precisa também ser flexível para mudar de acordo com as necessidades do mercado (exemplo: o lançamento de uma nova funcionalidade em um produto concorrente). Devido a isso, um grande desafio na vida do PO é manter esse backlog priorizado, fatiado e organizado, de acordo com as necessidades dos seus usuários, stakeholders e mercado. No meu dia a dia já usei algumas técnicas para me ajudar no meio de um mar de itens, separei as que mais gosto de trabalhar:

Priorização inspirada na Lean inception

Já usei para facilitar, em reunião com os stakeholders, com o objetivo de priorizar as features, ou funcionalidades, a serem desenvolvidas nos próximos meses. De forma bem resumida, é uma votação, de 1 a 3, do quanto o usuário vai gostar da funcionalidade, qual o valor que ela traz para o negócio e qual o esforço para desenvolver.

MOSCOW

Para mim a mais rápida e de fácil entendimento para usuários, uso bastante no dia a dia, em refinamentos e planejamentos gerais. É basicamente um quadro, para ranquear com os envolvidos no produto, quais funcionalidades/histórias, esse produto deve ter (Must), Deveria ter (Should), Poderia ter (Could), Gostaria — não terei no momento (Would).

WSJF — Weighted Shortest Job First

Umas das técnicas que mais gosto, é um modelo de priorização usado para sequenciar por exemplo, Features, Capabilities e Epics, com o objetivo de criar o maior benefício econômico, calculando o custo relativo do atraso (CoD) e o tamanho do trabalho. Esses itens são pontuados (pode ser através do fibonacci), de acordo com:

– valor de negócio

– urgência

– Risco

Que somados dariam o custo do atraso, que deve ser dividido pelo esforço para o desenvolvimento. Cada item tem um total, o com o maior valor é o de maior prioridade.

Matriz GUT

Já utilizei em momentos onde várias coisas eram muito importantes. Como funciona? Liste as funcionalidades ou histórias e crie um ranking para elas de acordo com Gravidade, Urgência e Tendência. Multiplique as 3 notas para obter o ranking dos seus principais itens a serem resolvidos.

Gravidade (impacto financeiro ou qualquer outro)

1. Sem gravidade;

2. Pouco grave;

3. Grave;

4. Muito grave;

5. Extremamente grave.

Urgência (é o fator tempo)

1. Pode esperar;

2. Pouco urgente;

3. Urgente, merece atenção no curto prazo;

4. Muito urgente;

5. Necessidade de ação imediata.

Tendência (o problema tende a piorar rapidamente ou se deve permanecer estável caso não seja solucionado)

1. Não mudará;

2. Vai piorar em longo prazo;

3. Vai piorar em médio prazo;

4. Vai piorar em curto prazo;

5. Vai piorar rapidamente.

Bônus: Coisas que não te contam sobre a priorização

  • Nem sempre dá tempo de usar técnica para priorização
  • Às vezes infelizmente acontece de a priorização vir top down, por conta de prioridades maiores da empresa/gestão

E aí me conta, quais técnicas você costuma utilizar para priorização?

Fontes:

https://www.caroli.org/sequenciador/

https://vidadeproduto.com.br/framework-moscow/

https://rockcontent.com/br/blog/matriz-gut/

https://medium.com/agileinsider/5-best-ways-to-prioritise-your-product-backlog-a761fadc8862

https://www.scaledagileframework.com/wsjf/

https://online.visual-paradigm.com/pt/diagrams/templates/moscow-method/moscow-template/

Como funciona o planning poker para estimativas ágeis

Confesso que uma das partes mais intrigantes do gerenciamento de projetos ágeis é quando o time tem que estimar as tarefas. Uma das formas de fazer isso é através do planning poker, com ele o time a debate e consequentemente obtém um entendimento acerca do que deve ser feito em uma feature.

Mas o que é Planning Poker?

“Também chamado de scrum poker, é uma técnica de estimativa baseada em consenso e gamificada, usada principalmente para estimar o esforço ou o tamanho relativo dos objetivos de desenvolvimento no desenvolvimento de software” (fonte: Wikipedia).

A estimativa é uma das atividades principais no Scrum e outros processos ágeis. Isso significa que o processo de atribuir um tamanho a uma história ex: quanto tempo isso irá levar, ou quanto de trabalho/esforço existe para implementar, quanto isso é “caro”, impacta na seleção de itens futuros do backlog a serem feitos e velocidade do time. A estimativa é uma atividade da equipe, todo o time participa do processo de estimativa para cada história (ou tarefa).

O Planning Poker® (as vezes chamado Scrum poker) é uma simples porém, poderosa ferramenta que faz o time estimar rapidamente, com mais probabilidade de acerto e além disso é uma forma mais divertida para se estimar.

Resolvi pesquisar na Internet como funcionava pois tinha algumas dúvidas quando acompanhava times “jogando”. Achei o artigo a seguir e resolvi traduzir. Para mim foi um dos melhores textos que encontrei, explica bem passo a passo como deve ser feito.

via GIPHY

Estimando sem o planning poker

Temos a seguir um problema com estimativas feitas pelo time. Vamos dizer que nós estamos realizando a reunião de planejamento de uma sprint (sprint planning meeting) e o product owner (o “dono do projeto”) diz: Ok, pessoal quanto tempo isso vai levar?

Então, o time começa a pensar quanto tempo esse item vai levar para ser feito (nesse caso em homem/dias)….

O SR. A acredita que sabe exatamente o que precisa ser feito, então ele acha que vai levar 3 dias. Sr. B e C são mais pessimistas. Sr. D e E estão mais distraídos, Então Sr. A diz: “3 dias”.

Isso deixa B e C confusos. Eles começam a ficar na dúvida com relação as próprias estimativas. Sr. E acorda e não sabe realmente o que está sendo estimado. Sr. D continua cochilando.

O product owner pergunta para o resto do time suas estimativas.


Como você pode ver, o resto do time for muito influenciado por A, apenas por que A falou antes. Isso é muito arriscado! B e C pensam que isso levará mais do que 3 dias, suas dúvidas deveriam estar sanadas.

Estimando com o Planning Poker

Agora imagine que cada membro do time está segurando um bolo de cartas, contendo as seguintes cartas:


Vamos voltar a estimativa. O Product Owner diz:


 

 

 

Mais uma vez, o time começa a pensar sobre quanto tempo a tarefa irá levar para ficar pronta.


Nesse time ninguém diz nada. Ao invés disso, todos tem que apresentar a carta com a face para baixo, contendo sua estimativa. Todo mundo tem que apresentar uma carta, então Sr. D e E acordam. Sr. D admite que estava dormindo e pergunta do que se trata a tarefa. É difícil de ser distrair quando a estimativa é feita dessa forma.

Quando todos já tiverem feito suas estimativas, então as cartão serão viradas ao mesmo tempo revelando o que cada um estimou.


Opa! Grande divergência aqui. O time em particular o Sr. A e o Sr. C, precisam conversar sobre a tarefa e o por que de suas estimativas serão tão diferentes. Depois de alguma conversa, Sr. A percebe que tinha esquecido algum item importante que deveria ser incluído nessa tarefa. Sr. C percebe que com o design que o Sr. A apresentou, a tarefa deveria ser menor que 20.

Depois da conversa (3 minutos no total) eles fazem outro round de estimativa para a mesma tarefa.


Convergência! Ok, não é uma total convergência. Mas eles concordam que uma estimativa de 5 deveria estar próximo do suficiente. E aí vem a próxima tarefa.

Por que essa séria estranha de números?
Os números mais altos tem menor granularidade. Por quê? Por que não tem 21 por exemplo?


Por diversos motivos:

  • Para aumentar a velocidade do processo de estimativa limitando o número de escolhas (número de cartões).
  • Para evitar uma falsa sensação de exatidão para estimativas altas.
  • Para encorajar o time a dividir histórias grandes em menores.

Uma estimativa alta (> 20 por exemplo) normalmente significa que a história não está entendida em detalhes. Será perda de tempo para o time discutir se a a história é 19, 20, 22.5. É simplesmente uma grande história e o 20 refletirá isso. Se você precisa entrar em detalhes, quebre a história em menores. Histórias menores podem ser estimadas em maiores detalhes.

Cartas especiais

O zero significa “a história está pronta” ou “esta história é quase nada leva apenas minutos de trabalho”.
O cartão de dúvida significa “Eu não tenho absolutamente ideia de nada” Deve ser raro. Mas esse cartão é usado frequentemente, o time precisa discutir mais as histórias e tentar alcançar um melhor entendimento para passar para todos do time.
O cartão do café significa “Estou tão cansado para pensar. Vamos dar um pequeno intervalo”

Traduzido de: http://www.crisp.se/planningpoker/

 

Conclusão final:

A meu ver o planning poker é uma das melhores formas de fazer estimativa que já usei com times, com ela não pensamos em tempo e sim no “esforço” ou “peso” que uma tarefa possui em relação a outra. Para o ser humano, é muito mais fácil fazer estimativas relativas do que absolutas, por exemplo: responder qual é o peso de um gato ou de um leão é complicado, mas responder quem pesa mais, o gato ou o leão, não é. No momento dessa reunião que informações importantes vem a tona, bem como a complexidade dos itens e dependências de terceiros.

Uma observação é que deve-se orientar as pessoas a levarem a discussão a sério em torno do que será desenvolvido, e sobre as divergências de cartas apresentadas, senão a ferramenta vira uma brincadeira ao invés de um ótimo instrumento.

Extras: ferramentas e apps

https://www.planitpoker.com/ 

https://scrumpoker.online/

https://www.planningpoker.com/

Scrum poker for Jira 

App Scrum Poker

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).