O Product Owner, o otimizador de valor

O papel do Product Owner, tanto do ponto de vista estratégico como tático, é mal compreendido por muitas empresas em transição para as abordagens Scrum ou Agile.

Em linhas gerais o Product Owner atua como agente de mudança organizacional e ponte entre o lado comercial e a equipe do projeto. A título de exemplo, é possível fazer a seguinte analogia:

Se olharmos para o Scrum como um filme, o proprietário do produto seria o diretor. O PO tem a visão das entregas do projeto de software e traduz isso para sua “equipe” por meio de histórias de usuários. O proprietário do produto não é apenas responsável, mas também responsável pelo valor comercial visado. O desafio: como o PO pode não apenas ficar satisfeito com o que a equipe entrega, mas ir além para otimizar o valor do negócio?

Como o nome sugere, o Product Owner é o proprietário do produto ou resultado. Como usuário líder do sistema, ele é o visionário da equipe Scrum. Eles explicam os requisitos de negócios por meio da elaboração de histórias de usuários, o que, por sua vez, resulta no produto final.

O PO (Product Owner) também possui uma forte compreensão das tendências do mercado e da concorrência onde a partir disso, organiza essas informações e as interliga através de épicos, riscos e suposições.

Em um ambiente de gerenciamento de projetos Scrum-Agile, o proprietário do produto atua como um catalisador de mudanças na organização, permitindo a criação de valor por meio de projetos e produtos.

Os proprietários de produtos criam o vínculo necessário entre a aparência do negócio no futuro e o estado atual. O proprietário do produto é um facilitador chave dentro da organização para conectar o cliente e a comunidade de negócios com a equipe de desenvolvimento Agile.

O sucesso com o Scrum depende de toda a equipe, não apenas do proprietário do produto. No entanto, assim como dirigir um carro, o PO pode liderar o Scrum na obtenção do valor ideal de negócios.

Suponha que o PO esteja tentando trazer certos recursos para um aplicativo bancário para ser usado por clientes finais. Com um bom conhecimento do domínio, o PO explicaria:

  • Os desafios presentes na aplicação devido à falta de tais recursos
  • Quais benefícios adicionais os recursos dariam aos clientes finais
  • O que os aplicativos do concorrente têm, etc.

O Product Owner como Analista👨‍💻

O proprietário do produto desempenha o papel de analista de mercado para antecipar as necessidades do cliente com alta precisão – e depois traduz isso como histórias de usuário para os desenvolvedores, desempenhando assim o papel de designer de produto.

Embora o PO não afete os compromissos de um Scrum durante o planejamento do sprint (avaliando o progresso por meio de revisões e retrospectivas do sprint), ele usa o chapéu de gerente de projeto na equipe.

Ao criar uma lista de itens do backlog e, em seguida, priorizar e analisar as dependências, o PO desempenha o papel de estrategista. Eles alinham o roteiro do produto com os objetivos de negócios, obtêm a aprovação do orçamento e garantem o patrocínio.

O PO precisa trabalhar mais para otimizar a produtividade da equipe – e deve ser capaz de demonstrar os resultados com clareza.

A maior parte do que um proprietário de produto realiza pode ser definido em sentido mais amplo como:

  1. Criação e aumento de valor para o negócio e;
  2. Eliminação e redução de custos para o negócio.

O proprietário do produto deve identificar as necessidades do negócio e determinar soluções para os desafios do negócio. Podemos caracterizar a descrição do papel do proprietário do produto em relação às tarefas acima em várias responsabilidades principais onde o PO precisa:

  1. De uma base para e criar épicos que orientam o negócio para a criação de valor e economia de custos;
  2. Planejar e manter épicos, temas e histórias de usuários;
  3. Elicita épicos, temas e histórias de usuários;
  4. Alcançar consenso e entendimento de temas épicos e histórias de usuários entre o negócio e a equipe de desenvolvimento ágil;
  5. Focar em histórias de usuários de acordo com diretrizes específicas como INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable);
  6. Comunicar-se e colaborar continuamente.

O Product Owner, o ponto focal 🎯

Como o proprietário do produto é o ponto focal para o gerenciamento estratégico e tático do produto, ele colabora com muitas partes interessadas e deve se comunicar com todas elas.

Especificamente, o proprietário do produto interage com a comunidade de negócios e as equipes de desenvolvimento Agile regularmente. Ele ou ela também deve se comunicar com a gerência para garantir que os objetivos de negócios sejam realmente capturados em temas e épicos.

Em qualquer esforço de desenvolvimento ágil, o proprietário do produto:

  1. Elicita histórias de usuários, tornando-as INVESTabile;
  2. Analisa-os com a equipe;
  3. Fornece feedback para a comunidade empresarial;
  4. Comunica-se continuamente enquanto prioriza histórias de usuários;
  5. Monitora histórias de usuários para seus respectivos épicos e temas;
  6. Apoia as equipes de desenvolvimento Agile em todo o Sprint – fornecendo esclarecimentos quando necessário;
  7. Aprova e aceita as funcionalidades desenvolvidas ao final da Sprint;
  8. Mantém uma rastreabilidade rudimentar ou completa de histórias de usuários para negócios, épicos, temas e quaisquer outros critérios relevantes que ele tenha definido.

A comunicação é um diferencial importante na eficácia do proprietário do produto e, na maioria das vezes, um aspecto em que os proprietários do produto não possuem o know-how necessário.

Isso, por sua vez, impacta negativamente o desempenho do proprietário do produto. A ênfase é dada à elicitação de histórias de usuários, uma vez que os proprietários de produtos geralmente estão reunindo as histórias em vez de elicitá-las.

A principal diferença entre coleta e elicitação é: Elicitação é um esforço analítico e de comunicação de fluxo livre e colaboração que se encaixa bem com o desenvolvimento ágil, conforme descrito no Manifesto Ágil. A coleta é uma atividade passiva com pouca análise investida. Quando um product owner é um coletor, ele não passa de um administrador.

Para resumir os pontos acima é vital que o proprietário do produto entenda o contexto em que está trabalhando, as ferramentas que ele pode usar durante a execução do trabalho e a essência do que significa ser um proprietário do produto em um ambiente de desenvolvimento que possa gerar valor ao cliente de forma eficiente.

Como manter um insight aprimorado sobre as necessidades do cliente?🤓

O proprietário do produto se comunica e colabora constantemente com a comunidade de negócios e com as equipes de desenvolvimento Agile. A comunicação é a base para a colaboração. A comunicação tem vários objetivos:

  1. Deixar os outros saberem de algo;
  2. Pedir feedback de outras pessoas;
  3. Convencer os outros;
  4. Construir relacionamentos de forma proativa.

No processo de comunicação, existem barreiras pessoais, culturais, interculturais e linguísticas. O proprietário do produto deve estar ciente dessas barreiras e entender que a mesma mensagem pode ser percebida de forma diferente do que o previsto, bem como de forma diferente por vários grupos e equipes de partes interessadas.

Um product owner eficaz entende que as mensagens são recebidas, decifradas e percebidas de forma diferente pelos outros, pois possuem filtros de percepção individuais e distintos. Exemplos de categorias de filtro podem ser:

  1. Valores pessoais – os valores impactam a forma como uma mensagem é percebida;
  2. Interesses – o interesse de um membro específico da equipe em uma determinada história de usuário pode afetar a maneira como ele estima essa história;
  3. Expectativas – diferentes expectativas resultam em diferentes níveis de colaboração;
  4. Experiência passada – a experiência passada pode alterar a forma como as pessoas aceitam uma determinada mensagem e respondem a ela. Isso, por exemplo, pode resultar em uma compreensão diferente da mesma história de usuário a ser desenvolvida.

Melhorando a comunicação do Product Owner e do time 🗣️👂🏼

Ao comunicar, somos subjetivos, afastando-nos de mensagens que conflitam com nossas ideias e crenças. Tendemos a ouvir apenas o que queremos ouvir e geralmente prestamos mais atenção às coisas que nos interessam.

Nossa experiência passada nos afeta e nos influencia, assim como emoções e estados psicológicos afetam como percebemos uma mensagem e como nos comunicamos.

Levando em conta esses obstáculos para uma comunicação mutuamente eficaz, é vital que o proprietário do produto gaste tempo tanto para extrair as histórias do usuário quanto para transmiti-las à equipe.

Durante a reunião de planejamento do Sprint ou qualquer outro processo Agile que inclua o detalhamento das histórias do usuário para a equipe de desenvolvimento, deve-se ter cuidado com os ciclos de feedback e o entendimento claro do que é necessário desenvolver.

Ao discutir a história do usuário com a equipe de desenvolvimento Agile, por exemplo, não é suficiente ler em voz alta os cartões da história do usuário.

O proprietário do produto deve solicitar ativamente feedback para garantir a compreensão da história específica. É útil adicionar gráficos, diagramas, ilustrações e mapas mentais para enfatizar a compreensão.

Eu provavelmente não posso enfatizar o suficiente o quão importante isso é em ambientes Ágeis.

Como o Agile é escasso na documentação formal, (quem fala isso dá uma viajada absurda na maionese) é fundamental ter o entendimento claro e conciso do que é necessário desenvolver durante o processo colaborativo entre o proprietário do produto e a equipe de desenvolvimento do Agile.

Sem a compreensão clara do que precisa ser desenvolvido, a equipe pode estar investindo esforços na direção errada. Assim, um Sprint muito eficiente — que produz resultados rápidos pode, no entanto, ser um Sprint ineficaz onde os resultados recebidos não são os esperados.

Esse feedback constante e loop de comunicação entre o proprietário do produto e a comunidade de negócios, e entre o proprietário do produto e a equipe de desenvolvimento, é a chave para o desenvolvimento bem-sucedido de produtos no ambiente Agile.M

 

Melhorando as competências dos Product Owners 🥋

É importante que todos os Product Owners realizem treinamento de suas habilidades de comunicação, aprendendo estratégias para o desenvolvimento de suas habilidades e aprimoramento de suas técnicas de facilitação.

Do ponto de vista prático, entre as possibilidades de como lidar com as barreiras de comunicação, temos:

  1. Conhecer antecipadamente o objetivo da comunicação;
  2. Permanecer consciente durante uma interação de comunicação e analisar a situação específica das perspectivas do comunicador e do receptor.
  3. Permanecer ciente das restrições impostas pelo ambiente.
  4. Estabelecer e promover um ciclo de feedback multidirecional;
  5. Ser capaz de se comunicar em mais de um método: ou seja, imagens, desenhos, diagramas e protótipos.

Além disso, também é importante que o proprietário do produto possua habilidades de facilitação, comunicação e liderança de modo que sejam capazes de:

  1. Ouvir
  2. Enfatizar
  3. Facilitar reuniões
  4. Lidar com situações difíceis de comunicação e gerenciamento de conflitos
  5. Ser um apresentador eficaz
  6. Liderar decisões de negócios relacionadas a produtos e discuti-las abertamente com a equipe de desenvolvimento Agile
  7. Negociar, mediar e influenciar entre as equipes de desenvolvimento Agile e a comunidade empresarial.

Fazendo tudo isso remotamente 🌎

Mas como isso é possível quando as equipes não estão fisicamente no mesmo local? Atualmente é muito comum que o PO esteja trabalhando longe do cliente, enquanto a equipe Scrum está trabalhando em um local offshore. Lembre-se que este desafio pode ser convertido em uma oportunidade.

Nesse sentido, o PO deve se autoavaliar às vezes com estas perguntas:

  • Tenho uma visão clara dividida em metas de lançamento e sprint?
  • Posso garantir que todos os membros da minha equipe participem ativamente das discussões?
  • Posso garantir que toda a minha equipe entenda e tenha clareza sobre as histórias de usuários narradas por mim? Estou tomando a iniciativa de fazê-los entender pelos membros silenciosos?
  • Eu daria o escopo à minha equipe para desafiar meus requisitos, dependências e problemas narrados?
  • Estou redefinindo frequentemente os itens do backlog mesmo depois que a equipe começa a trabalhar em um sprint?
  • Estou elevando a meta do sprint e motivando a equipe? (Ou estou fazendo com que eles se comprometam com algo que eles não são capazes?)
  • Estou disponível para a equipe sempre que ela precisa de mim? Sou acessível?
  • Posso identificar e controlar o desperdício puro, juntamente com itens que não agregam valor/desnecessários (como tempos de espera com comunicações)?
  • Como os defeitos são um dos itens de puro desperdício na entrega de software, posso fazer uma análise de causa raiz de cada defeito no meu Scrum?
  • Tomei alguma medida para controlar eficazmente os defeitos? Minha equipe é clara sobre a resolução?
  • Posso listar as melhorias contínuas feitas no meu Scrum de sprint para sprint?
  • A velocidade da minha equipe Scrum é rastreada e discutida para melhorias (se necessário)?
  • As retrospectivas de sprint são conduzidas sem falhas após cada sprint? (Se não, por que não?)
  • Minha equipe é capaz de implementar as lições aprendidas em avaliações anteriores?
  • Eu sou realmente adaptável?

Se o proprietário do produto puder atender às expectativas de todas e demais questões que possam surgir, a maioria dos desafios no projeto Scrum poderá ser tratada no momento certo.

É dessa forma que os gargalos vão sendo identificados e devidamente eliminados de modo que a atuação do PO possa garantir que a equipe Scrum otimize seu valor comercial.

No comments yet.

Leave a comment

Your email address will not be published.

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.