Diferenças entre um Product Owner e um Analista de Negócios x Analista de Sistemas

Jogo dos 7 erros

Antes de falar sobre as diferenças entre um Product Owner e um Analista de Negócios, vamos olhar para a  imagem abaixo. Ela possui diversos problemas:

1. Analista de Negócios como Proxy de PO. Equipes de desenvolvimento de software não devem ter um profissional no papel de Product Owner sem empoderamento e autonomia para tomada de decisões. Grande parte das decisões do dia a dia devem ser tomadas pelo PO.
2. Team não representa o time. No conceito de Scrum, o texto até poderia ser “Development Team” ou “Engineers” que é o conjunto de perfis necessários para efetuar uma entrega.
3. Proximidade e pertencimento do Business Analyst (BA) e do PO com relação a equipe. Se há um entendimento de que o Analista de Negócios não faz parte do time, quem responde as dúvidas diárias? Quanto tempo demora para resolver questões de entendimento e direcionamento? Quem escreve os requisitos que serão desenvolvidos pela equipe?

Uma outra perspectiva…

 

A figura acima, representa uma organização de equipe que eu acredito que funcione bem (e tive boas experiências práticas com composições neste formato). Todos que estão comprometidos com o time, são membros e partes do time.

O Product Owner, neste contexto, ele é um profissional que domina conhecimentos de negócio. Ele não fica 100% do tempo trabalhando com a equipe, pois se ficasse, ele deixaria de possuir o domínio sobre o contexto do negócio. Ele precisa continuar desempenhando algumas das suas atividades, ele tem de continuar alimentando a sua área de negócio com o que está sendo planejado/realizado e permanecer atualizado com questões de negócio.

Scrum guide: Product Owner [texto adaptado/modificado]

O Product Owner é responsável por maximizar o valor do produto e do trabalho desempenhado pelo Time. Gerenciar o Backlog do Produto, expressar claramente os itens do Backlog do Produto,  priorizar e ordenar os itens do Backlog do Produto para atingir metas e objetivos, dar visibilidade aos Backlogs, transparência sobre o que o Time vai trabalhar a seguir, garantir que o Time possua um entendimento adequado sobre os itens do Backlog são algumas das responsabilidades.

O Product Owner pode também delegar para o Time de Desenvolvimento desempenhar algumas destas atividades. No entanto, o Product Owner continua sendo o responsável pelos trabalhos. O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog devem convencer o Product Owner

 

Analista de Sistemas

O Analista de Sistemas, no contexto da figura acima, é um profissional que conhece sobre o domínio de negócio (níveis diferentes de conhecimento, de iniciante a especialista) mas também entende sobre sistemas e tecnologia. Este perfil, deve ser capaz de ter conversas e facilitar discussões com áreas de negócios e com áreas técnicas (desenvolvedores e eventuais áreas cross). Também deve conhecer especificidades dos sistemas que trabalha, por exemplo, se falarmos de um Analista que trabalha com uma equipe que desenvolve micro serviços, minimamente este Analista de Negócios deve conhecer quais são as interfaces, entradas, saídas, propósito do serviço e etc dos seus serviços, consumidores e integrações. Este profissional, pode e deve apoiar o PO na resolução de dúvidas, escritas de história de usuários, resolução de dúvidas dos desenvolvedores em tempo de desenvolvimento e etc.

O analista busca as melhores oportunidades de negócio, analisa tendências, cria novos produtos, recria produtos existentes, está sempre preocupado em encontrar novos caminhos para a empresa. Ele está em permanente contato com o cliente e os donos do negócio.

Fundamentalmente, esta função está atrelada ao conhecimento e facilidade em lidar com negócios, focada nos recursos de TI e de Sistemas (em toda sua extensão) para poder prover soluções exequíveis para atingir um determinado objetivo.

Problemática

Em algumas organizações que estão passando por transformações ágeis, os recursos de Analista de Negócios, Analista de Sistemas e Product Owner são mal compreendidos e as responsabilidades, papéis e expectativas não são claras.

A confusão entre os papéis, impacta diretamente no resultado das organizações. Estas escolhas e definições de Staffing (que vai alem da alocação e seleção de profissionais para compor uma equipe) são críticas para o sucesso.

O problema é que geralmente, as organizações não estão preparadas para reduzir a demanda de trabalho dos seus POs (que deixam de ser Analistas de Negócios em tempo integral e passam a trabalhar apenas parcialmente para área de negócios priorizando uma equipe Ágil).

Outro desafio, é a quantidade de atribuições dos Analistas de Sistemas.  Vou citar apenas alguns exemplos:

• Conhecer o usuário
• Conhecer o stakeholder
• Capacidade para falar sobre requisitos com viés de negócio e técnico
• Facilitar o entendimento dos desenvolvedores sobre os requisitos
• Mapear e validar valor/ROI das entregas
• Habilidade de comunicar e apresentar ideias e conceitos com clareza
• Técnicas para experimentação e validação de hipóteses [A la Testes A/B]
• Técnicas de ideação e concepção de serviços e produtos [Direto Ao Ponto, Pre-game, Dev Jam Session, Inception, e etc..]
• …

Para resolver ambos problemas, é necessário pensar fora da caixa e na verdade fora dos silos. As responsabilidades podem ser centralizadas mas o trabalho precisa ser distribuído nas equipes de forma que exista as especialidades mas o time seja multi-disciplinar a ponto de conseguir entregar valor da forma mais autônoma possível (aqui não significa entregar de forma independente, pois ainda assim tem de ser uma entrega de valor, alinhada aos objetivos e necessidades da organização).

Como estas ideias se encaixam e aplicam ao seu contexto?

 

 

Publicidade