Também conhecido como dívida técnica, o débito técnico é um conceito no desenvolvimento de software utilizado para representar o custo implícito de uma implementação ou solução pensada somente no agora, elaborada para suprir demandas atuais, em vez fazer uso de uma abordagem de melhor qualidade. O motivo por trás de tudo isso? Diminuir o tempo de lançamento de determinado produto de software.
Mesmo que tenha se originado no setor de tecnologia, este conceito recebe o nome “débito técnico” devido a uma inspiração no mercado financeiro. Isso porque, as suas consequências se assemelham a uma dívida financeira, de cartão de crédito que, quando não quitada, faz com que você tenha que arcar com juros altos ao longo do tempo, aumentando ainda mais a dificuldade em pagá-la. Além disso, em termos de software, esta dívida cria a dificuldade de manutenção de código, e gera ainda mais atrasos e mudanças no produto final.
Neste conteúdo, vamos te nortear a respeito dos débitos técnicos com algumas dicas gerais. Confira!
Como zerar?
É impossível zerar o débito técnico! Você não leu errado. É isso mesmo: acreditar que a solução de todos os seus problemas é acabar com todo o débito técnico do seu projeto, é um tanto quanto ingênuo. A dívida técnica é inevitável e, portanto, sempre irá existir. A única coisa que nos resta fazer é controla-la o máximo possível.
Um exemplo disso é o envelhecimento de um código com o passar do tempo. Parece simples, mas é uma dívida técnica. Portanto, se você ou seu time está na luta para não ter débito técnico, saiba que isso é ruim, e é uma situação que recebe até um nome específico: Gold Plating.
Gold Plating
No setor de projetos, o gold plating representa o ato de entregar mais do que aquilo que foi solicitado pelo cliente. Uma atividade comum, mas que muitos ainda não compreendem o quão prejudicial ela pode ser.
Quando você entrega algo além dos desejos do cliente, pode acreditar que está deixando-o ainda mais satisfeito com o trabalho da sua equipe. No entanto, a situação pode ser exatamente o contrário e você acaba oferecendo soluções das quais ele não precisa ou deseja, causando uma insatisfação que poderia ser evitada.
A tentativa de acabar com todo e qualquer débito técnico existente em um projeto é uma das grandes responsáveis pela existência de tantos gold plating no setor de tecnologia, algo que causa diversas consequências aos projetos, que podem estar ligadas desde ao encarecimento dos produtos, da geração falsas expectativas aos clientes até o aumento dos riscos para o projeto e para a equipe.
Motivos do surgimento de um débito técnico
Os débitos técnicos podem surgir por diversos motivos, desde o fator tempo, citado acima, até situações mais delicadas.
Correr contra o tempo e trabalhar com prazos muito curtos faz com que a equipe deixe de olhar para a qualidade do produto, pensando apenas na velocidade para concluir tarefas. Por este motivo, estipular entregas em períodos de tempo irreais é uma das principais causas de débito técnico.
No entanto, existem outros motivos que provocam as dívidas técnicas. São eles:
- Falta de conhecimento técnico;
- Escolha de tecnologia inadequada;
- Passar do tempo;
- Falta de uma metodologia de desenvolvimento iterativa (sem feedback e teste do cliente).
Tipos de débito técnico
Além das diversas causas, existem 4 tipos de débito técnico, e podemos classificá-los da seguinte maneira, através do “Quadrante de Dívida Técnica, de Martin Fowler:
- Imprudente intencional: “Sabemos do problemas mas, não vamos resolver!”
- Imprudente não intencional: “Trabalhar com uma nova linguagem de programação”
- Consciente intencional: “Temos um prazo X, precisamos entregar com esse problemas, depois corrigimos”
- Consciente não intencional: “Agora que entregamos o projeto sabemos como deveríamos ter feito.”
Como mensurar tratar o débito técnico
Embora o conceito de débito seja subjetivo, existem diversas maneiras de mensurá-lo, sendo elas:
- Duplicação de código;
- Cobertura de testes;
- Fragilidade de builds;
- Linhas de código comentadas;
- Complexidade ciclomática;
- Coesão do código.
Leia também: Métricas para medir o débito técnico
Cada empresa lida com o débito técnico à sua maneira, geralmente de acordo com as metodologias seguidas no dia a dia. Para te dar um norte, vou explicar como fazemos no nosso ecossistema.
Se você trabalhar com SCRUM, pode deixar alguns pontos de folga, para que no final da SPRINT o time possa puxar alguns itens de correção de débito técnico.
Em último caso, você pode criar uma SPRINT ou uma Release apenas com correções de débito técnico. Nós particularmente não gostamos disso, pois não tem geração de valor real para o cliente final. Por isso, em grande parte das vezes, é bem interessante mesclar as técnicas utilizadas.
Para aprender melhor sobre como você pode evitar os débitos técnicos no seu negócio, recomendo que leia este conteúdo: Débito técnico: evite-o de uma vez por todas. Assim, você terá uma visão mais ampla a respeito das soluções.
Débito técnico versus Startups
Quando falamos de Startups, sempre falamos também sobre agilidade para testar hipóteses. Dessa maneira, muitas empresas acabam aceitando – até demais – o débito técnico em prol de lançarem seus produtos o mais rápido possível no mercado.
Este é um assunto um tanto quanto complexo e, para falarmos sobre isso, precisamos dividir as startups em duas etapas:
Antes do product-market-fit
Nesse momento, o objetivo principal da startup é validar seu modelo de negócio. E, sim, nessa fase é muito importante lançarmos o MVP o mais rápido possível. Aqui um pouco de débito técnico vale a pena, desde que esteja no quadrante “Consciente e intencional”.
Esta situação se justifica, pois é muito importante decidir o que será deixado de lado para que, em um futuro próximo, estes itens possam ser tratados sem muitos problemas. Nesse momento, especialistas e desenvolvedores podem fazer a diferença.
Escalando
Nessa fase é importante evitar ao máximo a dívida técnica e, inclusive, matar alguns débitos da fase anterior. A partir de agora, surgirão problemas de performance, usabilidade e arquiteturas, por exemplo, que são frutos de dívidas passadas.
Aqui, todo o cuidado é pouco! Afinal, como dito anteriormente, quanto mais débito deixamos, mais difícil fica trabalhar na manutenção do projeto. A partir daí precisamos ser mais exigentes em relação à qualidade do nosso código: defina padrões, faça ainda mais testes e invista em tudo o que for necessário para garantir um alto nível de qualidade.
