Analista de Negócios e Product Owner – É tudo a mesma coisa?

Opa!

Recentemente tenho me deparado no mercado com vários profissionais com os seguintes questionamentos: Marcelo, analista de negócios faz a mesma coisa que o product owner? É tudo a mesma coisa? O product owner é o analista de negócios em times ágeis? Para responder essas perguntas me acompanha na leitura abaixo para juntos chegarmos a uma conclusão.

Nesse artigo vou te mostrar os seguintes pontos:

1. A definição de cada papel
2. As responsabilidades
3. Existe analista de negócios em contextos ágeis?
4. Analista de negócios no SCRUM

Recomendo que você leia do início ao fim para ter um melhor entendimento do meu ponto de vista sobre o assunto.

A definição de cada papel

Primeiramente, vamos examinar a definição de cada um dos papéis de acordo a literatura oficial onde são definidos cada um dos papéis em questão. Veja abaixo o trecho extraído do SCRUM Guide sobre o papel PRODUCT OWNER.

 

“O Product Owner é responsável por maximizar o valor do produto e o trabalho do time de desenvolvimentoO Product Owner é a única pessoa responsável por gerenciar o backlog do produtoO Product Owner pode representar os desejos de um comitê no backlog do produto, mas aqueles que desejam alterar a prioridade de um item no Backlog devem recorrer ao Product Owner.”

Fonte: SCRUM Guidehttp://scrumguides.org/scrum-guide.html

 

Prestou atenção na palavra que mais aparece na definição desse papel? A palavra aqui em destaque é PRODUTO. E, de acordo com o SCRUM Guide, a missão do Product Owner é maximizar o valor do produto. Dessa forma podemos concluir que o escopo de atuação de um product owner é a criação/manutenção de produtos de software. Nesse contexto o product owner tem a responsabilidade de representar os diferentes interesses das partes interessadas da organização no que diz respeito ao produto de software.

Agora confira abaixo o trecho extraído do BABOK v3 sobre o papel ANALISTA DE NEGÓCIOS.

 

“Um analista de negócios é qualquer pessoa que executa as tarefas de análise de negócios descritas no Guia BABOK, independente do cargo, título ou papel. Analistas de negócios são responsáveis por descobrir, sintetizar e analisar informação de várias fontes dentro da empresa, incluindo ferramentas, processos, documentação e partes interessadas. O analista de negócios é responsável por elicitar as necessidades reais das partes interessadas – o que muitas vezes envolve investigar e esclarecer seus desejos expressos – para determinar os problemas e as causas principais.” – Fonte: Guia BABOK v3

 

Com essa definição do Guia BABOK é possível concluir que o escopo de atuação do analista de negócios é todo o negócio. O analista de negócios contribui para a melhoria organizacional em contextos de criação de produtos de software, melhoria de processos de negócios, estratégia do negócio e etc.
Bem, já deu pra perceber que o foco desses dois papéis são diferentes, porém complementares. O product owner tem como foco o PRODUTO e o analista de negócios tem como foco o NEGÓCIO como um todo.
O recado aqui é simples e direto: Análise de Negócios não se restringe a TI. Análise de Negócios, como o próprio nome já diz, refere-se ao negócio. E é claro que a TI usufrui dos benefícios de se fazer análise de negócios.
Mas ainda é cedo para concluirmos qualquer coisa. Precisamos agora examinar as responsabilidades de cada um dos papéis. Isso vai nos ajudar a entender melhor a missão e o escopo de atuação de cada um deles.

As Responsabilidades

Consultando o Guia SCRUM identificamos as seguintes responsabilidades do Product Owner:

Cuidar do backlog do produto;

Organizar os itens do backlog;

Otimizar o valor to trabalho do time;

Garantir que o backlog está visível, transparente e que mostra o trabalho a ser feito pelo time;

Garantir que o time entende os itens do backlog.

Está claro aqui que todo o trabalho do product owner gira em torno de manter o backlog do produto. Embora possa delegar todo esse trabalho ao time, a responsabilidade final é do product owner. Interessante dizer que o produto final do trabalho de um product owner é proporcionar ao time um entendimento correto do quê e quando precisa ser feito.

E o analista de negócios? Quais são suas responsabilidades? Segundo o Guia BABOK v3 são responsabilidades do analista de negócios:

Entender os problemas e oportunidades da empresa;

Analisar necessidades e soluções;

Desenvolver estratégias;

Direcionar a mudança;

Facilitar a colaboração entre as partes interessadas.

Aqui percebemos uma clara distinção do trabalho desses dois papéis. O product owner tem como responsabilidade o backlog do produto e de servir como porta-voz de várias partes interessadas referentes ao produto.

Já as atividades do analista de negócios revelam um trabalho mais voltado para a organização, embora possa contribuir bastante durante a construção do produto de software. Como o analista de negócios é um profundo conhecedor do negócio, quando no papel de product owner, utiliza seu conhecimento de negócio para ajudar o time a criar o produto que realmente vai atender as necessidades do cliente.

A missão do analista de negócios é a melhoria organizacional.

Portanto, faz sentido falar sobre do analista de negócios no contexto de criação de produtos de software? Vejamos.

Existe analista de negócios em contextos ágeis?

Para responder a essa pergunta tomemos como exemplo o framework Scrum. O Guia Scrum identifica 3 diferentes elementos: o time de desenvolvimento, o product owner e o Scrum Master. O Scrum Master é aquele que zela pelo processo e elimina impedimentos. O product owner é o responsável pelo backlog e por fazer o time compreender o que precisa ser feito. E o time de desenvolvimento é aquele que codifica, testa e entrega o produto.
Note que, em momento algum, o Guia SCRUM fala do analista de negócios. Curioso que este também não fala diretamente sobre testadores, DBA’s e tantos outros que obviamente fazem parte do time de desenvolvimento. Sendo assim, e seguindo a mesma lógica de raciocínio, nada impede que um analista de negócios faça parte do time de desenvolvimento e, como veremos a frente, atue como product owner ou até mesmo seja o Scrum Master. Bem, mas sobre isso eu já já eu falo como isso é possível.

Mas eis que ao examinar o Guia SCRUM o leitor vai se deparar com as duas seguintes e bombásticas declarações a respeito do time de desenvolvimento:

“O Scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.”

e

“Times de Desenvolvimento não contém sub-times dedicados a domínios específicos de conhecimento, tais como teste ou análise de negócios.”

E agora? Será que o Guia Scrum, quando afirma que não reconhece outro título a não ser o de Desenvolvedor, está dizendo que não há espaço para analistas de negócios? Não. Essa seria uma afirmação no mínimo falsa.

Um time não consiste apenas de desenvolvedores. Desenvolvedor aqui não é sinônimo de programador. Desenvolvedor é aquele que desenvolve algo, portanto, aqui no Scrum, olhamos para todos os elementos do time como desenvolvedores, e o analista de negócios é um deles.

Evita-se no Scrum sub-times dedicados a uma especialidade, ou seja, evitamos o time de testes, o time de DBAs e, porque não, evitamos o time de analistas de negócios.

O time como um todo é multifuncional, ou seja, reúne todas as competências para criar o produto de software. TODOS são desenvolvedores no sentido de serem responsáveis pela criação do produto e não apenas uma parte dele.

Agora que já vimos que é possível e, nada impede, a figura do analista de negócios em times Scrum, vejamos como este profissional pode atuar.

Analista de negócios no SCRUM

Para entender melhor a figura do analista de negócios em contextos ágeis vou tomar como exemplo o framework Scrum. O Guia Scrum identifica 3 diferentes elementos: o time de desenvolvimento, o product owner e o Scrum Master. O Scrum Master é aquele que zela pelo processo e elimina impedimentos. O product owner é o responsável pelo backlog e por fazer o time compreender o que precisa ser feito. E o time de desenvolvimento é aquele que codifica, testa e entrega o produto.

Vejamos então as possíveis configurações do analista de negócios em um ambiente que utiliza o framework Scrum.

A. Analista de negócios como Product Owner
B. Analista de negócios no Time de Desenvolvimento
C. Analista de negócios como SCRUM Master
D. Analista de negócios como hub entre o PO e o Time
E. Analista de negócios como hub entre o negócio e o Product Owner

Já que em momento algum o Guia SCRUM fala de analista de negócios, assim como não fala de testadores, por exemplo, nada impede que um analista faça parte do time de desenvolvimento. Pode ser que você nunca tenha visto a figura de um analista de negócios conforme descrito abaixo, mas o que eu vou te mostrar agora é fruto do meu trabalho de consultoria em análise de negócios para várias empresas e o que eu tenho visto sendo utilizado.

A. Analista de negócios como Product Owner

Para muitos talvez essa seja a configuração mais apropriada do analista de negócios no SCRUM – fazer o papel de Product Owner. O analista de negócios utiliza todo seu conhecimento de negócio para ajudar a construir o produto de software. Por ter habilidades de colaboração, o analista de negócios consegue se mexer mais facilmente na organização articulando os recursos necessários para a criação do produto de software que realmente atende as necessidades do cliente.

Embora o time SCRUM ganhe bastante com as ricas contribuições do analista de negócios durante a criação do produto de software, cabe lembrar que o escopo de atuação é a inteira organização. E não apenas na TI.

B. Analista de negócios no Time de Desenvolvimento

Lembra que o Guia SCRUM não cita detalhadamente cada profissional que trabalha no time SCRUM? Pois bem, dessa maneira podemos ter o analista de negócios como um dos componentes do time.

Embora se fale muito do time SCRUM trabalhar com metas de negócio compartilhadas, isso na prática não é algo tão simples de se fazer. Ter o analista lado a lado dos desenvolvedores “lembrando” o que é valor para o negócio e as pessoas nele é valioso.

Nesse cenário o analista de negócios atua como o grande articulador da visão. Gosto muito da atuação do analista de negócios diretamente no time pois esse vira um suporte do PO em várias outras tarefas como, por exemplo, a gestão do backlog.

À medida em que o time SCRUM avança em maturidade, o papel do analista de negócios se torna irrelevante, pois o time acaba desenvolvendo a competência em análise de negócios e não mais necessita de alguém para desempenhá-la exclusivamente.

C. Analista de negócios como SCRUM Master

Eu confesso que essa é uma das mais improváveis atuações do analista de negócios no SCRUM. Mas já tive a oportunidade de colocar um analista de negócios como SCRUM Master em um cenário onde boa parte dos impedimentos do time era sobre o entendimento das necessidades do negócio e onde o PO era uma figura pouco atuante.

Foi uma situação que estava emperrando o desempenho do time. Já que  analista de negócios conhecia muito bem o SCRUM, porque não? Os resultados foram incríveis, já que consegui remover as dúvidas sobre o negócio.

D. Analista de negócios como hub entre o PO e o Time

Essa eu considero uma das piores atuações do analista de negócios. Ele funciona como um proxy.

E a coisa começa a piorar quando você pára pra pensar que o ambiente vira a brincadeira do telefone sem fio. O PO fala o que quer, o analista de negócios comunica ao time. O time fala de volta, o analista de negócios fala com o PO e por aí vai…

E. Analista de negócios como hub entre o negócio e o Product Owner

O product owner, apesar de representar o negócio, nem sempre tem a experiência, maturidade e visão estratégica tão desejada. Nesse caso, funciona bem quando temos um analista de negócios do lado do negócio auxiliando e apoiando o PO. O time ganha com as contribuições mais assertivas do analista de negócios na criação do produto. Ele consegue trazer a visão do negócio mais apurada.

Experimentei esse cenário em 3 empresas com times de 10-15 analistas de negócios e o resultado foi o aceleramento do aprendizado a cerca do backlog.

Esse é só o início de uma longa jornada…

Até aqui já deu para entender que analista de negócios e product owner são papéis diferentes e complementares. Mas, tem outras considerações que gostaria de trazer para a mesa.

A crença de que em times ágeis não existe analista de negócios resulta em times com uma longa e demorada curva de aprendizado. O analista de negócios ajuda a encurtar essa curva de aprendizado.

PO é um papel desempenhado no framework Scrum. Enquanto que o analista de negócios é um papel dedicado a melhoria do negócio, podendo atuar nas mais variadas iniciativas da organização.

Análise de negócios não é só um papel, é uma competência que praticamente todos na organização deveriam desenvolver. Inclusive, times maduros (!!!!) de criação de produtos de software dispensam o papel de analista de negócios, mas dependem da competência para terem sucesso na entrega.

Esse artigo foi escrito como resultado da compilação de conhecimentos e experiência prática do meu dia a dia ajudando times de analistas de negócios em grandes empresas. Se ficou alguma dúvida não deixa de fazer seu comentário. Faço questão de responder todas as perguntas.

Um grande abraço.

0 comentários

Enviar um comentário