Qual é a diferença entre o Product Owner e o Business Analyst?

Esta é certamente uma das primeiras perguntas que surgem quando começamos a estudar o Scrum.

Há alguns anos venho me dedicando a isto e devo dizer que levei um bom tempo para encontrar a minha resposta.

Poeticamente eu diria que: O Product Owner é a ave que voa mais alto que o Business Analyst.

Enquanto o Business Analyst recebe a informação de que é necessário especificar uma funcionalidade o Product Owner recebe uma visão de um produto e é o responsável por identificar, entre tantas solicitações, o que precisa ser feito para atingi-la.

Abaixo listo algumas características que diferenciam o Product Owner do Business Analyst.

1 – Entender o negócio para decidir com clareza aquilo que deve e não deve ser feito

Enquanto o Business Analyst fica focado em detalhar o que lhe foi pedido para que posteriormente a especificação seja enviada à equipe de desenvolvimento, o Product Owner ao receber uma solicitação deve avaliar se ela deve ou não ser desenvolvida.

Por exemplo:

Imagine-se como o Business Analyst de uma plataforma de E-Commerce e o seu gerente ou diretor lhe faz a seguinte solicitação: Precisamos de uma funcionalidade para quando o cliente colocar o produto A no carrinho, que o produto B também seja colocado.

Neste momento você começará a identificar todas as telas, fluxos, riscos para o negócio, limitações que esta funcionalidade pode trazer, fazer o documento de especificação e entrega-lo à equipe de desenvolvimento.

Imagine-se agora recebendo esta mesma solicitação porém, desta vez você é o Product Owner desta plataforma que está sendo utilizada por mais de 150 clientes diferentes.

Suponha que esta funcionalidade seja de fato importante para apenas 3% dos teus clientes e você, como um bom Product Owner, sabe que todo novo código inserido ao produto demandará algum tempo de desenvolvimento, de testes e aumentará seu TCO (Total Cost of Ownership) e, acima de tudo, aquela funcionalidade não tem qualquer relação com a visão do produto.

Neste momento o Product Owner, antes mesmo de escrever a primeira história de usuário, deve julgar – preferencialmente com dados – se faz sentido ou não aquele desenvolvimento e, caso não faça, explicar o motivo pelo qual a solicitação não será atendida.

2 – Decidir, dentro daquilo que será desenvolvido, o que deve ser desenvolvido e em qual ordem.

Em geral, tudo aquilo que foi especificado pelo Business Analyst é enviado para a equipe de desenvolvimento. Os desenvolvedores leem o material gerado e criam as tarefas de desenvolvimento que eles entendem necessárias para atender a 100% da especificação.

O Product Owner divide a funcionalidade em histórias de usuários, analisa cada uma delas e as prioriza de acordo com o valor para o negócio. Geralmente o Princípio de Pareto é utilizado nesta fase, ou seja, determinar quais são os 20% de histórias que precisam ser desenvolvidos para representar 80% daquilo que se pretende com a nova funcionalidade.

O Product Owner sabe que nem tudo precisará ser desenvolvido para que a funcionalidade seja testada e melhorada ou descartada. E é justamente “as histórias que realmente importam” que devem ser enviadas à equipe de desenvolvimento.

3 – Ter excelente relacionamento com os desenvolvedores.

É muito comum que o Business Analyst seja alguém que prepare documentações e envie para equipes que muitas vezes ele nem conhece as pessoas que as compõem. Claro que isso não é uma regra mas geralmente o contato entre eles ocorre somente para esclarecimento de dúvidas da documentação, quando ocorre.

O Product Owner é um dos membros do Scrum Team. Ele é o responsável por transmitir segurança ao time de desenvolvimento, ter bom relacionamento com todas as pessoas e ser capaz de comunicar com clareza as decisões e as alterações de decisões, para todos as pessoas envolvidas com o produto. Ele deve ser o ponto de apoio para todo e qualquer problema. É principalmente nele em quem a equipe de desenvolvimento deve confiar. Se não houver esta confiança, não há time e por consequência, não há Scrum.

Claro que o Product Owner também deve ter um bom relacionamento com os stakeholders mas isso também é necessário ao Business Analyst.

4 – Saber falar “Não!”

Já falei sobre isso anteriormente mas esta é uma das habilidades que, para mim, mais diferenciam o Business Analyst do Product Owner.

Em geral os Business Analyst não dizem “Não”. Eles até podem, em casos específicos, dizerem não para algumas coisas específicas de uma funcionalidade, mas ele nunca dirá que não vai especificar o que foi solicitado.

O Product Owner deve saber falar NÃO e deve usar esta palavra muitas vezes durante os seus dias de trabalho.

Lembre-se, o Product Owner recebe informações (pedidos) de inúmeras fontes porém a capacidade de entrega das equipes de desenvolvimento é sempre menor do que a criatividade das pessoas que estão ao redor do produto. Por isto ele deve saber filtrar o que precisa ou não ser desenvolvido – sempre tendo como referência a visão do produto – e o quanto é realmente necessário desenvolver.

Somente assim ele conseguirá atingir o principal objetivo desta função que é “entregar o que tem maior valor para o negócio o mais rapidamente possível”.

Se não souber falar NÃO, certamente o Product Owner falhará.

Acredito que estes são os principais pontos que diferenciam estas duas

importantes funções das diferentes metodologias/framework de desenvolvimento de software.

Por último gostaria de deixar uma pergunta e um vídeo (em Inglês).

O Product Owner pode mudar a visão de um produto?

Eu aconselho a ver a apresentação toda mas do minuto 16 ao 21, Marty Cagan conta um pouco da trajetória da Kate Arnold na Netflix e, ao meu ver, de alguma forma, nos dá uma pista da resposta.

https://www.mindtheproduct.com/2016/10/behind-every-great-product-marty-cagan/

Espero que tenham gostado e caso tenha uma opinião contrária, um comentário ou algo a adicionar, fique a vontade em escrever seu comentário abaixo.

Todas as opiniões são bem vindas e respeitadas.

Achou interessante? Tem dúvidas ou discorda de algo?
Me adicione ao  e vamos conversar.