Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

PO de TI

Em minha empresa existe o conceito de PO de TI e projetos podem possuir um PO do Cliente (que gerencia diversos projetos) e o PO de TI, que faz parte da equipe de TI mas faz o papel de PO de um projeto. Toda interacao da equipe de TI eh com o PO de TI que aciona o PO do Cliente, que tem contato com o cliente... Isso esta correto?

1 resposta
solução!

Marco, tudo bem?

Não chega a ser uma questão de correto ou não, mas uma questão de estar de acordo com algum framework de escala de Scrum. Pelo seu exemplo desconheço, e vão algumas considerações sobre isso. Não entendi sobre o contexto da sua empresa, por isso vou fazer um paralelo entre uma consultoria e uma empresa com silos (departamentos separados sem muita comunicação).

Quando você é PO em uma empresa que tem produtos deve ser aquele que vai criar as histórias, organizar a priorizar o backlog. Se houverem muitos projetos deve haver mais PO's e algum tipo de escala do Scrum (Nexus, SAFe,etc). Essa pessoa, ou essas pessoas, devem ser capazes de analisar e repassar para a equipe as informações necessárias. Lembrando sempre de não funcionar como barreira entre equipe e cliente e sim como um facilitador.

Consultorias costumam vender o pacote completo Scrum, e o PO está nesse pacote. Pago! Ele conhece as técnicas e está apto para ser um PO, algo que as empresas nem sempre tem. Mas sempre a empresa apresenta uma pessoa que será a responsável pelas demandas, conhecedora do negócio e que circula facilmente entre as áreas interessadas no projeto. Minha opinião, essa pessoa deveria passar por um treinamento para ser PO e o PO da consultoria deveria ser seu mentor. Infelizmente o pacote é pago e é preciso que o PO da consultoria atue, isso causa grandes problemas de relacionamento entre as equipes.

Nesse segundo caso entra o seu exemplo, PO de um lado e PO do outro. Como se fossem pontos de ligação entre as empresas/departamento. Sempre que você coloca mais um ponto de comunicação entre as partes é um ruído a mais. Não é certo ou errado, mas começa a burocratizar as coisas.

Dentro de um projeto, um PO, um backlog, quando fazemos além disso estamos levando nossos velhos hábitos para o Scrum e isso não costuma ser bom.