Nunca fui uma PO de FDP!

  •  
  • 3
  •  
  • 265

Oi pessoal,

Não se preocupem, o título não tem nada ver com xingamento. FDP quer dizer Fatiar, Descartar e Priorizar.

A primeira vez que escutei esse termo foi no Agile Trends Belém com a Mila Orrico. Descobri o quanto é importante fatiar bem para que o time possa entregar valor o quanto antes para o cliente, descartar para evitar o desperdício de tempo, dinheiro e suor de todos envolvidos e priorizar de forma consciente, ou seja, com fatos, feedbacks ou métricas. Você deve estar se perguntando o que isso tem a ver com a minha curta experiência como Product Owner (PO). Tudo! Um momento de luz. Veja os fatos para comprovam isso.

  • Não tinha ideia qual era o verdadeiro propósito para resolver o problema definido.
  • Não deixava o time auxiliar/contribuir para a solução.
  • Não tinha autonomia para escrever histórias devido ao cenário do projeto. Percebam projeto e não produto. 
  • Não tinha feedback sobre as entregas realizadas.

Eita, Jana, então o que você realmente fazia enquanto atuava com esse papel? Colocava em templates “agéis” as demandas que chegavam, fazia suas análises, não tinha abertura para conversar sobre feedback com o cliente final do que estava sendo entregue e geria as horas do time ao invés de throughput (começamos a fazer isso somente no final do projeto). Enfim, era uma situação na qual aprendi muito sobre o que eu não gostaria de fazer e também percebi que a ausência de um propósito claro para um projeto, desmotiva o time em quase 100%.

Quando voltei as origens do Scrum ao ler o clássico Scrum: a arte de fazer o dobro do trabalho na metade do tempo de Jeff Sutherland, me ajudou na auto análise sobre o papel de Product Owner. Destaco a seguir os quatro pontos tratados no livro: 

Conhecer sobre o negócio.

o Product Owner precisa ter conhecimento sobre o campo. Isso significa duas coisas: ele deve entender o processo que a equipe está executando bem o suficiente para saber o que pode ser realizado e, tão importante quanto isso, o que não pode ser feito. Mas também tem de compreender o quê bem o suficiente para saber como traduzir o que pode ser concretizado em valor real e significativo.

Não entender sobre o negócio dificulta você repassar a real necessidade de uma história ou feature. Já conheci pessoas que não entendiam nada do assunto, mas estudaram e buscaram compreender para que tivesse empatia no processo. Além do mais, há técnicas de ideação de produto que auxiliam no descobrimento sobre o produto.

Ter autonomia.

Assim como a gerência não deve interferir na equipe, ele [PO] deve receber carta branca para tomar decisões sobre qual será a visão do produto e o que precisa ser feito para chegar lá.

Como dono do produto, se faz necessário ter o empoderamento para tomar decisões. Às vezes, não é tão simples, requer um processo de conquista dos stakeholders, principalmente para os que estão iniciando no contexto ágil. Cuidado para não se tornar refém nesse processo.

Disponível para o time.

(…) para explicar o que precisa ser feito e por quê. Ele é, em última instância, responsável pelo backlog, assim é necessário que haja um diálogo constante com a equipe. Muitas vezes a experiência do grupo indicia as decisões que o Product Owner precisa tomar. O Product Owner tem de ser confiável, coerente e disponível.

Por mais que você tenha os domínios anteriores, ser um PO estilo mestre dos magos, não ajuda em nada. Lembre-se do princípio de Comunicação cara a cara. O conhecimento colaborativo pode trazer excelentes contribuições e percepções sobre um mesmo problema.

Responsável pelo valor.

O essencial é decidir qual é a medida de valor e dar ao Product Owner a responsabilidade de entregá-lo em quantidades cada vez maiores.

Para saber se estamos agregando valor, precisamos de um propósito e conhecer o estado atual para podermos identificar o quanto queremos evoluir em um contexto. Conforme cada entrega, saber se estamos atingindo esse propósito. Para isso, as métricas servem como um meio para conhecermos essa evolução, permitindo dar respostas mais rápidas a partir de feedback.

Esses quatro pontos são importantes para que um PO seja bom de FDP. Exemplo, como sei se a fatia ,X definida por mim, é uma boa fatia se não tenho nem certeza do propósito do produto?  Se só apresento a fatia X para o time sem ter a possibilidade de troca de informações, como tenho certeza que o time compreendeu? E se eu não tivesse a autonomia de descartar algo que não agrega para o projeto devido a gerência do projeto? Ou seja, uma disfunção alimentado a outra.

Por fim, a partir de hoje, retiro do meu currículo que fui Product Owner. Na verdade, estou fazendo melhor!!! A partir de agora, posso dizer que fui uma PO de mentirinha.

E aí, pessoal, deixo a pergunta: você é um(a) PO de verdade?

Abraço

Showing 2 comments
  • Mila Orrico
    Responder

    Muito assertivo o texto Jana! Quanto a sigla FDP (fatiar, descartar e prioriza), a primeira vez que escutei ela foi no treinamento CSPO da K21, foi um termo criado pelo Rodrigo de Toledo, que está muito conectado com tudo isso que você comentou. E esse livro do Jeff é sucesso!

    • Jana Pereira
      Responder

      CFC comentou isso essa semana. Obrigada pelo esclarecimento e feedback! Abraço

Leave a Comment