Nem sempre temos condições de fazer, da melhor maneira, o que tem que ser feito. Eu não gosto disso, mas a realidade nas empresas que produzem software, em muitos casos – mas não todos – não é muito legal, quando falamos da qualidade dos projetos executados.
Para entender melhor o que citei acima, entenda porque os projetos de software não costumam dar certo.
E se não dá para fazer tudo da melhor maneira possível, coisas ficam por fazer. Vamos entender estas coisas como sujeira. E vamos considerar que esta sujeira é jogada para debaixo do tapete.
Esta sujeira é o que chamamos, em projetos de software, de débito técnico, ou dívida técnica.
Já pensou na complexidade real de um software?
Desenvolver software profissionalmente – me refiro a fazer isso como profissão, oferecendo este serviço no mercado – é uma atividade complexa pela sua própria natureza. Construir um sistema exige muito do profissional.
Se pensarmos bem, estamos falando de algo quase infinitesimal.
Parece exagero? Pense no último projeto de grande porte que participou. Consegue imaginar a quantidade de variáveis (variáveis de código mesmo) que este sistema tem? E ainda some a elas as variáveis embutidas nos frameworks e APIs que este sistema consome. Não consegue fazer a conta. Mas facilmente esbarra no milhão.
Nunca temos os recursos suficientes e a qualidade paga o preço
Além da questão da complexidade, temos ainda a feroz concorrência entre empresas do setor, ansiedade exagerada de clientes, gestores e investidores, no que refere-se às entregas do projeto, falta de educação – me refiro à instrução, educação intelectual – por parte dos profissionais que produzem software, dentre outros fatores, tudo isso tornando o processo mais estressante ainda.
Tudo isso deságua no projeto. E aí, nenhum projeto possui o prazo, o tempo e o dinheiro que são necessários para sua conclusão bem sucedida.
Num contexto como este, produzir um software que atenda a 100% do escopo desejado pelo cliente e com qualidade excelente, é praticamente impossível.
E algumas coisas que poderiam ser feitas (algumas até “deveriam”), acabam sendo postergadas para um segundo momento. O software é entregue. Entregue com pendências.
“O bom é inimigo do ótimo” ou “Antes feito do que perfeito”
Eu não gosto destas duas frases, talvez eu tenha até ojeriza a elas. Não quero dizer que tudo que faço fica excelente, sou ser humano como você.
Mas 85% das pessoas que conheço que utilizaram estas frases para justificar débito técnico, utilizaram não porque estavam sem opção, sem saída, nem porque não tinham como evitar o débito técnico. Utilizaram para justificar falta de zelo, compromisso, ou preguiça.
Profissionais desleixados se passam de coitados, sempre alegando que “não tinham as condições necessárias”, mas no fundo sempre acabam passando a perna em alguém, criando débito técnico por falta de ética e não por falta das “condições necessárias”.
Débito técnico é sempre ruim?
Os 15% restante dos profissionais que aplicaram as frases anteriores, o fizeram com bom senso, com prudência, com visão de problemas futuros. E isso é válido, faz parte do desafio de produzir software com a velocidade que o mercado exige, mas com a qualidade permitida pela escassez de recursos.
Nem todo débito técnico é ruim. Um exemplo disso são débitos referentes a escopo. Em projetos ágeis, onde as iterações (sprints) são curtas e o feedback é contínuo, é comum o software contemplar a parte do escopo que o cliente julgue mais prioritária ao seu negócio, que gere mais valor.
E entre uma iteração e outra requisitos vão sendo deixados de lado por questões de priorização, e ao fim do projeto sempre sobram algumas coisas que poderiam ter sido feitas mas que foram despriorizadas. Então o backlog é gerado, pois ainda existem coisas a serem feitas.
/* Para entender melhor sobre Priorização de Requisitos, leia este nosso post sobre o assunto. */
Neste caso é positivo, pois deu-se prioridade ao que gerava mais valor, o que ficou de débito de escopo poderá ser produzido posteriormente. E o mais importante: as prioridades não foram invertidas.
/* Débito técnico não refere-se apenas a pendências de código fonte, arquitetura e banco de dados. Refere-se também a pendências de escopo, geralmente funcionalidades que não foram feitas, ou que foram feitas deixando alguns recursos que não foram produzidos. */
Como são gerados os débitos técnicos ruins
Eu penso que a maioria dos débitos técnicos gerados em projetos de software não são positivamente gerados, como no exemplo que citei anteriormente.
Vamos ver abaixo alguns trechos de diálogos muito comuns no “parto” de débitos técnicos.
“Não temos tempo para realizar testes de carga e estresse, mas a rotina vai rodar legal, a performance será boa.”
“Implementar este padrão de projeto para desacoplar os módulos vai demorar muito, melhor fazer para funcionar, entregar, e depois refatoramos na manutenção.”
“Arquitetura é importante, mas já dividimos nosso sistema em camadas. Já conseguimos algum desacoplamento assim.”
“Vamos focar nos requisitos funcionais, requisitos não funcionais não são tão importantes.”
“Vamos implementar as funcionalidades básicas, o restante se sobrar tempo a gente faz.”
“Separar adequadamente as responsabilidades não pode ser levado a ferro e fogo, quem mais vai utilizar este método no sistema? Então deixa na camada de apresentação e tá valendo, resolve mais rápido assim!”
“Não temos dinheiro para contratar profissionais seniores, neste momento vamos codificar com a equipe que temos e depois contratamos algum cara bom para refatorar o que for necessário”
“Ficar namorando o modelo de dados gerará atraso na entrega, integridade referencial pode ser resolvida de outra forma; table scan não atrapalha tanto assim, depois criamos os índices.”
Uma pena.
Concluindo
Não tem como fugir do débito técnico. O adequado é aceitá-lo apenas quando: 1) não tiver outra saída ou 2) for uma opção que fará bem ao objetivo maior do projeto. E, sempre de maneira franca e transparente com o cliente.
E tão importante quanto saber aceitar o débito técnico é saber administrá-lo. Os débitos sempre existirão, mas uma hora precisarão ser resolvidos, serem pagos. Para isso, é fundamental ter um backlog de qualidade que contém o que existe de débito técnico, e ter um bom plano de ação para atuação neste backlog.
Grande abraço!