Cuidado com a dívida técnica

Depois de mais de um mês se escrever no blog, ufa, também com essa mudança de empresa, cidade e estado, só faltou mudar o país!! Bom, estava lendo alguns artigos na InfoQ e algo me chamou a atenção e resolvi escrever a respeito: Dívida Técnica. Primeiramente vou falar sobre o que é dívida técnica e depois abordarei algumas das causas mais comuns.

Definição de Dívida Técnica

O conceito de “Dívida Técnica”, é uma metáfora para indicar que toda vez que você toma um atalho técnico (o bom e velho “não importa que saia sujo, o importante é lançar o produto rápido!”), ou também as famosas POGs(Programação orientada a gambiarra). Isso não sai de graça. Toda vez que fazemos isso, é como fazer um empréstimo num banco, ou seja, é como assumir uma dívida. E como toda dívida, essa também corre juros e um dia será devidamente cobrada! Saliento que a dívida técnica influencia diretamente no TCO dos produtos.

O termo “dívida técnica” foi exposto a primeira vez por Ward Cunningham para descrever a obrigação que uma organização de software incorre quando escolhe um design ou um tipo de construção que é prático no curto prazo mas que aumenta a complexidade e é mais custoso no longo prazo.

Ward não explicou a metáfora muito a fundo. As poucas pessoas que discutiram dívida técnica parecem usar a metáfora principalmente para comunicar o conceito à equipes técnicas. Eu concordo que é uma metáfora útil para comunicar com equipes técnicas, mas estou mais interessado na incrível e rica habilidade da metáfora de explicar um conceito técnico crítico para stakeholders de projeto não-técnicos.

Impacto da Dívida Técnica no TCO

O TCO(Total Coast of Ownership) é quanto o produto custou efetivamente para seu desenvolvimento, um cálculo complexo que abrange desde a concepção, gastos com desenvolvimento, marketing, posicionamento no mercado, infra e tudo mais que for necessário para o produto ser posto em produção. Se nos deparamos um produto que depois de “pronto” demanda muita manutenção por apresentar um número de bugs muito alto, evidenciamos um caso clássico de dívida técnica. Concordam que os bugs tem que ser corrigidos, pois bem, essa correção a ser feita tem seu custo, esse custo deve ser acoplado ao já pago com o desenvolvimento do produto e sua manutenção normal por disponibilização.

Alguns fatores que influenciam na criação de dívidas técnicas

  • Owner Pression: Quem nunca viveu o caso clássico aonde o cliente(chefe, diretor e por ai vai) solicita ao desenvolvedor que termine logo uma determinada atividade porque o software tem que ser colocado em produção até uma date previamente determinada. Nesse ambiente há a pressão do dono e para a entrega ser feita o mais rápido possível abre-se mão de algumas coisas, entre elas, testes, exploratórios mais consistentes, unitários,  de integração. É o famoso funcionou tá pronto.
  • Subestimar complexidade das features: Quanto o time de desenvolvimento julga menor a complexidade de uma determinada feature, exemplo é quando o cliente pergunta quanto tempo para fazer uma determinada feature e o time diz sem analisar muito bem que demora X dias e quando vemos o tamanho dela percebemos que demoraria 3  vezes mais. Como o compromisso é com a entrega, mais uma vez algo deve ser abolido do desenvolvimento. Vale lembrar que este é um comportamento nocivo e não ágil que foge completamente no princípio da transparência.divida-tecnica-subestimar-features
  • Falta de habilidade do time: Esse caso é um dos mais complexos, porque envolve muitas coisas. Se temos um time que não está habilitado a trabalhar com tal tecnologia por exemplo, temos que treinar esse time antes. Mas como fazê-lo em meio a um projeto em andamento? É nesse tipo de cenário que surgem as implementações faraônicas e macarrônicas que são de difícil alteração ou manutenção, com alto acoplamento e alta coesão. Não que o time seja ruim, mas simplesmente não está pronto. Exemplo disso, como pode um time desenvolver orientado a comportamento (BDD) para web, vindo de plataformas desktop?
Quando a dívida técnica é aceitável
Pode ser que você se depare com uma situação onde há uma necessidade de entrega devido a algum fator aonde o cliente necessita por motivos estratégicos colocar algo incompleto em produção. Por exemplo, se o concorrente tem um lançamento de produto agendado e seu cliente precisa antever a esse lançamento. Nesse caso temos uma decisão estratégica guiando o release. É aceitável desde que seja claro e conceituado com o cliente que, será necessário pagar essa dívida o quanto antes, de preferência já na próxima iteração, para que não vire uma bola de neve no final. Nesse cenário a necessidade do cliente é mais importante que alguns fatores técnicos em si, e o risco é dividido entre time e cliente.

Enfatizo que uma hora ou outra tal dívida terá de ser paga. Essa dívida é crescente a cumulativa, pois quando a “bomba” estourar alguém irá pagar a conta. Normalmente quem fica com o prejuízo é o cliente, já que é ele quem irá sentir os impactos e arcar com os custos para a correção.

Creio que já ouviram falar em Sprint de normalização. Isso nada mais é que o time que assume a culpa por não ter feito um trabalho limpo durante o desenvolvimento do produto.

Dinheiro não nasce em árvore

Também há casos mais graves onde todo o produto tem que ser reescrito(refatorado é outro termo muito usado), isso nada mais é que jogar todo o dinheiro usado para o desenvolvimento deste produto no lixo.

Lembre-se que o dinheiro do seu cliente não nasce em árvores. Evite desperdícios com dívidas técnicas, seja sempre transparente sobre o andamento do projeto e principalmente: QUALIDADE NÃO É NEGOCIÁVEL!!

Sejamos sempre ágeis em identificar tais riscos e corrigir disfunções para que no futuro, o produto seja de qualidade inquestionável e vida útil aceitável

Quem é responsável pela qualidade do produto entregue é o time de desenvolvimento. Teoricamente é ele quem deveria arcar com o custo do baixo nível de qualidade, infelizmente não é isso o que ocorre.

4 pensamentos sobre “Cuidado com a dívida técnica

  1. Ótimo post! Não conhecia o termo embora já tenha vivenciado situações que levaram o time a ter que conviver com tal dívida técnica. Na prática vejo que as pressões dos usuários juntamente com a avaliação incorreta de complexidade são os maiores responsáveis por este cenário.

    Abs.,
    Douglas

    • Bom dia Douglas,

      Isso que você descreve é retrato de um mundo que ainda vê desenvolvimento de software com ciência exata. Há uma curva de aprendizado tanto para novos times, entre si, quanto da linguagem, do negócio. Daí é que vem a variação sobre es estimativas, que ao longo do projeto se tornam mais próximas de realidade. Algumas pessoas ainda acham que a produtividade de um time é sempre linear ao longo do projeto, engano que custa muito caro ao produto, time e cliente.

  2. Pingback: Qualidade não é negociável « Blog do Miguel Carlos

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s