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.
