top of page
Foto do escritorBen-hur Guimarães

Não pague juros abusivos, gerencie as dívidas técnicas do seu time!

Atualizado: 31 de ago. de 2022

Antes de falarmos sobre dívida técnica, é importante entendermos que uma dívida normalmente é:

  • Algo que você quer se livrar;

  • Se você não fizer nada ela só aumenta;

  • Quanto mais ela aumenta mais fica difícil de se livrar dela;

  • Querendo ou não você acaba pagando.

Certo, entendi. Mas então, o que é dívida técnica?


O termo dívida técnica foi definido por Ward Cunningham e descreve a dívida que a equipe de desenvolvimento com outras áreas, assumem quando escolhem um design ou abordagem fácil de implementar no curto prazo, mas com grande impacto negativo no longo prazo.


Martin Fowler, sugeriu a seguinte definição para dívida técnica:

"Dívida técnica é similar à dívida financeira, ou seja, exige o pagamento de juros. Estes vem na forma de esforço extra, que devem ser pagos em desenvolvimentos futuros por conta da escolha de um design mais rápido e de baixa qualidade. Nós podemos optar por continuar pagando estes juros ou quitar de uma vez a dívida fazendo uma refatoração, transformando um design de baixa qualidade em um design melhor. Apesar dos custos para saldar a dívida, ganhamos reduzindo os juros no futuro".

Steve McConnell, classifica a dívida técnica em dois tipos:


Não intencional: É quando um desenvolvedor menos experiente simplesmente escreve código ruim.

Intencional: É quando a organização toma a decisão consciente de priorizar a entrega ao invés da qualidade.


Já o Martin Fowler, classifica da seguinte forma:

  • Imprudente e Intencional: “Sabemos do problema, não vamos resolver”

  • Imprudente e Não Intencional: “Trabalhar com uma nova linguagem de programação”

  • Consciente e Intencional: “Dado nosso deadline, vamos entregar com o problema e depois corrigir o problema”

  • Consciente e Não Intencional: “Agora que entregamos o projeto, deveríamos ter trabalhado utilizando Métodos Ágeis”

Desta forma, ter uma dívida técnica em um projeto é normalmente inevitável e deve ser considerado como sendo uma expectativa. A chave está em ter certeza de que o time não está introduzindo dívidas irresponsáveis que contribuem para bagunçar o código e são muito difíceis, senão impossíveis de lidar. O ideal é procurar estar sempre entre os quadrantes Consciente, Intencional, Consciente e Não Intencional.


Origens e causas


Algumas frases ou comportamentos comuns em projetos de software podem ser consideradas fortes candidatas para gerar um alerta de dívida técnica. A simples presença de alguma delas pode ser considerada um fator de aumento de risco de uma dívida ser criada.


Por exemplo:

  • Não da pra botar só mais essa telinha?

  • Não temos tempo para testar;

  • Estimativa do time foi de 15 dias. Mas, vamos precisar fazer em 6;

  • Vamos refatorar isso depois. A prioridade é a nova feature;

  • Não tem documentação, vamos fazendo depois validamos com o cliente;

Essas frases podem inofensivas, MAS TAMBÉM podem ser fonte das dívidas técnicas do futuro. Além dessas frases, também podemos considerar as causas mais comuns para geração de dívida técnica.

  • Decisões (criativas) de arquitetura e design de código;

  • Deliberadamente sacrificar a qualidade para entregar na data;

  • Falta de conhecimento técnico;

  • Escolha de tecnologia/ferramenta/plataforma inadequada;

  • Código envelhece e apodrece;

  • Definição insuficiente;

  • Pressão do negócio;

  • Ausência de padronização;

  • Especificação de última hora;

  • Ausência de testes;

  • Postergação da refatoração.

Mas se a dívida técnica é tão importante, porque normalmente ela não tem a atenção que merece?


As origens e causas podem explicar a introdução de dívidas técnicas em um projeto, mas o seu acumulo pode estar ligado a uma armadilha, relacionada a motivação das pessoas.


O quadrante acima, nos ajuda a entender que a maior motivação de todos é trabalhar no quadrante verde, pois é algo que tem valor positivo e é visível. Tarefas relacionadas ao quadrante azul, também possuem valor positivo, entretanto, não são visíveis.


Os defeitos, apesar de visível pelo cliente, não tem valor positivo, pois se trata de um retrabalho (obrigação). Já a dívida técnica, fica justamente na zona cinza onde as tarefas além de não terem visibilidade ainda são consideradas retrabalho, por isso, acabam sendo negligenciadas.


A dívida técnica está ligada apenas ao código? Na verdade ela pode ser classificada em diversas categorias...


Como por exemplo:

  • Código - Complexidade ciclomática de método acima de 10;

  • Documentação - Defasada ou ignorada;

  • Teste - Testes parcialmente feitos ou desabilitados;

  • Arquitetura - Diversos microsserviços utilizando um único banco de dados;

  • Design - 70% do código na classe controller;

Com isso podemos entender que uma dívida técnica, pode ser algo que vai além de um código mal feito.


MVP


Quando penso em dívida técnica, isso sempre me faz lembrar que há um conceito muito comum no mundo das startups e grandes corporações, chamado de MVP - Minimum Viable Product, definido pela Wikipédia como:

Produto Viável Mínimo é a versão mais simples de um produto que pode ser lançada com uma quantidade mínima de esforço e tempo de desenvolvimento

O que NÃO É MVP?!


MVP NÃO É um software feito as pressas e entregue do dia para a noite sem a menor preocupação com código ou qualidade. Isso é pode ser considerado como um MVPIG 🐷!


Imagine o seguinte cenário...


Você só tem uma chance de conquistar o seu cliente e quando ele vai utilizar o seu produto ele acaba encontrando um problema. Aí podemos fazer a seguinte reflexão:

  • Quanto custa um possível cliente?

  • Quanto custa a reputação da empresa?

  • Quantas pessoas precisam se envolver na análise e/ou correção de um determinado bug para resolvê-lo?

  • Qual é o valor de um bug?

A ilusão das entregas rápidas e seu impacto negativo...


Antes de tomar qualquer decisão, é importante entendermos que códigos complexos e mal feitos são difíceis de mudar, por isso, fazer um MVPig as pressas e de qualquer forma, provavelmente não vai te trazer bons resultados.


Aquele software escrito em poucos dias, acaba trazendo a falsa ilusão de uma entrega mais "rápida".


Com isso, o sistema começa a evoluir...


E com a evolução do sistema, alguns problemas relacionados a qualidade, performance, segurança e experiência do usuário.


Junto com os problemas, surgem alguns sintomas, como por exemplo:

  • Estimar tarefas acaba se tornando cada vez mais difícil;

  • Erros na estimativa começam a ficar cada vez mais frequentes;

  • O time passa a maior parte do tempo lendo o código tentando entender o que foi feito;

  • O time começa a ficar desmotivado, pois, não consegue evoluir o produto;

  • O trabalho acaba se tornando braçal e desgastante;

  • As entregas começam a ficar mais lentas;

  • A qualidade acaba diminuindo a cada entrega;

  • Os clientes começam a reclamar;

  • Os juros das dívidas técnicas fica acumulado;

  • O impacto financeiro começa a aparecer;

  • A pressão por um prazo menor aumenta;

Como podemos evitar ou minimizar esse tipo de problema?


Para o gerenciamento dessas dívidas, podemos seguir os seguintes passos:


1. Identifique as dívidas técnicas do seu time

Considere dívidas de refatoração de fluxos ou serviços que não foram escritos da forma adequada, inclusão de testes de unidade nos módulos que estão sem testes, atualização de serviços escritos em tecnologias antigas que limitam a evolução do produto, documentação dos serviços desenvolvidos para servir de apoio para novos integrantes e para outras áreas ou até mesmo bugs que geram trabalho manual para o time ou outras áreas.


Como resultado, provavelmente você terá uma lista como essa:

  • Melhorar a performance do relatório X;

  • Reescrever o módulo Y;

  • Criar documentação para o serviço W;

2. Priorize considerando bons critérios


Como funciona a priorização dos itens de trabalho na sua organização? Quem falar mais alto decide? Ou é por feeling do Product Manager ou Product Owner?

Para evitar esse tipo de problema, crie critérios que façam sentido para o seu negócio...


Por exemplo:

  • Valor para o negócio: avalia o quanto aquela determinada feature trará de valor para o cliente e consequentemente para o negócio; (quanto maior for a contribuição para o negócio, maior será a nota)

  • Experiência do cliente: o quanto contribuí para melhorar a experiência na vida dos nossos clientes? (quanto maior for a contribuição para melhorar a experiência do cliente, maior será a nota);

  • Tamanho do trabalho: esforço necessário para realizar o trabalho e o tempo para entregá-lo (quanto maior for o tamanho do trabalho, maior será a nota);

Também procure envolver outras áreas nesse ritual, para ter visões diferentes com relação aos itens listados. Isso ajudará a ter um maior embasamento e alinhamento das prioridades com as demais áreas (principalmente desenvolvimento e produtos).

Como resultado, provavelmente você terá uma lista de itens priorizada como essa.


Considerações:

  • Considere usar notas de 0 a 5 para classificar os itens;

  • Considere utilizar a técnica WSJF (Weighted Shortest Job First);

3. Defina a forma como as dívidas serão pagas

  • Quantas dívidas podemos pagar esse mês?

  • Quantas dívidas podemos pagar até o lançamento da próxima release?

  • Qual é o número limite de dívidas aceita pelo time?

Considerações:

  • É muito importante considerar o risco/impacto que essa dívida traz para o negócio;

  • Se chegarmos no limite de dívidas definido pelo time, precisamos ligar o sinal de alerta e concentrar esforços no pagamento dessas dívidas;

4. Acompanhe


É importante manter o acompanhamento dessa lista, com uma determinada periodicidade. Por isso, é aconselhável criar rituais quinzenais ou mensais para acompanhar a evolução dos pagamentos e novas dívidas, junto ao time.


5. Evite criar novas dívidas


5.1 Entenda o momento do seu time

Procure entender os gaps que o seu time possui relacionados a tecnologia e até mesmo conhecimento de negócio. Com isso, será possível, criar planos de ações e treinamentos, focados naquilo que o time realmente precisa.


5.2 Evite seguir o hype do momento

É muito show trabalhar com tecnologias de mercado e acredito que a maioria dos desenvolvedores irão concordar comigo. Entretanto, é muito importante entender que por muitas vezes estamos mais focados em utilizar determinada ferramenta/framework para resolver o problema, sem antes ao menos entender o que de fato está acontecendo.

Com isso, existe grandes chances de estarmos trazendo uma complexidade desnecessária para o seu projeto e acabar gerando uma série de problemas e dívidas.


5.3 Utilize ferramentas para auxiliar na inspeção do código

O SonarQube é uma ferramenta que auxilia os desenvolvedores a escreverem códigos mais limpos e seguros. Além disso, também temos o SonarLint, que pode tem o objetivo de apontar possíveis erros/problemas durante o desenvolvimento.


5.4 Comece a escrever testes

Os testes trazem uma série de vantagens, entre elas, ajudam a melhorar a qualidade do projeto e a reduzir a chance de encontrar erros em ambientes produtivos.

Consideração: lembre-se, um erro encontrado em produção pode custar MUITO mais caro do que o tempo investido para escrever testes/testar de forma adequada.


5.5 Crie uma política de code review

Crie uma política que considere

  • Segurança;

  • Qualidade;

  • Performance;

  • Boas práticas de desenvolvimento (um guideline de boas práticas criado pelo time pode ajudar);

Conclusão


Dívida técnica não é um problema, desde que, ela seja gerenciada e paga em dia (lembra do cartão de crédito?).


A cada dia que passa, temos a necessidade de ser mais ágeis e temos o desafio de manter a qualidade do que é desenvolvido. Por isso, a responsabilidade de não gerar mais dívidas técnicas deve ser compartilhada com todo time. TODOS devem se preocupar com a qualidade do código que é desenvolvido.


Desenvolvedores devem ter a responsabilidade de apresentar o motivo (de forma clara), do porque determinada tarefa não poder ser feita, mostrando os riscos e impactos.


A alta gestão, tem o dever de assumir os riscos junto com time, caso eles optem por sugerir um prazo apertado (mesmo com altos riscos e impactos), é importante entender que uma dívida pode ser deixada para trás e que dívidas precisam ser pagas, se não, serão cobradas com juros abusivos.

 

O Ben-hur é o nosso arquiteto de software e está estreando nessa colaboração de conteúdos técnicos! No LinkedIn você também tem acesso a outros artigos escritos por ele ;)


E não esqueça de comentar com a gente no Instagram o que estão achando dessa troca de conteúdos mais aprofundados!

Posts recentes

Ver tudo

Comments


bottom of page