Como eu faço Reunião de Revisão (Review) - Product management

[@marialuizabuss9818]

Excelente, conteúdo! Obrigada, Diogo. Tudo 100% claro!

[@DiogoBeckerProductManagement]

Obrigado pelo feedback, Maria ! tamo junto!

[@Henriquepulga]

Muito massa Diogo, trazer exemplos práticos, isso com certeza é um diferencial do seu conteúdo. Ajudou bastante, valew!

[@DiogoBeckerProductManagement]

Obrigado pela mensagem e feedback!!A ideia é sempre trazer a vida real para aprender com exemplos. tamo junto!!!

[@DanielMartins-yi5tx]

Nossa incrível apenas conteúdo de extrema qualidade, esta me ajudando muito pois me foi tacado esse cargo em um projeto e to tendo que aprender a lidar e você tem me ajudado bastante a como me organizar e realizar as reuniões muito obrigado

[@DiogoBeckerProductManagement]

Olá, Daniel!! Blz? Obrigado pelo feedback!! Muito sucesso na jornada! Tamo junto

[@cms_conceição_123]

Dicas incríveis! Recentemente comecei como Product Owner Júnior e ainda me sinto um pouco perdida nesse rito, já que meu papel é apenas comentar sobre o que foi feito, enquanto o Tech Lead conduz a reunião. Diogo, você poderia fazer um vídeo explicando como realizar uma boa reunião de rollout? Parabéns pelo excelente conteúdo!

[@DiogoBeckerProductManagement]

Fico feliz que você tenha encontrado as dicas úteis! A carreira de Product Owner pode ser desafiadora, mas com prática você vai se sentir mais confiante. Vou colocar aqui na lista sua sugestão de vídeo sobre reuniões de rollout! :)

[@israelsilva4328]

Esses exemplos que você deu não está mais pro lado da retrospectiva? Na review não deveriam ser feitas discussões técnicas? Ex: Nas proximas US precisamos definir melhor o critério de aceitação... A documentação de API não está boa... Nesse Card não está claro a parte X e assim por diante Sei lá, as vezes to viajando.. mas o review e retrospectiva me parece bem próximas

[@DiogoBeckerProductManagement]

A retrospectiva é especificamente sobre como trabalhar melhor em equipe, focando em não necessariamente apenas na Sprint. A review é mais técnica e foca no que aconteceu na Sprint. Pode-se fazer uma seguida da outra sem problemas. A única questão que precisa cuidar é que na Review pode ser convidado outras pessoas para participar (como o cliente). Sobre os ex que vc deu, minha sugestão inicial seria que apareceriam mais nas: - Comentários sobre próximas descrições de US (retro) - Documentação (retro) - este card não está claro a pate X (review) Porém, o cerne aqui não pode ser esquecido!!! O objetivo final é que haja a interação, confiança e abertura para se falar estes tópicos. O que a gente tenta combater é o silêncio e medo de comentar o que não estamos satisfeitos. Por isso, pode acontecer de alguns assuntos virem não necessariamente na reunião específica. A intenção não é colocar em caixinhas, mas sim, criar entrosamento.

[@thgmarcon]

Pode comentar como conduz as atividades com diversas squads? Você participa de todas as reuniões com todas squads?

[@DiogoBeckerProductManagement]

Boa pergunta, Thiago. O que eu faço é organizar com os outros líderes como vamos fazer a divisão. (e esta divisão pode mudar após 3 ou 6 meses, ok?). Geralmente eu vou focar mais no squad que precisa mais, que está com gargalo na parte de Produto (geralmente é discovery ou é comunicação com stakeholders). O squad que está mais focado em desenvolvimento, deixo mais à cargo do Tech Manager. Assim, eu NÃO participo de todas as reunião, e alinho o que pode ter passado na 1on1 que faço semanalmente com o Tech Manager. Ficou mais claro?

[@pedroadmn]

Obrigado pelo vídeo. Como funciona o ciclo de desenvolvimento do time? Você menciona sprints de duas semanas, dai o time de desenvolvimento libera uma versão para o time de QA testar alguns dias antes do termino da sprint? ou as duas semanas é para desenvolvimento e libera algo para o time de QA no ultimo dia da sprint?

[@DiogoBeckerProductManagement]

Olá! em times ágeis raiz, não teria uma divisão entre QA e o resto da squad. As pessoas de QA ficam integradas então o processo é mais contínuo (em Loops). Então sempre que tiver uma feature concluída, ela é testada para validar, ajustes podem ser necessários, e segue o rollout. Em outras palavras, os testes são histórias de usuários normais a serem feitas durante a Sprint.

[@oifogs3287]

👏

[@alinenovaes6295]

As perguntas “quais foram os problemas…”, “E o que aprendemos” não seria na retrospectiva???? A review não seria pra revisar com os stakeholders e quais são os próximos passos?

[@DiogoBeckerProductManagement]

Olá, nas perguntas sobre Problemas e Aprendizados eu me refiro aqui especificamente sobre o desenvolvimento, código, pesquisas, etc. Um momento dedicado para o time revisar o que fez e compartilhar conhecimento entre si. Isso a cada 2 semanas. Esta forma de trabalhar foi uma adaptação que fizemos ao longo do tempo que proporcionou muito resultado para o time. Existe também a REVISÃO com o cliente externo (que é a que vc se refere). Porém, na minha experiência não tem exatamente uma frequência definida e tem uma proposta mais de atualização de status, e coleta de feedback do que foi feito. Então eu deixo ela "fora" do calendário fixo da gestão ágil. Na retro, vc pode usar as mesas perguntas, Mas o objetivo e foco é mais na relação de como trabalhar entre o time.