Na escola, a professora ensinava a fazer rascunho antes de passar a limpo. Você escrevia a redação, riscava, corrigia, reorganizava os parágrafos. Só então copiava tudo no papel definitivo, sem rasuras.
Ninguém entregava o rascunho como trabalho final.
No mundo dos produtos, a gente entrega o rascunho o tempo todo. A diferença é que ninguém chama de rascunho. Chama de MVP, de versão beta, de entrega rápida. E o rascunho, que deveria ser temporário, vai virando permanente.
Esse acúmulo tem um nome no mundo do desenvolvimento de software: dívida técnica. O conceito foi criado por Ward Cunningham em 1992 – um desenvolvedor que precisava explicar para gestores por que era necessário parar de entregar features e arrumar o código. A metáfora é perfeita: como numa dívida financeira, você toma um atalho agora e paga os juros depois. Se nunca pagar, vai à falência.
A sujeira que ninguém vê
O problema da dívida técnica é que ela é invisível para quem não está no código. O cliente não vê. O gestor não vê. O board não vê. Só o time de desenvolvimento vê – e sente, todos os dias.
Existe uma teoria da criminologia chamada Broken Windows, publicada em 1982 por George Kelling. A ideia é que sinais visíveis de desordem – uma janela quebrada não consertada, um prédio abandonado – funcionam como um convite para mais desordem. A negligência atrai mais negligência.
Nos produtos, funciona igual. Um código confuso convida mais código confuso. Uma tela com fluxo mal pensado convida mais gambiarras. Um processo cheio de etapas desnecessárias cresce com mais etapas.
E enquanto o time enxerga isso todos os dias, o gestor vê apenas que as entregas estão ficando mais lentas. Sem entender por quê.
A dívida cobra juros agora – não só no futuro
Há um erro comum de quem lida com dívida técnica pela primeira vez: achar que o problema é lá na frente. “Vamos limpar isso depois, quando tivermos mais tempo.”
O problema é que o “depois” não chega. E a dívida cobra juros hoje, não amanhã.
Lou Franco, engenheiro com mais de 30 anos de experiência, conta uma história que resume bem isso. Quando era gestor de desenvolvimento, priorizava apenas features. Ignorava a bagunça do código por anos. Um desenvolvedor foi embora e, na entrevista de desligamento, citou a dívida técnica como um dos motivos. O Franco chegou tarde demais à conclusão: a dívida não era um problema futuro. Era a razão pela qual seu time estava frustrado todos os dias.
Quando ele finalmente parou, reescreveu o sistema de build e instalação – um trabalho de um mês para um desenvolvedor. O resultado foi imediato: builds mais rápidos, menos bugs, menos tempo perdido. Não em dois anos. Na semana seguinte.
Velocidade de entrega não é só questão de esforço. É também questão de ambiente.
A tentação do recomeço
Quando a bagunça fica grande demais, aparece uma solução tentadora: jogar tudo fora e começar do zero.
Joel Spolsky, um dos fundadores do Trello, escreveu sobre isso num artigo chamado Things You Should Never Do. Ele dizia que a primeira reação de um programador ao ver um código ruim é querer demolir tudo e construir algo grandioso no lugar. E identificou o motivo:
“É mais difícil ler código do que escrevê-lo.”
O código antigo parece um caos porque você não consegue ler facilmente. Mas ele carrega anos de decisões, de bugs corrigidos, de casos de borda que ninguém documentou. Quando você joga tudo fora, joga esse conhecimento junto.
Isso não significa que grandes reescritas nunca fazem sentido. Às vezes fazem. Mas exigem tempo real, equipe real e apoio da liderança – não otimismo. E quando a decisão é pela reescrita, o ideal é não parar de entregar valor durante o processo. As duas coisas em paralelo.
Mostre o que ninguém está vendo
Para convencer uma organização a investir em “passar a limpo”, você precisa tornar o invisível visível.
Dashboards funcionam. Métricas de tempo de build, frequência de erros, tempo médio de revisão de código – tudo isso transforma uma sensação de lentidão em um número que qualquer gestor consegue entender. Quando você mostra que o time está gastando X horas por semana esperando um processo que deveria levar minutos, a conversa muda.
Mas há uma armadilha aqui. Se você apresentar a limpeza como um projeto de engenharia interna, vai ter dificuldade de conseguir prioridade. “Dívida técnica” não significa nada para um time de marketing, produto ou financeiro.
A solução é simples: não apresente a dívida, apresente o resultado da limpeza. Os médicos não falam sobre a higienização das mãos depois de uma cirurgia. Falam sobre o sucesso da operação. Você também não precisa falar sobre o código que foi refatorado. Fale sobre o que ficou mais rápido, mais estável, mais fácil de evoluir.
Passe a limpo enquanto entrega
A melhor forma de lidar com dívida é não deixá-la acumular. A segunda melhor é atacá-la junto com a entrega de valor.
Sempre que seu time vai trabalhar numa área problemática do produto, essa é a oportunidade. Você vai lá de qualquer jeito. Então limpa enquanto está lá. É a regra do escoteiro aplicada ao produto: deixe o acampamento mais limpo do que encontrou.
Isso funciona em qualquer camada do produto – não só no código. Um processo interno com doze etapas desnecessárias é dívida. Uma tela com quatro versões diferentes do mesmo botão é dívida. Uma funcionalidade que ninguém usa mas que ninguém tem coragem de remover é dívida. Uma integração que exige que o cliente faça manualmente o que a plataforma deveria fazer automaticamente é dívida.
Na 4yousee, tínhamos um fluxo em que o cliente precisava converter o vídeo para um formato compatível antes de fazer o upload. Dívida de produto. Quando resolvemos – convertendo automaticamente qualquer formato recebido – não anunciamos uma melhoria técnica. Anunciamos que o cliente não precisava mais se preocupar com formato de arquivo. Mesmo resultado, enquadramento diferente.
O rascunho nunca some
Todo produto começa como rascunho. É impossível – e indesejável – que a primeira versão seja perfeita. A velocidade de lançar e aprender é parte do processo.
O problema não é o rascunho. É achar que o rascunho já é o produto definitivo.
Passar a limpo não é uma tarefa de fim de projeto. É um hábito. Pequenas melhorias constantes, acopladas ao trabalho real, sem parar de entregar. Com o tempo, o produto que nasceu em papel amassado vai ficando mais claro, mais coeso, mais fácil de evoluir.
A professora tinha razão. O rascunho não é para entregar.
