Gestão de débito técnico: o que é, o que gera, como calcular e reduzir?
TEMPO DE LEITURA: 12 MIN
No mundo financeiro, o termo débito carrega consigo um peso negativo. Desta maneira, acumular dívidas em cartões de crédito de forma imprudente é a receita mais certeira para o desastre. Contudo, a maneira mais viável para muitas pessoas que desejam atingir objetivos, como adquirir um imóvel, é através da realização de dívidas - que exigem um bom planejamento financeiro, certo?
Na década de 1990, o lendário desenvolvedor de software Ward Cunningham - inventor do wiki e coautor do Manifesto para Desenvolvimento Ágil de Software - propôs a ideia de que escrever e entregar software é como contrair dívidas.
A maioria dos desenvolvedores já teve a experiência de subir códigos para a produção, mesmo sabendo que os mesmos contêm falhas que resultarão em mais trabalho no futuro.
Cunningham vê isso como uma prática aceitável para ganhar participação de mercado ou cumprir prazos importantes, desde que seja contabilizada no planejamento de longo prazo.
"Um pouco de débito acelera o desenvolvimento, desde que seja paga prontamente com refatoração", disse ele, lá em 1992. "O perigo ocorre quando o débito não é pago. Cada minuto gasto em um código que não está totalmente correto para a tarefa de programação do momento conta como juros sobre esse débito. Organizações de engenharia inteiras podem ser paralisadas sob o peso da implementação não refatorada."
Essa ideia de débito técnico tornou-se crucial para os líderes de engenharia. Às vezes, a expressão é usada apenas como uma maneira de destacar que o código antigo foi apressado para a produção e que ninguém teve tempo de corrigir. Porém, um líder inteligente pode usar a ideia para quantificar as compensações entre a velocidade de desenvolvimento e a qualidade do código.
O que é débito técnico?
A forma mais útil de pensar no débito técnico é que ele representa o trabalho que você terá que fazer no futuro para refatorar ou atualizar o código que você está usando ou liberando para a produção hoje. Se a sua aplicação atual é propensa a erros ou é difícil de ser trabalhada pelos desenvolvedores, esse esforço extra representa os 'juros' que você está pagando pelo débito técnico incorrido no passado.
Embora isso deva funcionar como uma definição, as pessoas frequentemente querem dizer coisas diferentes quando falam sobre débito técnico. A engenheira da Mozilla, Chelsea Troy, diz que a expressão se tornou tão universal que as pessoas frequentemente "usam o termo para se referir a qualquer coisa que as incomoda ou assusta" em relação aos códigos que não gostam. Importante prestar atenção ao que as pessoas realmente estão falando quando usam o termo e buscar usá-lo com cautela.
Por que o débito técnico é importante?
O débito técnico é necessariamente ruim? Bem, às vezes pode ajudá-lo a chegar ao mercado mais rápido ou a lançar um MVP (Produto Mínimo Viável). Nestes casos, pode ser algo bom, ou pelo menos um mal necessário.
Como líder de engenharia, sua equipe estará sujeita a demandas contraditórias. Entregar código da mais alta qualidade no menor prazo possível é impossível. Como conceito, o débito técnico é importante para os gestores porque fornece um quadro de tomada de decisões quando se está sob pressão de tempo. Documentar e quantificar os atalhos que você toma hoje na corrida por um produto mínimo viável pode ajudá-lo a planejar a refatoração e a melhoria do código no futuro - ou pelo menos a perceber que algum trabalho simplesmente não pode ser adiado.
O conceito de débito técnico também pode ajudá-lo a gerenciar quando você está lidando com um código caótico que já está em produção, mas precisa ser melhorado. Determinar quanto tempo você gasta lidando com uma infraestrutura abaixo do ideal - os juros que você está pagando pelo débito contraído há muito tempo - pode ajudá-lo a justificar o esforço de hoje para refatorar o código e caminhar em direção a um futuro sem débito técnico.
Tipos de débito técnico: planejado e não planejado
O débito técnico pode se enquadrar em duas categorias amplas: planejado e não planejado. Em um ensaio influente, Martin Fowler abraçou essa dicotomia e também sugeriu outra: uma distinção entre débito imprudente e prudente.
Débito prudente é contabilizado quando é assumido, enquanto o débito imprudente é acumulado sem muita reflexão sobre as consequências. Isso leva ao que ele chama de quadrante de débito técnico:
- Deliberado/imprudente: "Não temos tempo para projetar isso corretamente, então não o faremos."
- Deliberado/prudente: "Avaliamos os riscos deste design e vamos implementá-lo, sabendo das consequências que teremos que lidar no futuro."
- Inadvertido/imprudente: "Tudo provavelmente vai dar certo!" [As coisas acabam não dando certo]
- Inadvertido/prudente: "Perdemos alguns problemas durante o desenvolvimento, mas estamos acompanhando à medida que surgem e aprendendo com nossos erros."
É desnecessário dizer que, como líder de engenharia, você deve incentivar suas equipes a serem prudentes em vez de imprudentes ao assumir débito técnico e a fazer as coisas deliberadamente em vez de inadvertidamente.
A essa dicotomia, podemos adicionar outro tipo: débito ambiental, às vezes chamado de bitrot. Isso representa a degradação lenta de um sistema em uso por muitos anos, com complexidade e erros acumulados por meio de mudanças lentas e incrementais, às vezes implementadas por pessoas que não estavam envolvidas no lançamento inicial. Isso é uma forma de dívida inadvertida, mas surge mais por meio da entropia do que por algo que pode ser rastreado até uma decisão ruim. Ainda assim, produz consequências negativas e trabalho, e deve ser tratado da mesma forma que outros tipos de débito.
Quais são as causas do débito técnico?
Até agora, temos falado em termos um tanto abstratos. Vamos entrar em detalhes e discutir alguns cenários mais específicos que podem levar a sua equipe a lidar com débito técnico quando preferiria estar criando novos recursos ou aplicativos.
- Pressão de tempo: esta é provavelmente a razão mais comum pela qual as equipes assumem débito técnico. Seu trabalho como líder de engenharia é ajudar a priorizar as tarefas e acompanhar o trabalho que está sendo adiado na busca por um prazo curto.
- Requisitos de projeto ambíguos: se não estiver claro quais são os objetivos finais de sua equipe, isso aumenta as chances de eles lançarem um código que precisa ser refeito ou reescrito completamente mais tarde. Os líderes de equipe precisam trabalhar com todas as partes interessadas para tornar os requisitos do projeto o mais claros possível desde o início, a fim de evitar trabalhos futuros.
- Código ruim: um problema básico e óbvio que pode ter repercussões infinitamente irritantes. Um código bem escrito é mais fácil de implementar, trabalhar posteriormente e integrar com novos módulos. Já o código ruim, atrasa o desenvolvimento futuro e consome tempo quando eventualmente precisar ser reescrito.
- Más escolhas de ferramentas: como líder de engenharia, você precisa garantir que as ferramentas escolhidas para o ambiente de desenvolvimento sejam as melhores disponíveis e adequadas ao caso de negócios; caso contrário, resultarão em desperdício de recursos a longo prazo e, eventualmente, precisarão ser substituídas.
Documentação ruim: não subestime quanto tempo e esforço serão desperdiçados no futuro se você não documentar adequadamente seu código quando o escrever. Certifique-se de que sua equipe tenha processos para documentar módulos à medida que são escritos.
- Falta de testes: o desenvolvimento orientado por testes deve ser um requisito básico em um ambiente moderno. O código que não é completamente testado quando é lançado quase certamente incluirá erros e exigirá esforço para corrigir posteriormente.
- Mudança ao longo do tempo: mesmo as bases de código mais bem planejadas e bem implementadas exigem cada vez mais manutenção e esforço ao longo do tempo. As necessidades comerciais impulsionam solicitações de novos recursos; mudanças no cenário de cibersegurança exigem correções e revisões; linguagens de programação, bibliotecas de código e estruturas de desenvolvimento se tornam obsoletas. Como líder de engenharia, você precisará reconhecer quando será necessário um esforço para lidar com o débito que se acumula para evitar que ele consuma tanto tempo ao ponto de ser necessária uma extensa reescrita do aplicativo
Como gerenciar e reduzir o débito técnico?
Quer você tenha gerado débito técnico por boas ou más razões - ou esteja assumindo débitos já acumulados - parte do seu trabalho como líder de engenharia é ajudar a gerenciar e reduzir esse débito para que sua equipe possa focar mais energia na construção de novos recursos e aplicativos.
Uma das principais problemáticas do débito técnico é que ele consome tempo e esforço do desenvolvedor que deveria estar focado em tarefas mais produtivas. Contudo, apesar de parecer contraproducente a curto prazo, pense nisso como uma dor imediata para ganhos a longo prazo. Como, por exemplo, quando cortamos gastos por alguns meses para pagar o cartão de crédito e liberamos espaço no orçamento para gastos opcionais no futuro.
Aqui estão algumas práticas que você, como líder de engenharia, pode implementar para ajudar a gerenciar e reduzir o débito técnico:
- Envolva sua equipe. Muitos desenvolvedores que não estão familiarizados com o termo débito técnico (ou que apenas o usam para se referir a "algo que os incomoda") podem se ater a pensar no esforço que o débito técnico consome na rotina. Procure mostrar a eles como o débito pode ajudá-los a curto prazo, mas requer atenção a longo prazo para facilitar suas vidas.
- Mantenha um inventário do seu débito: Você está optando por atalhos durante o lançamento de um produto ou recurso? Documente o que você está fazendo (ou não está fazendo) e esboce o que precisa ser feito para refatorar as coisas adequadamente, e quando você acha que isso precisa acontecer. Os desenvolvedores estão batendo cabeça contra o mesmo código mal escrito várias vezes? Peça a eles que descubram os parâmetros do problema e tentem entender soluções potenciais em vez de apenas balançar a cabeça e resmungar.
- Inclua a resolução do débito no seu fluxo de trabalho: Uma vez que você sabe com o que está lidando em termos de débito técnico, você precisa incorporar o processo de resolução dele na rotina diária da sua equipe. Isso significa adicionar tarefas relacionadas à resolução do débito à sua lista de tarefas pendentes e estabelecer prazos específicos para concluí-las, em vez de deixá-las para quando os membros da equipe tiverem tempo extra.
Também garanta que seus desenvolvedores saibam que completar essas tarefas é tão importante quanto qualquer outra coisa em sua lista, recompensando-os adequadamente.
Na Mentoria CTO do IFTL, você aprende como aplicar as melhores práticas de desenvolvimento e engenharia e otimizar os recursos de tecnologia para o negócio. Candidate-se para a próxima turma e faça como as mais de 800 pessoas que já passaram pela formação de liderança técnica do IFTL.
.png)
Outra maneira de reduzir débito técnico é investindo em uma arquitetura evolutiva. Falarei mais sobre o tema em um próximo artigo.
Como explicar o débito técnico aos stakeholders?
Não estamos aqui para debater o quão bem a metáfora do débito financeira se aplica ao que chamamos de débito técnico, mas ele definitivamente tem uma vantagem: executivos e tomadores de decisão não técnicos, que muitas vezes se concentram nos aspectos financeiros da gestão de negócios, podem entender rapidamente o que você quer dizer com isso. Isso é importante porque pedir tempo e recursos para melhorar o código que já está em produção pode ser uma venda difícil.
Discutir o débito técnico com executivos ajuda a chegar preparado com números para levantar questões como:
- Quanto tempo sua equipe está desperdiçando com trabalho que poderia ser resolvido com um esforço focado?
- Quais são os impactos de um aplicativo que funciona com uma qualidade mediana no atendimento ao cliente ou nas vendas?
- Que tipo de vantagem você pode obter ao lançar um aplicativo ou recurso rapidamente, mesmo que isso signifique trabalhar para refatorá-lo no futuro?
As respostas a essas perguntas podem dar à sua equipe o tempo e o espaço de que precisam para lidar com o débito técnico.
Como calcular o débito técnico?
Fornecer esses números é mais fácil de apontar do que calcular, mas existem várias técnicas e métricas que você pode usar para fazê-lo. Uma das mais proeminentes é a carga de manutenção - ou seja, quanto esforço sua equipe precisa colocar apenas para manter um aplicativo funcionando com os recursos que já possui. Quanto maior a carga de manutenção, menos tempo e energia os membros da equipe têm para lançar novos recursos ou melhorias.
Existem várias outras métricas que você pode usar para avaliar sua carga de débito atual. Essas métricas variam desde as relativamente simples, como uma proporção de problemas resolvidos para não resolvidos, até métricas mais complexas e subjetivas, como a Taxa de Dívida Técnica (TDR), que pode ajudar a estimar o custo de escrever código em comparação com o custo de remediação no futuro.
Seja qual for a técnica que você usa para calcular seu débito atual e futuro, saiba que apenas reconhecer essa dívida o coloca no estágio 'deliberado' do quadrante de débito técnico, que é exatamente onde você deseja começar.
Co-Founder IFTL
Danrley Morais
Empreendedor de tecnologia, com formação em Sistemas de Informação, iniciou sua carreira aos 13 anos como desenvolvedor e desde então atua nos mais variados projetos com desafios de escalabilidade. Aos 20 anos começou a empreender e se tornou sócio LinkApi, onde atuou como CTO liderando o time de produto e engenharia até a aquisição realizada pela Semantix em uma transação que ultrapassou R$ 100 milhões. Atualmente é sócio e CTO na IFTL, palestrante e tech advisor em 4 startups.
.svg){kind=icon}
.svg){kind=icon}
Co-Founder IFTL
Danrley Morais
Empreendedor de tecnologia, com formação em Sistemas de Informação, iniciou sua carreira aos 13 anos como desenvolvedor e desde então atua nos mais variados projetos com desafios de escalabilidade. Aos 20 anos começou a empreender e se tornou sócio LinkApi, onde atuou como CTO liderando o time de produto e engenharia até a aquisição realizada pela Semantix em uma transação que ultrapassou R$ 100 milhões. Atualmente é sócio e CTO na IFTL, palestrante e tech advisor em 4 startups.
Ver perfil do autor
