Estou escrevendo uma sequência de 15 textos sobre a história nua e crua da criação do Real Valor até o exit. O objetivo é mostrar o dia a dia, os erros, acertos e desmistificar aquele glamour do empreendedorismo de palco
Semana passada escrevi a parte 1, então se não leu, dá uma olhadinha aqui.
Se já leu a parte 1, sabe que eu e o Gabriel Farias tínhamos decidido fazer uma plataforma para ajudar os investidores a acompanharem os investimentos. Mas a gente precisava decidir algumas coisas antes:
App ou web?
Essa decisão foi rápida de tomar. Em 2017, todo mundo já tinha smartphone e passava cada vez mais horas nele por dia. Como a gente não sabia desenvolver nem para web nem para app, fazia mais sentido ir na direção que o mercado estava indo: vamos fazer um app.
Mas ao escolher fazer um app, surge uma nova dúvida:
Android ou iOS?
Essa decisão envolveu mais pesquisa. Na época, o Android tinha um marketshare no Brasil de quase 85% e o iOS de uns 15%.
A escolha parecia óbvia.
Mas tinha um detalhe: a appstore (loja do iphone) fazia mais receita do que a playstore (loja do Android) no Brasil.
Isso significava que mesmo com menos gente usando iPhone, essas pessoas gastavam mais dinheiro do que todo o resto que usava Android. Isso era um dado importantíssimo porque nossa ideia era fazer uma empresa lucrativa.
De nada adianta fazer uma ferramenta fora de série que não consiga monetizar. Eu tinha isso bem vívido na minha mente: eu adorava um site chamado plug.dj que acabou apesar de todos amarem porque não tinha receita.
No fim, apesar de ter feito uma pesquisa a fundo para decidir, tomamos a decisão olhando para outra coisa: conteúdo na internet.
Para se fazer o app Android, era necessário programar em Java. Para fazer o app iOS, seria necessário programar em Swift.
Como a gente não sabia programar nada em nenhuma das duas linguagens, tivemos uma conversa rápida:
“Cara, a gente precisa conseguir achar soluções para os problemas que vamos ter. Tem muito mais gente usando Java, logo tem mais gente tirando dúvidas na internet e mais gente respondendo essas perguntas. Vamos de Java.”
Linguagens mais usadas em 2016 segundo o GitHub. Tá vendo Swift no Top10? Nem eu.
Assim foi tomada a decisão.
A estratégia inicial teve menos a ver com receita e mais com a necessidade de conseguir aprender na internet.
Um detalhe importante: descobrimos mais tarde que para programar um app iOS, era necessário ter um Mac para usar o programa Xcode. Se soubéssemos disso, a decisão seria muito mais simples, visto que nem eu nem o Gabriel tínhamos Mac na época.
Começando o Java
Ok. Vamos fazer um app Android. E agora?
Simples, uai! Vamos comprar um curso e já era!
Compramos e começamos a seguir o curso. Ele nos ensinou a instalar o software para programar em Java e a usar algumas boas práticas de programação.
Curso que ajudou a gente a ter alguma ideia por onde começar.
Mas depois de assistir umas 2h de curso, meu TDAH não permitiu que eu continuasse.
Eu tenho uma dificuldade BRUTAL de prestar atenção em aula. Eu preciso botar a mão na massa.
Para se ter uma ideia, eu fiquei de recuperação em basicamente todas as matérias no colégio da sexta série até o 3o ano. Isso inclui “religião” que era considerada uma matéria fácil.
Tive que dar uma ideia no Gabriel: “Vamos começar a tentar fazer o app e usamos o curso para fazer consultas quando a gente empacar”.
Ele gostou da ideia.
Mas o que fazer?
Eu já tinha lido o Lean Startup, então estava familiarizado com a ideia do MVP. Definimos o que seria o nosso MVP.
Sabe aquela frase do Reid Hoffman “Se você não tem vergonha da sua primeira versão, você demorou muito para lançar”? A gente seguiu à risca.
Nada de login: as informações ficariam armazenadas localmente no celular de cada usuário (porque era mais fácil fazer). Nada de tela de loading: não agregava em nada e daria trabalho aprender a fazer. (A gente criou uma tela com a imagem de um touro com texto dizendo “isso deveria ser uma tela de loading”)
Cor? Design? Esquece.
Lembra que o objetivo era ter algum progresso no app em 1 mês?
Nosso MVP só precisava de duas coisas: Pegar o input de dados do investimento do usuário. Só ações brasileiras para simplificar ao máximo. Cruzar esses dados com dados de mercado e devolver gráficos e análises de como o portfólio estava performando.
Criando o input de dados
Essa parte foi “simples”. O que a gente precisava fazer era bem trivial e já tinha sido feito por infinitas pessoas, então foi só uma questão de saber perguntar para o Google (em inglês, óbvio, porque tem mais conteúdo em inglês).
“How to create a new screen in android app java”
“How to create text input for android app - java”
“How to create a button for android app - java”
“How to store data in a local database - Android - Java”
Pronto. Fizemos um formulário em que o usuário adicionaria:
Código da ação
Data da transação
Quantidade de papéis
Preço de compra
A imagem mais antiga que achei foi essa foto de março, onde já tínhamos suporte para Tesouro Direto.
Antes de pular para a próxima parte, só quero deixar registrado que essa tarefa era SIMPLES, mas não FÁCIL. Coisas que um desenvolvedor faria em 2 minutos levavam 10 horas para a gente. Eu programava parecido com o meme do cachorro no laboratório.
Como eu me sentia nessa época
Cruzando com dados de mercado
Se a primeira parte foi simples, porém difícil, essa foi complexa e difícil.
Antes de ir atrás dos dados históricos das ações, subimos dados aleatórios para conseguir fazer a lógica do aplicativo funcionar.
Parece simples, mas existiam 2 desafios:
Colocar os dados no formato .json (não tinha a MENOR ideia do que era isso)
Hospedar os dados no Firebase (aprendemos a fazer isso no curso, mas "na prática a teoria é outra")
Para quem não conhece, json é um tipo de base de dados não relacional. Uma máquina lê os dados no formato json muito mais fácil do que num formato de tabela como o do Excel, mas para seres humanos é um pouco mais complexo.
Exemplo de dados em .json da ação americana MSFT (Microsoft) nos dias 31/01/19 e 01/02/2019.
Uma vez que vencemos esses 2 desafios, mexemos no código até o cruzamento de dados funcionar certinho. Isso demorou uma ou duas semanas.
Para contextualizar um pouco, estamos no final de janeiro. Nesse momento, o Gabriel já estava convencido que a gente iria conseguir fazer o app, o que era uma excelente notícia.
Mas vamos voltar à história.
O app estava funcionando com dados fantasiosos. Era hora de buscar os dados históricos verdadeiros no site da Bovespa.
Dados de ações
O site da Bovespa disponibilizava arquivos com os dados dos papéis negociados. Tinha o formato anual, mensal ou diário. Decidi que o app teria histórico desde 2007.
Baixei os arquivos de 2007 até 2016 e depois baixei o arquivo de cada dia.
Tinha um problema. Esse arquivo vinha num .txt numa formatação ruim de mexer. Tanto que eles tinham um MANUAL explicando como transformar esse .txt num arquivo legível (.xlsx, óbvio).
Esse é a formatação do arquivo que traz os dados históricos. Puro caos.
Apesar de eu não saber programar em Java, eu não era um completo analfabeto digital. Eu tinha masterizado a arte do Excel ao longo de 2 anos de consultoria. O Gabriel também.
Sempre que possível, a gente dava um jeito de jogar as coisas para o Excel e resolver por lá. Por que aí ao invés de demorar 10 horas para adicionar um botão, a gente resolvia rápido. Para tratar esses dados, não deu outra: fomos de Excel.
Só que tinha um problema grave: esses dados precisavam estar no formato .json.
Eu já tinha passado da fase do “Que porra é Json” para a fase do “Como é que eu vou passar os dados para Json??”
Tentei todos os conversores de .xlsx para .json do Github e ferramentas online. Nenhuma funcionou.
Lembra que na parte 1/15 eu falei para o Gabriel que eu aprendi a tocar guitarra só vendo vídeo no Youtube? Na verdade, eu não aprendi a tocar guitarra. Eu aprendi a reproduzir músicas que eu gosto na guitarra, mas não tenho a menor ideia do que eu to fazendo. Só imito o guitarrista.
Na programação estava seguindo uma linha parecida. Eu não tinha muita ideia do que aqueles códigos que convertiam de Excel para json faziam. Eu só rodava eles e via o resultado. Se não fosse do meu agrado, passava para o próximo. Só que nenhum estava funcionando.
Tive uma ideia!
Sempre jogava jogo de tabuleiro na casa de um amigo e as vezes o irmão dele jogava com a gente. Ele era doutor em física manjava de programação. Mandei uma mensagem para ele, expliquei a situação e perguntei se ele conseguia ajudar.
Ele fez meia dúzia de perguntas sobre o que eu precisava e mandou um script em Python que convertia o meu Excel para json.
Bingo.
Agora era só baixar o arquivo, tratar os dados e no fim rodar um python que transformava para o formato json e depois eu subia o arquivo. Com os dados históricos na nuvem, o app passou a ser funcional!
Uma observação interessante sobre esse processo de subir os dados: eu fiz esse processo todos os dias por uns 2 anos.
Sabe aquela história do Michael Phelps que dizia que treinava TODOS os dias? Mesmo quando não queria?
Fui buscar uma referência para não dizerem que estou criando história
Para o Real Valor não ficar com dados atrasados, eu precisava acordar antes do mercado abrir e fazer essa rotina todos os dias. Não importava se eu estava cansado, se eu estava viajando, ou qualquer outra coisa. Foram quase 2 anos fazendo isso religiosamente.
Pô, vamos ser sinceros aqui: além de respirar e comer, o que você faz TODOS os dias do ano? Até banho passa em branco de vez em quando. Mas não atualizar as bases.
Como “todo processo repetitivo pode ser automatizado” e dado os meus conhecimentos de Excel, esse processo foi quase todo automatizado (no Excel).
A planilha realizava os seguintes passos:
Entrava no site do Bovespa
Pulava um Captcha
Baixava o arquivo .zip
Unzipava
Tratava os dados no Excel
Salvava no drive para a gente ter backup
Abria o python para transformar em .json
No fim do texto, coloquei um link para um video dela funcionando em novembro de 17.
No fim, o trabalho era basicamente subir o .json no Firebase. O Thiago Ferolla automatizou essa última parte e melhorou o processo todo, tirando do Excel também.
Como era a dinâmica do trabalho
Acabei entrando muito a fundo nos desafios técnicos e não falei de como era a nossa dinâmica de trabalho.
A rotina era a mesma todos os dias: Gabriel me buscava em casa de carro umas 7:30-8:00 e a gente partia para a PUC, que ficava a uns 10 minutos da minha casa. Era 10 minutinhos ouvindo rap nacional e conversando pouco por causa do sono.
Chegando lá, a gente partia para a biblioteca do prédio de engenharia, que abria as 8:30 e trabalhava de lá.
O almoço era sempre num bar chamado Simpatia, na rua de trás da Puc.
Na volta do almoço, o Gabriel sempre parava para tomar um café e a gente aproveitava para trocar ideia com alguns amigos que estavam fazendo mestrado lá. Depois era subir para a biblioteca e trabalhar até o horário de fechar.
Trabalhando na presença de um amigo de tempos de colégio que também ia à PUC durante as férias universitárias porque estava fazendo mestrado.
Algumas vezes, precisamos estender o expediente porque estávamos no meio de um raciocínio e parecia que faltava pouco.
Mas como a biblioteca fechava, nesses dias eu recorria ao laboratório do Baja, que é uma equipe de competição de carros entre universidades. Como eu tinha sido capitão de lá, conhecia o pessoal e eles abriam o laboratório para eu e o Gabriel continuarmos programando.
Dinâmica de juntar o código
Eu trabalhava em algumas coisas e o Gabriel em outras. Quando a gente descobria algo que poderia ser útil para o outro, a gente mostrava um para o outro e assim era possível aprender no dobro da velocidade.
Cada um trabalhava em seu computador para ir aprimorando o MVP.
No fim do dia, cada um tinha progredido em uma direção e a gente precisava juntar esses códigos.
Exemplo de uma to-do list de 10/02/17. Eu fazia o que estava em vermelho e o Gabriel o que estava em azul.
A boa prática de programação diz que deveríamos usar um software de versionamento e juntar esses códigos através de um merge. Só que a gente não tinha a menor ideia das boas práticas de programação e tão pouco conhecíamos Git.
O merge era da seguinte forma: Eu mandava as linhas de código que eu tinha feito para o Gabriel via WhatsApp web e avisava em qual linha era para colocar. Óbvio que existia conflito. A gente ia tentando resolver no talento. Sim, faltava talento, o que era um problema. Mas sempre dava certo. Até porque a gente nem conseguia fazer muitas linhas de código por dia.
Depois disso, a gente zipava aquela versão no drive com um .txt explicando que cada um tinha feito no dia e o que aquele código era capaz de fazer. Assim, a gente tinha um backup.
A gente teve versão zipada com .txt até a versão cinquenta e poucos. Ai o Carlos Henrique Martins nos apresentou o Git.
O MVP do MVP estava pronto
Agora já temos um app semi-funcional.
Mas um app não é nada se os usuários não usam. Era chegada a hora de ir atrás de usuários para testarem.
Mas eu precisava achar onde eles estavam primeiro.
Além disso, precisamos de um nome, de um domínio, etc etc.
É sobre isso que eu vou falar na parte 3/15 na quarta feira que vem!
PS: Ficou curioso de ver a planilha rodando? https://youtu.be/sPbmnPSwfRc