Qual granularidade usar? Essa é uma pergunta bem comum para #agilistas, #pms e #pos que estão buscando estruturar seus #roadmaps e #backlogs, com o objetivo de melhorar a #previsibilidade e a eficiência do time, trazendo cada dia mais valor, mais rápido.
Com base em insights trazidos por agilistas do meu time, montei esse material pra ajudar você agilista, você PM a estruturar melhor sua prancheta de trabalho.
Além disso, é claro, tem meu video do Youtube explicando como gerar essa “Documentação” de Backlog com base em uma lógica estruturada.
Obs.: Essa proposta de granularidade não contempla a técnica #PBB, do Fábio Aguiar, portanto, não usamos o nome #Features, que é um tipo de abstração diferente do que usamos aqui.
Espero que faça bom proveito!
Deixa aqui nos comentários se esse conteúdo te ajudou.
Você conhece a abordagem de quebra/divisão de histórias do Mike Cohn? O SPIDR é um acrônimo para Spikes, Paths, Interfaces, Data e Rules, e são abordagens para divisão de histórias em partes menores.
Tomei a liberdade de traduzir o material em inglês, espero que seja útil.
Você sabe o que é fatiar? Fatiar é uma técnica que visa a entrega de produtos menores, a fim de validar um experimento (se o produto atende ao problema de um cliente). Os motivos e benefícios do fatiamento são vários: -> Ter melhor gestão visual das pequenas partes que compõem o produto e como elas estão dentro do fluxo do time; -> Possibilitar ciclos curtos de feedback (o mais curtos possível); -> maior gestão de riscos e menos surpresas; -> Melhor previsibilidade das entregas. O fatiamento (do inglês “Slice”) deve ser feito no nível estratégico e de release, sempre com métricas baseadas na hipótese. A quebra de histórias (do inglês “Rock Break”, “Split”) deve ser feita no nível de backlog, também para objetivos similares. (Referências: Jeff Patton’s User Story Mapping, Mike Cohn’s SPIDR approach to splitting user stories)
Depois de falar um pouco sobre Métricas e Retorno sobre o Investimento, vamos falar um pouquinho mais sobre como acompanhar o ROI de um produto ou serviço. Pra isso, vou trazer aqui pro palco, ninguém menos do que Dave McClure pra trazer as Métricas do Pirata.
Então, o que são as Métricas do Pirata? São elas que medem o comportamento do seu cliente durante o Ciclo de Vida dele em contato com seu produto. Como assim?
Quando estamos fazendo gestão de produtos, esta pergunta é bem comum: Como eu verifico e checo a saúde do meu produto utilizando métricas?
Quais métricas devo considerar? Todas as métricas possíveis? Algumas? Como ser mais assertivo em relação a elas?
Primeiramente…
Uma métrica (ou várias delas) tem como objetivo medir a saúde de um problema que você está resolvendo. Leia-se problema como uma “dor do negócio” ou “oportunidade de negócio”. Leia aqui sobre problemas e oportunidades.
Uma vez definida a hipótese sobre o problema que você está resolvendo, chega a hora de definir as métricas. Na minha visão, existem métricas de nível operacional e de nível mais macro, que atingem necessariamente os resultados da empresa.
Eficiência ou Eficácia?
Como donos de produto, temos como dever perseguir as métricas de eficácia, mas nunca nos esquecer que as métricas de eficiência colaboram para a melhoria das métricas de eficácia e a nossa aproximação dos resultados de forma cada vez mais ágil. Não sabe do que tô falando? Se liga:
Pois bem, as métricas de negócio são responsáveis por medir a Eficácia, e as métricas organizacionais são responsáveis por medir a Eficiência. Combinado?
Entendi. Mas como é que vamos medir a Eficácia? Como é que eu sei que estou sendo eficaz com meu produto?
ROI
Você sabe o quanto está investindo no seu time? Por quantas pessoas ele é composto? Quanto custa este time?
Seu produto faz vendas diretas? É vendido? Monetizado? Qual o total de vendas que seu produto faz ou fará?
Seu produto facilita uma venda? O Quanto ele facilita essa venda? Quantas vendas seu produto ajuda a fazer?
Estes são exemplos de retornos de investimento direto que um produto pode gerar.
Como calcular um ROI?
ROI = [(Retorno – Investimento)/Investimento]*100
Cost of Delay
Cost of Delay é uma métrica que ajuda a tangibilizar o risco de não fazer determinada feature ou produto. Basicamente, o Cost of Delay mostra, caso um produto não possua ROI direto, formas de medir o impacto que um problema não resolvido pode ter. O Cost of Delay também pode ser usado juntamente com o ROI.
Dessa forma, Cost of Delay pode tangibilizar casos de:
Aumento de Receita
Proteção de Receita
Prevenção de Custo
Redução de custos
Como calcular o Cost of Delay?
Verifique qual o problema atual, exemplo: Quantos clientes eu posso suportar com a aplicação atual? Quantos clientes eu posso suportar com a aplicação nova? Quanto de faturamento traz cada cliente? Quanto de faturamento eu terei com mais clientes?
A Diferença encontrada será o Cost of Delay.
O universo de métricas é extenso e estou mergulhando nele agora 🙂 Para que o post não fique também muito grande, pretendo criar alguns vários dedicados a esta disciplina.
Deixe aqui sua dúvida, comentário, vamos trocar! Eu te ajudo com o que aprendi e você me ajuda a pesquisar e entender coisas novas. Combinado?
No dia-a-dia de quem trabalha com produto, é frequente a pergunta: “Mas qual problema você está resolvendo?” e essa simples pergunta pode confundir o transeunte que acaba de chegar no meio.
O problema que você está resolvendo tem muito a ver com a hipótese que você está trabalhando.
MAS PRI DO CÉU SÓ COMPLICA! ISSO QUE EU TÔ TRABALHANDO NÃO É HIPÓTESE, É UMA DEMANDA REAL!!!!!111
Disse o PO transeunte…
Sobre hipóteses:
Toda iniciativa começa com uma hipótese. E a premissa de toda iniciativa é:
Este produto pode/deve ser construído? Qual o resultado de valor esperado desta iniciativa?
Quantas vezes você já viu um produto no mercado que não fazia muito sentido? Quantas vezes você viu uma demanda sendo atendida para um “total de zero pessoas”?
Uma hipótese abraça o conceito de que toda demanda merece um olhar atento e precisa resolver um problema. Portanto, toda iniciativa carrega em si o fato de que são apenas apostas, suposições de que algo vai dar certo.
MAS DAÍ PRI, ENTÃO A GENTE PODE SAIR TESTANDO?
Nossa missão aqui é reduzir o risco dessa hipótese. Mas como?
Sabendo qual problema estamos resolvendo.
A iniciativa é composta de três conceitos:
Output > Outcome > Impact
Onde output é a saída do seu produto, outcome são as métricas operacionais do seu produto, e impact são os resultados para o negócio.
Por exemplo
Output: Entreguei uma nova área de ofertas
Outcome: Rendeu 10000 visualizações e 1000 cliques no primeiro mês de vida
Impact: Ajudou a monetizar 1000 clientes no primeiro mês, trazendo R$ 5000,00 de incremento de faturamento.
Declarando em palavras esta hipótese, vou deixar aqui a colinha:
Nós acreditamos que será alcançado este
[outcome de negócio]
se [este usuário]
conseguir com sucesso [seu outcome de usuário]
com [esta funcionalidade].
Saberemos que isto é verdade se observarmos este feedback:
1) qualitativo e/ou
2) quantitativo e/ou
3) alteração em algum indicador/KPI.
Então, independente se um problema (dor já existente) ou oportunidade (resolvendo um problema futuro para obter algum resultado), as hipóteses nivelam esse conceito para que possamos acompanhá-las da mesma forma.
Priscila Chagas 