Produziu código, não é MVP
Porque você não precisa saber programar para testar sua ideia
Recentemente fiz uma thread no Twitter após ler um tweet muito interessante sobre MVP e um erro bem comum. Como acredito que a thread é quase uma utilidade pública sobre o assunto e não queria que ela se perdesse com o tempo, decidi fazer uma postagem mais elaborada sobre o assunto.
O tweet de inspiração foi esse aqui.
Posso te contar a maior mentira do munto de "TI Ágil"?
— Bruno Vinicius (@brunusvinicius) December 27, 2018
"Código de MVP é pra se jogar fora."
Quase nunca é jogado fora.
=(
Agilidade versus MVP
Uma confusão comum sobre agilidade geralmente é causada sobre o uso mais comum que fazemos da palavra. Usamos a palavra agillidade como sinônimo de rapidez, mas no desenvolvimento de software ágil falamos no sentido de mudar ou se adaptar com facilidade, outro significado da palavra.
Já sobre MVP muitos ao ler sobre Lean Startup(startup enxuta) pensam que um MVP é um software feito as pressas e entregue do dia para a noite sem a menor preocupação com código ou qualidade, para testar uma hipótese, afinal o Ries fala de um software cheio de bugs. Isso até pode ser um MVP, mas não é algo muito ágil.
Dividas técnicas e MVP
— Mauricio R. Duarte (@mauriciord) December 20, 2018
Códigos complexos e mal feitos são dificeis de mudar. Isso é bem importante para entender o porque um MVP feito as pressas e com qualquer código, não vai resultar em algo ágil.
Aquele MVP escrito em 5 dias, se torna de dificil manutenção e o ideal seria realmente jogar fora e reestruturar, mas isso não acontece e ainda leva para outro problema, já que a reconstrução vai levar tempo.
Como quem desenvolve ou o time, começa a ter entregas mais lentas e trabalhosas por conta das dividas técnicas, surge o pensamento de que o time é lento e não tão ágil. Geralmente nesse ponto a agilidade morre. Ao fazer mais horas extras o time começa a cometer mais erros, mais códigos complexos são gerados e a velocidade diminui ainda mais e a qualidade também.
Resultado qualquer progresso importante de novas funcionalidades demoram meses para acontecer, vão precisar de mais pessoas, que vão gerar mais trabalho isso quando o produto não deixa de existir com a ideia sem validação por conta dessas falhas.
Produziu código, não é MVP
Essa talvez seja a declaração mais polemica minha em 2018, pelo menos foi o que senti diante dos feedback, discussões geradas e também por ter me motivado para escrever esse texto. Então vou me aprofundar mais no assunto do porque penso assim e explicar alguns exemplos.
O Minimum Viable Product, trabalha com a ideia de entrega de valor já logo no começo para a validação de uma hipótese e também da captura de feedbacks rápidos para melhorar esse produto.
As vezes uma hipótese só pode ser validada diante da entrega de um software, mas em alguns casos podemos fazer essa validação sem precisar da criação de um software e isso casa muito bem com o principio da simplicidade do manisfesto ágil. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
Um lugar que vi alguns casos sobre MVPs bem interessantes, foi durante as aulas do Startup School em que eles falam sobre fazer coisas que não escalam (Doing Things that Don't Scale). Para isso vou pegar um caso citado por lá e que acredito que é um bom caso de e também outro caso bem emblemático quando falamos de MVP.
Doordash
Stanley Tang estava estudando em Stanford, quando ouviu de Chloe sobre alguns problemas que ela enfrentava em seu negócio. E um dos problemas dela era a dificuldade por não entregar alguns pedidos.
Stanley conversou com entorno de 150 à 200 donos de pequenos negócios que disseram que tinham problemas semelhantes. Como eles poderiam testar sua ideia? Eles não tinham caminhões ou infraestura para criar uma empresa de entregas nessas condições.
O que eles fizeram é um exemplo bem legal de MVP.
Eles colocaram uma Landing Page no ar que levava para um PDF com menu de um restaurante e nessa página tinha o número pessoal de telefone dos fundadores e aguardaram o primeiro pedido.
Logo o primeiro pedido aconteceu, eles cuidaram pessoalmente do processo de ir até o restaurante e fazer a entrega. Logo conseguiram ouvir onde as pessoas tinha encontrado o site.
A Doordash hoje é uma empresa que já recebeu mais de 900 milhões em investimentos se quiser se aprofundar ainda mais sobre essa história pode ver nesse video.
Dropbox
O exemplo do dropbox é inclusive retirado do próprio livro do Lean Startup (Startup Enxuta) e também do texto do Eric Ries para o Techcrunch e que acabou chegando até mim como um comentário da thread.
Qualquer trabalho adicional além do que foi requirido para iniciar a aprendizagem é desperdício, não importa a relevância que pareça ter tido naquele momento. - Eric Ries - Lean Startup (Startup Enxuta)
Drew Houston é o CEO do Dropbox e ao falar sobre a sua ideia para investidores (um mundo que sonhamos aqui no Brasil) eles rejeitavam a ideia por já acharem que era um mercado muito concorido, mas Drew saiba que o problema era que os softwares de armazenamento em nuvem, não tinham clientes por conta da péssima experiencia do uso.
O problema de Drew é que o seu protótipo seria impossivel, ele costruir um software que envolvia um serviço online de alta confiabilidade, precisaria de um software desktop para diversos Sistemas Operacinais diferentes.
Para resolver o problema ele criou um video, exibindo o que pretendia alcançar e com isso tever mais 75 mil inscritos no seu site aguardando um beta. E você pode ver abaixo.
O MVP é diferente do desenvolvimento de outros produtos, ele precisa validar uma hipótese de negócio, não só questões técnicas ou de design de produtos.
Nem todo MVP poderá ser validado através de um video, mas já é um bom começo ou caminho para validar um ideia de forma simples. Um MVP pode se transformar em uma startup sem precisar de um programador.
Nem sempre será possivel, por isso precisa de um bom exercio para entender qual será a melhor forma de obter esse feedback de possiveis usuários e saber se vale a pena investir dinheiro, tempo e também em programação de software muitas vezes bem complexo.
Goleiro de Aluguel
O relato do Goleiro de Aluguel é bem interessante, vou relatar na integra com o que recebi do próprio Samuel.
Em janeiro de 2015 criei uma fanpage chamada Goleiro de Aluguel. Com uma foto, me coloquei à disposição para ser goleiro pelo valor de R$30,00. No primeiro mês fiz 14 partidas e até junho fiquei só com o Facebook.
O negócio cresceu e precisei elaborar algo mais organizado, confesso que na época nem sabia oq significava MVP. Minha proposta era usar ferramentas gratuitas pra expandir, oferecer o serviço para outros times e goleiros e obter uma receita maior.
Fiz um site em WordPress, meu primeiro investimento foi comprar o domínio, hospedagem e a licença de um layout. Nesse site coloquei dois Googles Forms (Cadastro de Goleiros e Convocações de Goleiros). Esses formulários alimentavam planilhas, quando preenchidas recebia um e-mail.
Copiava as informações dos jogos e enviava para grupos de WhatsApp de Goleiros, separados por cidades. O primeiro que respondesse que aceitava a solicitação, recebia o contato do Contratante.
O goleiro jogava e recebia, depois repassava a comissão, tudo na base da confiança. No dia seguinte enviava um formulário de avaliação por e-mail para quem contratou o goleiro, essas notas construía um ranking e premiava os melhores.
Foi assim durante 15 meses, sem programar nenhuma linha e faturei R$100mil. Em agosto de 2016 lançamos a primeira versão do aplicativo.
Corporações "inovadoras", ágeis e seus MVPs
Um outro ponto quando falamos de MVP e sua clara associação com startups vem do lado de grandes corporações estarem muito preocupadas em não serem a próxima blockbuster ou taxistas da parada, com isso elas estão olhando muito para a forma de agir das startups.
Falar de rodar um MVP e ser ágil, virou algo sexy de se falar no meio corporativo e de desenvolvimento de software tradicional, parece que estamos falando realmente de algo inovador e super criativo. (não ser criativo no Brasil é um crime)
Mas no geral poucos realmente leram as literaturas de onde surgiram os termos agilidade ou MVP. E com conceitos rasos sobre MVP tem a ideia de algo, mal construido e não precisam se responsabilizar no longo prazo ou vai poder culpar pessoas pelo trabalho mal feito e com prazos apertados.
Algumas organizações ainda mantem suas estruturas travas e com dificuldades para validar ideias e sufocam a criatividade por jogar a carga de trabalho de uma ideia em cima de um time de desenvolvimento.
Muitas esquecem de outros termos, por exemplo o termo protótipo, como algo para validar um ideia, afinal aqui não precisa validar uma hipótese de negócio, só testar um determinada funcionalidade.
Alguns MVPs se resumem à produtos de baixa qualidade, que apresentam pouca inovação, que foi mal programado e vai ser muito dificil de evoluir ou modificar no futuro.
Se realmente precisar programar um MVP, lembre-se de que ele pode evoluir e essa evolução precisará ser ágil, para acompanhar o ciclo de feedbacks, não fique polindo muito a arquitetura ou enfeitando muito as coisas, mas deixe com uma boa estrutura que te ajudaram no futuro, para revisitar e alterar coisas.
Algumas boas práticas como teste unitários, não deve tanto tomar tempo de desenvolvimento no ponto de ser mais custoso do que o desenvolvimento do software em si.
Landing pages, videos, Google forms e coisas semelhantes, que já simulam uma funcionalidade real e que já podem realizar uma cobrança é um bom caminho para uma validação, o jeito de fazer isso é do seu gosto, mas explore essas opções antes de criar um software, hora de desenvolvimento é cara e um luxo.
Para finalizar, não pague por uma linha de código pra fazer um MVP, use as armas que você tem.
