Temos pouco orçamento e o prazo é exíguo, vamos construir um MVP? #SQN

Não sou apegado a formalismos. Acho que cada um põe o nome que quiser nas coisas, o importante é fazer bem feito a coisa certa.

Mas às vezes ao usarmos o mesmo nome para coisas diferentes podemos gerar alguma dificuldade de entendimento, principalmente para quem está iniciando no uso de algum framework, processo ou metodologia.
Por isso resolvi escrever algumas palavras sobre o conceito de MVP ou Produto Mínimo Viável.

Tudo certo quanto aos termos Mínimo e Viável, nesta sigla o que pega é a palavra Produto, pois um MVP é em sua essência um experimento para validar hipóteses e gerar aprendizado.

Diferente do que pode parecer, um MVP não é um produto final e nem tampouco um produto inacabado.

Como vou tentar explicar, os impactos decorrentes destas diferentes percepções de experimento ou produto não se tratam de filigranas conceituais.

Sempre é bom iniciar com a definição de Eric Ries, criador da abordagem Lean Startup e principal disseminador do conceito de MVP: “O produto mínimo viável é a versão de um novo produto que permite que um time obtenha o máximo de aprendizado validado sobre os clientes, com o mínimo de esforço”.

Para que possamos obter o máximo aprendizado, que seja validado com os clientes e aplicando o mínimo de esforço, precisamos ter foco total nas hipóteses que estamos querendo validar, deixando de lado questões que seriam relevantes para a construção de um produto a ser colocado em produção ou implementado em escala.

O que está em jogo é eliminar o desperdício que seria tudo aquilo que não estiver associado à hipótese que queremos validar. E precisamos disto para aprender a adaptar rapidamente, executando ciclos de construir-medir-aprender, junto com seus momentos de pivoteamento que fazem parte da abordagem Lean Startup.

O negócio então é codificar rápido e colocar em uso, mesmo que a cobertura de testes não seja a adequada? Também não. Excelência técnica é um dos elementos essenciais de um MVP.

Um dos exemplos cristalinos do uso de um MVP está na criação da Zappos, empresa de comércio eletrônico de calçados fundada em 1999. Naquela época, ao invés de adquirir estoques de calçados e construir uma plataforma robusta para sua comercialização, Nick Swinmurn, fundador da Zappos construiu um MVP para validar a hipótese de que as pessoas comprariam calçados pela Internet. Com a permissão de diferentes lojas físicas, fotografou os calçados, que foram assim colocados à venda em um site que tinha apenas as funcionalidades necessárias para validar esta hipótese. Assim que as pessoas faziam a compra, o próprio Nick adquiria o produto em uma das lojas, fazia e expedição e cobrança. Em 2009 a Zappos foi adquirida pela Amazon por mais de 1 bilhão de dólares.

Um dos principais pressupostos de um MVP é que ele poderá ser descartado e que isto não significará um fracasso. Se o cliente não gostar do que fizermos, isto será uma descoberta, não uma falha. Trata-se de um processo discreto e por isso muitas vezes não incremental de construção.

Muito provavelmente o segundo MPV não será formado pelo MVP inicial com algumas mudanças e novas funcionalidades adicionadas. E assim seguiremos adiante até que chegue o momento em que a visão de um produto estará consolidada e poderá entrar em uma esteira de desenvolvimento incremental em escala.

Então quando vejo como resultado de um workshop de planejamento de release um roadmap de features ou histórias delineando uma sequência de MVPs de forma incremental eu fico pensando se estamos falando da mesma coisa.

Enquanto tivermos hipóteses de negócio a serem validadas existe muito risco e desperdício se planejarmos o trabalho de forma incremental. Por outro lado, se estivermos falando de requisitos, que já tragam em si alguma estabilidade e certeza, daí o modelo iterativo incremental será de grande eficácia.

Outra forma de pensarmos a diferença entre estas duas perspectivas refere-se ao foco no problema ou na solução. Quando trabalhamos com um MVP nosso foco está no problema, ou na validação de nossas perguntas. Uri Levine, criador do Waze, outra empresa adquirida por mais de 1 bilhão de dólares, expressa esta mentalidade como “Apaixone-se pelo problema, não pela solução”. Já quando trabalhamos com um backlog de produto, nosso foco está na solução, ou na implementação das respostas. Trata-se de diferentes situações em que precisamos de diferentes abordagens e mentalidades de execução. Se aplicadas nos momentos certos, ambas tendem a gerar eficácia.

Talvez se o nome usado fosse MVE, mínimo experimento viável, o termo causasse menos confusão, mas por ora criar outro nome é que pode causar, então fiquemos com MVP mesmo.

Existem várias formas de construirmos MVPs, como vídeos, landing pages e técnicas como mágico de Oz e Concierge, mas isto é assunto para outra conversa.

O importante é compreendermos a ideia base.