O MVP de um Produto Escalável

Quem olha a plataforma da Contabilizei hoje, não faz muita ideia do que foi e é feito no nosso dia-a-dia para atender mais de 10.000 clientes, processando mensalmente milhões em notas fiscais e impostos, gerando relatórios contábeis e abrindo novas empresas.

Em constante evolução, saímos de uma arquitetura exclusivamente monolítica para microserviços, usando tecnologias como: PaaS, Kubernetes e Serverless. Atualmente nossa plataforma é composta por:

• +20 Aplicações PaaS (Java)
• +50 Microservices (Java/Kotlin)
• +40 Functions Serverless (NodeJs)

Sim, os monolitos ainda existem, mas estamos evoluindo nossa arquitetura…

Por que fazer um MVP?

O significado de MVP é Minimum Viable Product (Produto Mínimo Viável), ou seja, um conjunto mínimo de funcionalidades para validar e testar o mais rápido possível seu produto/ideia.

“MVP’s help you discover “what really matters” — Eric Ries

Até 2013, quando iniciamos a Contabilizei, eu só conhecia uma forma de implementar projetos de tecnologia: o famoso Waterfall. Projetar completamente o que fazer, desenvolver de ponta-a-ponta e só testar no final. Simples. Totalmente focado na entrega de… sistemas, que muitas vezes não refletiam em valor real para o usuário.

Já havia falhado na implementação de algumas ideias, pois havia construído sistemas do zero, usando este processo onde tive pouquíssima (ou nenhuma) interação ou teste com usuários reais.

Então, em agosto de 2013, iniciei a jornada no desenvolvimento da plataforma da Contabilizei. O Vítor Torres havia me apresentado a ideia poucas semanas antes e era sensacional imaginar que podíamos criar algo de grande impacto para micro e pequenos empresários.

Na Contabilizei começamos diferente. Como tínhamos poucos recursos (apenas nossas economias), precisávamos provar muito rápido que era possível sim oferecer contabilidade online.

Através de hipóteses, experiências do Vitor e do conhecimento de processo contábeis do Heber Dionízio, definimos quais seriam as features básicas da plataforma. Enquanto eu codificava e íamos testando com cobaias digo, parentes e amigos, fazendo correções no sistema, o Vítor analisava o interesse e perfil do usuário através da publicação de landing pages e site com testes A/B.

Enfim, 5 meses depois, nossa plataforma estava no ar e disponível para o público.

Por que fazer o mínimo valeu a pena?

Nosso business é muito complexo. Então, focamos no simples: reduzimos escopo, encontramos um pequeno nicho (algumas cidades e apenas alguns tipos de empresas) e conseguimos mostrar que era possível entregar o que nos propusemos, a contabilidade completa de nossos clientes. Se olhássemos para um sistema contábil de mercado, estimo que levaríamos uns 2 anos para implementar e precisaríamos de pelo menos mais uns 5 desenvolvedores. Nosso MVP foi construído apenas por mim em apenas 5 meses.

Só o começo de uma longa jornada

Estes primeiros 5 meses, onde validamos nossa ideia e lançamos a primeira versão do produto, foi apenas uma amostra de como deveríamos seguir trabalhando, e sem dúvida, foi essencial para que a Startup ganhasse a tração inicial que precisava.

A jornada de criação e continuidade de um produto é longa, cheia de erros e acertos e tivemos diversas oportunidades de aprendizado. Abaixo listei aquelas que considero algumas das principais:

#01 — Valide sua visão

Segundo Steve Blank, os principais objetivos de um MVP são:

1. Ser uma tática para reduzir desperdício de horas de implementação de um produto
2. Colocar seu produto na mão de early adopters o mais cedo possível

“You’re selling the vision and delivering the minimum feature set to visionaries not everyone.” (Steve Blank)

Nem todos comprariam um produto que ainda não está pronto. Nesta etapa de validação, contamos com os conhecidos early adopters, que são os usuários mais dispostos a testar um novo produto ou tecnologia. São eles que nos ofereceram os primeiros feedbacks e sem dúvida, muito valiosos!

Estava claro que precisávamos mostrar para estes usuários que de fato, resolveríamos um problema.

Para que o futuro usuário entendesse bem nossa visão e proposta, foi essencial fazer bem a venda, preparar um bom pitch sobre o produto e o que ele resolvia.

Invista na comunicação do que seu produto resolve, crie landing pages, monitore e estudo o comportamento dos visitantes. Que palavra converte mais? faça testes A/B e analise com cuidado. Faça e refaça as páginas. Converse com os usuários, ensaie muito seu pitch, anote as reações das pessoas. Por exemplo, demoramos um bom tempo para encontrar os termos que nossos usuários entendiam melhor, como “Migre sua empresa”.

#02 — Escolha uma tecnologia que conheça

Qual framework front-end devo usar? Webservices ou Microservices? Escolha o que você já conhece e se sente mais confortável! De início, a tecnologia que você precisa usar é aquela que vai permitir a você implementar, testar e publicar seu produto muito rápido.

Para construir nosso MVP, escolhi trabalhar com o Google AppEngine, uma tecnologia de Platform as a Service (PaaS). Entre as vantagens que identifiquei na época:

• Suporte a Java
• Faixa de uso gratuito
• Banco de dados NoSQL nativo
• Deploys rápidos
• Scaling automático

Como linguagem de programação back-end escolhi Java. Apesar de existirem outras linguagens despontando no mercado, as vantagens que percebi foram:

• Ser uma tecnologia consolidada
• Grande comunidade de desenvolvedores
• Facilidade de contratação no futuro (grande parte das empresas em Curitiba usavam)

Para front-end, escolhi o AngularJs. Era um dos primeiros frameworks MVC e, na época, o two-way data binding era incrível!

Microservices? O conceito ainda não era tão difundido e, como disse antes, precisávamos ter um MVP rápido, então utilizei webservices e estrutura em camadas que já havia utilizado em outros projetos.

Não passe muito tempo escolhendo entre a tecnologia A, B ou C, ou ainda desenhando uma arquitetura para milhões de usuários. Seu produto pode não dar certo, pode demorar para ganhar tração ou ainda, pode precisar pivotar! E de que valeu todo este esforço?

Primeiro construa algo rápido, para 10 ou 100 usuários, então jogue fora, adapte ou reconstrua para 1.000, então jogue fora, adapte ou reconstrua para 1.000.000, e assim por diante … Dedique esforço quando for realmente necessário.

#03 — Seja rápido (esqueça a dívida técnica, ao menos agora)

Time to market é a velocidade com que um produto chega ao usuário final. Startups não costumam ter muitos recursos e um bom time to market vai te ajudar rápido em duas coisas: rentabilidade e tração.

Com recursos limitados, validar e rentabilizar rápido pode ser primordial para seu sucesso. Com usuários pagando pelo seu serviço, você adquire recursos e tempo para explorar novas oportunidades, como expansão de mercado, ou novos produtos. Já com tração, aumentando sua base de usuários você dificulta a entrada de concorrentes e ainda atrai investidores. A tração é uma das métricas mais analisadas.

No caso da Contabilizei, lançamos o produto em 5 meses para um escopo limitado de usuários. Isso permitiu que tivéssemos os primeiros clientes, enquanto entendíamos melhor o mercado e implementávamos as integrações com as próximas cidades para expandir nosso mercado.

#04 — Gerencie muito bem a sua dívida técnica

De fato, o que seria uma dívida técnica? A dívida técnica é acumulada por software implementado com má qualidade, resultando em baixa performance, baixa produtividade do time de desenvolvimento e dificuldade de manutenção. Normalmente é causado por prazos curtos ou mal planejamento.

Imagine que você comece a construir seu produto, faz o mais rápido que pode para ver seu código funcionando, testa, corrige, testa, publica e por aí vai… de repente, olha para a lista de features que planejou para o MVP e pergunta: “Fazer a próxima feature ou reescrever o código que acabei de fazer com mais qualidade?” Acredite, você vai para a próxima feature. Sua Startup não tem usuários pagantes e você ainda nem provou que seu produto vai ter tração. É aqui que entra o famoso “código bom é código funcionando”.

Mas qual a melhor forma de lidar com esta dívida?

Nem toda dívida técnica é ruim. Imagine a situação do exemplo anterior, que foi o que aconteceu comigo na implementação do nosso MVP. O que poderia acontecer se a cada implementação eu voltasse e “limpasse” o código? É muito provável que não estivesse escrevendo este artigo…

Para lidar melhor com sua dívida técnica:

• Engaje o time a manter e gerenciar uma lista dos problemas mais críticos e tenha certeza que todos os envolvidos tenham conhecimento. Deixe claro os momentos em que optaram por uma entrega rápida e o impacto na qualidade do seu código
• Encontre qual é o limite aceitável para seu time. É impossível ter ZERO de dívida técnica, seguindo a regra do 80/20, o esforço seria enorme e não valeria a pena. Sua dívida técnica pode deixar seu time lento, mas excesso de zelo pelo seu código também pode deixar sua empresa lenta…
• Reserve um tempo para reescrever código. Conforme um novo produto ou feature surge, revise o código legado e encontre oportunidades para reescrever e/ou migrar partes de um monolito para microservices, por exemplo.
• Defina regras para Codereview. Isso irá evitar novos códigos com baixa qualidade, ajudará a manter o código limpo, criará padrões de boas práticas de desenvolvimento e qualidade.

#05 — Invista nas pessoas

O que vai fazer a diferença na sua Startup é cultura e pessoas. Processos praticamente não existem no início (não deveriam existir).

Quando você estiver construindo algo novo, busque aqueles que consigam enxergar o mesmo propósito que você e com excelentes valores pessoais. Vocês vão passar muitas horas juntos (inclusive finais de semana), irão discutir, errar e aprender juntos.

Formar um time de desenvolvimento com uma cultura realmente forte, envolve práticas como pair programming, code review, compartilhamento de conhecimento e troca de experiências, discussões sobre soluções técnicas, feedbacks verdadeiros entre membros do time, aprendizado constante.

Pegando os pontos que comentei até agora, você vai perceber que no início uma das ações que mostra mais resultados, é resposta rápida. Seu código não é o melhor do mundo, lembra? Identificar e corrigir falhas, pequenos bugs e atender solicitações de melhorias, vai contribuir muito para a perceção do seu cliente e consequentemente gerar indicações (um dos melhores meios de aumentar sua base de usuários). Um time engajado e motivado por uma cultura forte vai garantir isso, pode ter certeza :)

Por fim, espero que nossos aprendizados possam ajudar você que está passando por alguma das etapas desta longa jornada ou ainda está pensando em tirar aquela ideia bacana do papel (quem sabe não chegou a hora de colocar em prática?). Muito do que citei ainda está em andamento e estamos em constante adaptação e aprendizado :)

*** Este post foi originalmente publicado emhttps://inside.contabilizei.com.br/o-mvp-de-um-produto-escal%C3%A1vel-6e02b389c3c4 ***