Não Deixe a Dívida Técnica Definir o Seu Roteiro — Assuma o Controlo Agora com 5 Estratégias

Tudo começa de forma pequena: uma revisão de código ignorada, uma migração do Rails adiada ou a reafetação de recursos de engenharia da manutenção para cumprir o prazo de lançamento de uma nova funcionalidade.

Um ano depois, a sua equipa de engenharia passa um terço do tempo a resolver problemas urgentes, as reclamações dos clientes acumulam-se e o seu CFO depara-se com um excesso de custos de 2 mil milhões de dólares no orçamento.

Jeff Watkins, CTO da CreateFuture, já viu este cenário repetir-se vezes sem conta: a dívida técnica acumula-se lentamente, começa a reduzir a produtividade da engenharia e acaba por afetar o negócio. 

“A dívida técnica é inevitável à medida que cresce,” afirma Watkins, “mas as empresas mostram-se frequentemente relutantes em atribuir recursos para resolver problemas que não estão visivelmente avariados, sobretudo quando há novas funcionalidades para lançar.” A longo prazo, porém, esta mentalidade de "se não está avariado, não o conserte" pode consumir até 20% dos orçamentos de engenharia. 

Com a procura por lançamentos mais rápidos e sistemas escaláveis num nível historicamente elevado, adiar as correções hoje provoca problemas maiores amanhã. Eis como abordar estrategicamente a dívida técnica sem deixar o seu roteiro completamente parado.

O que é a dívida técnica?

A dívida técnica é o custo acumulado do retrabalho quando a rapidez se sobrepõe à qualidade a longo prazo no processo de desenvolvimento. Manifesta-se de várias formas distintas:

• Dívida arquitetural: quando a arquitetura do seu sistema não consegue acompanhar as necessidades de crescimento ou expansão.
• Dívida de código: código de baixa qualidade ou testado de forma insuficiente que cria instabilidade em produção, provocando falhas frequentes.
• Dívida de processos: ineficiências nos fluxos de trabalho, falta de processos automatizados ou um pipeline de CI/CD danificado que cria obstáculos.
• Dívida de documentação: documentação em falta ou desatualizada, dependência de membros da equipa com conhecimento tribal e maior dificuldade em resolver problemas e integrar novos elementos.
• Dívida de infraestrutura: utilização de versões desatualizadas de dependências ou negligência da recuperação após catástrofes, o que pode conduzir a vulnerabilidades e falhas do sistema.

Causas da dívida técnica

Não é possível corrigir aquilo que não se compreende. Conhecer a razão por trás do aumento da sua dívida técnica é essencial para a travar antes que fique fora de controlo. Eis as principais causas da dívida técnica a que deve estar atento:

• Aumento da pressão empresarial: a pressa em entregar rapidamente provoca frequentemente um aumento do âmbito, recursos de engenharia sobrecarregados, testes ignorados e funcionalidades mal concebidas que terão de ser corrigidas mais tarde, se é que alguma vez o serão. 
• Arquitetura de sistema desatualizada: manter sistemas desatualizados e não realizar migrações quando necessário cria integrações frágeis e mais dívida técnica. As API e os sistemas de autenticação antigos são frequentemente deixados acumular com vários fornecedores.
• Processo de desenvolvimento deficiente: revisões de código demasiado permissivas ou inexistentes, código duplicado com baixa legibilidade e bases de código extensas com mais de 1M de linhas de código (LoC). 
• Complexidade dos sistemas legados: correções adiadas, infraestrutura desatualizada e versões sem suporte conduzem à incompatibilidade dos sistemas e ao crescimento progressivo da “dívida de segurança”. A Microsoft ainda está a tentar recuperar desse problema. Entre o ataque ao Exchange Online e o ataque do Midnight Blizzard, continua a pagar o preço de ignorar a dívida que se acumulou ao longo do tempo.
• Gestão do conhecimento isolada em silos: escolhas tecnológicas inadequadas, implementação insuficiente de padrões de conceção e utilização indevida de estruturas de desenvolvimento podem obrigar as equipas a desenvolver soluções excessivamente complexas, como adotar microsserviços sem conhecimentos especializados em sistemas distribuídos.
• Baixa produtividade dos programadores: os programadores sujeitos a pressão constante, sem tempo para consultar a documentação ou se dedicarem a trabalho profundo, irão sempre dar prioridade a objetivos de curto prazo e podem fazer aumentar a dívida técnica. 

As estratégias mais eficazes de gestão da dívida técnica abordam estas causas profundas em vez de tratarem apenas os sintomas.

5 passos para os CTO reduzirem a dívida técnica

A dívida técnica é frequentemente uma decisão consciente, especialmente quando o objetivo é lançar rapidamente um MVP, com planos para proceder à refatoração mais tarde, caso seja bem-sucedido. Funciona– até deixar de funcionar. Por isso, se está nesse ponto crítico ou quer manter uma abordagem proativa, apresentamos cinco estratégias diretamente do manual do CTO para lidar com essa dívida técnica crescente: 

1. Torne visível a sua dívida técnica 

Não pode corrigir aquilo que não consegue medir, mas, como afirma Martin Riley, CTO da Bridewell, também não pode medir aquilo que não consegue ver. Isto significa garantir que o seu trabalho de desenvolvimento pode ser rastreado até à dívida técnica que cria. Com essa visibilidade, pode alinhar os investimentos em engenharia com os objetivos empresariais, justificar os esforços de refatoração e evitar falhas inesperadas do sistema. “Saber quem é responsável pelo código que está a criar dívida, e se este foi aprovado, facilita a gestão.”

Uma visibilidade granular da sua dívida técnica começa com dados sólidos. Utilize um agente de IA que se ligue ao seu pipeline de CI/CD, extraia dados das reuniões de equipa e acompanhe os padrões de comunicação, a distribuição da carga de trabalho e o progresso dos sprints. Pode até automatizar o registo para sinalizar código desatualizado ou complexo, enquanto monitoriza a forma como a qualidade do seu código melhora ou piora ao longo do tempo. Combine estes dados com inquéritos regulares nos quais os ICs possam avaliar a dificuldade de modificar o código, o tempo despendido na manutenção e os pontos problemáticos. 

2. Implemente um registo de dívida para definir prioridades 

Crie um registo centralizado da dívida técnica que documente todas as formas de dívida: código, arquitetura e documentação de processos. Mas listar as fontes de dívida técnica não é suficiente; a tarefa mais árdua é identificar as áreas que terão o impacto mais significativo. Watkins recomenda que se concentre no ROI: “Se uma correção poupar uma hora por dia a 20 programadores e demorar apenas uma semana a implementar, isso representa um retorno do investimento quase imediato.” Identifica retornos semelhantes na resolução de problemas como a instabilidade dos testes ou tempos de compilação longos. 

Ao criar o seu registo de dívida, siga a regra 80/20: concentre-se nos 20% da dívida técnica que causam 80% dos seus problemas. Identifique as fontes críticas dos “20%” acompanhando: 

• Tempo de manutenção vs. desenvolvimento de novas funcionalidades
• Número de erros recorrentes e não resolvidos
• Feedback dos programadores sobre a dificuldade das alterações
• Percentagem de cobertura dos testes
• Tempos de compilação (10 minutos ou mais)
• Taxas elevadas de reescrita de código (mais de 20% por sprint)

As métricas quantitativas fornecem os factos concretos, mas também precisa da vertente qualitativa para obter uma visão completa de como e onde a sua dívida técnica se está a acumular e que partes da empresa sentem mais pressão.

Watkins recomenda que esteja atento aos problemas da experiência do utilizador, aos tempos de implementação mais longos e ao maior problema de todos– a diminuição da produtividade da sua equipa de desenvolvimento. Tenha em consideração as horas de trabalho concentrado dos seus programadores, as pontuações CSAT dos clientes que se queixam de períodos de indisponibilidade, os tempos de carregamento lentos e as compilações instáveis em produção. Torne esta prática parte do seu fluxo de trabalho habitual, integrando o seu registo com o JIRA e atribuindo um “responsável pela dívida” a cada categoria para se manter a par da situação. 

3. Integre a dívida técnica no planeamento dos seus sprints 

Jeff Delaney, vice-presidente de Engenharia de I&D na Black Duck, tem uma abordagem inteligente à gestão da dívida técnica: inclua-a no seu planeamento de capacidade, com objetivos trimestrais e um quadro JIRA. “Garantimos que reservamos uma quantidade fixa de capacidade em cada versão para a dívida técnica. A quantidade pode variar, mas sabemos sempre qual é a dívida técnica que temos, damos-lhe prioridade e prestamos-lhe a devida atenção.”

Comece com rotações de 45 dias, nas quais os programadores alternam entre a manutenção de sistemas antigos e o desenvolvimento de novas funcionalidades. Forme pares durante a transição para permitir novas perspetivas e uma transferência sólida de conhecimentos. Trabalhar em pares distribui naturalmente a carga de manutenção, proporciona a todos uma compreensão mais profunda do sistema e desenvolve empatia pelas tarefas de “manutenção” menos apelativas. 

O desafio, contudo, seria obter o apoio da direção de topo, especialmente se esta vir os programadores a trabalhar em sistemas antigos em vez de impulsionarem novos objetivos empresariais. Watkins sugere que adicione tempo de correção aos seus tickets de desenvolvimento e adote uma mentalidade de “corrigir antes de expandir”. “A entrega pode abrandar inicialmente, mas o resultado a longo prazo cumprirá tanto os objetivos técnicos como os empresariais.”

4. Crie “barreiras à dívida” no pipeline de CI/CD

Prevenir a dívida técnica é mais barato do que corrigi-la mais tarde– contenha-a enquanto ainda é inofensiva. Crie um programa de registos de decisões arquiteturais (ADR) com um modelo padrão para registar alternativas, critérios de decisão e o impacto esperado da dívida técnica. Armazene-o juntamente com o seu código no sistema de controlo de versões. Os ADR ajudam a evitar a dívida técnica acidental e orientam os futuros esforços de refatoração. Contudo, os ADR proporcionam uma visão panorâmica. 

A redução real da dívida técnica no dia a dia resulta, contudo, da entrega de código de elevada qualidade. Pode utilizar o seu agente de IA ou uma ferramenta de análise de código (se ainda não estiver preparado para a IA) para sinalizar automaticamente problemas quando determinados valores de referência forem ultrapassados:

• Bloquear implementações quando a complexidade ciclomática atingir 15
• Sinalizar os testes como instáveis após 3 falhas aleatórias
• Falhar as compilações se os conjuntos de testes demorarem mais de 10 minutos
• Impedir os PR quando estiverem prontas para integração classes com mais de 500 linhas 

Quanto às dependências, execute scripts personalizados para bloquear implementações com dependências de risco e impedir integrações com versões incompatíveis. Por exemplo, associe o seu script a uma base de dados de segurança em formato CSV para bloquear automaticamente as implementações que incluam pacotes vulneráveis. Também pode escrever scripts para impedir a integração de PR se estes criarem dependências incompatíveis ou utilizarem bibliotecas desatualizadas. 

As escolhas do CTO Club para as principais ferramentas DevOps!

1. 

   TestDevLab

   Visit Website
2. 

   Site24x7

   4.7

   Visit Website
3. 

   GitHub Actions

   4.8

   Visit Website

5. Modernize a sua infraestrutura legada 

Muitas empresas têm dificuldades em modernizar-se porque estão presas a arquiteturas monolíticas que tornam o desenvolvimento ágil e os lançamentos mais lentos. Riley sugere a utilização do Padrão Strangler para resolver gradualmente a dívida técnica, em vez de tentar reescrever tudo de uma só vez.

Em vez de uma migração de alto risco realizada de uma só vez, moderniza a sua tecnologia legada de forma incremental, funcionalidade a funcionalidade ou grupo de utilizadores a grupo de utilizadores, para reduzir as perturbações e recolher comentários ao longo do processo.

Algumas equipas de grande dimensão utilizam uma abordagem de execução em paralelo, tal como a Spotify fez com o seu leitor de música. Mantiveram as versões Web e de ambiente de trabalho a funcionar com a mesma interface para sincronizar os dados e testar o novo sistema antes de concluírem a migração.

Supere a dívida técnica antes que esta comprometa o seu progresso

A dívida técnica nem sempre é algo negativo– é, na verdade, um sinal de que a sua equipa de engenharia está a crescer. A melhor pergunta a fazer é: está a geri-la ou é ela que o gere a si? Como Delaney afirma, “Mais cedo ou mais tarde, a equipa terá de lidar com a dívida técnica. O segredo é fazê-lo nos seus próprios termos, através de um planeamento cuidadoso, em vez de agir em modo de crise mais tarde.” 

A liderança precisa de deixar de esperar que os problemas expludam e começar já a investir em eficiência, execução e otimização de custos.

Quer manter-se a par de tudo o que diz respeito à dívida técnica e à liderança? Subscreva hoje a newsletter do The CTO Club.