Guia definitivo para Histórias de Usuário - Product Management

[@djsilva781]

Vídeo muito bom... poderia me ajudar a criar 4 historias de usuários nesse exemplo? Preparação de uma campanha publicitária online para converter usuários da versão gratuita de um aplicativo em usuários pagantes. O app consiste em uma mesa de exercícios voltada para perda de peso. Na versão paga existem três categorias de exercícios (peitorais, abdominais e extremidades), narrados ao longo de 30 dias combinados com recomendações gerais sobre a dieta mais recomendada. A versão paga inclui uma análise personalizada a partir dos dados inseridos pelo usuário e um leitor de código de barras que fornece informações sobre as calorias de cada alimento.

[@sulimararse]

Excelente, parabéns!

[@DiogoBeckerProductManagement]

Muito obrigado!

[@markdomingues]

Grande Diogo, parabéns pelo conteúdo. só uma informação... SPIKE são histórias de testes.. por exemplo se um time vai utilizar uma determinada tecnologia que não conhece... eles devem fazer um spike para testar a tecnologia antes de assumirmos como compromisso de entrega... então spike são pequenos testes de implementação, ou provas de conceitos...

[@DiogoBeckerProductManagement]

Olá, Marcos!! Obrigado pelo feedback e contribuição!! Baita conhecimento compartilhado! tamo junto!! ;)

[@lucasfurtado6360]

Fala Diogo, parabéns pela didática, muito bom! Só um ponto, definição de pronto (DoD) é genérico aplicado as todas as historias de usuário, os critérios de aceite são específicos da história. Ex de DoD Funcionalidade disponível em produção Testes unitários realizados Cenários de testes aprovados Review realizada e aprovada E por aí vai

[@DiogoBeckerProductManagement]

Olá, Lucas! Obrigado pelo feedback! E massa demais a sua contribuição. Super clara! Faz sentido. Obrigado e tamo junto!!

[@amarofilhosilva]

Sim, eu até já tenho uma listinha meio que pré-definida para a DoD e só vou copiando e colando em cada história pra ganhar tempo, á que não muda muito de uma pra outra. kkkk

[@Gabi1000show]

Incrível esse vídeo, linguagem super simples que até parece que é fácil, hehehe. Sua didática é muito boa. Obrigada por manter este canal ativo.

[@DiogoBeckerProductManagement]

Muito obrigado pelo feedback! Saber que o conteúdo é aprendido é o maior resultado que um professor pode receber. :)

[@victormunduruca]

Muito bom o conteúdo! a melhor aula sobre histórias de usuário que vi até agora no youtube

[@DiogoBeckerProductManagement]

Muito obrigado pela mensagem, Victor! Conta muito pra mim! Tamo junto

[@LifePlayerss]

Uhuuu... muito bom Diogo!! Gostei demais, ajudou muito!! Bora lá!! Ansioso para o próximo vídeo!!

[@DiogoBeckerProductManagement]

Obrigado pelo feedback, Life!! tamo junto!! :)

[@maisaneves8290]

Bom demais, como smp! Já tô me coçando pra fazer o curso kkkkk

[@DiogoBeckerProductManagement]

Boa, Maísa!!! Será um prazer ter vc como aluna! Eu tiro as dúvidas por whats e email tb :)

[@leonardo8850]

Seria legal disponibilizar o Miro

[@gabmattosp]

Muito bom! Pra mim aproximou demais a teoria da prática. Perfeito!

[@DiogoBeckerProductManagement]

Obrigado pelo feedback, Gabriel!! Pegou o espírito da coisa! Tamo junto

[@SteRib1]

Dinheiro faria sentido se tivesse opção de entrega já que é online

[@stevanbressane5643]

Muito bom, está ficando inevitável fazer esse curso!!! Rsrs... Obrigado pelo conteúdo!

[@DiogoBeckerProductManagement]

Obrigado pelo feedback, Stevan!! Será um prazer ter vc como aluno. Conte comigo, tamo junto

[@tiagofuhrmann]

gostei muito do tipo de video

[@DiogoBeckerProductManagement]

Obrigado pelo Feedback, Tiago! Tamo junto

[@LeoDabague]

Diogao, seria legal ter um conteúdo que você convida uma pessoa de design para mostrar a sinergia necessária entre os dois mundos: produto & design para que o usuário seja bem "servido". Nem sempre o que a gente rollouta tem as melhores métricas de adoção e ad vezes não é a funcionalidade em si, e sim a experiência fornecida. Acho que pode ser um conteúdo bem rico ;)

[@DiogoBeckerProductManagement]

Ótima sugestão, Leo!! Vou pensar neste tema e criar um roteiro aqui. Se tiver alguma sugestão de pessoa ref para falar, ajuda tb! hehe

[@felipebeloneoficial]

Excelente vídeo!

[@DiogoBeckerProductManagement]

Boooa, Felipe! Tamo junto!!

[@JeffersonFerreira84]

Diogo, muito boa sua explicação! Explicação leve, objetiva, sem formalismo, muito fácil de entrar na cabeça. Você me passou o link pelo Linkedin. Valew!

[@DiogoBeckerProductManagement]

Booooa Jefferson! Obrigado pelo feedback e mensagem. Tamo junto!!

[@gustavschult9002]

Excelente conteúdo !

[@DiogoBeckerProductManagement]

Obrigado pelo feedback, Gustavo! Tamo junto!!

[@LarisseCarvalho]

Conteúdo incrível, Diogo! Sou fã do canal ✨

[@DiogoBeckerProductManagement]

Muito obrigado pelo feeedback e parceria faz tempo já, né? tamo junto, Larisse! :)

[@rafaelmartins8791]

Parabéns, valeu mais uma vez Diogo. Seu conteúdo tem ajudado muito no meu dia a dia.

[@DiogoBeckerProductManagement]

Muito obrigado novamente, Rafael!! Tamo junto, guri

[@ariadnenunes9203]

Gostei Muito! Show!

[@DiogoBeckerProductManagement]

Obrigado pelo feedback, Ariadne! tamo junto

[@israelsilva4328]

Muito bom... ótima explicação

[@DiogoBeckerProductManagement]

Muito obrigado pelo feedback, Israel! Tamo junto

[@kaioaramys]

sensacional o video...

[@DiogoBeckerProductManagement]

Muito obrigado pelo feedback, Kaio! Tamo junto!

[@kaioaramys]

@@DiogoBeckerProductManagement já vou fazer a aquisição do curso ein... realmente seus conteúdos bons e passam a visão do dia a dia

[@GibaAirCooled65]

Mais um conteúdo top !!! Uma duvida: É normal criar uma historia de uma forma mais "superficial" e contar com a experiência dos Dev's ou geralmente é melhor detalhar o máximo possível as funcionalidades (validação de campo, comportamento da funcionalidade e etc.)? Pois caso seja muito detalhado, podemos "perder tempo" escrevendo o óbvio.

[@Berocks100]

O óbvio não é óbvio para todo mundo. Devemos escrever com detalhes de qualidade o que queremos construir =)

[@DiogoBeckerProductManagement]

Boa pergunta, Thyago! Acho que a dúvida que todos temos quando estamos fazendo várias histórias. Mas a resposta é na linha que temos que escrever imaginando que uma pessoa média vai ler. (média no sentido de nova na empresa ou super antiga). Não necessariamente vc vai escrever tudo do projeto. Pois precisamos ser objetivos. Existem outras documentações que servem para dar contexto mais detalhado. Recomendo neste caso colocar o link delas para consulta. por ex: o link de uma apresentação do projeto, por ex. Temos que ter documentação nos Épicos tb. Para que as histórias consigam ser mais específicas. Em times de tecnolgia também temos o problema de ter uma giro alto de pessoas e Histórias é uma forma de deixar todo mundo na mesma página.

[@paulafariaq]

Sensacional!! Obrigada ♥

[@DiogoBeckerProductManagement]

Top!! Obrigado

[@yagamikisuke]

Muito esclarecedor o vídeo.

[@DiogoBeckerProductManagement]

Espero ter ajudado! tamo junto!

[@brsanches]

Ótimo conteúdo, muito obrigado por compartilhar esse conhecimento. Só me bateu uma dúvida que você montou o DOD para a história específica. O DOD não seria uma definição de pronto criada para que atenda a todas histórias?

[@DiogoBeckerProductManagement]

Olá! Obrigado! Isso, eu coloquei o DoD para a história que coloquei como exemplo pois ela, em si, é uma feature inteira do produto. Assim, ela tem como ficar "Pronta". Tanto que para a História que usei como exemplo, comento que dá para criar Sub-tasks dentro dela. Eu acho que toda história fica melhor com o DoD pois conseguimos ter noção de quando ela termina e o que precisa ser feito. Histórias sem DoD ou Critérios de aceite tendem a gerar dúvidas. Ficou mais claro? :)

[@brsanches]

@@DiogoBeckerProductManagement Acho que minha pergunta ficou confusa. Minha dúvida é o seguinte: Na história específica, vc colocou um DOD com especificação para aquela história em específico. O DOD não teria que ser um conjunto de definições "geral", que quando qualquer história atenda, esteja "pronta" ? Ou realmente o DOD é específico por tarefa?

[@salvarenga75]

Boa didática!!!

[@DiogoBeckerProductManagement]

Obribado pela mensagem! tamo junto

[@TheFiireBoy]

Muito bom o vídeo! Tem algum motivo para você não usar o nível de "Funcionalidade" e ir do "Épico" direto para a "História"?

[@DiogoBeckerProductManagement]

Olá, Funcionalidade é uma tradução para Feature? Se for, está um nível acima do Épico e seria gerenciada no Roadmap.

[@hosanaaparecidarodrigues6742]

Diogo, boa tarde!!! Tudo bem? E as Regras não deveriam entrar separado como o item Critérios de Aceite? Teria mensagens, como de sucesso ou de erro?

[@Francimar619]

Normalmente sim. Aqui na minha empresa nós separamos: Histórias, cenários, requisitos e regras de negócio.

[@DiogoBeckerProductManagement]

Olá! As regras de negócio podem estar na parte de Contexto. Ou então linkadas em um Doc mais abrangente de Product Discovery, já que as regras de negócio vão servir para várias Histórias.

[@marielilemes]

Pegunta de noob, essas historias de usuario serve a estrutura tbm pra BUGs?

[@DiogoBeckerProductManagement]

Olá, Marieli. Para BUGs dá pra deixar mais direto e enxuto. Se for um problema maior que apenas um BUG, ai recomendo fazer uma história de usuário.

[@Francimar619]

A escrita de cenários, no formato BDD, dentro da história faz sentido?

[@DiogoBeckerProductManagement]

Olá! sim, é possível usar vários frameworks existentes (BDD, JTBD, etc) ou mesmo criar um próprio. Checklists sempre ajudam a gente nãoo esquecer nada relevante! :)

[@LucasSantana-fv3wu]

Fiquei com uma dúvida. Normalmente na descrição do épico ali no Jira, devemos colocar também uma história de usuário do propósito da aplicação ou só uma descrição explicativa do que seria o épico?

[@DiogoBeckerProductManagement]

Boa pergunta Lucas! O que diferencia um Épico de uma História às vzes é até filosófico. Gosto de enxergar um Épico como uma História GRANDE. Então eu seguiria de forma parecida, dando contexto, explicando quem são os clientes, stakeholders, qual o problema, necessidade, qual a solução, etc. Às vezes, acontece até da gente ter 1 História de usuário que fica tão grande que decidimos mudar ela para um Épico com outras histórias aninhadas. Porém, não precisa ficar repetindo descrição sempre, tá? A ideia desta "árvore" é agilizar e não burocratizar. Ficou mais claro?

[@LucasSantana-fv3wu]

@@DiogoBeckerProductManagement Ficou sim! Muitíssimo obrigado!

[@batepapodeti]

Parabéns pela iniciativa. Peço mil desculpas, mas me vejo obrigado a comentar, o conceito de SPIKE dado no vídeo está equivocado!

[@DiogoBeckerProductManagement]

Olá! Imagino que vc use o spike como o tempo dedicado a estudar para refinar, isso?

[@DavidPereira-wq6sq]

E o INVEST?

[@DiogoBeckerProductManagement]

É um framework que pode te auxiliar a escrever. Mas é opcional.

[@andreluissouza93]

Ótimo conteúdo!

[@DiogoBeckerProductManagement]

Obrigado pelo feedback Andre! tamo junto