Visão de produto no Scrum

[Música] olá neste vídeo vamos falar sobre a visão de produtos dos clã e conversar um pouco sobre toda a história que está por trás de uma história do usuário a dinâmica dos frangos da forma como ela é geralmente descrita assumir que existe um backlog com uma lista de itens que representa aquilo que deve ser desenvolvido no produto numa visão ordenada por prioridade esses itens geralmente são descritos como histórias de usuário é a partir dessa lista que o time decide a cada sprint quais histórias serão desenvolvidas naquele momento o time sempre direcionar a atenção para as

histórias que estão mais no topo do backlog já que elas correspondem aos itens mais prioritários uma das responsabilidades principais do produto ao ler o ppi ou é justamente a de manter essa lista de histórias atualizada e ordenada por prioridades dessa forma ele consegue guiar o time sobre o que é mais importante desenvolver naquele momento de forma do produto entregue lá na frente que gere o maior valor possível mas de onde eu tiro essas histórias de usuário e como ele toma essas decisões sobre a ordem em que elas devem ser desenvolvidas é sobre isso que a

gente vai conversar nesse vídeo na verdade o trabalho do produto nem já começou lá atrás muito antes da primeira história de usuário aparecer no backlog do produto esse trabalho começa quando o pior percebe uma necessidade das pessoas e tem uma idéia para um produto de software um produto que as pessoas iam adorar ter nas mãos que teria grande valor para elas em outras palavras o pior vislumbrou lhe uma boa oportunidade mas como seria esse produto quem ia por exemplo utilizá lo e o que tornaria esse produto tão atrativo para as pessoas a ponto de convencê

las a usá lo uma das primeiras responsabilidades do produto ao né é justamente a de amadurecer essa idéia e desenvolver uma visão mais clara do objetivo maior do produto é o que chamamos de visão do produto a visão geralmente é sucinta pode ser até mesmo uma única frase que sintetiza a essência do produto mas é muito importante porque nos ajuda a lembrar que no fundo um produto de software é sempre um meio para um fim maior que é o de atender alguma cidade das pessoas vamos imaginar que o nosso pior já têm uma ideia bastante

claro dessa visão do produto será que o próximo passo então já é finalmente criar as histórias de usuário no backlog para que os sprints possam começar na verdade não o nosso produto nem ainda vai ter muito trabalho pela frente primeiro ele vai precisar encontrar uma resposta para uma pergunta muito importante será que investir neste produto é algo que realmente vale a pena a gente sabe que construir qualquer software requerem algum tipo de investimento e alguém tem que tomar a decisão de investir neste produto que foi proposto será que o retorno que esse produto vai trazer

justifica este investimento e por que investir nele e não em algum outro produto não é fácil responder essas perguntas porque a gente está lidando aqui com vários tipos de incerteza pode existir por exemplo a incerteza técnica quando a gente tem dúvida se é mesmo possível desenvolver um produto com a tecnologia que a gente tem disponível a incerteza pode ser de negócio quando a gente não sabe ainda se o produto pode ser rentável se há espaço para ele no mercado quais são os competidores que a gente vai ter que enfrentar e se ele é mesmo capaz

de trazer um bom retorno sobre o investimento pode haver também a incerteza de custo é possível desenvolver o produto com o orçamento que a gente tem disponível então de prazo a gente consegue ter uma versão empregável até o nosso design e por último tem outro tipo de certeza que é muitas vezes menosprezada a incerteza de valor será que os usuários precisam mesmo de um produto como esse será que eles desejam esse produto a ponto de querer usá lo quando ele ficar pronto principalmente quando a gente pensa em um produto inovador é muito difícil prever como

que os usuários vão recebê lo na prática essas incertezas são muito grandes pode ser difícil decide entre investir ou não no desenvolvimento do produto nesses casos geralmente vale a pena reservar algum tempo para atividades experimentos que nos ajudem a reduzir essa incerteza a gente consegue usando algumas técnicas até bem simples e que não requerem tanto investimento obter rapidamente informações preciosas que vão nos ajudar a tomar essa decisão de maneira mais fundamentada a gente vai ter a oportunidade de conversar melhor sobre as técnicas mais adiante no próximo no final pode ser que a gente conclua por

exemplo que não vale a pena investir no produto ea gente descarta a ideia mas vamos pensar no caso que as informações levantadas aqui só reforçaram a ideia de que se trata mesmo de uma ótima oportunidade de negócio vamos imaginar também já existe um time de desenvolvimento preparado e disponível para dar início à construção do produto agora o nosso piloto ainda mais entusiasmado ele acha que o produto vai ser um sucesso mas antes de criar um blog com as histórias do usuário para poder dar início às sprints de desenvolvimento o nosso produto não vai ter que

pensar primeiro em qual a estratégia que ele vai usar para o desenvolvimento e para entrega do produto essa estratégia que vai permitir a ele tomar decisões do tipo em que data vai sair a primeira versão que funcionalidades essa versão tem que conter será que ao invés de a gente tentar pensar num produto perfeito não é mais interessante a gente deixa algumas funcionalidades de fora agora na primeira entrega em troca de termos uma entrega mais rápida a gente chega aqui então num ponto muito importante no desenvolvimento ágil a gente assume que uma das coisas mais importantes

no desenvolvimento de qualquer produto é o feedback que o feedback mais valioso que a gente pode ter é aquele que é gerado quando a gente entrega o produto aos usuários reais por mais que a gente tente antecipar o que vai ser a reação de seus usuários com o produto ou mesmo como uma funcionalidade específica nada pode dar pra gente mais informação preciosa sobre isso do que ver usuários reais usando software em contextos reais por isso ao invés de planejar uma única entrega no final do ciclo de desenvolvimento o que seria muito arriscado a gente trabalha

com entregas mais rápidas que chamamos de release para isso a gente define metas menores que possam ser alcançados em tempos mais curtos e planejarmos as entregas com base nessas metas como o feedback é uma prioridade do desenvolvimento ágil a gente está sempre buscando formas de tentar reduzir ao máximo o tempo de entrega uma tática muito usada é de procurar qualquer o menor conjunto possível de funcionalidades e buscar uma versão do produto que seja a menor possível mas que já seja capaz de trazer valor para os usuários por exemplo se a gente está falando de um

aplicativo móvel que vai gerar receita a partir de publicidade de anúncios a gente pode pensar de uma primeira entrega só com algumas funcionalidades mais elementares o mínimo do mínimo assim a gente consegue colocar uma primeira versão mais rapidamente no mercado e já começamos a ter feedback desses usuários sobre a experiência de uso do produto a entrega seguinte poderia incluir mais algumas funcionalidades importantes já usando o feedback desses usuários e só depois já com uma comunidade formada de usuários que acessam o produto regularmente a gente incluiria os anúncios publicitários agora é claro que esse produto aqui

eu sou um exemplo essa estratégia de entrega vai depender muito de cada produto e da visão de negócio que está por trás quando a gente tem essa estratégia de desenvolvimento definida com as entregas previstas e as metas de cada uma a gente pode agora pensar mais detalhadamente na primeira entrega esse planejamento da entrega é conhecido como release planning é o momento em que a gente pára para pensar em como organizar as sprints para alcançar da melhor forma possível a meta definida para a entrega agora sim a gente vai organizar o nosso backlog do produto a

gente vai inserir no backlog as histórias do usuário que correspondem às funcionalidades e recursos mais importantes para que o produto alcance a meta de negócio definida para sua primeira entrega quanto mais no topo do backlog mais prioritária é a história do usuário e essa prioridade é dada principalmente pela criticidade daquela história para alcance da meta definida para a entrega a priorização aqui é crítica porque é ela que vai guiar a ordem em que as histórias vão entrar nos sprints a história ou as histórias mais importante centro na primeira sprint as seguintes vão para a segunda

sprint e assim por diante no final de cada sprint o time gera como resultado uma versão do produto funcionando incluindo as histórias de usuários que foram desenvolvidas naquela sprint essas versões vão fazer presente outro feedback muito importante o pi ou quando ele vê o software funcionando e também quando ele mostra esse software para outros interessados no projeto ele pode aprender com eles e perceber que é importante fazer algum tipo de ajuste no backlog a idéia é usar esse feedback para pensar em formas melhores mais simples e mais eficazes de alcançar a meta naquele prazo tudo

isso vai se materializar por time naqueles ajustes que o produto a une vai fazendo continuamente no backlog nas histórias que ainda estão na fila pra esses pleitos seguintes isso vai acontecendo sucessivamente sprint a sprint até que a gente chega no momento de fazer a entrega de fato do produto o marco de entrega pode ser definido por uma data quando a gente trabalha com entregas de prazo fixo ou então quando o produto ao ver concluiu que as histórias já desenvolvidas até aquele momento já são suficientes para cumprir aquela meta da entrega é nesse momento que ocorre

o evento mais importante de todo esse ciclo é quando uma versão do produto é de fato entregue aos usuários no ambiente de produção e esse momento é importante por dois motivos o primeiro é que é nele que o produto começa a gerar valor é nele que os usuários vão começar de fato a usufruir do produto e dos seus benefícios e é nele também que a gente começa a ter algum retorno de negócios seja qual for o tipo de retorno de negócio que a gente vai buscando com o produto ao desenvolvê lo pode ser lucro com

vendas de licenças ou publicidade ou redução de custos de algum processo de negócio ou qualquer outro tipo de retorno é a partir da entrega aos usuários em ambiente de produção que esse retorno começa a ser gerado o outro motivo pelo qual esta entrega é importante é mais uma vez feedback e aqui a gente está falando do principal feedback de todo esse ciclo que é o feedback dado por usuários reais que estão usando o produto em contextos também reais esse feedback é muito valioso e pode nos guiar de várias formas ele pode por exemplo confirmar aquelas

premissas que a gente assume lá atrás quando a gente desenvolveu a visão do produto que a sua estratégia nesse caso o feedback indicando que a gente está indo no caminho certo mas pode mostrar também o contrário que algumas dessas premissas não eram verdadeiras e que a gente precisa fazer um ajuste esse feedback pode nos indicar por exemplo a necessidade a gente rever as nossas metas para as entregas seguintes porque surgiu o fato houve um aprendizado novo o que nos fez repensar a nossa visão de qual é a melhor estratégia para o produto daqui pra frente

isso também vai se materializar na escolha das histórias do usuário que vão ser incluídas no backlog do produto para as próximas entregas e na priorização dessas histórias em alguns casos o feedback dado pelos usuários reais pode nos mostrar coisas tão surpreendentes a ponto de nos fazer repensar até mesmo as nossas decisões mais estratégicas se o feedback foi muito negativo por exemplo ou então se os usuários simplesmente demonstraria que eles não se interessam por um produto como esse isso pode nos fazer repensar se vale a pena mesmo continuar investindo naquele produto ou então se o feedback

foi muito positivo se o produto foi um sucesso e começar a gerar um bom retorno e isso pode nos motivar a investir ainda mais daqui pra frente esse feedback do uso do produto pode também mostrar algumas coisas que a gente não conseguiria percebê lo atrás quando a gente ainda estava concedendo a visão do produto e pode também mostrar oportunidades idéias pra ele ou para outros produtos que podem ser também criados é daí que vem a importância de tentar reduzir esse ciclo ao menor tempo possível trabalhar sempre buscando começar a gerar valor rapidamente e adaptar rapidamente

a partir do feedback obtido nessa capacidade que mora a tal agilidade que a gente tanto fala esse ciclo não vai acontecer só no início quando o produto criado não durante toda a vida do produto a gente usa essa mesma estratégia pra a partir da observação dos usuários e de como eles usam o produto e identificar novas necessidades e oportunidades evoluir nossa visão e traçar a estratégia para quais histórias desenvolver nas próximas entregas o produto ao ler é o responsável direto pelas atividades que a gente tá mostrando aqui nesse ciclo a visão do produto a partir

das necessidades das pessoas passando pela análise de viabilidade a estratégia das entregas a definição das histórias validação das versões parciais e análise do feedback dos usuários sempre que uma versão entregue ea toda essa visão que ele procura refletir quando inclui uma história do usuário no microblog ou então quando ele cid que uma história é mais prioritário que é outra em outras palavras e respondendo aquela pergunta que a gente fez lá no início é desse ciclo de todo esse ciclo que nascem e que são priorizadas as histórias de usuário mas o pior não vai fazer isso

tudo sozinho um bom produto ao nerd vai envolver escutar com atenção o time de desenvolvimento representantes de usuários e qualquer outra parte interessada que seja importante para o sucesso do produto bom quando a gente pode ver o ciclo de produto é algo muito mais amplo que o ciclo de um sprint definido lá no dia do scream claro que um bom desempenho do time nos sprints é essencial porque são eles que constroem um produto de fato mas a gente não pode esquecer que existe toda essa visão de produto e de negócio por trás e que trabalhar

de forma alinhada com essa visão é algo essencial faz parte do trabalho do produto ao nervo buscar formas o tempo todo de garantir esse alinhamento para isso ele vai lembrar o time dessa visão do produto o tempo todo vai procurar refletir essa visão nas histórias nas prioridades que lhe dá para as histórias ele vai ajudar o time tudo que ele puder no dia a dia para que essa visão se concretize com sucesso de forma rápida e ágil bom é isso a visão de produto estranho que a história por trás das histórias nos próximos vídeos a

gente vai começar a explorar algumas ferramentas e técnicas bastante práticas que vão nos ajudar em cada uma das etapas desse ciclo que a gente acabou de percorrer muito obrigado e até lá [Música]