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