Product Owner no Scrum: a Alma do Negócio

O trabalho do Product Owner (PO) é possivelmente o menos compreendido e o mais subestimado entre os praticantes mais novos do Scrum. É ele quem transmite uma visão de negócios e prioriza os objetivos de forma a entregar valor. O PO é quem dá a direção e o propósito a um produto, envolvendo a equipe para a criação, desenvolvimento e evolução. Por isso está diretamente ligado ao sucesso (ou não) de um projeto de tecnologia.

Tendo isto em mente, o primeiro grande fator para o sucesso de um Product Owner é a coragem. Pode parecer clichê, mas não há como fugir disso. Como o PO é o responsável por equilibrar os vários interesses sobre determinado projeto, ele pode ficar tentado a atender apenas aos mais bem posicionados na hierarquia da empresa ou àqueles que mais diretamente se relacionam com ele. Sem coragem, o PO pode inconscientemente abrir mão da oportunidade de sucesso, parando de ouvir os clientes finais ou até mesmo idealizando um produto grande demais com resultados inferiores.

O PO e o cliente

Para gerenciar um produto, em particular um software, é preciso entender que mesmo um especialista precisa do feedback do usuário final. É o cliente, e apenas ele, quem poderá validar o que o há de inovador em um sistema. Aquilo que já é conhecido, ou que já foi medido anteriormente, pode até dar certo sem a validação do cliente, mas o que for o diferencial competitivo do seu produto, não. Fica no diferencial, em suas características únicas, o maior potencial de geração de valor; por isso, ouvir o cliente o tempo todo é fundamental.

A sintonia com o cliente é o que permite que o PO consiga capturar e transmitir a direção correta para os outros stakeholders e para a equipe de desenvolvimento. O contato entre a equipe e os stakeholders com o cliente final sempre será limitado, se comparado ao do PO. Por isso, o PO não deve se privar de "estar na rua", falando com seu público-alvo. Para manter essa sintonia viva e constante, precisa orientar a equipe na direção de entregas pequenas e frequentes. O produto deve ser criado de forma incremental e a cada passo as funcionalidades produzidas devem passar por um ciclo de feedback envolvendo os usuários finais. É importante observar que, quanto antes uma funcionalidade estiver em produção, sendo utilizada por usuários verdadeiros, melhor será o produto.

Qualidade relativa e qualidade absoluta

Outro ponto que pode desviar o caminho de sucesso dos gestores de um produto de software é a qualidade. Discussões intermináveis sobre este assunto são frequentes entre a equipe e o PO, com ou sem a participação de outros stakeholders. Tais discussões, além de improdutivas, podem crescer e se transformar em antagonismo, o que as tornam destrutivas para o produto, e também para a união e a motivação dos envolvidos.

O principal motivo de divergência reside em uma sutileza sobre o que é qualidade em um produto de software. Como em qualquer outro produto, qualidade é um conceito relativo. Os padrões de qualidade e os custos de se fazer um novo produto são variados e dependem de fatores como regulamentos, leis e o público-alvo. Para usar um exemplo do dia-a-dia, a qualidade exigida em um carro popular não é a mesma que a de um carro de luxo.

Podemos dizer que o PO entende qualidade como o nível de aceitação de seus clientes enquanto consumidores daquele novo produto. Este tipo de qualidade está, de certa forma, sob o controle do PO, e influencia suas decisões. Muitas vezes, a equipe não entende este parâmetro; apenas quer fazer o seu trabalho bem feito. Na verdade, é comum que a equipe leve em consideração outro tipo de medida: a qualidade no seu ciclo de desenvolvimento. Apenas para citar um exemplo, no caso de uma indústria automobilística, o PO estaria preocupado com a aceitação de determinado veículo pelo público, sendo que a equipe está mais comprometida com a qualidade do fluxo de produção.

Neste caso, ainda que as fábricas (ou unidades de fabricação) dos carros populares e luxuosos também tenham suas diferenças, elas são de fato bem mais parecidas do que a distância que existe entre os dois produtos finais: um carro pode ser desenhado para não dar defeito nunca, enquanto outro, se durar cinco anos, já estará ótimo para o fabricante. Para construir as fábricas destes carros é um pouco diferente, no entanto; ambas, é claro, foram feitas para durar e entregar vários modelos por muitos anos. Em software, não podemos abrir mão da qualidade, já que ela é determinante para a aceitação de um produto.

A qualidade do ciclo de desenvolvimento deve ser vista como absoluta, e é essa qualidade que a equipe luta para manter, enquanto muitas vezes os stakeholders não sabem do que a equipe está falando. A falta de qualidade no ciclo de produção gera um acúmulo de dívida técnica, que funciona como uma dívida de juros altos e compostos, ou seja, quanto mais postergamos o valor da dívida, maior será, e com crescimento exponencial.

A dívida técnica, quando acumulada, diminui a capacidade de mudar de direção e de se adaptar às necessidades dos negócios, que surgem em todo momento. Acaba com a agilidade. Em pouco tempo, a equipe começa a perder a velocidade de desenvolvimento e o tempo de vida útil do sistema se reduz, com crescentes custos de manutenção e evolução e capacidade de inovação seriamente limitada. É do interesse do PO manter a agilidade e a velocidade do seu projeto, então não criar dívida técnica é fundamental para todos.

Portanto, o PO deve conseguir explicar bem se a cada entrega estamos fazendo o carro popular ou o carro de luxo. E a equipe também deve deixar claro se o foco está no carro em si ou na fábrica que faz os carros.

PO, equipe e produto

A tentação de ir além do produto mínimo viável (MVP, na sigla em inglês) deve ser combatida a todo momento. É o óbvio: "o produto mínimo deve ser mínimo". O PO terá mais chance de sucesso se conhecer muito bem os seus clientes e, ao mesmo tempo conhecer muito bem o produto e a equipe responsável pela criação efetiva do software. Ser um PO significa conhecer em detalhes cada funcionalidade do produto que lidera e ser capaz de explicar aos stakeholders o que está acontecendo a qualquer tempo.

Com este entendimento nos detalhes e o feedback constante, o PO ganha embasamento para perceber novos e melhores caminhos, estabelecendo hipóteses que necessitam de um curto ciclo de entrega e feedback. Com uma boa equipe, o PO poderá validar tais inovações de forma rápida e eficaz.

Ao mesmo tempo, é necessário cuidado para não confundir o conhecimento dos detalhes com o microgerenciamento. A equipe de desenvolvimento tem capacidade e conhecimento técnicos para entregar o software pedido, e o PO se beneficia quando evita dizer à equipe como fazer o seu trabalho. O PO, em primeiro lugar, deve falar de negócios! Ele passa para a equipe suas necessidades não em termos técnicos, mas do ponto de vista do cliente, da empresa. Quando o PO permite à equipe com conhecimento técnico tomar as decisões que lhe cabem, não só a solução técnica é melhor; ele também poderá contar com uma equipe muito mais motivada e envolvida com o resultado do projeto. E assim, todos ganham.

Conhecer bem a equipe significa entender do que ela é capaz, especialmente saber traduzir as demandas de negócio para as técnicas e vice-versa . Quanto mais se estabelece este conhecimento mútuo, melhor é a comunicação e o PO se torna mais eficiente para planejar.

Deixe de empurrar funcionalidades

Com isso, chego ao ponto final: o planejamento. Planejar um produto de software é algo realmente complexo. É fundamental para o PO entender que, a partir do seu orçamento, ele não deve acreditar em um plano pré-determinado, com um conjunto de funcionalidades já estabelecidas. Ele gerencia seu orçamento semanalmente, mensalmente. Isso significa que, ao invés de uma lista de funcionalidades, o PO deve entregar objetivos de negócios.

Como e por meio de quais funcionalidades tais objetivos serão alcançados, não é conhecido no início do projeto. É apenas a execução do projeto que poderá responder. A visão prescritiva é o maior inimigo da inovação, de um produto de software e, consequentemente, do PO.

É preciso olhar além da imagem inicial que se tem do papel do PO. Pensar em uma lista de funcionalidades é menor que pensar em uma lista de objetivos. Aprovar uma funcionalidade é menor que o uso do seu cliente e um objetivo de negócio alcançado. Olhando com mais calma, o PO é mais que um papel, é a Alma do Negócio.

Fonte: INFOQ