Acabei de ler, “Agile Product Owner Secrets: Valuable Proven Results for Agile Management Revealed“. Este livro está repleto de dicas para Product Owners (POs). Gostaria de compartilhar aqui alguns dos pontos que achei mais interessantes.
Para o autor Michael Nir, idealmente, o PO deve conhecer ambos os mundos o do desenvolvimento de software, e o mundo dos negócios (claro, no contexto do software que está sendo desenvolvido) e deve saber traduzir conceitos entre pessoas de um desses mundos para as do outro.
Ele afirma também que a maior parte do que um PO faz pode ser definido em amplo senso como:
- Criar e aumentar o valor para o negócio.
- Eliminar e reduzir custos para o negócio.
Atividades do PO
- Minerar e criar épicos que guiam o negocio em direção à criação de valor de negócio e redução de custos.
- Planejar e manter épicos, temas e histórias de usuários.
- Elicitar épicos, temas e histórias de usuários, mantendo as histórias no formato INVEST.
- Alcançar o consenso e o entendimento entre o negócio e o time de desenvolvimento.
- Analisar as histórias com o time.
- Dar feedback para a comunidade de negócio.
- Priorizar histórias por Valor de Negócio.
- Dar suporte em relação ao negócio para o time durante o desenvolvimento.
- Aprovar e aceitar histórias.
- Manter a rastreabilidade de histórias para temas e épicos.
O PO não é um levantador de requisitos
A principal diferença entre elicitar e levantar requisitos, segundo Nir, é que a elicitar é um fluxo de comunicação e colaboração livre e analítico que se encaixa bem com desenvolvimento ágil e está em acordo com o manifesto. Levantar é uma atividade passiva e há pouco investimento de análise. Por isso é essencial que o PO entenda bem do contexto no qual está trabalhando e, ele deve não apenas ler documentos e transformá-los em requisitos, mas também deve incluir seu próprio entendimento, seu processo de análise e síntese, e tomar decisões em prol da comunidade de negócios visando aumentar o valor agregado das entregas. Elicitação trata-se de entendimento, não de captura.
O PO não é um apenas um represente dos desejos da comunidade de negócios, em vez disso, o PO processa os desejos em necessidades guiadas por valor de negócio.
O PO deve ter boas habilidades de comunicação
A boa comunicação é uma das principais habilidades de um bom PO. Além disso ele deve também ser um bom ouvinte, saber dar ênfaze para prioridades, facilitar reuniões, gerenciar conflitos, ser uma apresentador/palestrante eficiente, deve saber discutir abertamente, e negóciar e influenciar pessoas. Sem um entendimento claro do que precisa ser desenvolvido o time pode estar investindo seus esforços na direção errada. Por isso é essencial a comunicação do PO com o time e com a comunidade de negócio.
E você concorda com a visão de Michael Nir? Deixe seu comentário.
Saiba mais sobre que eu ando lendo: Siga-me no GoodReads.
Concordo com Michael Nir, acredito que um PO deve conhecer os dois mundos, mas principalmente entender a necessidade e valor de negócio para o cliente, sabendo priorizar com cautela o que a equipe de desenvolvimento deverá entregar primeiro. O bom relacionamento entre o PO e a equipe também é fundamental, pois podem acontecer casos em que o PO estima que uma tarefa será rápida de ser feita, porém o desenvolvedor é quem dará o palpite final, por isso a importância de entender e se envolver nos dois lados, pois assim o PO entenderá melhor a dificuldade do desenvolvedor em entregar e o desenvolvedor entenderá melhor a dificuldade de um PO ao analisar uma tarefa, fluindo desta forma, um trabalho em equipe com maior chances de sucesso e, consequentemente, maior satisfação do cliente com os resultados.
Bacana, Alline.
Obrigado por compartilhar suas impressões.
Abraços.
Esse é o caminho podendo ser adaptável ao perfil de cada empresa, com isso deve se dar mais enfase para os processos que cada empresa mostrar maior importância, concluindo, ser ágil.