Jeremie Lebrun está na BlaBlaCar há seis anos, após uma década passada em consultoria. Hoje, como Head of Engineering, Corporate Services, lidera uma equipa de 35 pessoas responsável por todas as ferramentas internas da empresa: portáteis, redes, ferramentas de RH, finanças, CRM, automação e aplicações relacionadas com a atividade de autocarros. Em resumo, tudo o que não se destina diretamente aos utilizadores finais, mas que permite aos 800 colaboradores, distribuídos por seis países, trabalhar de forma eficiente.

Que critérios técnicos e de negócio orientam as escolhas entre desenvolver uma solução internamente ou utilizar uma ferramenta de terceiros?

Jeremie Lebrun: Provavelmente não somos muito originais: por um lado, os programadores são um recurso raro. Por outro, existem soluções no mercado concebidas por pessoas mais maduras do que nós em muitos temas, que já pensaram bastante sobre eles.

O nosso princípio é simples: tudo o que é diferenciador face à concorrência e contribui para avançar a nossa visão de produto, desenvolvemos internamente. Pelo contrário, tudo o que não é diferenciador, procuramos «pronto a usar». Por exemplo, não faz sentido desenvolvermos software de finanças e contabilidade. Por outro lado, para os nossos algoritmos de moderação de trocas entre passageiros de boleias, somos os únicos com a experiência e o contexto de negócio. Isso permanece em desenvolvimento interno.

Mas entre os dois extremos existe uma zona cinzenta. As arbitragens são então feitas com base em critérios de manutenibilidade, cobertura de mercado, custo e impacto organizacional.

Um exemplo: para o serviço BlaBlaCar Bus, tivemos de implementar um sistema de comunicação com passageiros em caso de atrasos. Inicialmente, comprámos uma solução existente porque não tínhamos equipa disponível e ainda não sabíamos exatamente o que queríamos. Dois anos depois, quando os desafios se tornaram mais específicos, internalizámos o desenvolvimento.

Como se avalia o custo real de «construir» versus o custo de «comprar»?

Jeremie Lebrun: Do lado do construir, é preciso calcular: que equipa está envolvida, durante quanto tempo, com que infraestrutura e complexidade de produto. A nossa experiência permite-nos estimar a dimensão da equipa necessária e o prazo de entrega. Tentamos sempre manter-nos nas tecnologias que já dominamos, para evitar acrescentar dívida técnica desnecessária.

Do lado do comprar, não se trata apenas de licenças. Há sempre um custo de configuração, ligação a sistemas internos, administração, segurança e produto. Depois, é preciso contabilizar a manutenção ao longo do tempo. Um SaaS não elimina problemas: também traz a sua quota de evoluções e restrições.

A dependência do fornecedor faz parte da escolha inicial. Não se pode querer tudo ao mesmo tempo: quando se escolhe uma solução SaaS, é preciso aceitar alguma dependência, assumi-la e geri-la em conformidade.

Num contexto como o da BlaBlaCar, onde a plataforma tem de suportar um crescimento forte e picos de tráfego, quais são as decisões de construir vs comprar mais estruturantes?

Jeremie Lebrun: Temos uma abordagem pragmática: a dívida técnica não é um palavrão. Pode ter valor se permitir acelerar o time-to-market. O importante é aceitá-la coletivamente desde o início, como uma dívida financeira: sabemos que teremos de a pagar mais tarde, mas o benefício imediato pode ser maior do que o custo futuro.

Exemplo: para o nosso sistema de envio de SMS a passageiros, primeiro comprámos uma solução externa. Durante dois anos, enviámos mais de 4 milhões de SMS, o que nos permitiu ganhar mais de 10 pontos de NPS. Quando internalizámos, sabíamos exatamente o que queríamos fazer. O trabalho puro de programação ainda estava por fazer, mas 80% do trabalho de gestão de produto já tinha sido concluído, o que tornou o desenvolvimento mais rápido e pertinente.

Arrepende-se de alguma das suas escolhas?

Jeremie Lebrun: Houve casos em que não escolhemos o parceiro certo e tivemos de mudar. Mas, no geral, são ajustes normais na vida de um projeto de engenharia, e tivemos a sorte de não nos arrependermos de uma escolha entre construir e comprar.

Como é que as escolhas de construir vs comprar influenciam a cultura tecnológica e a organização das equipas na BlaBlaCar?

Jeremie Lebrun: Historicamente, a BlaBlaCar tem uma forte cultura tecnológica: tudo era desenvolvido internamente. A introdução de soluções SaaS e low-code exigiu, portanto, um verdadeiro trabalho pedagógico. Foi preciso despolitizar o debate: claro que os nossos programadores conseguem programar tudo, mas o seu tempo é precioso. Desenvolver uma ferramenta de ticketing não faria sentido.

Isto também implica gestão da mudança: uma squad ágil que entrega a cada duas semanas não funciona ao mesmo ritmo que um fornecedor SaaS que implementa uma nova versão a cada dois meses. Foi necessário harmonizar métodos de trabalho, simplificar a comunicação e alinhar expectativas.

Não existe também uma questão de ego a gerir entre os programadores?

Jeremie Lebrun: Sim, como em todo o lado quando se comparam duas abordagens. Mas existem perfis de programadores que gostam de se orientar para o ecossistema SaaS, como o Salesforce. Outros estão cansados de programar sempre as mesmas coisas e encontram um novo fôlego na administração ou integração. O essencial é despolitizar a questão: sim, os nossos programadores conseguem fazer tudo, mas por vezes é mais inteligente utilizar uma solução que já está 80% pronta.

Que conselho daria a startups e scale-ups que enfrentam estas escolhas?

Jeremie Lebrun: Manter-se muito aberto e objetivo. Muitas scale-ups querem construir tudo internamente, mas rapidamente externalizam a parte «ops» (CRM, automação). O que importa é ter em conta o custo completo: construção, manutenção, organização, dependência. Não há escolha inerentemente boa ou má, apenas boas ou más análises.

E acima de tudo: não considerar como garantida a natureza escalável ou não escalável de qualquer tecnologia. Na BlaBlaCar, enviámos milhões de SMS através de uma solução low-code, com sucesso. Mas para que isto funcione, o projeto tem de ser apoiado por equipas técnicas (arquitetura, testes) e não apenas por equipas de negócio. Caso contrário, o risco é que a solução não escale.

Pontos-chave

• A BlaBlaCar desenvolve internamente funcionalidades essenciais e diferenciadoras, e utiliza soluções de terceiros para processos padrão.
• A avaliação de custos inclui não apenas desenvolvimento ou licenciamento, mas também manutenção e impacto organizacional.
• A dívida técnica pode ser uma alavanca estratégica se acompanhada de um ROI claro.
• A integração de SaaS e low-code exige um verdadeiro trabalho de gestão da mudança e comunicação entre equipas.