P.O é Time?

  • 71
  •  
  •  
  •  

Atuo como Product Owner (P.O) fazem três anos efetivamente. Antes disso fui P.O de mentirinha e também trabalhei com gerenciamento de projetos no modelo waterfall por um bom tempo. Quando me deparei com o ágil foi amor à primeira vista!!! Tudo que eu lia a respeito me levava ao questionamento: Como não descobri isso antes! Hoje sou uma Product Owner apaixonada pelo meu trabalho, estou buscando aprender continuamente e sempre que possível compartilho meus aprendizados com colegas de profissão.

Foi, em um destes momentos de compartilhar experiências, quando me deparei com diversos colegas perguntando qual abordagem utilizar para ter uma boa integração com o time de desenvolvimento.

O Scrum Guide diz:

O Time Scrum é composto pelo Product Owner, o Time de Desenvolvimento e o Scrum Master.

Sabemos que o P.O faz parte do time e também que é a voz do negócio na equipe.  Mas como se sentir efetivamente parte deste time?

Eu ouso compara-lo com o patinho feio do time. Enquanto o time está falando em configurações do Mongo, Apache e um complexo tecniquês, o P.O tenta encontrar uma relação que faça sentido entre o mongo e uma tribo indígena.

A primeira vez que me perguntaram como eu havia construído a sinergia com o time, qual técnica eu utilizava, confesso que fiquei confusa e respondi:

Seguimos as boas práticas, estamos embasados nos direcionamentos.

Realmente, sem as boas práticas, direcionamento, objetivos e metas claras, nada daria certo. Mas, seria apenas isso?  Trabalhávamos duro para melhorar continuamente, errávamos continuamente também e passei a me questionar o que as pessoas viam que eu não via, como esta sinergia fluía e transcendia até as entregas?

Um dia em uma retrospectiva depois de um ano de trabalho árduo, o time disse algo que jamais parei para pensar. Eles colocaram como ponto positivo a confiança do P.O e da área de negócio no time e, eles fizeram questão de citar alguns exemplos como:

  • “Quando falamos que precisaríamos atuar em tal débito técnico o P.O entendeu, nos apoiou e consequentemente a área de negócio”;
  • “Eles confiam em nossas estimativas”;
  • “Não gostamos de errar, mas não temos medo de errar”;
  • “Eles nos ouvem e participamos ativamente da construção do produto”;
  • “Nos sentimos como uma extensão da área de negócio”;

Mas, como construir este tipo de relação? Bom, quero reforçar alguns pontos que para mim, como P.O e também como pessoa, fazem toda a diferença:

Ouça com ATENÇÃO!

Procure entender o time, os problemas técnicos, se importe, engaje e promova a participação do time em tudo que for possível. Não interrompa insights, as ideias absurdas podem ser a solução de muitos problemas. O time sugeriu uma alteração de escopo? Escute atentamente. Já sai de refinamentos direto para sala do stakeholder dizendo:

Não sei como não pensamos nisso antes, vamos rever este escopo?

Por vezes estamos tão centrados em nossos produtos que esquecemos de inovar e o que é um produto sem inovação? Contribua para que o time te estimule a olhar para fora da sua caixinha!  

Se Envolva!  

O primeiro item do manifesto ágil: Indivíduos e interações mais que processos e ferramentas, ou seja, envolva-se com o time e com as pessoas.

Envolvimento não tem a ver com afinidade e sim com participação, sempre que possível esteja presente nas cerimônias. O Scrum Master irá promover uma dinâmica com o time ou não fez uma ação que você esperava? Sem problemas!! Procure colaborar, sugerindo ideias ou melhorias para que o time alcance o objetivo esperado daquela cerimônia.

Ações de team building agregam valor sempre!

Seja disponível!

O time precisa de você! Acredite, o time precisa mais de você do que o seu gestor. Caso tenha dificuldades de conseguir tempo para o time, converse com seu gestor. Um P.O não disponível pode impactar diretamente na qualidade de entrega de um produto.

Imagine se o time tiver uma dúvida sobre o produto durante o desenvolvimento e não conseguir falar com o P.O para esclarece-la? Pode acontecer de ser identificado na review a necessidade de um ajuste. Pense na sensação de frustração do time. E se a correção for algo demorado? Se precisar de mais uma semana de desenvolvimento para realizar a correção? Se aumentar o custo de desenvolvimento? Se aquela dúvida fosse esclarecida imediatamente este contratempo poderia não existir ou seja, esteja lá quando eles precisarem de você!

Confie!

Para que o time confie em você, você precisa confiar no time! Já ouvi muito a frase:

Esse time pensa que me engana!  

Um dos valores do Scrum é o comprometimento, o time todo tem o mesmo objetivo. Se somos um time comprometido, precisamos confiar uns nos outros.  

O P.O com um viés mais técnico tende a debuggar o código na review, se apegando aos detalhes que competem a área técnica e a verdade é que se o time quiser te enganar ele irá e, o pior, eles podem ter a sensação de que você quer achar pequenos erros para cobrá-los.

O P.O não é chefe e não valida se o time fez certo ou não. Ele valida o produto! Se você tem um conhecimento técnico e acredita que pode contribuir com o time, sugira antes do desenvolvimento iniciar, saiba também que eles podem não concordar com a sua sugestão e caso isso te incomoda absurdamente, sugiro abandonar a posição de P.O e buscar ser um líder técnico.

Outra coisa importante sobre confiança é: se o time falar que não dá para fazer no prazo ou que não dá para fazer isso, por favor, acredite! Tente avaliar sob a ótica do desenvolvimento se é algo novo a ser feito?  É um ambiente instável? Analisem, como time, todos os fatores e, principalmente, as métricas (CFD, throughout, cycle time, lead time) se os números apontarem que é possível fazer sim dentro do prazo desejado, explique seu ponto de vista afinal contra números não há argumentos, mas por favor, não se comprometa com entregas fantasiosas ou prazos desumanos.

Se você estiver em uma situação sem muitas alternativas, por exemplo um prazo extremamente apertado para uma entrega sob o risco de perder o time to market ou algo do tipo, peça ajuda para o time e, em conjunto, busquem uma solução.

Talvez a entrega possa ser fatiada, talvez cheguem a conclusão que é possível entregar um MVP nesse prazo. Esse é um problema de todos, logo a solução deve ser encontrada em conjunto. Não acione o time apenas informando que terão de fazer hora extra. Você é time, preocupe-se com o bem-estar do todo!

Seja Time!

Vocês conversaram e, mesmo fazendo hora extra e o time dando o sangue pela entrega, ela não irá acontecer dentro do prazo estimado. (Vamos falar do dilema estimativa e prazo de entrega em outro post)

É seu papel levar a notícia para o stakeholder, re-alinhar as expectativas e, por favor, não culpe o time por isso. Imprevistos acontecem.

Não denigra a imagem do time, pois você faz parte dele. Apoie o Scrum Master no que for necessário e blindem o time!  Se há uma queixa da área de negócio trate-a na retrospectiva.

O time não está performando? A previsibilidade do time está ruim? Não temos cadência? Espero que depois desta leitura, você entenda que o papel do Product Owner impacta diretamente nessas métricas. Uma peça desajustada e a máquina chamada time para de funcionar.

Foi assim que me senti finalmente parte do time, mesmo ainda não falando muito bem a língua deles e nem eles a minha, aprendemos a nos respeitar e cooperar. Ficamos juntos por mais de um ano e chorei alguns litros quando foi o momento de partir, mas os muitos aprendizados levarei para sempre comigo. <3

E aí galera, como é esta relação no dia-a-dia de vocês? Compartilhem aí nos comentários! 🙂

Showing 15 comments
  • André Luis Gomes
    Responder

    Muito bom

  • Uri
    Responder

    Isso aí Pri! Foi um prazer enrome!

  • Bueno
    Responder

    Sensacional Pri, foi excelente trabalhar com você! Obrigado.

  • Pavanelli
    Responder

    Parabéns! E agradeço a oportunidade de fazer parte desta jornada… foram tempos de aprendizagem e parceria!

  • João
    Responder

    Muito bom seu artigo, parabéns!

    Tenho uma dúvida: Você acha que o PO pode ser responsável por elaborar especificações do tipo Regras de Negócios e/ou Regras de Tela (UI)?

    • Bruno
      Responder

      Olá João ele elabora sim, mas nada que você não possa revisar as regras de negócio com o time, se caso você tenha um UX no seu time recomendo revisar as regras de UI com ele, caso contrário, revise com o próprio cliente. Abs

    • Pri Leite
      Responder

      Oi João, então sim como P.O eu busco definir as regras de negócio com os stakeholders mas sempre divido com o time e nada deveria ser cravado na pedra (mas nem sempre é assim né?).Caso a gente identifique que uma regra não esta legal montamos uma nova proposta e levo ao stakeholder.
      Se a empresa atuar com uma área de UX/UI eles participam desde a reunião inicial com o stakeholder até o refinamento com o time.

  • Bruna Sayuri
    Responder

    Adorei !

  • Jessika Milhomsm
    Responder

    Fantastico, Pri! Obrigada por compartilhar tua experiencia!

  • Nadja
    Responder

    Perfeito, Pri!!!
    É sobre confiança, apoio mútuo, colaboração…
    “Indivíduos e interações mais que processos e ferramentas”…

  • aline
    Responder

    Oi Priscila, Parabéns pelo texto! Você pode me tirar uma dúvida? Na sua empresa tem a figura do PM(Product Manager) ? Se sim, qual a relação de PO e PM?

    • Priscila
      Responder

      Oi Aline, na empresa que estou atualmente o papel do P.M existe e para que nossa relação seja produtiva sempre o coloco na mesma “caixinha” do stakeholder, afinal ele normalmente centraliza os desejos das áreas de negócios/clientes.
      Temos o mesmo objetivo final que é ter o produto mais desejado e útil para os nossos clientes então saber se comunicar, mediar as expectativas e se posicionar como um P.O com autonomia sobre o product backlog mas sempre colaborativo fazem toda a diferença.

  • Érica
    Responder

    Parabéns pelo artigo Pri!
    Continue compartilhando suas experiências. 🙂

  • Jadilson Oliveira
    Responder

    Parabéns pelo artigo Pri!
    Muito bom vivenciar e apoiar nesta sinergia incrível. Eita times bons, ownerships, que entregam e participam! Abcs

  • Karynne Marinho
    Responder

    Acabei de nascer na metodologia Ágil (5 meses). Ainda estou em estágio na área mas me apaixono a cada dia que chego ao trabalho. Tudo é muito novo pra mim e esse artigo somou bastante aos meus conhecimentos.
    Parabéns pelo artigo! Excelente!

Leave a Comment