Como escolher Product Owners

Um dos papéis mais polêmicos do Scrum, o Product Owner, é fundamental para a máxima geração de valor para o cliente em um curto espaço de tempo, se adequadamente abordado pela organização. No entanto, é preciso, para garantir uma abordagem mais exitosa, compreender exatamente o que um PO precisa saber e fazer e em que contexto ele está inserido.

Se a escolha da pessoa que vai assumir tal papel se basear em preconceitos, é possível que o projeto caminhe para as mesmas frustrações de um contexto tradicional de gerência de projetos: hierárquico, imperativo e frustrante para cliente e time.

Ao observar o Scrum Guide, é possível perceber que ele não prescreve o rol de competências de um PO, muito embora deixe claro seu papel em um time Scrum.

O Product Owner deve buscar aprimorar o valor do produto e do trabalho do time através do gerenciamento do backlog do produto que considera, dentre outras coisas: definir os itens presentes no backlog, trabalhar para que todos tenham conhecimento sobre os itens do backlog e ordenar os itens de forma a facilitar o alcance dos objetivos do projeto.

O Product Owner pode realizar este trabalho acima, ou transferi-lo para o time de desenvolvimento. Entretanto, ele permanece responsável pelas tarefas.

O Product Owner é uma pessoa, não um comitê. Ele pode representar os desejos de um comitê no backlog de produto, mas aqueles que desejarem alterar a prioridade de um item no backlog precisam fazê-lo através do Product Owner.

Para o Product Owner ter sucesso, toda a organização precise respeitar suas decisões que devem ser visíveis no conteúdo e priorização do backlog. Não é permitido a qualquer outra pessoa dizer ao time de desenvolvimento para trabalhar de acordo com outro conjunto de requisites, e não é permitido ao time agir de acordo com o que qualquer outra pessoa diga.

Para o projeto, pode-se escolher como Product Owner alguém do próprio cliente ou alguém da organização contratada para gerar o produto.

A escolha de alguém do cliente (ou o próprio cliente, se for apenas uma pessoa) é adotada por muitas organizações. Nesse caso, ele definirá o produto a partir de suas necessidades e da sua organização. Naturalmente, essa escolha simplifica a gestão da participação do cliente no projeto e todo o processo de obtenção de feedback.

Em diversos cenários, no entanto, a escolha de alguém designado pelo cliente pode não ser a melhor opção, especialmente se essa pessoa não souber exercer esse papel.

Esse problema é mais comum do que parece. Um Product Owner do cliente pode simplesmente não ter as habilidades e conhecimentos necessários, que obrigatoriamente incluem o próprio Scrum e a gestão de produtos.

Embora talvez treinamentos sejam uma opção, é mais comum que o foco do cliente esteja quase que inteiramente nos problemas e muito pouco nas soluções, enquanto se espera que um Product Owner seja capaz de oferecer soluções de negócios a partir do produto que está definindo.

Além disso, mesmo que esse Product Owner possua os conhecimentos e habilidades, é possível que ele não possua a disponibilidade necessária para executar o seu papel, pois provavelmente estará envolvido em outras questões do seu próprio dia a dia de trabalho no cliente. O resultado seria um Product Owner que pouco interage com o time de desenvolvimento e que não consegue dedicar tempo para pensar no produto e refinar o product backlog.

Essa definição é fundamental para guiar uma correta identificação do perfil ideal de um Product Owner. A definição, ao contrário do que se observa disseminado na comunidade, está centrada mais na comunicação clara com o time de desenvolvimento do que no conhecimento do negócio.

O foco exclusivo no pretenso conhecimento do negócio pode acarretar em um distanciamento do que se espera do PO, principalmente em relação à clareza na comunicação e à priorização e ao detalhamento adequados do backlog. Isso nos indica um caminho controverso, mas racional, na análise do perfil, a começar pela proximidade do contexto.

Abismo entre sentir e declarar o problema

Um dos primeiros mitos que devem ser derrubados na busca pelo time ideal de Scrum é a da associação direta entre a sensação da dor e a habilidade em declarar um problema – ou elaborar uma hipótese que conduza à sua solução.

Da mesma forma que um paciente não será necessariamente a melhor pessoa para fazer um diagnóstico – quem dirá um prognóstico –, exceto quando ele é um médico, as pessoas envolvidas diretamente em um problema organizacional (ou oportunidade de negócio) também podem não ser. No plano ideal, os mais indicados podem não ser as pessoas envolvidas na situação – muito embora elas devam ser envolvidas na análise ou concepção.

Embora essa afirmação de “o cliente não sabe o que quer” seja combatida por alguns, ela encontra respaldo nas ciências sociais, se recorrermos à semiótica, neurolinguística ou gestão do conhecimento.

A saber, o mundo físico, real, palpável conecta-se ao mundo das ideias apenas pelo intermédio do indivíduo. Essa ideia é corroborada por Michael Polanyi, idealizador do conceito do polo tácito do conhecimento, quando afirma que toda articulação do saber é inerentemente pessoal.

Destarte, a formulação da relação semiótica estabelecida entre o cliente e o significado, por intermédio de uma rede de significantes construída pelo seu singular estado mental, será, certamente, transmitida com algum grau de perda ou distorção a um outro indivíduo, possuidor de outro singular estado mental – inclusive pela inclusão de outras variáveis como a proteção de zonas de domínio intelectual que julga seu diferencial competitivo.

Em outras palavras, o que ele sente não é exatamente o que ele precisa, o que quer não é exatamente o que sente, o que pede não é exatamente o que quer e o que o outro entende não é exatamente o que ele pede.

Tradicionalmente, há disciplinas e técnicas diferentes para lidar com situações distintas nessa formulação do problema (diagnóstico) e elaboração de hipóteses (prognósticos), conduzidas por perfis diferentes como Analistas de Processos e Analistas de Negócio.

Essas funções, no Scrum, em contraposição à visão tradicional, recaem sob a tutela do Product Owner, que tem a função exatamente de entender a dor sentida pelo cliente (representado por uma ou mais partes interessadas), transformá-la em uma declaração sucinta, objetiva, e desenvolver as hipóteses que conduzirão à geração de valor esperada pelo cliente.

Obviamente, essa não é uma atividade nem solitária, nem pontual. A todo momento o PO está em contato com o cliente para revisar suas dores, identificar as prioridades (onde mais dói) e ouvir as hipóteses que certamente o cliente também concebe, para enriquecer as linhas de atuação. Essa troca contínua é definida por alguns como pré-jogo, mas é importante lembrar que enquanto o time está em um ciclo (Sprint), o PO também está realizando um pré-jogo do ciclo subsequente.

Então, pensar continuamente em melhoria, formular problemas e hipóteses é uma atividade que mantém o PO bastante ocupado. Um cliente, envolto em operação e envolvido na dor que está sentindo, dificilmente terá a disponibilidade para agregar essas atividades a sua rotina.

Dentro do escopo da declaração do problema, tanto pelas competências quanto pela disponibilidade, e levando em consideração que algumas dessas técnicas, disciplinas ou perfis são até certa extensão disseminadas dentro do público de TI, torna-se razoável dizer que uma pessoa com essa formação seja mais afim do perfil de PO que alguém da área de negócio – salvo, claro, casos em que numa avaliação específica, identifique-se que uma determinada pessoa já domina aquelas competências e possui a capacidade de se desapegar da situação-problema para efetuar uma análise o mais objetiva possível, buscando constantemente o principal valor do PO.

A Tabela 1 apresenta um quadro progressivo de competências de um PO, exemplificando um rol de conhecimentos e habilidades necessárias para analisar a adequação do perfil. Este quadro será acrescido de outras competências ao longo deste artigo, a fim de ilustrar a complexidade de uma análise do perfil de competências de um PO tomando como base o que prescreve o Scrum Guide.

Já a Tabela 2 apresenta um quadro progressivo de técnicas, conceitos e arcabouços relevantes, nas competências identificadas. Da mesma forma que o quadro de competências, este sofrerá inclusões ao longo deste artigo, a fim de sugerir destaques no domínio das competências elencadas

Tabela 1. Quadro progressivo de competências de um Product Owner.

...

Competência	Relevância	Nível
Análise de Processos de Negócio
Análise de Causa e Efeito

Quer ler esse conteúdo completo? Tenha acesso completo