BT

Product Owner no Scrum: a Alma do Negócio

Postado por Victor Oliveira em 26 Mar 2012 |

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.


Sobre o autor

Victor Oliveira (@v_oliv) é Trainer pela Scrum.org, Conselheiro da Iniciativa Lean BizAgility e Sócio-fundador da Concrete Solutions, consultoria global que desenvolve negócios digitais há mais de dez anos e em cerca de 40 países.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Verdade ou mito: um PO substitui um AN! by Alexandre Queiroz

Victor, boa tarde! O IIBA lançou um draft da extensão do BABoK para cobrir as atividades de AN em um desenvolvimento sob a ótica Ágil. Ainda está bem confuso a aplicação prática desse papel. Existem termos do tipo "...em alguns projetos, um AN é desnecessário.", "...em ambientes complexos, um AN pode ser um facilitador.", "...o AN pode atuar como o PO...". Diante desse reconhecimento da própria comunidade de AN, será que já podemos assumir que será de vital importância que um PO tenha skills de um AN para ser um PO completo e tenha uma visibilidade mais clara frente ao cliente? Assim, podemos também acabar com o impressão de que a função de PO é subestimada? Se um PO realmente for "A Alma do Negócio" podemos declarar o fim do AN e o surgimento de um novo papel: um BPO (Business Product Owner)? Um AN dentro de uma organização deve ter um papel bem distindo do um PO, e assim, um PO continuaria apenas com a "função" de entender o negócio/necessidade e fazer o software acontecer da melhor forma possível. Será que a verdadeira "Alma do Negócio" dificilmente deixará de ser o AN, apesar de não ser citado em nenhum momento no seu post, e mesmo contrariando as novas definições do IIBA? Responde essa... rsrsrs!

Um grande abraço!

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

1 Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT