Custo de Resgate - Tecnologia

O preço da ausência de estratégia técnica: um ano de retrabalho, milhões em prejuízo.

1. A complexidade invisível da tecnologia

Trabalhar com tecnologia não é algo trivial. Há diversas nuances e algumas delas são contraintuitivas.

Gosto de destacar que muitas pessoas têm dificuldades para entender o mundo "virtual". Frequentemente, quando faço metáforas convertendo conceitos de tecnologia em analogias com o mundo real, a compreensão acontece como se fosse uma revelação. Esse momento escancara o quão distante do universo digital essas pessoas estão.

Para quem atua em tecnologia, não é fácil fazer o papel de "tradutor". Muitas vezes, as pessoas balançam a cabeça afirmando que entenderam, mas, quando surge um exemplo prático, os questionamentos demonstram claramente que a compreensão não foi real.

Por exemplo: Um CEO, envolvido diretamente com o time de tecnologia na criação do próprio produto, definiu uma funcionalidade em que o usuário apenas colaria a URL de um vídeo do YouTube e a plataforma cuidaria de baixar o vídeo e fazer o upload automaticamente.

O problema é que, com o tempo, as políticas de privacidade do YouTube ficaram mais restritivas e alguns downloads passaram a ser bloqueados. Mesmo com os desenvolvedores explicando que o erro era decorrente dessas políticas, o CEO insistia que o problema era técnico e que deveria haver uma solução.

Ele dizia entender sobre leis de privacidade, mas reforçava que "deveria ser resolvido tecnicamente". Após várias tentativas frustradas, expliquei por analogia:

"Imagine que temos todos os carros na rua disponíveis para dirigir. O usuário pode pegar um carro e sair com ele, mas nós estamos fazendo isso por eles. Agora, os donos dos carros começaram a trancar com chave. Não podemos mais entrar. A única forma seria invadir o que seria um crime. Em outras palavras, o vídeo era público, mas agora está bloqueado para download e não podemos acessá-lo dessa forma."

Foi só então que ele entendeu.

Esse exemplo mostra como pode ser contraintuitivo, difícil de explicar e como se perde tempo com isso.

Para piorar, qualquer pessoa com dinheiro pode contratar um time e se tornar o "criador" de um produto digital. As barreiras de entrada são baixas. Esse cenário é comum e, como vimos no exemplo acima, a falta de entendimento técnico conduz a desperdício de tempo e dinheiro. E, infelizmente, pode piorar.

Quem lidera tecnologia toma decisões que podem custar caro em tempo, dinheiro e até na viabilidade do produto (ou da empresa). Decisões erradas geram um débito que, cedo ou tarde, alguém terá que pagar. O grande desafio é entender onde esse impacto será sentido.

2. Quando decisões erradas comprometem tudo

Na mesma empresa, outras decisões técnicas equivocadas foram tomadas:

1. Escolheram a tecnologia errada: buscavam inovação e escolheram um framework recém-lançado, instável e com abordagem contrária às boas práticas do mercado. Pouco tempo depois, o framework foi abandonado. Isso exigiu a troca da base do software, ou seja, refazer tudo. Imagine quatro anos de trabalho precisando ser reconstruídos o mais rápido possível.

2. Montaram a equipe errada: contrataram muitos desenvolvedores inexperientes. É compreensível que, no início, não haja orçamento para profissionais sêniores, e nem sempre há necessidade de soluções complexas. Mas isso exige um plano estratégico, o que nos leva ao próximo erro.

3. Escolheram o CTO errado: um desenvolvedor foi promovido a uma função estratégica sem preparo. Ele atuava como um executor, além de ser forçado a gerir a equipe (função tática). Aqui também pesa o orçamento, já que CTOs experientes são caros. E é importante lembrar: nem todo CTO serve para o início da jornada, assim como nem todo CTO de startup serve para uma empresa em fase de escala. Os desafios são diferentes. O ponto central aqui é que a definição da estratégia técnica — e da evolução do produto — deveria ser justamente responsabilidade do CTO. Quando essa função é ocupada por alguém com perfil operacional, a ausência de estratégia se torna inevitável.

Essas três decisões geraram um grande débito, com impacto direto no crescimento da empresa:

• Criar novas funcionalidades era demorado.

• Mesmo assim, as entregas tinham muitos bugs.

• Os problemas aumentavam com o tempo.

3. O que é o custo de resgate?

Dado esse cenário, entra o conceito de custo de resgate. Era necessário recuperar a área de tecnologia para que o negócio pudesse continuar.

Mas antes de falar do custo em si, havia outro problema: o dono não sabia que precisava ser resgatado.

Na visão dele, bastava contratar desenvolvedores mais experientes. Com essa crença, levou o produto até a fase seed, recebendo um aporte de cinco milhões de euros. O objetivo era gerar tração.

Os investidores indicaram uma empresa de recrutamento para encontrar talentos técnicos e foi assim que entrei na história.

Logo percebi: o problema não era só falta de desenvolvedores experientes. Era mais profundo.

A equipe técnica precisava reescrever todo o sistema em uma nova base tecnológica, lidar com a pressão por crescimento acelerado e equilibrar o retrabalho com a entrega de novas funcionalidades. Além disso, dois grandes buracos: quem definiria a estratégia para sair do buraco? E quem garantiria que essa estratégia seria executada corretamente?

Não faltavam apenas desenvolvedores experientes. Faltava um CTO para traçar a rota de saída e um gestor técnico para garantir a execução.

Sim, eu fui o CTO, o tech lead e o desenvolvedor. Para ilustrar: imagine um time de futebol que precisa melhorar as cobranças de escanteio. O treinador define a jogada, o batedor cobra e outro jogador finaliza de cabeça. Eu era o treinador, o batedor e quem corria para cabecear.

4. A estratégia para trocar o pneu com o carro andando

Qual foi a estratégia?

Primeiro, eu precisava garantir que seria possível trocar o pneu com o carro andando. No nível de infraestrutura, criei algo que desse liberdade ao time para construir o novo software sem que o usuário percebesse. Na prática, dois softwares rodavam e coexistiam de forma transparente. O usuário navegava e a infraestrutura alternava de um para o outro sem que ele notasse. Isso permitiu que o time começasse a criar funcionalidades no novo sistema com agilidade.

Segundo, era necessário adicionar processos de criação de software de forma cíclica: definir objetivos, planejar, executar, testar e lançar. Depois, repetir o ciclo. Com a estratégia definida, criei um plano de execução e garanti sua aplicação, então entrava meu papel como gestor técnico e garantidor dos processos.

Quais foram os processos?

1. Nada era criado sem antes ter discussões: Qual o objetivo? Como iríamos fazer? Estava claro para o time?

2. Defini responsabilidades: quem define tarefas, quem desenvolve, quem testa, quem lança, quem atua em caso de bug.

3. Como os desenvolvedores deveriam se organizar para trabalharem em conjunto: versionamento de código, avaliação de código.

4. Adicionei algumas diretrizes: o que fazemos em caso de problemas críticos? Como devemos testar? O que fazer se houver bug após o lançamento? Qual metodologia adotar (Kanban, Scrum)?

Também era necessário ter um roadmap que desse clareza sobre o que aconteceria, passo a passo. Isso ajudava a definir a ordem das ações.

A primeira fase e, inevitavelmente, a primeira em qualquer empresa com problemas técnicos é revisar e refazer os ambientes de desenvolvimento local e a infraestrutura. Não foi diferente. Tive que refazer todo o ambiente local, pois era custoso para os desenvolvedores trabalharem. Eles perdiam muito tempo apenas para conseguir rodar a aplicação. Algumas partes funcionavam apenas com hacks, outras apenas em produção, outras apenas na máquina de certos desenvolvedores.

O processo de deploy e integração de código também era lento. Para quem não tem familiaridade: para que todos os desenvolvedores possam trabalhar juntos, eles precisam atualizar o código constantemente e garantir que essas alterações funcionem bem para todos. Sem organização, um desenvolvedor atrapalha o outro e o ambiente vira um caos improdutivo.

Para resolver isso, utilizei técnicas padronizadas de mercado, como Gitflow e Trunk Based Flow (padrões de integração de código). Também criei automações que validavam as alterações, dando segurança para que os desenvolvedores codificassem com confiança. Além disso, foi preciso reconstruir a infraestrutura para suportar a estratégia que mencionei da coexistência dos dois softwares.

5. O custo real do resgate

Esse processo consumiu dois meses de trabalho árduo, com jornadas de cerca de 12 horas por dia. E aqui já podemos começar a mensurar o custo do resgate. Na época, em 2019, meu valor/hora era de 49,50 euros, e a cotação do euro era de R$6,30. Multiplicando por 12 horas diárias, 5 dias por semana, durante 2 meses, temos um custo operacional de aproximadamente R$149.940,00. Detalhe: esse valor não inclui o tempo de estratégia nem o trabalho de gestão. É apenas o custo operacional da reconstrução inicial.

Bom, o software inicial demorou quatro anos para ser construído. Quanto tempo seria necessário para reconstruir um novo do zero? Quatro anos? Seria até razoável... mas completamente inviável para o negócio.

Além disso, o negócio não poderia simplesmente esperar a reconstrução do novo software para lançar funcionalidades. Por outro lado, também não poderia seguir criando coisas novas no sistema antigo porque tudo demorava mais do que o necessário. Era como se o carro estivesse andando com o pneu furado.

A estratégia que criei buscava resolver ambos os cenários: permitir a criação rápida de novas funcionalidades e, ao mesmo tempo, viabilizar a reconstrução do sistema.

Após os dois meses iniciais de reestruturação, o time já conseguia criar funcionalidades novas no novo sistema com agilidade. Com o tempo, as partes críticas do sistema antigo foram sendo migradas, recriadas e integradas ao novo sistema. Em um ano, o software antigo foi completamente removido.

Aqui já conseguimos calcular o custo de resgate em termos de tempo. Esse período de um ano foi o tempo que a empresa continuou sendo penalizada. Apesar de já conseguir lançar novidades com mais rapidez, ainda havia a sobrecarga de ter que reconstruir o legado.

Ou seja, o potencial de criação do time estava cortado pela metade. Imagine se, ao invés de reconstruir o passado, o time pudesse ter se dedicado exclusivamente ao futuro do produto?

Para mensurar esse prejuízo em números, considere o seguinte: a equipe tinha quatro desenvolvedores, dois de backend e dois de frontend. No entanto, apenas um de cada atuou com esforço dobrado. Considerando €30 por hora para frontend e €50 para backend, durante um ano com jornadas duplicadas para metade da equipe (16h por dia, 5 dias por semana), o custo operacional aproximado foi de €499.200 (~R$3.144.960,00) apenas com trabalho técnico direto.

Esse valor é ainda mais significativo quando colocado em perspectiva: a empresa havia recebido R$5 milhões em investimento seed com o objetivo de escalar, mas cerca de 62% desse valor foi consumido apenas para recuperar a área de tecnologia.

Esse cenário não é isolado. Estudos mostram que até 90% do custo total de um software pode estar relacionado à sua manutenção ao longo da vida útil. Além disso, dívidas técnicas acumuladas podem consumir, em média, 25% do esforço de desenvolvimento em empresas de tecnologia. Ou seja, esse tipo de desperdício de capital é mais comum do que se imagina — e muitas vezes invisível para quem toma as decisões de investimento. E esse número não inclui gestão, testes, overheads ou o custo de oportunidade de não estar entregando apenas novas funcionalidades.

Aprendizados

O custo do resgate não é apenas financeiro. Ele se manifesta em várias frentes: tempo, energia, foco, motivação e, principalmente, nas oportunidades perdidas.

• Financeiro: mais de R$ 149 mil na fase inicial operacional e cerca de R$ 3,1 milhões ao longo de 1 ano de reconstrução.

• Tempo: 1 ano de equipe dividida entre reconstrução e evolução.

• Produtividade: o time poderia ter dobrado sua capacidade de inovação se não estivesse preso ao legado.

Algumas lições que ficam:

1. Escolhas técnicas erradas sempre cobram a conta. Às vezes, essa conta vem depois de alguns anos e o valor costuma ser alto.

2. Investir em maturidade organizacional é mais barato do que resgatar uma estrutura doente.

3. CTO não é apenas um programador promovido. É quem define a rota técnica e garante a saúde do produto.

4. Começar pequeno, mas certo, é mais estratégico do que começar grande e mal estruturado.

5. O tempo perdido reconstruindo poderia ser tempo ganhando mercado.

Em resumo: toda empresa que constrói tecnologia está fazendo apostas. Algumas erram cedo e têm a chance de corrigir. Outras erram tarde e pagam caro para serem resgatadas.