O PO seria um analista de requisitos? Ele domina somente a regra de negócio ou também a área técnica?

Olá Francisca,

o PO é o representante do cliente dentro do time scrum. Seu papel é entender as necessidades do cliente, montar histórias que façam sentido para o projeto de acordo com estas necessidades, priorizá-las de acordo e transportar este conhecimento para os desenvolvedores. Tanto que se formos listar o trabalho no dia a dia de um PO ele é composto por:

1) responder às dúvidas dos desenvolvedores sobre o que está sendo desenvolvido ou indicar quem poderia respondê-las melhor

2) prover uma meta clara para cada Sprint

3) obter feedback e expectativas dos clientes e extrair delas as necessidades

4) manter o Product Backlog atualizado, isto é:

• adicionar itens novos

• remover itens desatualizados

• revisar a priorização do backlog constantemente.

Tanto que é natural muitos gerentes de projeto ou analistas assumirem este papel quando o time começa a adotar o Scrum.

E o PO não precisa conhecer da área técnica. Se ele tiver algumas noções ajuda muito na questão da comunicação com os desenvolvedores. Mas como nem é papel dele dizer como fazer o software, isso é responsabilidade dos desenvolvedores, não é necessário o PO ter conhecimentos de programação.

1) responder às dúvidas dos desenvolvedores sobre o que está sendo desenvolvido ou indicar quem poderia respondê-las melhor

Existe uma linha tênue com o papel do SM. Acredito que se há uma duvida na validação de uma regra de negocio, ou sobre sua importância no negocio, prevendo uma mudança nas prioridades, o PO é o cara correto.

Se há duvida na documentação ou existem impedimentos do ambiente, banco ou a codificação da feature, o atalho seria com o SM, como facilitador.

É sempre importante lembrar que o SM não é relacionamento com o cliente, nem líder técnico. Ele esta focado mais nas pessoas e como ajuda-las a serem profissionais hiperprodutivos.

Muito bem citado Lucas e Leandro. :)

No curso, foi comentado que poderíamos ter uma sobrecarga de atividade entre o PO e os desenvolvedores. Eu, por experiências anteriores, não vejo isso como uma coisa boa.

É muito importante que o PO vista a camisa da funcionalidade. Pensar em como ela será implementada pode prejudicar o alinhamento dele com o cliente (no nosso caso, sempre ficávamos tentados a controlar o requisito com já uma proposta de execução, o que limitava o poder da equipe de bolar soluções).

A sua equipe tem que ser livre para pensar, montar soluções, buscar ferramentas etc. Senão sempre haverá uma dependência.

Se for fazer sobrecarga, por gentileza, arruma um jeito de fazer com que o PO se comporte de maneira diferente quando estiver em ambientes diferentes.

E boa sorte na execução. ;)