Gastando muito com engenharia de produto? Um passo-a-passo para torná-la eficiente e barata.
“Vejo frequentemente times de tecnologia criando um headcount específico para cada coisa que vão executar. “Vou trabalhar com qualquer coisinha de dados, então vou atrás de um engenheiro e de alguns cientistas para resolver o meu problema”, mas, com o tempo, vemos que isso não está conectado com o fato da empresa ter tração. Os custos aumentam consideravelmente e não necessariamente a empresa dá passo pra frente”.
A fala é do Bruno Pereira, CEO da ElvenWorks. O Bruno é um dos pioneiros de computação em nuvem do Brasil. Antes de empreender em Elven, ele foi fundador da Rivendel, uma consultoria líder na migração para cloud de grandes empresas brasileiras. A consultoria foi vendida para a Mandic em Fevereiro de 2018 e, no início de 2020, ele fundou a ElvenWorks, uma plataforma de monitoramento de aplicações em cloud.
“Existe um certo fundamento para fazer esse tipo de escolha — dos times criarem um headcount para cada coisinha. Normalmente, o empreendedor recebia um termsheet e precisava crescer porque nos próximos 12–18 meses outra rodada iria acontecer. Era quase certeza, dado que existia mais capital disponível.”
Mas uma hora a conta chega. Com a alta da inflação brasileira e norte-americana, os investimentos em Venture Capital desaceleraram consideravelmente nos últimos meses. “O discurso saiu de um “Vamos crescer a todo custo” para um “vamos tentar criar um bom business”. O que é ótimo.”, diz o Bruno. “Mas, com isso, uma das principais áreas afetadas das startups é tecnologia (a grande essência das startups), que normalmente possuem custos e despesas relevantes.”
Dada a experiência em Rivendel e em ElvenWorks, Bruno viu de perto o quão danoso pode ser para a companhia imaginar que o “céu é o limite” e contratar (i) pessoas e (ii) arquitetura / serviços de engenharia para fazer um produto mais robusto. Na visão dele, principalmente para startups early stage, ter esse tipo de comportamento pode ser um grande tiro no pé.
Para criar engenharias e produtos mais baratos / eficientes, Bruno leva consigo um modelo mental — que, a priori, parece simples: não dar passos maiores do que as próprias pernas. O modelo tem como referência os conceitos iniciais de MVP, de 2010–2011, em que o Steve Blank e Eric Ries pregavam a ideia de construir um produto à medida que ele é testado e que a demanda batesse na porta do empreendedor — essencialmente, um processo iterativo. Na visão do Bruno, aplicar o conceito para a engenharia, produto e dados tende a criar bons resultados. “Por exemplo: você não precisa ter uma estrutura de software / infraestrutura, no early stage, para durar 5 anos — que é um dos principais erros dos CTOs. As vezes, ir para um caminho de aprender com o cliente, resolver uma dor específica e criar uma estrutura para 6 meses-1ano é o que vai permitir você crescer de uma maneira saudável e evitar desperdícios.”
O modelo veio com a experiência..
“Em ElvenWorks, começamos fazendo um processo iterativo, nos mantendo sempre próximos aos clientes. Mas um ponto que erramos foi na concepção da empresa. No começo, estávamos evitando, a qualquer custo, fazer serviço. Queríamos montar uma plataforma 100% SaaS — o que é justo, dado que tínhamos acabado de sair de uma consultoria— mas isso nos trouxe um grande erro, que nos fez perder tempo e dinheiro: achávamos que o produto tinha que ser o mais completo possível para os clientes, porque todos os problemas deveriam ser resolvidos por ele.”, conta o Bruno.
“No final do dia, tudo tinha que virar uma feature. Isso gerava uma grande pressão por um roadmap robusto, em que precisaríamos de uma engenharia bem complexa para colocar tudo aquilo no ar. Dá pra imaginar que os nossos custos com a arquitetura e com mão-de-obra fugiam do ideal.”
Com a experiência, veio o aprendizado. Do seu modelo mental de “não dar passos maiores do que as próprias pernas”, Bruno criou um passo-a-passo para que CTOs desenvolvam uma engenharia e produtos enxutos. O pensamento, segundo ele, vai desde a estruturação da arquitetura até a concepção dos times de desenvolvimento.
Passo 1: Valide com o mínimo de engenharia
If you’re not embarrassed by the first version of your product, you’ve launched too late — Reid Hoffman
“Uma engenharia estado da arte é em uma etapa muito à frente. No começo, faça de forma iterativa: tente vender. O que o seu cliente está pedindo é possível de você resolver? Necessariamente, nesse começo, você precisa fazer tudo de forma 100% escalável? Se o seu ticket for alto, a resposta provavelmente é não.” nos conta o Bruno.
“Um dos maiores erros que eu cometi foi ter pensado que todas as solicitações dos clientes iriam virar feature. Pode ser que num futuro isso seja verdade, mas você mais perde do que ganha tentando fazer isso no curto prazo.”
Principais trade-offs
Um importante cuidado é escolher, nessa fase de iteração, estratégias para você transformar aquilo em algo que o cliente vai querer pagar.
“Vamos supor que no começo eu não quero criar nenhuma plataforma e, por isso, crio um typeform para avaliar o potencial de uma ideia. Será que isso vai me trazer algum risco em relação à segurança? Tem chance dos dados vazarem? Ou, por exemplo: vai ser difícil eu mudar para uma nova arquitetura num futuro e puxar esses dados? Ter um senso crítico aqui é fundamental. Se o “MVP” de engenharia me inviabilizar o futuro, eu tenho que voltar pra prancheta e tenta pensar em algo maior.”
Além disso, Bruno conta sobre a importância da autonomia do seu time de produto. Se todo teste que você fizer tiver que passar por muitas etapas / aprovações, vai doer tanto o processo de teste que você ou seu time vão acabar desistindo.
“E, complementando: parece too much pensar nisso no early stage, mas não é: o Discord, por exemplo, que é uma plataforma que usamos no dia-a-dia, tem alguns pontos no termo de uso que fala que as informações dentro da plataforma podem ser analisadas e utilizadas da forma como a empresa (Discord) bem quiser. É até bizarro. Colocar dados de clientes, contratos e coisas do tipo em uma plataforma assim pode custar caro, mesmo no early stage.”
Aprendizados com ElvenWorks
“No começo, usamos uma única linguagem para o front-end e para o back-end — JavaScript. Também usamos um único banco relacional, mesmo sabendo que no futuro teríamos que trocar — em Elven, para cada finalidade específica, teríamos que ter um tipo de banco diferente. Também, fizemos um processo que tínhamos pouquíssima operação, que um time puramente de desenvolvimento conseguiria fazer (e que era a nossa expertise). Sempre pensávamos: o que é o essencial mesmo para eu resolver essa dor específica do cliente, sem eu perder a minha visão de plataforma? No nosso caso, eu precisava ter uma interface web e algumas APIs, .. o que dava para não acontecer no primeiro momento deixamos para revisar no futuro.”
Passo 2: Se mantenha fiel à competência do seu time core
“Vamos supor que você começa a empresa com um time full dev, sem ninguém de infraestrutura, começa com uma arquitetura / plataforma que permita que o dev publique tudo sem precisar de ninguém de infraestrutura. Você elimina distração e roda num modelo sem grandes trade-offs.” diz o Bruno.
“Em Elven, temos um time com uma competência de desenvolvimento de software, de infraestrutura e operação muito boas, mas não temos a mesma competência em arquitetura de dados e em segurança, por exemplo. O que fomos fazendo: ou utilizamos uma plataforma mais alto nível sem ter um profissional daquele setor, ou desenhamos uma estrutura que evitasse que uma grande profundidade em segurança. No nosso processo, algumas componentes de SaaS gerenciado que usamos foram levando a gente a navegar melhor no desenvolvimento do nosso produto”.
Se você não tem no seu time core competências fortes naquele tema, você dificilmente vai conseguir formar uma pessoa júnior.
“Um mantra que levamos aqui em Elven é: o que eu sou muito bom eu consigo executar e formar novas pessoas naquilo. O que eu não sou, vou procurar uma plataforma e parceiros que possam ter essa competência.. vou discutir com eles no nível que eu preciso, mas não vou tentar internalizar, porque as chances de não ser uma boa experiência são gigantescas.”
A escolha de um parceiro
“Ele precisa estar no nível de sofisticação e conhecimento com a sua necessidade. Quanto de experiência o parceiro tem em um cenário parecido com o que a sua empresa está passando?”
Na escolha de um bom parceiro de negócios, Bruno avalia três principais fatores que, segundo ele, vão definir se estão aptos ou não para fazer um bom trabalho com a sua startup.
- É um parceiro nacional ou internacional?
Você vai conseguir ser a prioridade daquele parceiro? Ele vai te dar todo o suporte necessário para o sucesso dessa nova área na sua empresa? A probabilidade de um parceiro internacional te dar um bom suporte é menor do que a do nacional fazer isso.
2. O tipo de cliente que o parceiro atende é o mesmo que você está encaixado?
Ele já fez trabalhos com empresas similares a sua? Ele conhece como o “seu mundo” funciona?
3. Coleta de referências com colegas.
Alguém que você conhece ou de alguma comunidade que você pode ter acesso já fez um trabalho com esse parceiro? “Às vezes”, diz o Bruno, “vale a pena demorar algumas semanas a mais procurando referências ou até mesmo fazendo uma POC do que tomar uma decisão errada.”
Passo 3: Saiba que complexidade e custo andam lado-a-lado
E aqui vem a parte difícil. “Temos que ter um grande cuidado em ter clareza se tudo aquilo que eu estou fazendo é a melhor alocação de tempo e recursos que eu poderia ter. Será que eu preciso ter 2 ou 3 tipos de bancos de dados no primeiro ano? Será que não dá para fazer algo um pouco mais simples e depois mudamos / revisamos? Será que precisamos ter 3–4 linguagens de programação na minha empresa no early-stage?” conta o Bruno.
“Existe até uma discussão sensível sobre alguns temas, como o de começar com uma estrutura de monolito versus a de microserviços. Na minha opinião, no curto prazo, o monolito pode ser uma bela de uma opção para os desenvolvedores — ele permite um aprendizado mais rápido e diminui um pouco da complexidade do sistema. Uma outra é a de contratação de mão-de-obra: no começo, tente priorizar a mão-de-obra que vai estar mais diretamente ligada com o aumento de receita. Para engenharia, alguém que vai começar resolvendo uma dor específica de um cliente (seja a partir de uma integração ou de um pequeno sistema, por exemplo) é melhor do que algúem que vai desenvolver algo focado no longo prazo.”
Aprendizados com ElvenWorks
“Um dos pontos que erramos — e que foi doloroso, foi que ficamos tentando por quase 1 ano ir para uma arquitetura mais complexa e um pouco mais sofisticada de datalake, que era dentro da Amazon. Vimos, depois desse tempo, dois problemas: (i) o meu time interno não conseguiria absorver, com amplitude, aquele ferramental e ter uma autonomia relevante. Eu sempre dependeria de um parceiro externo para suprir a mão de obra. Vimos também que (ii) ela era um pouco mais custosa — e a complexidade era maior do que precisaríamos. Para trazer uma ordem de grandeza: eu precisaria ter 1–2 pessoas novas contratadas (~BRL 30–40k de custo extra) + ~BRL 10k de estrutura de nuvem. Pro early stage, era um gasto totalmente desnecessário. Acabamos indo para uma solução mais médio prazista. Daqui 5 anos, provavelmente eu vou querer voltar para a minha solução original, mas até lá, eu vou estar muito mais robusto e preparado do que agora.”
