O estado da tecnologia na Dronemapp

Sim, este artigo é inspirado no famoso artigo escrito pelo Osvaldo, “O estado da tecnologia na Olist”. Acredito que era inevitável que eu acabasse escrevendo algo semelhante, dado que, sob vários aspectos, a Dronemapp passa, nesse começo de 2017, por um momento bem parecido com o que a Olist passou no começo de 2016.

Um pouco de história pessoal

[Início de cópia quase que palavra-a-palavra do artigo do Osvaldo.]

Até janeiro de 2017 eu trabalhava como líder técnico de uma empresa de tecnologia que tinha uma das melhores equipes técnicas que vi ao longo dos meus 12 anos de experiência na área de TI. Todos os programadores da equipe eram extremamente qualificados e gostavam bastante do trabalho.

Ter pessoas assim é essencial para se ter sucesso em um empreendimento, mas ter indivíduos incríveis não é o suficiente. A coisa toda só funcionava bem porque a empresa conseguiu criar um time com essas pessoas e implantou bons processos de trabalho que permitiam a todos trabalhar com tranquilidade.

Em uma nota lateral, é importante dizer que nesse time o trabalho remoto era quase que a regra e criamos uma equipe distribuída que funcionava tão bem (ou melhor) que muitas equipes “de escritório”. Eu mesmo trabalhava quase todo dia de casa. Ia para o escritório de vez em quando, para tirar proveito do fato de poder passar lá e ficar mais por dentro do “clima” da empresa.

[Fim de cópia quase que palavra-a-palavra do artigo do Osvaldo. Mas novas cópias descaradas virão. Leia o original para comparar. ;-)]

Tudo ia bem, tudo ia tranquilo, quando o Tagôre, founder da Dronemapp, me contacta, via Linkedin, atrás de desenvolvedor experiente que tivesse, entre outras coisas, habilidades em geoprocessamento. Conversamos um pouco por lá e posteriormente, via telefone, tivemos uma conversa muito boa onde trocamos várias ideias. Eu gostei da atitude do Tagôre e do fato de ele estar aberto a me ouvir e considerar o que eu dizia, mesmo tendo conhecimento mínimo sobre o modelo de negócios da empresa dele.

Eventualmente nos encontramos, ele passou um tempo me mostrando como a Dronemapp funcionava e, ao contrário do que era de se esperar, eu é quem acabei entrevistando-o.

Explico: eu não tinha um bom motivo para sair da Olist. Okay, é bem verdade que “geoprocessamento” é um assunto que me interessa mais do que “comércio eletrônico” e, além disso, eu tenho uma certa paixão por empresas com menos de 10 pessoas. Mas a Olist me dava condições de trabalho muito boas, a equipe era excelente, os desafios eram legais, a arquitetura com a qual contribuí para a construção era muito sólida… Estaria eu saindo, então, de uma situação tão boa para me meter num empreendimento que não fosse sólido? Por isso, anotei várias perguntas que me ajudariam a descobrir se a Dronemapp teria boas possibilidades de “decolar” (olha o “trocadilho aéreo” com a empresa que lida com drones…) ou não.

No fim, gostei muito do modelo de negócios, da atitude da empresa para com os clientes, da própria carteira de clientes, do desafio que seria reconstruir a infraestrutura de T.I. e estabelecer processos e procedimentos, da atitude do founder, do fato de a empresa já ter recebido um aporte e das perspectivas de futuro. Gostei muito de tudo. Ah, e o escritório era no Nex Coworking, o que é bem legal. Acertada a proposta salarial (que fez eu e Tagôre parecermos dois turcos negociando um tapete num mercado árabe), ficou acordado: eu estava arrumando minhas malas para passar a fazer parte da equipe da Dronemapp.

Empresa de tecnologia “sem tecnologia”

A Dronemapp entrou no ar em 2015 e, de lá pra cá, teve algumas mudanças profundas em seu modelo de negócios.

A primeira versão da plataforma (que chamamos de “V1”) foi implementada em Javascript e umas pitadas de Python e shell scripts (para o processamento de imagens). Ela foi escrita e colocada no ar muito rapidamente, sendo, em teoria, um “MVP”.

Mas não demorou para que surgissem problemas causados pelo excesso de velocidade de desenvolvimento e falta de um processo mais rigoroso. Em algum momento da vida da Dronemapp, cortar funcionalidades do sistema acabou tornando-se o método padrão de se “resolver” problemas. O que, para quem prestou atenção ao que eu disse, leva à inevitável pergunta: se havia funcionalidades que podiam ser cortadas, que tipo de “MVP” era esse?

Sim, apesar de a plataforma “funcionar” (e pagar o salário da galera), a história do “setor de T.I.” da empresa apresentou vários “maus cheiros”. Falta de uma visão acertada com relação às “entregas”, falta de rigor quanto à qualidade do código e falta dos devidos testes automatizados podem ser levantados como culpados, mas creio que o ponto mais crítico foi a falta de experiência nessa “arte” que é o desenvolvimento de software.

Muita gente pode pensar que eu sou rigoroso demais, mas é fato: se fazendo tudo corretamente já não é fácil criar uma base de código que sobreviva uma década que seja, imagine a situação de quem não tem rigor algum e está seduzido pelo engodo do “estamos entregando muito rápido”!

Enfim…

Posteriormente, por problemas pessoais (externos) do desenvolvedor responsável, na época, a Dronemapp acabou ficando sem uma equipe de desenvolvimento.

Nesse meio-tempo, aconteceu o que era de se esperar: sem ninguém para manter a base de código antiga, os demais funcionários da empresa deram seu jeito de criar manivelas e manter a coisa funcionando da maneira que fosse possível.

Não demorou muito e o Tagôre, em busca de um desenvolvedor que tivesse alguns conhecimentos específicos relacionados aos serviços que a Dronemapp presta, me encontrou e entrou em contato comigo.

Em janeiro de 2017 eu iniciava a minha jornada na Dronemapp com um objetivo: fazê-la se tornar referência em tecnologia.

O plano de ação

Ao contrário do Osvaldo quando entrou na Olist, que teve que decidir entre “evoluir o produto” ou começar tudo quase-do-zero (“quase” porque nunca é do zero se você já tem pelo menos uma versão anterior para entender um pouco do modelo de negócios), eu já entrei sabendo que não iria evoluir nada: criaríamos uma V2 e eu já sabia disso desde o primeiro dia. E a montagem de uma equipe era um processo já meio que em andamento, sobre o qual eu não teria tanto controle quanto gostaria. Logo, meu plano de ação teve leves diferenças do dele. O que eu precisava era:

• Compreender o sistema e as regras do negócio;
• Treinar a equipe e definir processos claros e eficientes de trabalho;
• Ralar muito!

Passei os primeiros dias tentando entender como a empresa funcionava, o quanto do sistema antigo supria as necessidades tanto dos clientes quanto da equipe e, principalmente, busquei medir a capacidade de adaptação dos tomadores de decisão, já que algumas “novidades” teriam que ser implementadas.

Mãos na massa

O sistema da Dronemapp teria duas interfaces principais com os usuários, uma web (“de abrir num navegador”, saca?) e outra rodando no Android. Logo, havia três frentes muito claras para o desenvolvimento: backend, web e Android.

Felizmente, não teríamos que usar desenvolvedores de backend para “ir fazendo” a webapp. Contratamos alguém só para lidar nisso, assim como alguém só para lidar no Android.

Ufa!

Ademais, segui quase que as mesmas diretrizes do Osvaldo:

1. Todo o desenvolvimento seria feito visando qualidade e as boas práticas de programação.
2. Deveríamos ter um processo claro e bem definido para trabalhar. Nada do velho “demanda chega, demanda sai” sem ordem, critério ou planejamento.
3. O novo sistema deveria ser simples. Nada de complexidade gratuita.
4. O novo sistema deveria ser robusto (ter capacidade de “aguentar o tranco”) sempre que possível. Aqui há uma diferença fundamental entre Dronemapp e Olist que quero salientar em seguida: nossa necessidade de escalabilidade é muito mais previsível e isso teve muito peso durante o desenho da arquitetura.
5. O novo sistema deveria ser resiliente (capacidade de continuar funcionando mesmo na adversidade). Uma parte com problemas não deveria afetar as outras.
6. O novo sistema deveria ser modular (cada parte do sistema tem uma responsabilidade clara e bem definida).
7. Deveríamos usar ferramentas e tecnologias testadas e comprovadamente robustas. Nada de seguir o hype do momento somente pelo “cool factor”.
8. Deveríamos priorizar ferramentas e tecnologias prontas e administradas por terceiros mesmo que elas tenham um custo maior. A equipe é pequena e temos muito trabalho a fazer num curto espaço de tempo.

Versão 1

Curiosamente, a V1 do sistema quase que poderia ser aposentada imediatamente. A maior parte do fluxo de caixa da Dronemapp acabou indo para projetos em que a interface web não é essencial. A equipe de cartografia está bem ocupada com projetos que baseiam-se meramente em entregas de arquivos e relatórios para os clientes. Embora esse não seja o modelo de negócios ideal e nem o objetivo da empresa, isso faz o dinheiro se movimentar e está servindo para manter nossos salários.

O complicado mesmo é o processamento de imagens, que é um trabalho que exige muito poder de processamento e demora muitas horas. A V1 automatizava isso, mas por problemas de versionamento do software que utilizamos e o fim da equipe antiga, essa automação acabou indo para o beleléu e hoje estamos na corrida para fazer a V2 suprir essa demanda.

Aos poucos fui descobrindo como eram as coisas na época do desenvolvimento da V1. Descobri que chegaram até a contratar um desenvolvedor remoto mas, por não conseguirem gerenciar direito, isso acabou dando errado. :-/

No mais, analisei muito pouco o código da V1. Eu perderia muito tempo para entender um modelo de negócios que, no fim das contas, é razoavelmente simples. Guiei-me mais pelas telas que existiam e pelas explicações do Tagôre sobre o que é que ele queria ter no fim das contas.

Versão 2

A V2 tem seu backend escrito em Python e usa Postgres como SGBD. A webapp está sendo escrita usando Vue.js e a app para Android é feita com aqueeele Java-do-Android que todos “amam”.

Algo sobre a necessidade específica da Dronemapp é interessante notar: na Olist usávamos microsserviços. E eu mesmo sempre fui um evangelista de arquiteturas baseadas em eventos. Entretanto, sob o devido escrutínio, percebi que o backend ideal, inclusive com vistas a médio e talvez longo prazo, era simplesmente “um Djangão simples”, com tudo no mesmo banco de dados, numa plataforma essencialmente monolítica.

“Que pecado!”, você deve estar pensando, mas não me arrependo nem um pouco disso. É importante, enquanto se pensa em uma arquitetura, não se deixar levar por algum tipo de zelo mal direcionado ou pelo hype de certas abordagens. O que funcionou perfeitamente bem na Olist e em várias outras empresas não pode-se garantir que funcionará perfeitamente bem na Dronemapp.

Afinal, não existe bala de prata. Microsserviços e arquiteturas orientadas a eventos tem vantagens e tem desvantagens. Existem certas coisas sobre as quais qualquer especialista no assunto dirá “não abra mão delas a não ser que seja realmente necessário”. Um banco de dados relacional é um exemplo. Logo, o backend da Dronemapp é essencialmente monolítico, fazendo uso de todas as benesses que essa abordagem nos dá.

Nossas necessidades de escalabilidade são muito simples e previsíveis. É diferente da plataforma da Olist, na qual o tráfego aumenta absurdamente no dia das mães, na black friday ou simplesmente porque algum canal está fazendo uma promoção imperdível de algum produto extremamente popular. Nós nem sequer cruzamos qualquer dado entre clientes, o que significa que, na pior das hipóteses, podemos simplesmente criar uma cópia da pilha toda e colocá-la para rodar dedicada a algum eventual “cliente gigante”. Em situações mais comuns, otimizar o código e manter a base de dados o mais limpa possível é um primeiro passo. Depois, se quisermos escalar horizontalmente temos tempo de planejar isso adequadamente e fazer a implementação da solução. E, como um meio-termo razoavelmente barato, ainda podemos escalar verticalmente.

Criar uma arquitetura baseada em eventos e com microsserviços, no nosso caso, tornaria a primeira entrega muito demorada, retiraria de nós certas comodidades e adicionaria uma complexidade desnecessária.

Ferramentas

Heroku everywhere. Os serviços da Amazon podem até ser mais baratos “na fatura”, mas no gestual do dia-a-dia o Heroku consegue se pagar. Da AWS, hoje, só estamos usando o S3, que é o serviço de armazenamento.

Para gerenciar os repositórios de código, usamos o Github. Para rodar os testes automatizados, Circle CI. Quando a V2 estiver indo para o ar, pretendemos usar o Sentry para monitorar os eventuais bugs.

Não pretendemos usar ferramentas específicas para métricas, por enquanto.

Processo

Nossas tarefas são gerenciadas num misto de kanban e SCRUM. Nós não somos muito apegados às métricas do SCRUM, mas fazemos reuniões diárias rápidas (dailys), estabelecemos prazos para “sprints”, que servem mais como “checkpoints”, e fazemos plannings e retrospectivas regulares.

As dailys são um destaque. Não somente a equipe tem respondido muito positivamente como a implantação disso na equipe de cartografia também tem gerado bons resultados.

A daily é da equipe, mas traz muitos benefícios para o indivíduo. Ela impede que você “flutue para longe” nas suas tarefas. Quando você se obriga a verbalizar o que andou fazendo e o que pretende fazer começa a fica óbvio para si próprio quando você está perdido ou debatendo-se demais sem sair do lugar e, assim, você mesmo vai se obrigando a se organizar devidamente para fazer o trabalho fluir.

Sobre o código, nada entra no “master” do repositório sem passar por revisão e aprovação de pelo menos dois outros desenvolvedores. Débito técnico é um monstro que sempre volta para nos incomodar. É uma bola de neve que só tende a aumentar. Logo, a ideia é evitar que qualquer débito comece a se formar. Pode parecer um tempo perdido, mas cortar problemas pela raiz ajuda a garantir que continuaremos com uma equipe enxuta que passa mais tempo criando do que no famigerado trabalho de “sustentação”. Além de nos ajudar na manutenção da nossa sanidade mental no futuro (e, por futuro, eu quero dizer “nos próximos meses”).

Tudo deve ter testes automatizados. Funcionalidades sem testes podem até funcionar hoje, mas nada garante que continuarão a funcionar depois de qualquer alteração que fizermos, mesmo que seja em uma parte aparentemente distinta do código. E o tempo que investimos hoje em fazer bons testes é menor do que o tempo que perderíamos depurando a aplicação nos casos de regressão (ou seja: a funcionalidade X funcionava bem, mas agora não funciona mais porque alguém mexeu em algum lugar do código).

O futuro

Pretendemos entregar a primeira versão funcional da plataforma até o final de março desse ano (2017). Algo que me anima é que a migração de dados, que foi um trabalho bem grande na Olist, na Dronemapp será muito tranquila, podendo até ser feita “na unha” pelo pessoal “não-developer”. E, com a entrega da V2 poderemos para de nos preocupar com as coisas básicas (afinal, a V2 não estará entregando features além das essenciais) e começaremos a trabalhar em entregar diferenciais interessantes para nossos clientes, envolvendo, por exemplo, visão computacional e talvez até machine learning.

A Dronemapp é uma empresa muito nova e ainda está em processo de crescimento. Isso causa problemas e dores. Mas é bom saber que todos estamos trabalhando com afinco para que ela seja um sucesso.