O que sustenta a ponta de um iceberg dentro de um cenário ágil, seja em uma organização, time ou até mesmo um papel, é o Agile Mindset. Essa nova mentalidade que o ágil nos leva a entender, está estabelecida por meio de 4 valores, fundamentados em 12 princípios, ou seja, Manifesto Ágil, e manifestada através de diversas práticas, técnicas e métodos diferentes.
Há uma grande distância entre ser ágil e estar fazendo ágil. Como Product Owner temos um radar de práticas, técnicas e métodos para ajudar de acordo com o contexto que estamos trabalhando, com isso, precisamos internalizar esse mindset que está fundamentado e estabelecido no Manifesto Ágil e em momento algum podemos feri-lo.
Os valores do Manifesto Ágil:
INDIVÍDUOS E INTERAÇÃO mais que Ferramentas e Processos
SOFTWARE FUNCIONANDO mais que Documentação Abrangente
COLABORAÇÃO COM CLIENTE mais que Negociação de Contratos
RESPONDER A MUDANÇAS mais que Seguir um Plano
O Manifesto é composto de valores e princípios, assim como cada um de nós, para preservar um valor na sua vida é preciso definir alguns princípios, por exemplo: você pode torcer para seu time do coração e, para preservar esse valor na sua vida, é necessário estabelecer alguns princípios, como: ser um sócio torcedor, assistir todos os jogos, assistir pelo menos um treino apronto no mês, comprar camisa oficial. Certamente seguindo esses princípios esse valor de torcer para um time favorito estará vivo em seu dia a dia.
Abaixo temos 12 princípios que preservam os 4 valores do Manifesto Ágil.
Vamos destacar os princípios de bolso de um Product Owner:
Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor – O Product Owner é responsável em criar, priorizar, fatiar e manter o product backlog, ou seja, é o dono do backlog (única fonte de requisitos do produto). A forma que o Scrum manifesta esse primeiro princípio é através de ciclos curtos que se chamam SPRINTS, com isso, o Product Owner determina o que é prioridade para o cliente no primeiro momento, buscando sempre a satisfação do cliente, e antecipa o poder de entregas (lembrando que não é somente entregar, também gerar percepção de valor em cada entrega).
Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas – O Product Owner precisa entender que o cliente não está comprando o produto, mas sim investindo no produto, certo que em um curto espaço de tempo terá esse retorno. Com o foco em fazer o cliente tirar vantagens competitivas de mercado, o PO precisa estar aberto a aceitar mudanças. Quem nos disse que um plano não pode mudar? a única certeza que temos em desenvolvimento de produto é que ele vai mudar, mas com métodos ágeis isso vai acontecer o mais cedo possível, com isso, existe a necessidade de adaptação para responder à mudança sem traumas, lembrando que mudanças sempre são bem vindas. Os requisitos podem mudar a qualquer momento, o que é normal e aceitável, é necessário gerenciá-los conforme suas prioridades. Se os seus requisitos não mudam, tem alguma coisa de errado.
Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos – O Product Owner precisa decidir quais funcionalidades são prioridade no primeiro momento, fatiar pequenos incrementos com valor para o cliente. A entrega constante gera a percepção de rápido, pois o objetivo é entregar o mínimo o mais cedo possível para o cliente e gerar o feedback antecipado, gerando assertividade, ou seja, maior frequência de planejamento e maior qualidade das entregas. Com o conceito MVP, tudo isso fica mais claro, pois o objetivo é escolher o mínimo do produto necessário, colocar na mão do cliente e o cliente determina se é viável para evidenciar o aprendizado emergente do produto. O Product Owner pode trabalhar a concepção do produto para entender o todo e priorizar o que precisa entregar. Nesse momento os detalhes não são importantes (detalhes são refinados durante o tempo) e o esforço inicial não deve chegar a duas semanas, apenas dias.
Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente durante todo o curso do projeto – O Product Owner está sempre engajado e disponível para o time de desenvolvimento, respondendo a quaisquer dúvidas relacionadas ao negócio. Durante sessões facilitadas, é importante o envolvimento dos desenvolvedores com as partes interessadas, facilitando o entendimento do negócio.
Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho – O Product Owner está muito próximo do time de desenvolvimento e é importante que todos saibam que ele faz parte do time (Scrum). O PO deve ter o conhecimento necessário sobre o negócio assim como ter toda confiança para que possa fazer seu trabalho, precisa priorizar o que deve ser feito, tem que ter poder de decisão e, principalmente, saber dizer “NÃO” para necessidade do cliente quando não está alinham com a visão do produto.
O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara – O Product Owner é responsável em manter o Product Backlog priorizado e com valor, o time de desenvolvimento em entregar o que está se comprometendo em cada Sprint. Com isso, há uma aproximação forte através de conversas ativas e sessões facilitadas, colaborando constantemente para entender os itens do backlog que podem ser apresentados por User Stories. Valoriza os momentos de conversas cara a cara para dar o entendo de negócio do que está representado através das User Stories, lembrando que ela é apenas um “lembrete” da necessidade do cliente, ou seja, fornece um flash da comunicação, representa os requisitos (necessidades) mais do que documentá-los. Os melhores documentos nos ajudam a recordar nossas conversas, eles não a substituem. Para provocar a colaboração de todas as partes interessadas, pode-se adotar ferramenta simples, como cartões, post-it, papéis, flip-chart, paredes ou quadro em branco, certamente incentivará a comunicação ativa de todos interessados no produto.
Software funcional é a medida primária de progresso – Todo incremento do produto representa uma entrega funcional de valor do produto para o cliente. O Product Owner é o responsável por demonstrar esse progresso de valor para todos interessados.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes – O Product Owner entrega o que precisa ser desenvolvido para o time, ajudá-lo no entendimento do negócio para que o time possa fatiar e estimar. O trabalho do Product Owner de refinamento dos requisitos é um esforço contínuo durante todo o projeto.
Contínua atenção à excelência técnica e bom design, aumenta a agilidade – O Product Owner contribui constantemente ajudando o time de desenvolvimento a entender a visão e roteiro do produto, seus objetivos de negócio e principais features, deixando claro todo contexto de negócio, com isso o time facilmente consegue identificar riscos técnicas, arquitetura, buscando sempre a excelência técnica.
Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito – A principal ferramenta do Product Owner é dizer “NÃO” para um item entrar no backlog. Todo o esforço de refinamento do Product Owner está nos itens de maior prioridade para o cliente, ou seja, saber o que é importante para o produto e saber o momento certo de parar, neste cenário “menos é mais”.
As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis – O Product Owner é o responsável pelo backlog e definir sua prioridade, mas em um projeto todos têm toda condição, habilidades e conhecimento necessário para auto organizar e se comprometer com o trabalho que precisa ser feito.
Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo – O Product Owner reconhece que o seu papel precisa se adaptar e melhorar a medida que o produto evolui e está bem alinhado com todo o processo. Retrospectivas frequentes conduzem a melhoria contínua e a forma como o time trabalha para maximizar o valor para seus clientes.
