Vamos falar sobre débito técnico?
Na verdade, eu adoraria estar iniciando esse post com o título “Vamos fazer alguma coisa para diminuir nosso débito técnico?”, mas começar por simplesmente falando sobre isso já é meio caminho andado (nem tanto, mas você entende onde quero chegar, né?).
Sou analista judiciário, especialidade análise de sistemas, em um tribunal superior no Brasil (TST) e desenvolvo software; ou seja, faço parte do pessoal que não gosta muito de perder tempo com burocracia. É com essa atitude que começa uma boa parte dos problemas!
Esse é o primeiro post de uma série de conversas que teremos. Veremos como a conversa progride e partimos aí.
Erro #1: Isso é chato e não é problema meu!
Não existe atividade humana que seja desassociada de contato humano. Parece uma frase solta, mas não é o que realmente acontece. Vejamos, os desenvolvedores de software, quase sempre, não sentem que as suas atividades devam ser “contaminadas” com outras preocupações comezinhas tais como conversar com o usuário final do seu sistema, ou mesmo apenas organizar, medir, registrar e acompanhar o seu próprio trabalho; e isso é péssimo.
É necessário que nos apropriemos sempre de todos os aspectos importantes do nosso trabalho. Se queremos ser bons profissionais, necessitamos ajustar as condições de produção, conduzir o trabalho todo de forma consciente e termos propriedade ao defender nossas ações para que o nível de burocracia seja benéfico para nós: não ceda à ilusão de que não precisamos de burocracia. O que necessitamos é que essa burocracia seja útil. Efetiva.
Por que estou falando disso? Simples: porque, ao nos alienarmos das obrigações de gestão do processo de trabalho, simplesmente nos alienamos das decisões que podem levar ao crescimento do débito técnico. Isso sim é problema nosso (ou nos prejudicará imensamente).
Agora, o que é mesmo débito técnico?
Um pouco de paciência aqui, ok? Vamos retardar essa conversa um pouco mais.
Erro #2: Se não tem tempo pra fazer bem feito, quando terá tempo pra fazer de novo?
Já trabalhei em algumas empresas antes de aterrissar no Tribunal Superior do Trabalho (TST), em Brasília. Guardadas as devidas proporções e, considerando o trabalho realizado em cada uma dessas organizações, a quantidade de profissionais sempre foi suficiente para entregar um trabalho de qualidade.
Então por que motivo há tanto software finalizado e em produção com baixíssima qualidade, resultando em um alto custo de manutenção e uma experiência do usuário ruim? Por que nos desrespeitamos tanto ao ponto de entregarmos um software ruim que será nosso pesadelo muito brevemente?
Os prazos são curtos? Ok, vamos por aí. Quando nos concentramos em algo que não podemos controlar não chegamos a resultado algum. Se o prazo é dado, toda a responsabilidade foi tirada de nossos ombros. Isso quando nossas considerações e avaliações não são consideradas no processo decisório que levou ao estabelecimento do prazo.
Sendo assim, o que nos importa é a qualidade com a qual concluiremos o trabalho! Isso sim podemos controlar. Isso sim irá determinar se o que foi entregue terá agregado valor à organização ou gerado uma dívida a ser paga com altos juros.
Nosso trabalho é imaterial em quase todos os aspectos e é por essa mesma razão que temos a obrigação de materializá-lo para nossa camada de gerência. É nossa responsabilidade encontrar alguma forma de apresentar as consequências que um trabalho de má qualidade terão em uma organização. Para isso, uma boa metáfora é uma ferramenta bem útil. Uma metáfora financeira é muito eficaz, afinal quem não entende que perder dinheiro é ruim?
Finalmente chegamos: débito técnico!
O que é Débito Técnico e como entendê-lo e gerenciá-lo pode nos ajudar?
Isso é o que veremos na próxima parte dessa conversa (assim que puder eu continuo).