Hoje a mobLee já é a maior plataforma mobile para eventos da América Latina! Com mais de 800 aplicativos publicados, já fizemos app para os 20 maiores eventos da América Latina, como Bienal do Livro de São Paulo e Salão do Automóvel. Nossa tecnologia já chegou às mãos de mais de 1 milhão de pessoas, mas há seis anos atrás a realidade era bem diferente.
Onde tudo começou
Em 2007, Steve Jobs apresentava ao mundo o iPhone, o smartphone da Apple, e nesse mesmo, ano o Google mostrava seu novo sistema operacional mobile, o Android. Enquanto isso, no Brasil, eu estava muito feliz com meu Motorola de flip, com tela colorida e joguinho de naves.
Mesmo quatro anos depois disso, em 2011, quando a mobLee foi fundada, ainda não era comum o uso de smartphones no Brasil. No final daquele ano, tínhamos apenas 9 milhões de smartphones, algo como 5% da população do país. Também me lembro que não se cogitava investir tanto em um celular, mas mesmo assim já havíamos vislumbrado uma mudança nesse jogo.
Primeiro contrato
Durante o ano de 2011, nessa expectativa que mercado mobile fosse estourar no Brasil, começamos a nos capacitar no desenvolvimento de aplicativos. Fizemos um drinking game para Android, o aplicativo das festas da UFSC e o app do encontro regional de design. Mas foi no final desse ano que nosso primeiro grande desafio apareceu, fomos contratados pela maior organizadora de feiras do Brasil para fazer aplicativos para 5 eventos no ano seguinte.
A mobLee tinha sido contratada para fazer o aplicativo dos seguintes eventos: Automec, Mecânica, PhotoImage, Agrishow e Fenasucro. Naquela época, eu mal tinha a consciência que estávamos trabalhando com algumas das maiores feiras setoriais B2B, não só do Brasil, mas como do mundo. Por exemplo, a feira Agrishow é uma das maiores feiras em área do mundo, tinha 440 mil metros quadrados em sua última edição. E a Automec é um evento que reúne mais de 1000 expositores de todo mundo e que trabalham no setor de autopeças.
Desafios tecnológicos
Com esse contrato em mãos e sabendo que os aplicativos dos eventos compartilhariam muitas funcionalidades, chegava o momento de escolher uma estratégia de execução. Sendo um pouco mais técnico, em 2011, não existiam muitas tecnologias para desenvolvimento híbrido e as que existiam, ainda não eram robustas e não encaixavam no nosso plano de mobile first.
Para vocês terem uma ideia, em 2011 o PhoneGap tinha sido recém adquirido, a empresa Xamarin tinha acabado de ser fundada e outras tecnologias como Ionic (2013) e React Native (2015) ainda nem existiam. Então, nossa decisão foi seguir com o desenvolvimento nativo, usando Java para o desenvolvimento para Android e Objective-C para o desenvolvimento para iOS. Tomamos essa decisão mesmo sabendo que teríamos que manter duas bases de código muito parecidas.
Primeiras entregas
Com a estratégia definida e tendo validado a interface com nosso cliente, iniciamos o desenvolvimento do primeiro aplicativo do evento que acontecia logo em março, aproximadamente 3 meses depois do fechamento do contrato. A cada aplicativo que entregávamos amadurecíamos a nossa base de código e copiávamos o código para iniciar o próximo app. Dessa forma conseguimos entregar os 5 aplicativos contratados:
Ainda durante a construção desses 5 primeiros apps, fomos demandados para construir mais 4 aplicativos para outros eventos desse organizador. Entravam na lista então os eventos: Movimat, Equipotel, Salão do Automóvel e Bienal do Livro de SP. Os últimos 2, como são eventos B2C, deixaram mais claro para a gente o tamanho dos eventos que estávamos lidando.
The big rewrite
Chegamos ao final de 2012 com 9 aplicativos entregues e muito aprendizado sobre o modelo de replicação de código. Estávamos com dificuldades de gerenciar as 18 bases de código que tínhamos criado (lembram que é dobrado por ser Android e iOS?) e isso gerava uma grande complexidade quando tínhamos que resolver bugs, republicar apps, mudar a interface, entre outros. A empresa que tinha nos demandado 9 aplicativos para 2012 agora nos demandava 16 novos apps para 2013.
Aproveitando tudo que aprendemos em 2012, decidimos tomar um caminho arriscado, reescrever todo nosso código. É uma técnica conhecida como The Big Rewrite, e o desafio é conseguir pesar quando é melhor refazer tudo do que consertar o que já está feito. Então no dia 21 de janeiro de 2013 demos o “First commit!” na nossa base de código Android que é usada até hoje. No iOS também começamos um projeto novo, mas esse já passou por outro Big Rewrite, papo para outro post.
A dor do crescimento
A partir dai fomos crescendo ano após ano, terminamos 2013 tendo feito mais de 25 eventos e 2014 com mais de 100. Com isso vimos alguns de nossos processos de construção de aplicativos engargalarem. Vou listar a seguir os 5 principais gargalos que encontramos durante esse crescimento, e também como fizemos para resolvê-los.
Gargalo #1 – Imagens
Problema: Sendo uma plataforma white label, a nossa expectativa é que os usuários do app tenham a sensação que o app é uma extensão da experiência do evento. Então, mesmo produzindo aplicativos por uma plataforma, fazíamos apps bastante customizáveis e chegávamos a gerar mais de 270 imagens para publicar um único app. Isso tomava muito tempo do nosso time de design que poderia estar investindo seu esforço melhorando a experiência do app.
Solução: Nossa solução, como vamos ver nos próximos gargalos, foi automatizar tudo. Hoje a plataforma já conta com um número considerável de imagens que são pintadas dinamicamente por código. Também automatizamos a geração de splash screens e screenshots necessárias nas lojas. Com isso temos um time de design focado em trazer uma experiência WOW para nossos clientes e usuários (mais detalhes nesse post).
Gargalo #2 – Configs
Problema: Como comentei, nossos apps são extremamente customizáveis, e a estratégia aqui é usar um mecanismo de flags que explicam para a plataforma como o app de um determinado evento vai funcionar. O problema que sofremos no começo era ter essas configs fixas em tempo de publicação, o que nos causava muita dor de cabeça quando precisávamos mudar coisas de apps já publicados, gerando republicações.
Solução: A solução aqui foi simples, jogamos todas essas configurações para o nosso CMS, e com isso temos total controle sobre o comportamento do app, mesmo que ele já esteja publicado. E mais que isso, a responsabilidade de configuração que antes era do nosso time de produto, agora é distribuída entre cliente e CS. (Por falar em CS, temos um time de CS lindo aqui na mobLee e sugiro a leitura de como ele foi construído)
Gargalo #3 – Strings
Problema: Para quem não conhece o termo, string nada mais é do que qualquer texto que aparece no app. Assim como as configs, as strings do app são altamente customizáveis, afinal cada evento define os termos que vai usar, uns usam agenda, outros programação, uns chamam de expositores, outros já consideram patrocinadores, e por aí vai. De novo, mais uma funcionalidade que precisávamos configurar em tempo de publicação.
Solução: A estratégia aqui foi igual a das configs, jogar tudo para o CMS. Dessa forma diminuímos consideravelmente a quantidade de republicação que tinham como único objetivo trocar um texto por outro.
Gargalo #4 – Publicação
Problema: Para que conseguimos mandar um aplicativo para a loja, tínhamos que executar um checklist de 30 passos, um para o iOS e outro para Android. Ou seja, 60 passos para que um evento pudesse ter seu app. Por ser uma atividade manual, ela era propensa a erros, e por muitas vezes nós nos causamos retrabalho por erros bobos. Além de ser propensa a erros, era um atividade que levava em média uma hora para ser executada, o que não chega a ser um problema quando tínhamos 9 apps, mas que escalou rápido com o crescimento da mobLee.
Solução: Como já comentei antes, a chave aqui foi a automatização. Boa parte dessas informações já estavam em algum lugar e só tínhamos que passar para os apps. O que fizemos aqui foi estruturar melhor o nosso CMS para que ele centralizasse tudo que precisávamos para a configuração de um app. Dessa forma, tanto nosso cliente, quanto nosso time de CS podem colocar no sistema tudo que é preciso e no final temos um script que é responsável pela construção do app.
Gargalo #5 – Lojas de apps
Problema: Quem já trabalhou com aplicativos já deve imaginar o que está por vir. Quando se trabalha com apps temos uma complexidade adicional que são as lojas de aplicativos. Diferente de sites que podem receber atualizações em tempo real, e quando você acessa pelo navegador, sempre está vendo a versão mais recente, com apps a história é diferente. Nem todos os usuários baixam a versão mais recente do app, e isso causa diversos problemas, como não ter acesso a correção de bugs e novas funcionalidades. Além disso, no caso da Apple, ainda temos outros n problemas. O desenvolvimento de apps para iOS é muito mais burocrático do que o do Android (e já foi mais), e depois de todo o trabalho construindo o app, ainda temos que esperar uma fila de revisão de apps. Esse processo de espera é pouquíssimo transparente, e além da Apple não te falar quanto tempo vai levar para revisar, ainda é possível ser rejeitado depois de dias.
Solução: Em relação à fila da Apple não se tem o que fazer. O que conseguimos desengargalar aqui foi todo o processo de criação de um app. Esse processo vai desde construí-lo nas lojas, mandar as informações, fazer upload de screenshots, configurar nossa plataforma, versionar automaticamente, até por fim fazer o upload do binário dos apps. A palavra chave aqui é fastlane, se você ainda não conhece, hoje é um bom dia para conhecê-lo.
Fechando
Tentei resumir um pouco dos aprendizados que tivemos ao longo dos mais de 6 anos que temos aqui na mobLee. Passamos um ano (2015) medindo o tempo que estávamos investindo em publicação de apps (incluindo aqueles 5 gargalos que citei) e no final do ano ficamos surpresos com quanto tempo desperdiçamos. Ao final de 2015 tínhamos investido mais de 28.211 minutos em publicações e republicações, o que dá mais de 470 horas e que seria mais ou menos 3 meses de um membro do time de produto só fazendo isso.
Tenho um conhecido que fala que as pessoas tem dificuldade de medir os pequenos deltas. Explico, se algo te tira 10 minutos todos os dias, ao final de um ano essa atividade consumiu mais de 40 horas do seu ano (contando só dias úteis), ou seja, uma semana de trabalho perdida. Por isso a importância de automatizar tudo, mesmo as coisas mais simples. Por outro lado, automatizar tudo desde o dia zero, pode aumentar o nível de complexidade de um projeto que ainda está em validação e pode gerar um ativo que vai ser descartado depois. Medir então é um dos primeiro passos, ter consciência do que está acontecendo para saber o momento de agir, muito alinhado com os pilares do Scrum que expliquei nesse post.
Gostou da nossa história? Curta, comente e compartilhe nas redes sociais! :)
Glauco é CTO e sócio na mobLee, maior fornecedora de aplicativos para eventos da América Latina. Já participou do desenvolvimento e publicação, como desenvolvedor, arquiteto ou líder técnico, de mais de 1.000 aplicativos para Android e iOS nos últimos seis anos, atingindo mais de 1 milhão de usuários. É Bacharel e Mestre em Ciências da Computação pela UFSC.
