Dívida Técnica: gestão estratégica entre velocidade e qualidade

Conceito de dívida técnica - Apresentação

Apresentando os instrutores e o tema do curso

Olá a todos, bem-vindos ao curso de Dívida Técnica. Nós somos Ederson Mello, trabalhamos como Coordenador e Líder Técnico de Data AI e de Engenharia de Software há muito tempo, e seremos instrutores nesta aula sobre Dívida Técnica.

No nosso dia a dia, estamos muito envolvidos em decisões técnicas que acabam afetando diretamente a evolução dos sistemas nos quais trabalhamos, especialmente em ambientes onde a velocidade e a qualidade estão sempre em conflito. Quando pensamos em velocidade, qualidade e conflito, pensamos no desenvolvimento moderno, que se refere ao uso de inteligência artificial também para desenvolver. Assim, quando usamos um copiloto ou um VibeCoding, podemos estar acelerando, ganhando velocidade, mas também podemos estar reduzindo a qualidade. Este é um dos conflitos que está surgindo e aumentando cada vez mais a questão da Dívida Técnica.

Introduzindo o conteúdo do curso

Portanto, parte das decisões, quando são tomadas ou geridas de forma inadequada, acabam se transformando em Dívida Técnica, e esse é o tema da nossa aula. Neste curso, abordaremos cinco aulas. A Aula 1 é sobre o que é a Dívida Técnica, sua origem e por que ela importa. Esta aula é extremamente importante para que, como líderes, possamos entender o contexto, identificar sinais, quais são esses sinais, quando agir, quando não agir, os tipos, e quando uma Dívida Técnica é saudável ou não. Sim, existe essa diferença.

Nesta aula, abordamos um contexto muito importante. Em seguida, teremos uma aula sobre como identificar e medir a Deuda Técnica com métricas e ferramentas. Nessa aula, discutiremos mais sobre essas medições, as ferramentas e o contexto de inteligência artificial.

Explorando decisões técnicas e estratégias de refatoração

Depois, teremos uma aula na qual falaremos sobre como tomar decisões técnicas e justificá-las para o negócio. É essencial que uma liderança saiba justificar essas decisões. Para a equipe, obviamente também, mas, em teoria, a liderança técnica já conhece o trabalho de desenvolvimento e está se desenvolvendo para níveis superiores. Portanto, essa aula tem grande importância.

Em seguida, discutiremos estratégias de refatoração incremental e redução de riscos. É importante saber o que refatorar e, principalmente, como trabalhar e agir para reduzir riscos.

Abordando cultura, processos e governança

Por último, falaremos sobre cultura, processos e governança para sistemas saudáveis. Assim, cobrimos todo o ciclo de vida, desde a identificação até a manutenção de um sistema de engenharia de software, com foco na Deuda Técnica.

Resumindo o curso e próximos passos

Em resumo, primeiro vamos entender o que é uma Deuda Técnica, depois como identificá-la no dia a dia, como medir e torná-la visível, como priorizar o que resolver e, por fim, como manter um sistema saudável ao longo do tempo. A ideia aqui não é apenas teoria, mas fornecer repertório para tomar a melhor decisão no contexto real.

Nos vemos na próxima aula.

Conceito de dívida técnica - O que é dívida técnica

Introduzindo o conceito de dívida técnica

Olá, bem-vindos à primeira aula sobre o que é dívida técnica. Esta é uma aula de contexto para que possamos entender exatamente do que estamos falando quando mencionamos dívida técnica. Antes disso, talvez precisemos dar um passo atrás e compreender um pouco sobre engenharia de software. É importante alinhar um ponto crucial: engenharia de software não se resume apenas a escrever código. Trata-se de tomar decisões e lidar com as consequências dessas decisões a longo prazo.

Quando pensamos em decisões a longo prazo, podemos afirmar que o software é um sistema vivo. Ele muda, cresce, recebe novas funcionalidades, e cada decisão que tomamos hoje influencia diretamente o quão fácil ou difícil será evoluir esse sistema no futuro. Este é um ponto extremamente importante a considerar. Todo sistema tende a começar bem. O código está organizado, a equipe é ágil, e as entregas fluem. Isso cria a sensação de que tudo está sob controle, funcionando bem. Com o tempo, começam as pressões: prazos curtos, necessidade de entregas rápidas, decisões tomadas no limite. Isso começa a se acumular.

Identificando sinais de dívida técnica

Então, surgem alguns sinais, e precisamos, como líderes técnicos, aprender a observá-los. Quais são esses sinais? Bugs estranhos, entregas mais lentas, medo de mexer no código, uma funcionalidade simples que leva dias para ser desenvolvida. Isso não acontece de repente; é uma acumulação silenciosa.

Compartilhando uma experiência prática

Gostaria de compartilhar uma experiência que tive há algum tempo. Fui líder técnico de vários times por dois anos, e um desses times trabalhava em um software com mais de 40 anos. Esse software começou com Cobol e foi migrado para Java, um linguagem que podemos considerar mais corporativa, devido à necessidade. Em uma versão específica, foi migrado por uma consultoria. O software continuou recebendo atualizações, mas, naquele momento, a consultoria saiu e outra entrou. Não havia documentação, e nem todas as pessoas permaneceram para a nova consultoria. Isso criou uma distância entre o que foi desenvolvido, o que foi projetado e o que restou.

Com o passar dos anos, muitas coisas foram se perdendo: o conhecimento foi se dissipando, a falta de documentação piorou, bibliotecas ficaram desatualizadas, as versões deixaram de ser atualizadas, e a pipeline deixou de ser corrigida e ajustada. Assim, tornou-se um software que funcionava, mas que todos tinham receio de modificar. Ninguém queria mexer, pois havia muitos módulos, que se interconectavam e se conectavam com serviços antigos e novos. Quando era necessário criar algo novo, geralmente se criava um novo módulo para adicionar. Até aí, de certa forma, não havia problema, exceto pelo fato de ser um software tão antigo e obsoleto, com tantas dívidas técnicas.

Abordando a dívida técnica em projetos

As equipes que precisavam desse software no dia a dia solicitavam à área de produto melhorias, inovações e ajustes. Apenas o que era possível fazer, e ainda assim com receio, era ajustado e entregue. Dessa forma, a dívida técnica crescia cada vez mais. Como líderes técnicos, trabalhando com arquitetura e engenharia de software, precisávamos garantir que essas equipes tivessem sinergia para corrigir isso. Chegamos a um projeto de migração de arquitetura, melhoria de desenvolvimento, documentação e testes. Havia muitos testes que nunca tinham sido realizados, então foi feito um acordo para que, a partir do momento em que tocássemos nos testes, eles passassem a ser desenvolvidos dentro de um padrão. Os testes anteriores ficariam como uma dívida técnica, mas uma dívida técnica acordada, controlada e, digamos, boa. Discutiremos isso na próxima aula.

Comparando dívida técnica com dívida financeira

Gosto de uma metáfora que compara a dívida financeira com a dívida técnica. A dívida técnica é a ideia de que aceleramos agora para pagar depois. Tomamos uma decisão rápida hoje, mas isso gera um custo futuro, que cresce com o tempo. Por isso, aprecio muito um conceito criado por Kanigan, um dos pioneiros do movimento ágil, que tem como ideia central algo muito simples: decisões técnicas que aceleram o presente geram um custo que deve ser pago no futuro. Quanto mais adiamos esse pagamento, mais juros se acumulam. Em resumo, tomamos um empréstimo hoje para resolver nosso problema atual, mas depois veremos se podemos pagá-lo ou não. Quando vamos pagar, essa dívida já é maior, o custo é maior, e já se prolongou. Isso torna todo o processo muito custoso. Por isso, gosto muito dessa metáfora para explicar e contextualizar melhor o que é uma dívida técnica. No entanto, nem toda dívida técnica é ruim, e falaremos sobre isso na próxima aula.

Conceito de dívida técnica - Nem toda dívida é ruim

Discutindo a dívida técnica e suas implicações

Na aula passada, discutimos sobre o que é a dívida técnica. Compartilhamos uma experiência que tivemos com um software, que foi a melhor experiência com o pior software e a pior solução do mundo, mas que, no final, deu certo. Também mencionamos que nem toda dívida técnica é ruim, e isso é verdade. Comentamos que, quando assumimos a responsabilidade por esse software, acordamos que, a partir do momento em que a equipe de engenharia de software começasse a desenvolver o que fosse necessário, haveria testes unitários, end-to-end (de ponta a ponta) e tudo mais. No entanto, o que já existia seria uma dívida técnica que pagaríamos depois, em um momento mais controlado. Isso funcionou porque havia uma coordenação e uma liderança técnica com o conhecimento e a capacidade necessárias, que é o que estamos adquirindo. Portanto, é muito importante entender que a dívida técnica nem sempre é um problema. Às vezes, ela é uma estratégia; podemos adotá-la como tal. Quando precisamos entregar algo rapidamente para validar uma ideia, podemos melhorá-la posteriormente. Essa pode ser uma estratégia, mas nem toda dívida é consciente ou estratégica.

Classificando os tipos de dívida técnica

Quando falamos de dívida técnica, basicamente pensamos em três tipos. Existe a dívida estratégica, na qual sabemos o que estamos fazendo, é assumida e consciente para alcançar um objetivo de negócio. Por exemplo, no caso mencionado, negociamos os testes para lançar um MVP (Produto Mínimo Viável) rapidamente, sabendo que depois teríamos que refatorar o código, pois até ali era um MVP.

Há também um tipo de dívida técnica que podemos chamar de acidental, que não percebemos, gerada por falta de conhecimento ou descuido, algo não planejado e que muitas vezes não é percebido até causar um problema real. Esse tipo de dívida aparece frequentemente quando não há uma liderança técnica que conheça adequadamente os processos, ou em equipes que talvez sejam muito inexperientes e estão desenvolvendo, ou em equipes que estão começando a desenvolver com VibeCoding e não aplicam a engenharia de software nesse desenvolvimento. Isso é real; já trabalhamos em equipes de inteligência artificial nas quais aplicamos a engenharia de software para resolver precisamente problemas que poderiam gerar dívidas técnicas futuras, enquanto resolvíamos as dívidas técnicas que já existiam quando entramos.

Identificando negligência e suas consequências

Por fim, existe a pura negligência, quando sabemos e ignoramos; o resultado de ignorar boas práticas conhecidas é mais prejudicial e reflete uma cultura de baixa qualidade da equipe, seja da direção ou da equipe que desenvolve. Portanto, é preciso entender, saber, conhecer e escolher a melhor estratégia.

Normalmente, a negligência se torna um padrão dentro da equipe quando ninguém se importa, pensando "entrego isso agora e depois resolvo". Muitas vezes, colocamos no backlog ou nem sequer fazemos isso, deixando apenas na memória ou em discussões com a equipe, esperando que alguém se lembre no futuro, mas sem resolver. Esse é o grande problema desse tipo de dívida.

Diferenciando dívida técnica, bugs e más práticas

Existem maneiras de identificar quando temos uma dívida técnica, um bug ou uma má prática. É um erro comum misturar esses conceitos, e precisamos entender claramente cada um deles. De forma clara e rápida: a dívida técnica é uma decisão que gera um custo futuro; é algo que resolvemos depois. O bug é um erro que precisamos corrigir, pois impede que o sistema funcione corretamente. Já a má prática é uma questão de baixa qualidade, que ocorre quando não conhecemos ou aplicamos padrões de desenvolvimento, ou quando a equipe é muito inexperiente e desconhece esses padrões.

Se não separarmos esses três conceitos, começamos a priorizar de forma incorreta. Quando priorizamos uma dívida técnica, um bug ou uma má prática, na verdade, não existe uma priorização para má prática; ela precisa ser trabalhada dentro da equipe para ser eliminada, trazendo conhecimento, estudo e técnicas. Muitas vezes, isso deve vir da direção, do tech lead para baixo, seja em uma revisão de código, na correção de uma pull request ou em uma orientação.

Exemplificando conceitos e priorizando problemas

Apresentamos um quadro com conceito, definição e um exemplo simples, mas comum no dia a dia. A dívida técnica é uma decisão consciente ou inconsciente que gera um custo futuro, como um módulo acoplado que dificulta novas funcionalidades. Um bug é um comportamento incorreto do sistema em relação ao esperado, como uma função que retorna um valor errado. Uma má prática é um código que viola padrões sem justificativa, como variáveis sem nomes semânticos ou valores definidos diretamente no código que deveriam ser variáveis.

É preciso entender bem a diferença entre esses três para poder separar o que é uma dívida técnica e, principalmente, qual priorizar. Um bug em produção com impacto financeiro é uma prioridade maior do que uma dívida técnica, mas menor do que um bug que deixa uma aplicação disponível apenas internamente. Precisamos diferenciar e separar tudo isso e, entre essas questões — entre um bug, uma queda em produção —, precisamos priorizar dívidas técnicas, alimentando a equipe com elas até que sejam eliminadas ou, pelo menos, até que comecem a abordar novas e futuras dívidas técnicas, ou aquelas que foram acordadas para serem resolvidas.

Concluindo e preparando para a próxima aula

Esperamos que os exemplos dados e o conhecimento transmitido aqui tenham ficado claros. Na próxima aula, vamos falar sobre as camadas que compõem a dívida técnica. Contamos com vocês. Até então!

Sobre o curso Dívida Técnica: gestão estratégica entre velocidade e qualidade

O curso Dívida Técnica: gestão estratégica entre velocidade e qualidade possui 89 minutos de vídeos, em um total de 39 atividades. Gostou? Conheça nossos outros cursos de Liderança em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Conceito de dívida técnica
• Identificação e diagnóstico
• Priorização e tomada de decisão
• Estratégias de mitigação e pagamento da dívida
• Sustentabilidade técnica e governança