Solucionado (ver solução)
Solucionado
(ver solução)
5
respostas

Quem pode ser o Product Owner?

Product Owner, segundo o curso Métodos Agéis do Alura:

  • "É a pessoa que representa o cliente";
  • "É o dono da visão e ele representa o cliente. Ele define as funcionalidades, prioriza, escolhe quando são feitos os releases, dá feedback, faz a gestão dos stakeholders, faz a gestão de todos os interessados do projeto e aceita ou rejeita a funcionalidade entregue pelo time."

Para mim ficou claro que o PO é o representante de uma empresa que desenvolve software, responsável por lidar diretamente com o cliente e transmitir as necessidades do produto a ser desenvolvido (prioridades, datas de entrega e outros requisitos).

No entanto, tenho dúvidas sobre quem pode assumir este papel. Um PO deve estar inserido dentro da empresa que desenvolve o software (prestadora de serviço) ou pode ser um funcionário da empresa contratante pelo serviço?

5 respostas

Acho que tanto faz.. uma caracteristica importante eh que ele entenda do negocio e esteja alinhado com os objetivos do cliente/produto. Se for uma pessoa que saiba um pouco da parte tecnica e tudo mais, acho que fica ainda melhor.

Entendo a sua colocação, Alberto, até concordo com parte de sua afirmação, contudo acredito que o PO tem um requisito que não é simples de ser atendido pelo cliente/contratante (pelo menos na imensa maioria dos casos não, porque desconhece) que é a capacidade opinativa sobre o time. Um PO pode opinar sobre quem vai participar no desenvolvimento do produto. Quando ele está inserido dentro da empresa contratada por desenvolver o produto é fácil decidir sobre quem participa do projeto, no caso contrário, de o PO estar inserido na empresa contrante é mais difícil, pois este não conhece as peças disponíveis e suas qualificações como profissional.

solução!

Geison,

Concordo com o Alberto, e compartilho um pouco da minha experiência. Já vi situações variadas, como:

PO é um funcionário da empresa de desenvolvimento, fica alocado nela, mas conhece o negócio bem para desempenhar sua função e representa cliente e os interesses dele no produto.

PO é funcionário da empresa de desenvolvimento, fica alocado no cliente, mantém contato com o time ágil e SM através do Skype (ou qualquer ferramente de comunicação que permita conferência), e se reunia com a equipe presencialmente em momentos muito necessários, como durante a reunião para planejar um sprint com histórias complexas, etc.

PO é funcionário da empresa contratante, fica alocado na empresa de desenvolvimento, já conhece bem o negócio, e toca o barco normalmente.

A única coisa que ainda não vi é o PO ser funcionário da empresa contratante, e ficar 100% alocado nas dependências do contratante e nunca reunir com o time ágil, nem comunicar de forma eficiente, ficar só na troca de e-mail por exemplo. Embora creio que com organização, disciplina e comunicação sólida o suficiente isso funcionaria sem problema algum. Exemplo disso são times ágeis formados por pessoas em cidades/países diferentes que funcionam mesmo assim.

Resumindo, acho que não existe regra definidora, uma coisa muito comum é o paradigma ágil ser adaptado para se encaixar no formato que a empresa precisa ou melhor irá atendê-la. Não é requisito para que um time ágil seja eficiente, tenha que seguir tudo à risca.

Espero ter contribuído, abraço.

Emerson,

Obrigado por sua participação. A experiência é, e sempre será, um canal muito importante para a aquisição e difusão de conhecimento.

A conclusão clara aqui é de que não há uma regra sobre onde deve estar inserido o PO. Sua atuação não está limitada as fronteiras da empresa prestadora de serviços. O mais importante é que ele detenha os requisitos necessários para realizar este papel.

Concordo meu amigo, minha visão é essa mesmo, ele deve ter os requisitos mínimos para cumprir a função com eficiência, o resto, como dizem, é história.

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software