5 dicas para lidar com a dívida técnica

Os CIOs lutam contra a dívida técnica há décadas, mas muitos ainda lutam para gerenciá-la adequadamente. E isso está custando a eles.

A empresa de consultoria de gestão Protiviti entrevistou mais de 1.000 executivos de tecnologia para sua pesquisa Global Technology Executive de 2023 e descobriu que a dívida técnica é um dos principais obstáculos à inovação para quase 70% das organizações. Os executivos também relataram que a dívida de tecnologia consome 31% dos orçamentos de TI e requer 21% dos recursos de TI para gerenciar.

A pesquisa da LeanIX, IT Cost Optimization Survey 2023, teve uma descoberta semelhante, pois 56% dos entrevistados disseram que tecnologia desatualizada e dívida técnica são, particularmente, grandes contribuintes ao desperdício de orçamentos de TI.

Enquanto isso, os líderes de TI que gerenciam com sucesso a dívida técnica estão muito mais bem posicionados para permitir que suas organizações tenham um melhor desempenho. De acordo com a empresa de pesquisa e consultoria Gartner, os líderes de infraestrutura e operações que gerenciam e reduzem ativamente a dívida técnica podem obter tempos de entrega de serviços pelo menos 50% mais rápidos para os negócios.

Diante dessas descobertas, muitos CIOs se concentraram em encontrar maneiras de reduzir sua dívida técnica. Líderes de tecnologia experientes compartilham cinco estratégias que usam para manter a dívida de tecnologia sob controle.

Seja analítico sobre como medir sua dívida técnica

Andrew Sharp, Diretor de Pesquisa para a Prática de Infraestrutura e Operações do Info-Tech Research Group, é um forte defensor da catalogação da dívida técnica. O analista aconselha os líderes de TI a estabelecer uma lista de suas dívidas técnicas críticas, conhecer o impacto dessa dívida nos negócios e ter um processo para resolvê-la.

Muitos CIOs, dizem ele e outros, muitas vezes ficam aquém dessas três questões fundamentais.

“Um dos maiores desafios é entender e organizar o escopo da dívida técnica”, diz Sharp, explicando como as equipes de TI lutam para saber o valor e o impacto da dívida técnica “porque ela se espalha em diferentes sistemas; ela tem efeitos indiretos”.

Mas, como quase tudo nos negócios hoje, a dívida não pode ser gerenciada com sucesso se não for medida, diz Sharp, acrescentando que a TI precisa melhorar na identificação, rastreamento e medição da dívida de tecnologia.

“A TI sempre tem uma noção de onde estão os problemas, onde o mofo está escondido, mas muitas vezes não há uma análise formal”, diz ele. “Acho que uma abordagem estruturada para olhar para isso pode ser uma oportunidade de pensar sobre coisas que não foram consideradas anteriormente. Portanto, não é apenas saber que temos problemas, mas saber quais são os problemas e entender o impacto. A visibilidade é realmente fundamental”.

Sharp adverte contra o rastreamento de todas as dívidas de tecnologia, enfatizando a necessidade de rastrear a dívida a ser corrigida.

Ken Knapton, Vice-Presidente Sênior e CIO da Progrexion, também fala sobre a importância de conhecer detalhes sobre a dívida que seu departamento de TI acumulou.

Para tanto, ele e sua equipe de TI desenvolveram um método para medir sua dívida. Eles avaliam a dívida em atributos-chave de tecnologia (suportabilidade, expectativa de vida útil restante, estabilidade e extensão) e, em seguida, em dois atributos adicionais (criticidade de negócios e alinhamento estratégico). Eles multiplicam a soma dos quatro atributos-chave pela soma dos dois últimos e, em seguida, normalizam os valores para uma proporção entre 0 e 1.

Knapton diz que qualquer dívida de tecnologia com taxas de 0 a 0,4 é aceitável, qualquer coisa entre 0,5 e 0,7 é preocupante e qualquer coisa acima de 0,7 é crítica.

“Agora que tenho uma estrutura para medir a dívida técnica, podemos rastreá-la. Podemos nos concentrar em qual parte de nossa dívida técnica vamos resolver e no que vamos trabalhar agora”, acrescenta.

Pague sua dívida priorizando-a nos roteiros

Knapton diz que viu em primeira mão o custo de não pagar a dívida técnica em tempo hábil.

Ele aponta para um incidente passado em que uma equipe de desenvolvimento usou uma biblioteca Java, mas não voltou para o código atualizado em prol do tempo e da velocidade de lançamento no mercado, como costuma ser o principal motivo para assumir dívidas. Essa decisão, embora justificada no momento do desenvolvimento e implantação inicial do produto, prejudicou a capacidade da equipe de adicionar atualizações ou fazer alterações necessárias posteriormente.

Knapton diz que aprendeu que “não há nada tão permanente quanto uma decisão temporária” se essas decisões temporárias não forem revisadas.

“Como você permite todas essas pequenas decisões, essa dívida técnica pode permanecer e então você tem soluções excessivamente difíceis, soluções excessivamente complexas, que não permitem que você seja tão ágil quanto possível como empresa. É aí que a dívida técnica começa a ser um passivo, quando não pagamos”, diz.

“Agora nós medimos, gerenciamos e reconhecemos que, se vamos assumir alguma dívida técnica para sermos os primeiros no mercado, temos que seguir em frente e pagar essa dívida técnica após o lançamento”.

Para garantir que esses pagamentos sejam feitos, Knapton diz que ele e sua equipe sabem que “temos que adicionar ao nosso cronograma a capacidade de gerenciá-lo e resolvê-lo”.

Para dar suporte a isso, as equipes da Knapton, que trabalham de maneira ágil em toda a TI, mudaram a meta para definir quando estão “concluídos” para incluir a mitigação da dívida técnica.

“Um projeto não está concluído até que você volte e ajuste o que quer que tenha assumido como dívida técnica; e todos concordam que é assim que definimos ‘concluído’”, diz Knapton, observando que a dívida técnica faz parte da lista de pendências de uma equipe até que o trabalho de mitigação seja concluído.

Ele acrescenta: “Não quero que uma solução temporária se torne permanente, por isso a colocamos oficialmente em nosso roteiro”.

Outros também defendem a alocação de recursos (tempo e dinheiro), bem como a criação de responsabilidade para lidar com a dívida.

Sharp, por exemplo, fala sobre “melhorar a verificação do valor que um projeto oferece, conhecer e ficar de olho nos bugs, orçar para manutenção e qualquer novo equipamento necessário”.

Ele acrescenta: “Um número surpreendente de organizações não faz isso”.

Trate a dívida de tecnologia como o risco de negócios que é

Enoche Andrade, que como Especialista em Inovação de Aplicativos Digitais na Microsoft assessorou executivos sobre dívida técnica, diz que a dívida técnica não é apenas um problema de TI; também é um risco comercial, apontando que a dívida técnica tem implicações comerciais, financeiras e de segurança.

Como tal, Andrade diz que a dívida técnica é um tópico para todos os executivos e líderes de funções de negócios, não apenas para TI, e as decisões sobre quando e quanto a dívida técnica incorre e quando e como ela é paga devem se alinhar à estratégia da empresa e às necessidades de negócios.

“Os CIOs têm a responsabilidade crítica de aumentar a conscientização sobre a dívida técnica entre o conselho e as equipes de liderança”, diz ele. “Para promover uma cultura de conscientização e responsabilidade em relação à dívida técnica, as empresas devem incentivar equipes multifuncionais e estabelecer metas e métricas compartilhadas que incentivem todos os grupos a trabalharem juntos para lidar com a dívida técnica e promover a inovação. Isso pode incluir a criação de um ambiente seguro para os desenvolvedores experimentarem novas abordagens e tecnologias, levando à inovação e melhoria contínua”.

Knapton concorda com a necessidade de envolver o negócio ao decidir quando assumir uma dívida técnica, medindo seu impacto e priorizando o que pagar.

Ele diz que as métricas de sua equipe de TI realmente ajudam a informar seus colegas de nível C sobre o assunto, dizendo: “Agora tenho uma maneira de me comunicar com meu conselho e minha equipe executiva para dizer: ‘Esta é nossa dívida e estamos alavancados por causa de decisões que tomamos no passado’”.

Seja intencional ao assumir novas dívidas

Mike Huthwaite, um CIO da Hartman Executive Advisors, que fornece liderança executiva fracionada para clientes, compara a dívida técnica à dívida financeira. “A dívida pra mim é algo que você contrai, que depois resolve”, acrescenta.

Assim como às vezes é inteligente assumir dívidas financeiras, Huthwaite diz que muitas vezes é mais inteligente optar por dívida técnica do que não. Como outros, ele diz que as equipes podem decidir incorrer em dívida técnica por velocidade e agilidade – vantagens de mercado que superam os custos da dívida técnica.

“É sempre uma troca e, se você continuar na analogia da dívida pessoal, há pontos ou decisões em que assumir dívidas tem valor. Mas ainda é dívida do mesmo jeito. Portanto, espero que você esteja fazendo isso de maneira prudente”, diz ele.

Huthwaite diz que instrui as equipes de TI a serem deliberadas sobre assumir dívidas técnicas, avaliando os benefícios que obtêm usando, por exemplo, código abaixo do ideal em relação ao lado negativo dessa decisão. Ele chama isso de dívida técnica intencional, em contraste com a dívida técnica não intencional que é incorrida sem tal deliberação.

“A dívida técnica intencional tem seu lugar e tem seu valor; a dívida técnica não intencional é um problema maior”, diz ele. “Quando não rastreamos todas as dívidas, você pode descobrir que está à beira da falência”.

Andrade tem palavras de conselho semelhantes, dizendo que, embora as organizações não possam eliminar de forma realista todas as dívidas técnicas, elas podem tomar medidas para limitar sua criação (e particularmente a criação de dívidas não intencionais).

Ele aconselha as equipes a adotar a metodologia de desenvolvimento ágil, refatorar, automatizar testes e otimizar processos. As equipes também devem usar ferramentas de análise de código para identificar a dívida técnica e fazer revisões regulares de código por colegas e partes interessadas para garantir a qualidade do código e identificar possíveis problemas. Eles também devem adotar a simplificação arquitetônica, a componentização e a padronização.

Reconhecer que a gestão da dívida é um processo contínuo

Wayne F. McGurk, CIO e Vice-Presidente Sênior de TI da National Rural Electric Cooperative Association, não vê a dívida técnica como uma coisa boa ou ruim, mas sim “um resultado natural do processo de desenvolvimento, ocorrendo porque algo novo está sendo construído”.

“Há uma tendência de ir o mais rápido possível para lançar o MVP, e você não necessariamente cria um aplicativo excessivamente industrializado no início”, diz ele. As equipes fazem compensações, optando por tecnologias que funcionam para o MVP que sabem que serão insuficientes à medida que as soluções aumentam.

Portanto, McGurk considera isso não apenas em seu ciclo de desenvolvimento, mas também nas operações de TI, aplicando várias táticas para criar uma abordagem holística para gerenciar a dívida técnica de forma contínua. Como parte dessa abordagem, a equipe de McGurk documenta e detalha a introdução de qualquer nova dívida técnica, que é rastreada por meio do sistema de tíquetes da organização para que as equipes de TI “possam acessar tudo, relatar e analisar”.

McGurk também considera como cada parte da dívida técnica afeta as operações em cinco áreas principais: simplicidade, flexibilidade, continuidade, segurança e transparência.

“Quando a dívida técnica começa a atrapalhar qualquer um desses princípios operacionais, ela sobe para o nível em que queremos resolvê-la”, explica ele.

McGurk e sua equipe de TI consideram o nível de impacto, o risco para a organização e a estratégia geral da organização para priorizar o que precisa de atenção. Eles, então, tornam essas determinações conhecidas, criando assim visibilidade do tópico em toda a organização.

Tudo isso está envolvido no fluxo de trabalho de seu departamento de TI, diz McGurk, o que garante que o gerenciamento da dívida técnica não seja tratado como um projeto único, mas gerenciado de maneira contínua. Por exemplo, espera-se que suas equipes Scrum identifiquem novas dívidas técnicas e determinem quando e como tratá-las.

“Você precisa construir a cultura de prestação de contas e responsabilidade para que suas equipes saibam que só porque um projeto foi entregue, ele não está concluído. É uma jornada, e não tem fim, então ela se torna parte de sua estratégia de gerenciamento de demanda — lidando com a demanda por novos trabalhos, mas também com trabalhos legados e dívidas técnicas”, diz ele.