Porque projetos de TI demandam tanto esforço, energia, custam caro e ainda por cima atrasam?

Você já deve ter se deparado com esta questão em algum momento da sua carreira, ou quem sabe nunca deixou de se deparar com ela. É claro que são diversas as possíveis causas para ineficiência em TI e este post não tem a pretensão de abordar todas elas. Ao invés, vamos abordar uma das principais causas, tratada anteriormente por autores como Martin Fowler e Uncle Bob: Technical Debit ou Dívida Técnica (tradução mais fiel, em minha opinião). Além de materiais escritos pelos tais autores, encontrei também excelentes posts a respeito no site da InfoQ, no blog do Adriano Tavares e, claro, na Wikipedia.

DefiniçãoDevo, não nego. Pagarei quando puder.

A dívida técnica é como um financiamento, ou uma aquisição de dívida qualquer em que há o pagamento pelo empréstimo do dinheiro (juros). Na maioria dos casos, a aquisição de uma dívida acontece quando o indivíduo ou organização opta por ter um benefício imediato, ao invés de poupar dinheiro para comprar sem precisar recorrer a um financiamento. Isso pode ser feito por necessidade, ou simplesmente por ser mais cômodo. Normalmente tal indivíduo ou organização tem ciência de que ao fazer isso pagará um valor maior pelo que está adquirindo e também sabe que poderá liquidar sua dívida no futuro, caso se planeje para isso.

Trazendo este conceito para o desenvolvimento de software, a dívida técnica é adquirida quando se opta por uma de ao menos duas soluções para um mesmo fim, sendo esta a mais barata a curto prazo ou mais rápida de se entregar, mas que falha ao endereçar adequadamente requisitos não funcionais como manutenibilidade, testabilidade, extensibilidade ou ainda suportabilidade. A solução descartada normalmente endereça bem estes requisitos, porém, acaba sendo mais custosa ou não atende a um prazo pré-estabelecido para o projeto.

Os juros que serão pagos neste contexto, podem se dar como custos adicionais que incorrerão em projetos futuros, decorrentes da dificuldade de entendimento e manutenção daquilo que foi desenvolvido anteriormente, custos adicionais por se ter um processo de teste complexo e/ou custos ocasionados por bugs em produção, custos adicionais de suporte, quando a solução não se adequa aos padrões de suportabilidade estabelecidos na organização, dentre outros.

Além destes custos tangíveis podem existir também outros não sentidos diretamente, ou intangíveis, como por exemplo: baixa motivação, engajamento ou energia e produtividade dos profissionais inseridos neste contexto.

Os juros se acumularão e os problemas se potencializarão se com o passar do tempo as dívidas antigas não forem pagas e ainda novas forem adquiridas. A dificuldade de entendimento, manutenção e teste implicam em cada vez mais esforço para fazer coisas que deveriam ser simples e rápidas, tornando as soluções mais caras e demoradas. Com a potencialização dos custos intangíveis, há uma maior rotatividade de profissionais e o pouco conhecimento que se tinha sobre o negócio e as aplicações acaba por se perder. Tudo isso se transforma em um ciclo vicioso: quanto mais dívidas são adquiridas, maiores são as dificuldades e mais novas dívidas são adquiridas para se cumprir prazos. Representei o ciclo descrito até aqui no esquema a seguir.

image

Dívida boa ou ruim?

Por definição, a dívida técnica acontece somente quando é contraída voluntariamente (conscientemente) e quando quem a contraiu se planeja para pagá-la no futuro – ou seja, planeja um release futuro com melhorias técnicas. Existem situações em que se sabe que a distribuição da solução deficiente naquele momento trará um retorno sobre o investimento tal que cobrirá os juros que deverão ser pagos em decorrência no futuro. Em outras situações, simplesmente pode não haver outra opção além de distribuir a solução mesmo com suas deficiências, seja por questões legais ou estratégicas. Nestas, também é possível se planejar para quitar a dívida.

Segundo Uncle Bob, existe ainda outro cenário bastante comum, quando as dívidas são adquiridas ou de forma inconsciente, em projetos em que a equipe envolvida não tem qualificação técnica suficiente, ou ainda de forma consciente, por preguiça ou falta de profissionalismo. Ainda segundo ele, estas não caracterizam aquisição de dívida técnica, já que muito provavelmente elas nunca serão reconhecidas por quem a fez, e por consequência nunca serão quitadas. O fato, porém, é que sendo consciente ou inconsciente, por falta de qualificação ou juízo a consequência da dívida técnica será sentida de qualquer forma, surgindo daí a esquematização dos tipos de dívida técnica do Martin Fowler, representado no diagrama a seguir (retirado do seu site, reproduzido e traduzido por mim).

 

Tipos de dívida técnica

Quitando a dívida

Como vimos, adquirir dívidas técnicas é fácil e muitas vezes inevitável. Porém, para termos uma organização de TI sustentável não podemos deixar de planejar a sua quitação. A seguir listei algumas práticas que podem ser adotadas para a redução da dívida da sua organização:

  • Criar um backlog de dívidas técnicas assumidas em projetos;
  • Criar e planejar projetos que visem quitar tais dívidas técnicas, seja através de refactoring de código ou redesign. Outra opção ainda é estabelecer uma cultura por incorporar tais melhorias em projetos de negócios;
  • Realizar avaliações técnicas sobre os sistemas legados e definir projetos de melhorias técnicas ou substituição;
  • Optar por profissionais com boa qualificação técnica durante a contratação;
  • Investir na qualificação técnica e reciclagem de profissionais já contratados.

E você, já adota alguma dessas práticas ou ainda outras para este fim? Deixe seu comentário!

2 ideias sobre “Porque projetos de TI demandam tanto esforço, energia, custam caro e ainda por cima atrasam?

  1. Luiz Gustavo

    Ótimo post!
    Infelizmente a aquisição de dívida técnica é uma realidade, e ocorre, de fato, por todos os motivos citados.
    Algumas causas, na minha opinião, podem ser tratadas de forma mais descomplicada, como com o treinamento e conscientização da equipe.
    O pior caso, na minha opinião, é o do consciente/imprudente, que sabe o que precisa ser (bem) feito mas opta pelo benefício a curto prazo. Vejo isso acontecer muito por questões comerciais, que levam ao indevido comprometimento com prazos absurdos para simplesmente atender a vontade (e não real necessidade) do cliente. Este comportamento comercial pode ser muitas vezes motivado por questões legítimas, como quando o prazo é uma real necessidade do cliente, e “ganhar” o projeto é uma questão estratégica. Ainda assim a dívida, como dito no artigo, deve ser adquirida com consciência.

  2. Luís Otávio

    Post muito bom. Leitura perfeita da maioria dos projetos em fábrica de software.
    Infelizmente vejo a maioria das dívidas técnicas adquiridas inconscientemente, criando algo que podemos chamar de “bolhas de software”.
    Apesar da realidade multi-thread, tento no meu dia a dia planejar “imersões” em projetos específicos, principalmente em releases iniciais ou críticas, para reduzir este risco.
    Claro que nem sempre é fácil vender isso para os coordenadores, gerentes etc, mas sempre vale a pena!

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*