Skip to main content

Autor: gabimiza

Gabriela Mizarela, Product Manager, Agilista, apaixonada por música e cães.

Os estágios de evolução do Product Owner

gabimiza Deixe um comentário

Já parou para pensar que existem estágios de evolução para a função do Product Owner, ou o PO? Veja abaixo quais são e me conta o que achou.

A evolução

Os estágios são incrementais ou seja, é a soma do anterior com o atual, as características e habilidades são acrescentadas. Esses estágios foram concebidos com base na experiência e percepção dos profissionais que atuam com Scrum em diferentes partes do mundo.

O escritor

Comumente acontece em adoções iniciais do Scrum, que passam a usar o padrão de história de usuário. Por possuir baixa influência sobre o negócio, precisa do marketing, comercial, gerente de produtos, etc para responder perguntas. É comum verificar atrasos e desperdícios nos times que atuam dessa forma.

O proxy

Possui forte habilidade de comunicação e com isso tem maior conexão com a área de negócio. Em alguns casos, pode influenciar na prioridade do itens de backlog. Ainda encontra dificuldades em esclarecer as dúvidas do time, pois recebe as demandas e nos melhores cenários, trabalha no detalhamento dela ganhando um pouco mais de propriedade.

O representante de negócios

Neste estágio o PO geralmente é alguém que representa o negócio, uma clara evolução do proxy. Este perfil conta com um domínio e acesso muito mais abrangente ao negócio, mas ainda falta a autonomia necessária para a efetiva gestão do produto. Existe uma colaboração mais ampla. entre TI e negócio.

O patrocinador

Possui influência e voz ativa para tomar decisões (dada pela área de negócio), tanto no produto quanto na gestão financeira. Auxilia no andamento do fluxo de trabalho, menos interrupções são causadas por falta de entendimento e de decisões de negócio. Proporciona uma certa segurança para a tomada de decisões do time.

O empreendedor

Totalmente responsável pelo orçamento do produto e pelas funcionalidades. Seu trabalho é criar Valor de Negócio para os clientes. Pode delegar algumas atividades de baixo valor agregado para outros profissionais, tais como: escrever histórias, critérios de aceite e etc. 

Conclusão:

É importante lembrar que por definição, um Product Owner não deveria ser somente um escritor de história de usuário e critérios de aceite, e muito menos o proxy entre negócio e desenvolvimento. Porém, isso ainda é visto em empresas, devido a gestão, cultura, perfil, etc.

Você deve se perguntar, mas e o Product Manager (PM)? Para mim é a mesma coisa e vai depender da empresa. Em algumas delas, onde o scrum não é adotado, tem o papel do PM que nada mais é, ou deveria ser, o mesmo que o PO empreendedor. Em outras que usam scrum, ou agilidade em larga escala, ele fica um nível acima cuidando de vários produtos a nível estratégico e também é responsável por guiar as entregas dos POs e times.

Fontes:

scrum.org

metodoagil.com

cafecomscrum.com

O equilíbrio das habilidades do product manager – skills de produto e skills gerais

gabimiza Deixe um comentário

Lendo um pouco mais sobre características ideais para um product manager, me deparei com o artigo do Roman Pichler, disponível no Medium. Destaco a questão de que devem ser profissionais T-shapped, com habilidades no produto e habilidades gerais, de liderança, estratégias e técnicas. 

As habilidades específicas do produto, podem ser de único produto ou portfólio. Isso demanda um conhecimento profundo das necessidades dos usuários, competidores, modelo de negócio e tendências do mercado, além do conhecimento das features, jornadas, objetivos, proposta de valor etc, do próprio produto. As skills específicas do produto são cruciais mas, por mais importantes que sejam, não são suficientes.

As habilidades gerais (estratégicas e técnicas), te ajudam a resolver desafios na gestão de produtos bem como te permite mais flexibilidade para atuar em diversas áreas de negócios. Alguns exemplos: análise de dados e feedbacks fornecidos; construção de KPIs ou OKRs; segmentação de mercado, proposição de valor do produto, validação de estratégia, priorização de backlog, etc. 

Fonte: https://medium.com/agileinsider/the-t-shaped-product-manager-c3e4587e5b84

Qual a principal diferença entre POC e MVP?

gabimiza Deixe um comentário

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

gabimiza Deixe um comentário

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

gabimiza Deixe um comentário

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