O caso Zoop – Introdução
Quando você trabalha em uma startup, você vive em um ambiente onde todos estão em busca de uma oportunidade para deslanchar o negócio da empresa. Cada investimento é realizado com o foco de se lançar no mercado o mais cedo quanto for viável, com o menor custo possível.
Se tratando em desenvolver as primeiras funcionalidades, é normal que seus esforços sejam proporcionais a um retorno de curto ou médio prazo, produzindo um sistema monolítico que realiza todas as funções em um único pacote, significando baixo custo e alta velocidade de implementação. Mesmo que seja um senso comum que os monolitos sejam péssimos para escalar grandes volumes de processamento, é inegável que eles são o melhor caminho para a prototipação.
Esses monolitos são construídos e lançados no ambiente produtivo, mesmo sabendo-se que serão refeitos com um ou dois anos de exposição à missão crítica. Lembre-se: o MVP ainda não foi publicado e a sua empresa ainda não está gerando renda, portanto vocês ainda não têm o tempo e o dinheiro necessários para investir nas soluções de ponta, com arquiteturas e designs definitivos que escalarão o volume crescente pelos próximos cinco a oito anos.
Mas um dia, com a gestão da empresa fazendo as escolhas corretas, esse momento excelente aparecerá e a sua empresa irá crescer do dia para a noite. O sistema precisa dessas novas funcionalidades demandadas pela nova grande oportunidade, além de também precisar continuar atendendo as demandas anteriores. Nessa circunstância, a dica mais preciosa é escolher as brigas certas.
- Não dá para reescrever todos os componentes do sistema de uma só vez: o time técnico é extremamente reduzido (é comum haver mais projetos do que pessoas!) e, nesse ponto, o monolito já é grande demais para ser reescrito completamente em tempo hábil.
- Não dá para triplicar o time: não haverá dinheiro para isso e, mesmo que houvesse, adicionar muitas pessoas descontextualizadas do projeto só iria atrasar mais ainda o desenvolvimento das novas demandas.
- Não dá para interromper todas as atividades e reformular essas demandas: se o escopo é enorme e o time é pequeno, pensamos logo em aumentar o prazo. Prazos longos são a morte para uma startup. Afinal, quanto mais tempo trabalhamos em funcionalidades já existentes, menos novas funcionalidades conseguiremos implementar para manter a empresa recebendo novos clientes. Então parar a operação por longos períodos para reestruturar todo o sistema é ainda mais fora de cogitação do que as alternativas anteriores!
Com todos os seus recursos limitados (tempo, gente e dinheiro), não há outra saída. Agora o desafio passa a ser a refatoração dos sistemas em pleno ar, o famoso trocar as rodas do carro andando, ou como costumamos dizer na Zoop, “botar mais combustível no avião em pleno vôo”. É arriscado mas repito: é possível vencer a guerra se brigarmos as batalhas certas.
A Zoop passou exatamente por tudo isso em 2018 e ainda sim conseguimos ter um crescimento exponencial no último ano fiscal. A cada dia sem uma nova entrega, era um dia sem uma nova vitória. Nós contratamos pessoas sensacionais, mas fizemos isso aos poucos. Fomos dando espaço entre as admissões para que os times fossem se expandindo e o conhecimento fosse passado de forma organizada. Mudamos a organização das pessoas: eram 4 times, depois viraram 5 squads e depois 4 áreas de negócio auto suficientes. Ainda sim, o que fez a diferença foi termos aceitado que era necessário desmantelar o nosso monolito e reescrever pequenas partes do nosso sistema para aguentar a demanda por grandes volumes.
É disso que quero tratar com vocês nessa série. Nos próximos capítulos, nós iremos contar essa história. Em cada postagem, vamos falar da abordagem que tivemos com um produto da nossa prateleira, começando com o desenho da arquitetura anterior, avançando para o problema a ser resolvido e passando pelo caminho que tomamos ao planejar a solução, pelo desenho da arquitetura posterior e, finalmente, chegando aos benefícios alcançados por essas mudanças.
Então é isso, vejo vocês no próximo capítulo! Até lá! 🙂
Focado em transformar o mercado através de boas escolhas tecnológicas e do cuidado com as pessoas. Larga experiência com construção de Restful APIs escaláveis utilizando Java, Node, Go e Python. Entusiasta de Agile e Coaching.
