04 . 04 . 2022

O Papel do Product Owner Wizzer no Desenvolvimento dos Produtos Digitais

Meu nome é Debora Santos, Especialista em Práticas Ágeis da Wiz Soluções. Minha missão é garantir a disseminação e adesão aos frameworks Ágeis adotados no Conglomerado Wiz, tendo como premissa que o principal ingrediente são as pessoas, ou seja, os wizzers. Aqui, vou explanar sobre como o PO (Product Owner) atua para garantir a geração de valor para Negócios e Usuários através de soluções digitais. Para ter uma visão geral do processo de desenvolvimento, sugiro a leitura do artigo “Como criamos e desenvolvemos produtos digitais na Wiz”.

O PO tem em seu DNA o propósito de gerar valor a partir de uma visão, que ele traduz em uma missão ao DevTeam! Para fazer acontecer, adota as seguintes ações em seu “modus operandis”:

1. Backlog Geral:

Aqui, devem constar todos os itens que reflitam as necessidades do negócio e também do usuário.

Não foi fornecido texto alternativo para esta imagem

O backlog é alimentado por diversas fontes, a saber:

  • Stakeholders: Os itens são obtidos através do contato com os próprios stakeholders e do planejamento estratégico anual da respectiva Unidade de Negócio. Nesse contexto, os itens normalmente são atrelados a inclusão/otimização de processos para redução de custos operacionais ou para desenvolvimento de novos processos ou produtos digitais que alavanquem seus negócios;
  • Usuário final: Através de técnicas utilizadas nos processos de UX, saiba mais, clicando aqui.

2. Gestão do UpStream

Uma vez que o PO (Product Owner) já tem seu backlog geral bem alimentado, ele inicia o processo do UpStream, seguindo as Macro Etapas abaixo:

2.1 Priorização:

1° Momento– Com a Squad: Aqui a gente parte do pressuposto que o Product Owner, que tem o dia-dia super próximo dos Stakeholders já tem uma perspectiva de quais seriam as prioridades para o negócio, já levando os itens que provavelmente deverão ser priorizados.

Para fins de priorização utilizamos os seguintes metadados:

  • Esforço: Escala Fibonacci (2, 3, 5, 8, 13, 21)
  • Business Value/Valor para o Negócio (Escala: 1 a 5)
  • Risco Negocial (Escala: 1 a 5)
  • Risco Técnico (Escala: 1 a 5)

Depois de Coletados todos os metadados, identificados os principais riscos, a Squad, de maneira coletiva, define o Plano de Release/Roadmap a ser apresentado como proposta para o trimestre seguinte. No próximo artigo, conto com maior riqueza de detalhes como essas estimativas são feitas. Os metadados são coletados em uma cerimônia que chamamos de “Estimativa de Release/Roadmap”.

2° Momento- Com os Stakeholders/Demandantes: Com a proposta de roadmap em mãos, o PO apresenta a sugestão aos Stakeholders/Demandantes.

Importante: É natural que ocorram pedidos de acréscimos de itens e para essa situação, o PO já com os metadados em mãos, consegue apresentar um contexto baseado em dados, assim as priorizações acontecem de maneira conjunta, tendo como resultado a retirada de uns itens para inclusão de outros, sempre considerando as proporções suportadas pelo DevTeam.

2.2 Refinamentos:

É aqui que a aspiração começa a ganhar forma, o que é “quadrado” começa a “arredondar”.

  • Refinamento Negocial: Nessa etapa, o PO, junto a Unidade de Negócio, deve mapear os processos (fluxo ideal e de exceção), regras de negócios e expectativas atreladas a entrega para o respectivo item. Vale salientar que é uma das etapas mais exigentes em relação a dinâmica de trabalho do PO e Unidade de Negócio e a qualidade dessa dinâmica diz muito sobre os resultados obtidos nas próximas etapas.
  • Refinamento Técnico: Já com o item detalhado e com as expectativas mapeadas, este é o momento que o PO reúne os perfis do DevTeam para definir o “Como”, ou seja, todas as ações necessárias para viabilizar a entrega. Nesta etapa, o risco técnico e estimativa Fibonacci também podem ser reavaliados. Feito o processo, tendo os riscos endereçados, e o item estando apto para inico, o mesmo se habilita para passar para o DownStream, ou seja, para o desenvolvimento. 

2.2 Refinamentos:

É aqui que a aspiração começa a ganhar forma, o que é “quadrado” começa a “arredondar”.

  • Refinamento Negocial: Nessa etapa, o PO, junto a Unidade de Negócio, deve mapear os processos (fluxo ideal e de exceção), regras de negócios e expectativas atreladas a entrega para o respectivo item. Vale salientar que é uma das etapas mais exigentes em relação a dinâmica de trabalho do PO e Unidade de Negócio e a qualidade dessa dinâmica diz muito sobre os resultados obtidos nas próximas etapas.
  • Refinamento Técnico: Já com o item detalhado e com as expectativas mapeadas, este é o momento que o PO reúne os perfis do DevTeam para definir o “Como”, ou seja, todas as ações necessárias para viabilizar a entrega. Nesta etapa, o risco técnico e estimativa Fibonacci também podem ser reavaliados. Feito o processo, tendo os riscos endereçados, e o item estando apto para inico, o mesmo se habilita para passar para o DownStream, ou seja, para o desenvolvimento. 

Você deve estar se perguntando como fica a solução depois da disponibilização ao usuário, né? Vamos lá!

Depois da entrega, o PO acompanha a mesma através de alguns mecanismos, veja alguns deles:

  • Resultados financeiros gerados, se for o caso.
  • Feedbacks de stakeholders/demandantes e Usuários: são obtidos no dia a dia ou através de ações estruturadas e conduzidas pelos Designers.
  • Relatórios obtidos através de ferramentas, por exemplo: Hotjar, Google Analytics, APP Insights.

O que você acabou de ler é um resumo de como os Product Owners da Wiz buscam atuar no dia a dia, obviamente que na prática vai muito além disso, sempre tendo como objetivo conciliar as aspirações das Unidades de Negócios em itens compreensíveis paro DevTeam, com o intuito de entregar soluções digitais que gerem valor não só para o negócio, como também para os usuários.

Finalizo dizendo que temos revisitado os processos, fluxos e cadeias de valor com o objetivo de experimentar e aprender novas formas que otimizem ainda mais o framework. Essa turma pratica ativamente as atitudes “Foque em resultados ” e “Faça em time”, e elas por si só moldam o modus operandis.

Não foi fornecido texto alternativo para esta imagem

Debora Santos – Especialista em Métodos Ágeis/Agile Coach