Gerenciando Dívida Técnica com DX e IA

Toda empresa, grande ou pequena, se preocupa com a dívida técnica. A Gartner estima que cerca de 40% dos sistemas de infraestrutura têm esse problema. Em uma pesquisa de CIOs pela McKinsey, quase um terço sentiu que mais de 20% do seu orçamento de novo produto foi gasto para resolver problemas relacionados à dívida técnica. Mas, contrariamente ao que muitos acreditam, isso não é apenas um problema de codificação; é também um problema de experiência do desenvolvedor (DX). Porque quando os desenvolvedores têm que trabalhar com arquitetura inadequada, ferramentas obsoletas e fluxos de desenvolvimento de baixa qualidade, a produtividade, o desempenho e a moral sofrem.

Priorizar a dívida técnica com o desenvolvedor em mente, focando em como eles abordam o trabalho, quais ferramentas usam e quais avanços de carreira podem obter, ajuda as equipes a se concentrar e a entregar mais rapidamente. É por isso que a forma como as empresas gerenciam a dívida técnica está mudando, impulsionada pela DX e por um foco aumentado em ferramentas alimentadas por IA.

Defendendo a DX

A forma como os desenvolvedores são geralmente incorporados deixa muito a desejar. Pode levar algumas semanas para que alguém comece a contribuir para um projeto. Uma vez que eles finalmente conseguiram adicionar recursos ou patches pequenos, não é incomum ver o serviço de integração contínua (CI) falhando devido a algo completamente não relacionado às alterações que eles trabalharam. Isso é basicamente a suíte de testes falhando devido a problemas de qualidade ruins, e o desenvolvedor não enviou alterações para fazer a suíte de testes falhar. É um teste fraco, mal escrito, que só funciona 90% do tempo. A equipe existente provavelmente está ok com isso – apenas desacelera os processos – mas as ferramentas podem ser obsoletas e desmoralizantes para qualquer pessoa fora da organização.

Este é apenas um exemplo de muitos que impedem a DX certa. Uma maneira de prevenir isso é ter um campeão designado em sua equipe de engenharia e desenvolvimento de software. Muitas pequenas organizações não têm um líder de DX, mas as grandes e bem-sucedidas têm. Esses profissionais acompanham coisas como o tempo que leva para um novo desenvolvedor configurar um ambiente. E se duas semanas são muito tempo, eles descobrem como cortar esse tempo pela metade.

Há ferramentas lá para ajudar, como o CircleCI, com recursos nativos que acompanharão a instabilidade de uma suíte de testes. O que é necessário é alguém para liderar e parar após cada sprint para abordar algumas das alterações que tornarão o código mais fácil de manter e trabalhar no futuro. Isso se resume a ter um líder interessado em melhorar a DX. Para fazer isso acontecer, procure um engenheiro de nível sênior, acompanhado por um membro da equipe relativamente novo que possa fornecer feedback sobre possíveis lacunas.

Além disso, a IDC espera que o mercado de automação de testes de software alimentado por IA continue crescendo a uma taxa de 31,2% ao ano até 2027, então certifique-se de que você está aproveitando ao máximo essa tecnologia.

Métricas e sinais de alerta

Há muitas métricas que você pode acompanhar ao avaliar como a dívida técnica está afetando sua equipe. Algumas básicas são “tempo para consertar” ou “tempo para recurso”. Digamos que você nota um bug e sabe como consertá-lo. Algumas ferramentas podem acompanhar o tempo gasto desde a escrita do código até a produção. Por exemplo, você poderia ver que um patch muito pequeno levou dois dias de negócios para consertar e enviar, quando sua equipe precisa ser capaz de fazer isso em horas. Você também pode acompanhar razões, como o número de correções de bugs versus os recursos concluídos.

Também há maneiras de identificar quando problemas de moral afetam o desempenho de sua equipe. Líderes de DX podem realizar pesquisas trimestrais para determinar quão feliz um desenvolvedor está trabalhando em um projeto ou parte dele. Eles podem se aprofundar e perguntar sobre áreas específicas, como o processo de CI. E você sempre pode acompanhar a rotatividade ou turnover em sua equipe. Se você notar que as pessoas continuam saindo, elas podem se sentir como se suas preocupações não estivessem sendo ouvidas.

Brincando com IA

O surgimento de ferramentas de IA é suposto tornar os desenvolvedores e engenheiros mais produtivos e os produtos mais rápidos, mas a dívida técnica desacelera isso. Digamos que você use uma ferramenta como o GitHub ou o Copilot para ajudar com alterações de código, então envie o pedido de pull, e o CI leva algumas horas para retornar a você. Enquanto isso, um desenvolvedor trabalha em algo mais? Verifica e-mails? É uma mudança de contexto e um matador de produtividade.

Os desenvolvedores querem trabalhar em produtos onde eles possam simplesmente se concentrar no código. As ferramentas estão lá para ajudá-los a colocá-lo em produção, não para ser um obstáculo constante. A IA pode economizar tempo, mas é até as equipes de engenharia definirem seus próprios padrões para complexidade aceitável. Para fazer isso, primeiro certifique-se de que qualquer código adicionado ao seu branch principal tenha um nível aceitável de dívida técnica. Antes disso, tenha uma discussão aberta e obtenha a aprovação da equipe de engenharia sobre o limiar aceitável de dívida técnica e qualidade de código. Certifique-se de que todos saibam que ultrapassar essa marca exige remediação imediata. Uma vez que você definiu esses padrões, a IA entra em jogo.

Há um caso para agentes de IA com engenheiros atuando como os orquestradores. Uma pesquisa da Capgemini com 1.100 executivos de grandes empresas revelou que 82% planejam integrar agentes de IA nos próximos três anos, e eles já estão impactando o futuro do trabalho. Você pode estar olhando para um relatório de bug e ver que é pequeno o suficiente para um agente de IA lidar desde o início até a revisão do código, economizando tempo para sua equipe e liberando-os para lidar com trabalhos mais complexos. No entanto, às vezes, quando seguimos cegamente essas ferramentas, há compensações que a IA luta para considerar.

É quando uma opinião humana se torna o fator decisivo.

Alinhando dívida técnica com metas

Como você alinha a redução da dívida técnica com as metas que você está tentando alcançar ou resultados mensuráveis? Isso volta à dívida técnica aceitável, e às vezes, nos negócios, você precisa entregar rapidamente. Você pode fazer isso sabendo que um produto não escala, e pode haver problemas de desempenho com o passar do tempo. Muitas vezes, um desenvolvedor fará uma nota para retornar a isso mais tarde, quando houver tempo para abordar esses problemas, mas raramente acontece. E quando essa cultura ruim assume o controle, na qual você está constantemente tendo que entregar amanhã, o impacto da dívida se torna abundante.

Isso é compreensível para uma startup, mas não para um negócio que está funcionando há uma década. Você precisa começar a mudar sua cultura cedo e ativamente para gerenciar a dívida técnica; caso contrário, você gastará uma tonelada de dinheiro consertando bugs de produção ou se preocupando com segurança e conformidade.

Finalmente, há métricas para ajudar a comunicar o valor de refatorar ou pagar a dívida técnica para as partes interessadas. O tempo pode ser um, desde a concepção até a produção, ou desde a abertura de um pedido de pull até a mesclagem e o envio para a produção. Outro é o tempo médio de reparo (MTTR). Nesse caso, você pode ter encontrado um bug ou uma compilação quebrada e medir quanto tempo leva para sua equipe consertá-lo. Você também pode acompanhar o número de bugs que você tem em produção. Se você vê que esse número aumenta, pode haver um problema relacionado à dívida técnica.

Dívida técnica com juros

Toda organização pode dedicar algumas horas todos os dias para melhorar sua DX e ajudar a reduzir a dívida técnica. Se não, você pode pagar por isso mais tarde, provavelmente com um desempenho lento, uma desaceleração considerável na velocidade de desenvolvimento ou problemas de segurança. Por exemplo, sua equipe de engenheiros e desenvolvedores pode ter adiado atualizações para Ruby on Rails por uma década. De repente, o custo do projeto aumenta em meio milhão de dólares porque a versão do Ruby está quatro gerações atrás, deixando você com uma massa de código e dependências desatualizadas.

Se você tivesse atualizado gradualmente, você não estaria nessa situação. Então, apoie sua equipe de desenvolvimento de software e pague à medida que você vai. Caso contrário, essa dívida técnica voltará para assombrá-lo, com juros.