MVP – Mínimo Produto Viável
Quando eu converso sobre a experiência que eu tive, sobre desenvolvimento de um MVP – Mínimo Produto Viável, eu tenho percebido um gap de conhecimento. Então, eu resolvi escrever esse artigo sobre o que eu aprendi do tema The Lean Startup do autor Eric Ries.
O Problema:
Nesses tempos competitivos, por conta desse mundo VUCA (Volatilidade, Incerteza, Complexidade e Ambiguidade), os produtos devem chegar logo ao mercado, e se preciso for, fracassar rápido.
Logo, não dá para ter uma timeline de produto, para ser lançado daqui a um ano, para só no fim desse prazo, descobrir se o produto é um vencedor ou perdedor.
Assim, quanto maior é o ciclo de desenvolvimento do produto (WIP), mais o capital da empresa fica preso e sem retorno.
Em síntese, particularmente em software, quando desenvolvemos produtos de longo prazo, o planejamento inevitavelmente falha.
A Reflexão:
É importante pensar sobre as hipóteses que deseja testar:
- Caso a hipótese seja algo de alto valor percebido e baixo risco apenas faça.
- Caso a hipótese é de baixo risco e pouco valor agregado, geralmente deve-se descartar.
- Caso a hipótese é de risco alto e baixo valor percebido, definitivamente deve-se descartar.
- E se a hipótese é de alto risco ou não se tem certeza se é adequada para um problema de mercado que estamos tentando resolver?
A Solução:
MVP – Mínimo Produto Viável:
Antes de mais nada, os investimentos iniciais no MVP podem ser menores e mais focados no entendimento sobre a posição do produto no mercado.
Definitivamente, não precisamos nesse momento de tanta qualidade. A princípio, são só validação de hipóteses.
Dessa forma, validamos as hipóteses com ciclos curtos e rápidos, para integrar continuamente o feedback do mercado. Olha o Devops nos ajudando aqui genteeeeeee.
Assim, através da coleta de evidências sobre o que realmente o cliente usa ou não usa, então podemos ajustar nosso planejamento ao longo do projeto.
De acordo com, o acompanhamento do fluxo com acessos reais dos clientes, começamos a dimensionar melhor as questões. Então, conseguimos entender se devemos empreender mais tempo, qualidade e investir neste Projeto.
Se tentarmos algo que não funciona, precisaremos pivotar e testar algo novo. Dessa forma, se você gastou muito tempo, qualidade e dinheiro, tudo isso irá para o lixo.
Produto resultado de hipóteses validadas:
Em suma, quanto mais aprendemos, mais justificável será o nível de investimento em qualidade e esforço empreendido. Em síntese, ao gerenciar através dos resultados, começamos a tomar decisões baseadas em dados.
Frequentemente o time vai ajustando o produto, ainda em ciclos curtos, a medida que os feedbacks vão sendo recebidos do público. Enfim, vamos fazendo mudanças e adaptando a real necessidade de mercado.
Time
Antes de mais nada, o seu time trabalha para fornecer valor aos clientes com eficiência e o mais rápido possível? A ideia é criar valor a partir do que entregamos ao cliente e não ao terminar o software.
Primeiramente, o time deverá ser empoderado. Embora as iniciativas ainda possam ser acionadas por data, os escopos são negociados pelas equipes, com base no que eles acreditam ser uma entrega minimamente viável.
Igualmente, é preciso deixar os times tomarem as decisões, pois caso as decisões estejam equivocadas, como estamos em ciclos curtos, eles poderão corrigi-las em duas semanas.
Assim também, esses times devem se dedicar ao projeto em que estão trabalhando (em vez de cobrir duas ou três iniciativas diferentes), estando em sincronia e sendo multifuncional.
Informações sobre a autora: Jacqueline Viana é Scrum Master e é apaixonada por agilidade.
