Eu sou um Product Owner.

A maioria das empresas de software acham que o Product Owner é o gerentão que coloca a pressão para as coisas acontecerem ou pensam que é o garçom da empresa que fica tirando pedido dos departamentos e acaba mais dizendo sim do que não. Pois é, geralmente essa é a visão distorcida que as pessoas tem do Product Owner e por este motivo decidi escrever uma breve abordagem do que faz um P.O.

product_owner_scrum_2

 

Acredito que o primeiro requisito para ser um P.O é ter bom senso, capacidade de tomada de decisão e muita inteligência emocional. Lidar com clientes, equipes de desenvolvimento, diretores, parceiros, indianos… é bem complexo. Nesse mix de perfils faz com que seja obrigatório entender de pessoas e não apenas de tecnologias. Pela minha experiência e pelos fatos que já presenciei, mais de 90% dos problemas em projetos e produtos ocorrem pela tomada de decisão errada das pessoas, ou pela falta de humildade de assumir um erro e correr para reverter ou pelo orgulho de não deixar que o time tome a decisão em conjunto.

O PRODUCT OWNER REPRESENTA A VOZ DO CLIENTE E É RESPONSÁVEL POR GARANTIR QUE A EQUIPE AGREGUE VALOR AO NEGÓCIO. O PRODUCT OWNER ESCREVE CENTRADO NOS ITENS DO CLIENTE , OS PRIORIZA E OS ADICIONA PARA O PRODUCT BACKLOG.

KEN SCHWABER

 

Portando, o papel que um P.O precisa exercer é de ser um conector entre a área de negócios e tecnologia, fazendo com que as direções sejam tomadas com base em justificativas consistentes de valor para os usuários.Ele precisa criar e aumentar o valor para o negócio e ainda eliminar o desperdício nas entregas.

product_owner_scrum_1

 

Outro ponto importante é que a parte tática do P.O para construir um projeto é entregue na elicitação de requisitos. Considero essencial criar um fluxo de colaboração para entendimento dos requisitos do projeto, por mais que seja uma tarefa exclusiva do P.O, ele precisa coexistir com o time e levantar a bandeira de entrega com a melhor qualidade. Não basta escrever histórias e definir bons critérios de aceitação, seu processo analítico e crítico precisa ser ativo em todas as interações, isso ajuda a incluir dentro da empresa uma visão de valor nas entregas. Elicitar se define como um entendimento muito maior do que apenas uma captura e escrita de documentos.

Abaixo coloco algumas atividade que um Product Owner precisa atuar:

  • Apoiar e manter a cultura ágil na empresa
  • Ser um líder servidor para seu time
  • Ter sempre uma meta a ser alcançada através de um valor de entrega
  • Entender de arquitetura de informação para solucionar a vida dos usuários
  • Disponibilidade para o time
  • P.O é full time P.O
  • Manter o time em uma velocidade saudável
  • Entender muito bem como funciona o nicho de mercado do seu produto
  • Planejar e manter épicos, temas e histórias de usuários
  • Dar feedback para a comunidade de negócio
  • Priorizar histórias por Valor de Negócio
  • Aprovar e aceitar histórias
  • Manter as histórias independentes
  • Definir o MVP e garantir a evolução continua
  • Manter a rastreabilidade de histórias para temas e épicos

Afinal, o que é um MVP de verdade?

Falar em Mínimo Produto Viável (MVP) tornou-se uma obrigação dentro de startups e no dia a dia de pessoas empreendedoras. Porém, mais do que um termo que caiu nas graças da área de tecnologia, o mesmo tem uma justificativa clara para ser usada com tanto afinco por aqueles que querem ver seu produto decolar.


Com a queda de metodologias burocráticas e suas falácias produtivas, o mercado de tecnologia objetivou o resultado com valor. Isto, antes de colocar um aporte de milhões em um projeto ou produto sem a possibilidade de validar a idéia proposta. A entrada das plataformas mobile capacitou o lançamento de aplicativos com alto valor agregado em pouco tempo de desenvolvimento. Esta facilidade permite a evolução contínua dos produtos, em paralelo com sua rentabilidade. Um exemplo clássico é do game Angry Birds. O mesmo obteve 10 milhões de downloads nos 3 primeiros dias de lançamento. Fora o valor incontável de brand alcançando, criando uma franquia gigantesca para produzir bonecos, desenhos entre outros produtos que hoje fazem parte do universo da marca.

“Startups não falham ao desenvolver uma ideia, mas falham ao encontrar clientes dispostos apagar. Uma tecnologia por mais incrível que seja, se não resolver um problema, jamais será um produto”

Steve Black

Um Mínimo Produto Viável (MVP) nada mais é do que uma forma de gerar a comprovação de uma idéia ou hipótese com base em feedback constante com os usuários, possibilitando um aprendizado para potencializar o produto em teste, ou ainda, desistir a tempo de não se colocar mais dinheiro em uma furada. Esta visão de evitar o desperdício de tempo em funcionalidades que não serão utilizadas pelos usuários, surgiu na cultura Toyota e evolui depois que Steve Black e Eric Ries construíram o conceito de Lean Startup. Também é importante considerar a contribuição de Don Normam e John Maeda para a virtualização do conceito de produtos e valor agregado.

Uma frase que sempre lembro quando pessoas ficam entusiasmadas achando que irão ficar milionárias com um aplicativo ou com sua super idéia:

 “Startups não falham no desenvolver uma ideia, mas falham ao encontrar clientes dispostos a pagar. Uma tecnologia por mais incrível que seja, se não resolver um problema, jamais será um produto” – Steve Black

 E depois vem essa:

“Não aguento mais conhecer empreendedores. Eles não entendem que um negócio inovador não é feito de ideias, mas de execução. Os grandes negócios que conhecemos são a terceira ou quarta execução de uma mesma ideia. A primeira rede social é de 1995. O Facebook veio bem depois” – Eric Ries

Feedback constante

A palavra mágica do conceito de Mínimo Produto Viável (MVP)  é o feedback, ou seja, abrir o seu produto para interagir com o maior número de usuários possíveis, procurando entender como o seu produto pode resolver o problema dessas pessoas. Portanto, não tente encher seu produto de funcionalidades e jogar todas as suas expectativas inovadoras nele. As pessoas terão pouco tempo para contribuir com a sua idéia e muitas nem saberão como utilizar. Seja o mais breve possível para solucionar seus problemas. Até porque, se você perder todo o seu tempo colocando funcionalidade no produto, vai perder o timming de lançamento, o que significa perder uma oportunidade por um pecado idiota.

Números!

Sempre que tiver um idéia nunca deve abrir mão de pensar em métricas, coleta de informação e mensuração dos seus objetivos. Falo isso porque não existe possibilidade de você lançar um produto sem ter que gastar com desenvolvimento, design e marketing. Você precisa saber exatamente onde está errando, como está errando e porque está errando; e, muitas vezes, saber até mesmo porque está acertando. Por isso, acredite, os números vão ser o balizador do que as pessoas passam nos feedbacks e o que realmente elas fazem na interação com seu produto. Resumindo, você vai ter um tempo hábil para responder às incertezas do mercado e criar um produto realmente valioso.

mvp

Algumas dicas para refletir antes, durante e depois de iniciar um Mínimo Produto Viável (MVP) :

  • Não se preocupe se sua primeira versão vai ter bug ou se o design pecou nas cores: isto faz parte do evoluir;
  • Escute os feedbacks. Eles podem fazer grande diferença;
  • As repostas não virão até você. Saia e as encontre;
  • Erre quantas vezes for necessário e, o mais importantes, não tenha medo;
  • Não se jogue na primeira ideia;
  • Para se ter resultado, precisa se ter números. Invista em analytics e ROI;
  • Evite que o seu produto cresça e fique empilhado de funcionalidades inúteis;
  • Pesquise, teste, prototipe, viaje, discuta. Só depois de tudo isto inicie um MVP, mas não passe de dois meses;
  • O MVP é um grande brainstorming, por isso não perca nenhuma oportunidade;
  • Mantra do MVP: “Alto valor agregado, baixo investimento, agilidade e sem desperdício”.

Implementar o Scrum na Trinca.

A primeira pergunta que fiz quando recebi a proposta para trabalhar com equipe da Trinca foi – Qual a metodologia de trabalho? E para a minha felicidade foi que o Scrum estava em processo de implantação, porém teríamos alguns desafios. Acredite ou não, as expectativas foram superiores para todos, um processo padronizado, resultados a curto prazo e uma equipe engajada para melhorar a cada dia.


Quando cheguei na empresa busquei entender quais eram as expectativas com relação a metodologia e o que de fato sabiam sobre a mesma. Durante um mês fiquei estruturando um formato ideal para trabalhar com o cenário que a empresa se encontrava com projetos complexos, equipe motivada e a busca por um retorno efetivo. A maioria das pessoas quando vão trabalhar com o Scrum não fazem idéia do quanto é evolutivo o processo de implementação e quanto o crescimento do time é importante para um desenvolvimento consistente dos projetos.

 

Não podemos criar um mundo de ilusões achando que ser ágil é entregar um projeto de 6 meses em 10 dias, pelo contrário, o Scrum prioriza aquilo que tem valor e é realmente relevante para o resultado final.

A cultura nunca deve ficar de lado

O ponto chave de uma metodologia ágil é a cultura da empresa, se queremos mudar os processos e as equipes, sem dúvida não podemos deixar de envolver diretamente aqueles que formam o DNA da empresa, que são os proprietários e diretores. Não podemos criar um mundo de ilusões achando que ser ágil é entregar um projeto de 6 meses em 10 dias, pelo contrário, o Scrum prioriza aquilo que tem valor e é realmente relevante para o resultado final. Portanto, os líderes precisam entender que o que iremos construir é um legado na maneira de pensar produtos ou projetos digitais e que a cultura será afetada positivamente para a melhoria das suas equipes de negócio, desenvolvimento e clientes.

agile_manifesto

Projeto Beta para validar o essencial

Outro detalhe importante para implementar a metodologia foi não tentar mudar da noite para o dia o que já estava acontecendo na empresa. A forma mais transparente para se fazer isso foi construir pequenos degraus de conhecimento dentro dos projetos. Durante algumas reuniões, vimos que um dos projetos mais complexos seria a nossa versão beta de implementação, isso porque se funcionasse bem neste projeto, os demais iriam receber de forma orgânica a utilização do Scrum. No momento que conseguimos deixar esse time totalmente envolvido com as práticas do Scrum a mudança ocorreu naturalmente nos demais projetos. Ou seja, quando as pessoas estão engajadas em um problema e querem resolver cooperando e construindo um novo cenário, os resultados acontecem e acaba virando um ciclo virtuoso pela busca de valor.

metodologia-agil-scrum_

 

Quando comecei a padronizar os artefatos para implementar a prática os times se colocaram em uma posição muito aberta a entender sobre cada novo passo que era dado. Abaixo fiz um breve check-list dos itens que utilizei na parte tática do processo de implementação:

 

  • Quandros brancos por todas as salas com kits de canetas coloridas
  • Padronizar os post-its para criar um entendimento comum
  • Padronização de planilhas para estimar as histórias e tarefas
  • Workshops para explicar como funciona os ciclos de entregas do Scrum
  • Burndown o mais simples possível
  • Utilização de ferramenta para documentar as histórias
  • Padronização da etapas dos projetos
  • Definição do tempo das sprints e releases
  • Formalização da discovery, planning, daily, retrospectiva e review.

O resultado

Depois de 4 meses a percepção das pessoas começava a mudar quando os resultados apareceram de forma expressiva nas entregas dos projetos.Começamos a ver que os problemas emergiram e precisavam ser resolvidos com maior envolvimento, os prazos estavam sendo mais precisos e as entregas feitas com um nível detalhado de testes, o módulo de comando – controle deixou de operar e entrou a visão de líder servidor, as abordagens de desenvolvimento focaram no valor do produto, o crescimento do time com relação a busca por qualidade de código e a economia em bugs resultou em motivação.

O mais interessante é que agora sabemos para onde iremos e como, entendendo qual é a nossa capacidade de produção e o perfil de projetos que desenvolvemos, isso tudo nos capacita para uma tomada de decisão mais precisa em relação as mudanças que enfrentaremos constantemente nos projetos e produtos digitais.

Dicas de livros para quem quer evoluir nesse assunto:

Getting real

Rework

Scrum 360°

Desenvolvimento de software com Scrum

Gestão ágil para projetos de sucesso

Scrum em ação

Chief Culture Officer

A alma da Toyota