Papel PO

O Product Owner (PO)

O Product Owner é responsável por maximizar o valor do produto e o trabalho do time de desenvolvimento. Trata-se de uma única pessoa no time que traz a perspectiva do cliente para o produto/projeto.

Responsabilidades do PO

• Desenvolver e manter uma visão de produto e a estratégia de mercado;
• Gerenciamento do Produto/projeto;
• Priorizar e gerenciar o Product Backlog;
• Envolver stakeholders e usuários finais no refinamento do Product Backlog e no gerenciamento do Backlog;
• Manter alinhamento com outros Product Owners quando precisam de uma visão geral na perspectiva de produto, empresa e clientes.

O que se espera de um PO da MSTECH

A missão de um PO para a MSTECH é de balancear os interesses do cliente, da equipe e da empresa:

• Interesse do cliente: Ter o que foi solicitado com o menor custo possível;
• Interesse da empresa: Ter seu cliente satisfeito E foco em rentabilidade e lucro;
• Interesse da equipe: Ter uma boa experiência de entrega somados à satisfação do cliente e da empresa.

Para isso, a MSTECH entende que um PO deve:

• Ser um consultor para o cliente, ou seja, analisar a situação e ajudá-lo a encontrar a melhor forma de resolver seus problemas. Além disso, ser no cliente, também, um "consultor de vendas" para a MSTECH, identificando novas oportunidades para a empresa;
• Desenhar e especificar a solução que o cliente PRECISA. Não é necessariamente o que ele diz que quer, nem o que julgamos que será tecnicamente mais completo e desafiador. Isso também não quer dizer que a qualidade deve ser deixada de lado, pelo contrário. Um PO busca entregar o que o cliente PRECISA com qualidade;
• Buscar sempre entregar o "mais por menos" ao seu cliente;
• Manter o foco total no Princípio de Pareto (80% - 20%);
• Levar, quando entendido como necessário, o Scrum Master para junto do cliente. O PO é responsável por contextualizar a situação do cliente para a equipe. Muitas vezes é mais produtivo que o SM acompanhe o PO em algumas atividades;
• Levar imediatamente sitauções críticas ao conhecimento do CEO;
• Criar e manter um relacionamento de confiança com o cliente. O cliente só confia em quem entende do assunto e do problema, quem colabora com ideias para solucionar seus problemas e com quem ele adquire empatia;
• Ter uma visão macro do cliente. Isso quer dizer, não conhecer apenas o projeto, mas ter uma visão dos stakeholders, cenários, contextos de negócio e motivações do cliente;
• Ajudar o Scrum Master a resolver os impedimentos relacionados ao cliente;
• Não deixar, de modo algum, a célula parada por falta de definição;
• Trazer a equipe para a realidade, além de ânimo e motivação. O PO deve levar todos os feedbacks do cliente (tanto positivos quanto negativos) à célula. Lembre-se, se a derrota é da célula, a vitória é ainda mais da célula;
• Manter a célula engajada ao cliente. Isso quer dizer que o PO deve manter a célula sempre contextualizada. Explicar quem é o cliente, por que o projeto, qual a necessidade do cliente e qual a importância do trabalho a ser feito.
• Monitorar os projetos para manter o resultado dentro das estimativas e trabalhar para reduzir os custos da empresa;
• Manter uma relação de parceria com o Comercial, com as filiais e todas as áreas da empresa. Lembre-se que compomos UMA SÓ MSTECH;
• Gerar novas ideias de produtos e serviços para a empresa. Buscar algo inédito, inovador, com base na vivência com o cliente;
• Não reinventar a roda. Deve propor soluções ou componentes free, essas sugestões serão sempre muito bem vindas.
• Por fim, deve ter a responsabilidade de identificar nos requisitos e histórias de usuários ferramentas que possam ser reusáveis para outros projetos da empresa. Além disso, deve identificar se os produtos serviriam a outros nichos de mercado também.

Além disso, um grande Product Owner...

• Compreende, compartilha e socializa a visão de produto: Um grande Product Owner representa a voz dos clientes: um grande PO representa a voz dos clientes e cria uma visão de produto junto com os stakeholders. Toda decisão é tomada com a visão de produto em mente. Isso garante um desenvolvimento sustentável ao produto, provê clareza para o time de desenvolvimento e aumenta as chances de sucesso do produto drasticamente.

• Supera as expectativas do cliente: Um grande PO compreende verdadeiramente as intenções dos clientes e os objetivos dele com o produto e é capaz de superar as expectativas deles. Afinal, a satisfação do cliente é o objetivo final!

• Possui poderes de decisão: Um grande PO recebe poderes de tomar decisões relativas ao produto. Claro, criar apoio às suas decisões pode levar algum tempo mas tomar decisões rapidamente é condição primária para o time de desenvolvimento.

• Prioriza o Product Backlog: Um grande PO entende que o Product Backlog deve estar sempre priorizado Prioridade, risco, valor, oportunidade de aprendizado e dependências são todas questões que devem ser levadas em conta nessa priorização. Por exemplo, para construir uma casa o telhado deve ter a prioridade mais alta possível se considerarmos o risco de chuva. Mas ainda é necessário realizar a fundação e as paredes antes e portanto esses itens devem ser priorizados antes da construção do telhado.

• Prefere comunicação face a face: Um grande PO entende que a melhor forma de transmitir informação é pela comunicação face a face. User stories são melhor explicadas em uma conversa pessoa. Se uma ferramenta é usada para o gerenciamento do backlog, sua função é apoiar o diálogo porém ela nunca substituirá a boa e velha conversa.

• Conhece técnicas de modelagem: Um grande PO tem um alto repertório de técnicas de modelagem. Ele conhece quando aplicar cada tipo de modelo. Exemplos de técnicas são a Business Model Generation, Lean Startup ou Mapeamento de impacto. Baseado nesses modelos ele sabe como direcionar o sucesso do produto.

• Compartilha experiências: Um grande PO compartilha experiências com seus pares. Isso pode ser feito dentro e fora da organização: seminários e conferências são uma grande forma de compartilhar experiências e absorver conhecimento. Além disso, escrever suas lições aprendidas podem ser valioso para outros Product Owners.

• Conhece o mapeamento da história de usuário: Um grande PO deve dominar o conceito de mapeamento de história de usuário. É uma técnica que permite a você adicionar uma segunda dimensão ao backlog. A visualização permite você visualizar o quadro geral do Product Backlog. Referência: http://jpattonassociates.com/user-story-mapping/

• Dá foco à funcionalidade: Um grande PO tem o foco na funcionalidade e nos aspectos não-funcionais do produto/projeto. Mesmo horas ou pontos são menos importantes. O objetivo do PO é maximizar o valor ao cliente. É a funcionalidade que tem valor, portanto esse deve ser o foco maior para o Product Owner.

• Mantém conhecimento: Um grande PO tem uma profundidade de conhecimento do produto/projeto de requisitos funcionais e não funcionais e entende sua composição técnica. Para grandes produtos pode ser difícil entender todos os detalhes. Entretanto o Product Owner deve sempre conhecer as peças grandes do quebra-cabeça e assim tomar decisões sólidas e conscientes do produto/projeto.

• Entende á área do negócio: Um grande PO entende o negócio e ambiente do qual ele faz parte. Um produto sempre deve ser construído com este contexto sendo levado em conta. Isso inclui um entendimento da organização do cliente para o desenvolvimento, mas também estar atento às mudanças no mercado do ramo. Liberar um produto fantástico fora da janela de oportunidade é um tanto quanto inútil.

• Atua em diferentes níveis: Um grande PO sabe como atuar em diferentes níveis. O modo mais comum para definir esses níveis é estratégico, tático e operacional. Um PO deve saber explicar a estratégia do produto para a Diretoria, criar respaldo com a gestão e motivar o time de desenvolvimento dentro dos desafios diários deles.

• Conhece os 5 níveis do planejamento ágil: No Agile, planejamento é feito de forma contínua. Todo produto precisa de:

1. Uma visão, com a qual irá providenciar itens para o roadmap do produto;
2. Definir o roadmap: Roadmap é um plano estratégico de médio/longo prazo de como o negócio gostaria de ver a evolução do produto. Um roadmap, entretanto, deve ser revisitado uma reavaliação periódica, dadas condições do mercado.
3. Planejar releases: baseado no roadmap, condições do mercado e status do produto;
4. Sprint Planning: Durante a Sprint Planning o time planeja e concorda com os itens do Product Backlog que eles estão confiantes que podem completar durante a Sprint e ajudar a atingir o objetivo da Sprint.
5. Daily Scrum: A reunião diária é usada para inspecionar e adaptar o progresso do time em seu caminho para atingir o objetivo da Sprint.

• Está disponível: Um grande PO é disponível para os stakeholders, seus clientes, o time de desenolvimento e o Scrum Master. Questões importantes são respondidas de forma rápida e informações valiosas são providenciadas em tempo. O PO garante que sua disponibilidade nunca bloqueie o time de desenvolvimento.

• É capaz de dizer “não”: Um grande PO sabe como e quando dizer não. Essa é provavelmente a característica mais óbvia e mais difícil de dominar. Dizer sim para uma ideia nova ou funcionalidade é fácil, é apenas outro item na product backlog. Entretanto, um bom gerenciamento de backlog engloba um product backlog gerenciável com itens que provavelmente serão realizados. Adicionar itens ao backlog sem saber nada sobre o que irá acontecer com eles irá criar apenas desperdícios, gastos e expectativas falsas.

• Atua como um “mini-CEO”: Um grande PO é basicamente um mini-CEO de seu produto/projeto. Ele tem um olho aberto para oportunidades, foca no valor de negócio e no retorno do investimento (ROI), além de atuar de forma proativa em riscos e ameaças possíveis. Tudo relacionado com o crescimento (tamanho, qualidade, Market share) de seus produtos é levado em conta;

• Sabe os diferentes tipos de itens de Product Backlog válidos: Um grande PO pode deixar claro o fato de que seu Product Backlog consiste em mais do que apenas poucas novas funcionalidades. Por exemplo: Inovação técnica, bugs, defeitos, requisitos não funcionais e pesquisas devem ser levados em conta;

• Leva a sério o refinamento do backlog: Um grande PO passa tempo suficiente refinando o Product Backlog. O refinamento do backlog é o ato contínuo de adicionar detalhes, estimativas e priorização dos itens do Product Backlog. A saída deve ser um Product Backlog que é granular o suficiente para ser bem entendido pelo time inteiro. Na média, o time de desenvolvimento gasta nada mais que 10% de seu tempo no refinamento de atividades. O modo como isso é feito não tem uma fórmula e depende do time. Um PO pode envolver stakeholders e o time de desenvolvimento no refinamento do backlog. Stakeholders porque ele dá a oportunidade de explicar seus desejos e vontades. O time de desenvolvimento porque eles podem clarear detalhes técnicos e funcionais, além de possíveis implicações. Isso irá garantir um entendimento comum e aumenta a qualidade do product backlog consideravelmente. Como consequência, a oportunidade de construir o produto certo com a qualidade desejada irá também aumentar.