- O Technical Debt pode aparecer quando prazos são priorizados em detrimento da qualidade de um software.
- Assim como a dívida financeira, dívidas técnicas custam um alto preço à empresas e, em muitos casos, levam Startups à inércia.
- Desenvolver um plano de gerenciamento e desvio do Technical Debt é essencial para que a equipe mantenha velocidade com qualidade.
Sabemos que não existem prazos dentro da inovação, pois, quando se deseja desenvolver algo, é necessário tempo de maturação da ideia e autonomia para o desenvolvimento do projeto, a fim de que surja algo que tenha e apresente valor.
Ao desenvolver uma solução digital é imprescindível que o idealizador do negócio tenha os objetivos de alcance da solução bem definidos. Principalmente quando consideramos que desenvolver um projeto é algo complexo e que soluções precisam de tempo para que possam ser desenvolvidas com qualidade.
É ao subestimar a complexidade existente no desenvolvimento de soluções tecnológicas que muitos empreendedores se perdem. Por mais inovadora que seja a ideia, priorizar prazos em detrimento da qualidade é um dos maiores erros a se cometer.
São nesses momentos que o Technical Debt se torna suscetível a aparecer, um problema muito comum no desenvolvimento de software, que pode ocorrer em situações onde há grandes exigências do mercado e prazos estreitos a serem cumpridos, levando à modificações no que foi estabelecido no desenvolvimento do software.
O que é Technical Debt?
Technical Debt ou Dívida Técnica, em português, representa a dívida que uma equipe de desenvolvimento assume quando implementa decisões inapropriadas em um curto prazo, apresentando, assim, consequências negativas um tempo depois.
Ward Cunningham, um programador que desenvolveu a primeira Wiki e co-autor do Manifesto Ágil, criou a metáfora chamada de Debt Metaphor, onde ele relaciona o mundo financeiro com a produção de um software.
Desenvolver um produto envolve a tomada de decisões tanto em relação ao software, quanto ao negócio. Isso envolve escolhas como a arquitetura do código e os objetivos que a solução deverá atingir.
Dessa forma, na produção de um software, definições erradas podem ser geradas através do desalinhamento existente entre a equipe técnica e a equipe de gestão.
A organização é imprescindível para que um código seja construído de maneira sólida, o que exige tempo de desenvolvimento, análise e pensamentos críticos nas tomadas de decisões.
Assim, decisões imediatistas geram atrasos no longo prazo, o que se assemelha ao pagamento de juros sobre um empréstimo.
Posteriormente, a metáfora de Cunningham começou a ser chamada de Technical Debt. Depois de tomar decisões erradas, a equipe técnica de desenvolvimento terá uma dívida técnica e, um dia, ela precisará ser paga.
Assim como são acrescidos juros ao pagamento de uma dívida financeira, o pagamento da dívida técnica vem em forma de trabalho extra. Tal esforço adicional precisa ser pago em desenvolvimento, seja por escolha de tecnologias inapropriadas ou por desenvolver um produto de maneira impensada, em decorrência da pressão existente para o lançamento.
E, aqui, temos duas opções: continuar com a dívida, ou seja, utilizar um produto com a performance prejudicada, ou quitar a dívida, realizando uma refatoração.
A refatoração significa a reconstrução de partes do software e, por mais custosa que seja, é necessária para que sejam saldados os juros futuros.
Dois tipos de Technical Debt:
De acordo com Steve McConnell, CEO da Construx Software, a dívida técnica pode ser classificada em dois tipos, as que ocorrem sem querer e as intencionais:
- Sem intenção: A primeira classificação de dívida técnica se refere a um tipo que ocorre sem intenção. Por exemplo, quando uma companhia contrata outra que já tem histórico de dívida técnicas, e só identifica isso posteriormente.
- Intencional: O segundo tipo é aquele que ocorre intencionalmente. Realizado, normalmente, quando uma empresa toma uma decisão de maneira consciente, a fim de otimizar uma entrega no presente e não no futuro, mesmo que isso ocorra em detrimento da qualidade.
Quais suas consequências?
Conforme mencionado, a refatoração se torna uma das consequências do Technical Debt. A soma de várias decisões tomadas erroneamente se transforma em uma grande dívida e, posteriormente, cada falha se transformará em retrabalho.
No fim, a equipe terá um grande volume de trabalho para ser refeito na solução. A refatoração, uma das grandes consequências deste débito técnico, se constitui em desenvolver novamente partes do software.
As falhas apresentadas devem ser reconstruídas, considerando a não apresentação dos objetivos estabelecidos ou dos requisitos projetados, como também a ocorrência de uma performance inadequada.
Uma consequência ainda mais prejudicial é a possibilidade de ter que reescrever todo o código. Um resultado mais extremo que ocorre quando há um grande acúmulo de dívidas técnicas. Aqui, tudo que foi desenvolvido precisa ser refeito, o trabalho já entregue é totalmente perdido e o software precisa ser erguido do zero.
Ao escrever novamente, a equipe de gestão junto à equipe técnica precisa alinhar novamente os objetivos e estabelecer os requisitos outra vez. Ou seja, tudo que prioritariamente deveria ter sido alinhado entre as duas equipes, neste momento, precisará ser finalmente estabelecido.
Um tempo ganho agora pode representar tempo perdido no futuro. Se não for solucionada, a dívida técnica pode atrapalhar sistemas, causar atrasos de vários meses nas versões do projeto, travar softwares, diminuir a eficácia da empresa a longo prazo e fazer com que startups fiquem inertes.
Outro ponto é, assim como o nome já aponta, é uma dívida. A cobrança existente sobre os desenvolvedores para que entreguem rapidamente uma necessidade do mercado os possibilitam pouco tempo para projeção de uma solução.
Entretanto, embora atalhos e suposições os ajudem em um curto prazo, as dívidas são inevitáveis. E, não sendo atendidas, em determinado momento, a conta desses atrasos chegará.
Embora pareça ser abstrato, o termo tem valores reais. De acordo com a VenturePact, uma plataforma de SaaS, para cada 1 dólar ganho em atalhos para liberar um produto rapidamente, podem ser gastos 4 doláres em refatoração.
Segundo um relatório do Google, foi constatado que a dívida técnica afeta diretamente na produtividade. Os entrevistados com alto índice de dívida técnica são 1,6 vezes menos produtivos e os com melhor desempenho possuem 1,4 vezes menos chance de possuir a dívida.
Conforme aponta Bill Curtis, cientista chefe da CAST:
A dívida técnica cria uma dose dupla de problemas, porque consome dinheiro da inovação em TI para pagar pelos reparos de software. A consequência é menos dinheiro para desenvolver novos aplicativos capazes de fornecer uma vantagem competitiva a uma organização e aumentar o risco incorporado nos novos aplicativos projetados para criar essa vantagem. Isto certamente faz da dívida técnica algo que deve ser extremamente importante para os CIOs e CEOs.
Consequências em cases reais de Technical Debt
Muitas empresas ignoram a dívida em sua juventude, mas, logo se deparam com surpresas técnicas desagradáveis ao longo do tempo.
A dívida técnica deve ser um problema a ser temido nos negócios tanto quanto é a dívida financeira.
Os seguintes cases mostram o quanto o negligenciamento técnico afeta a existência de muitas empresas. Nomes conhecidos como Uber, Instagram e Twitter, apesar de terem se tornado negócios de sucesso, tiveram sua existência comprometida e contornaram a situação pagando um alto preço:
O Twitter, que inicialmente construiu o front-end de sua plataforma utilizando Ruby on Rails, sentiu dificuldades em melhorar o desempenho das pesquisas e adicionar recursos.
Logo, o substituiu por um servidor Java, que segundo a empresa, possibilitou a redução de três vezes na latência da pesquisa.
Krishna Gade, na época Gestor de Engenharia da rede social, publicou em um anúncio no blog do Twitter:
Com o tempo, também acumulamos dívidas técnicas significativas em nossa base de códigos Ruby, dificultando a adição de recursos e a confiabilidade do nosso mecanismo de pesquisa.
Assim como o Twitter, desde o início, o Instagram foi uma vítima da dívida técnica. Ao lançar seu aplicativo para iPhone, em outubro de 2010, a operação foi realizada em um único servidor em Los Angeles. Em seis horas, a operação de back-end estava completamente sobrecarregada.
Porém, logo após um ataque de tráfego quase travar o servidor, o Instagram precisou realizar uma mudança, em apenas três dias, para um banco de dados hospedado no Amazon Elastic Compute Cloud (EC2).
Na época, Mike Krieger, co-founder do aplicativo, comparou essa transferência a uma cirurgia de coração aberto.
Krieger e o também co-founder, Kevin Systrom, imediatamente viram que seria necessário refazer tudo rapidamente. Principalmente, se houvesse um grande fluxo de pessoas no aplicativo no fim de semana, que na época, se aproximava de 40.000 usuários – hoje, são 1 bilhão de usuários ativos.
Atualmente, há um trabalho preventivo sobre possíveis dívidas técnicas para que não se tornem adversidades, como ocorreu em 2010.
Uber
Em 2016, 57 milhões de passageiros e motoristas do Uber tiveram seus dados violados, como o número de cartão de crédito e outras credenciais.
Quem causou a violação? A dívida técnica.
O crescimento rápido da plataforma levou a decisões de codificação que economizaria tempo, aumentaria sua eficiência momentânea e possibilitaria alterações rapidamente no software.
Outros erros se agregaram. Sobretudo, pelo código de software ter sido postado em um repositório de código popular chamado GitHub, tudo em texto simples e nada criptografado. O erro cometido pelo Uber possibilitou um ataque, somado a isso, a autenticação de dois fatores não estava ativada.
Como a chave de acesso codificada estava em texto simples, os atacantes a usaram para acessar os bancos de dados de software, onde os dados do cliente eram armazenados.
Assim, o pior pôde acontecer: a conta do GitHub foi comprometida por hackers, que utilizaram as credenciais para roubar os dados de 57 milhões de usuários.
Como comentado pela CSO, a respeito do caso:
A realidade é que não é a segurança que gera dinheiro para uma empresa. Mas a falta de segurança pode custar muito à empresa, além de danos institucionais e à reputação. A resposta para essa dívida técnica é incorporar as práticas recomendadas, bem como as ferramentas de segurança adequadas. […] São as medidas preventivas adotadas que podem eliminar a dívida técnica e manter os negócios e seus clientes seguros.
Como evitar?
O preço a se pagar quando se acumula uma dívida técnica é muito alto e, diferente de uma dívida financeira, é difícil de mensurar, pois é um custo totalmente dependente de fatores externos. Como exemplo, não é possível o controle absoluto do lançamento da atualização de um software.
Na maioria das vezes, as necessidades do mercado reduzem o tempo de desenvolvimento de um produto para que ele seja lançado o mais rápido possível. Mudar a mentalidade dos envolvidos que podem gerar a dívida técnica não é fácil. Por isso, pontuamos alguns itens que podem fazer com que o Technical Debt seja evitado:
Tenha uma estratégia inicial clara
Antes de iniciar o desenvolvimento, é importante definir todos os detalhes técnicos envolvidos. Quais serão as funcionalidades? Quais os recursos do produto serão aceitos e implementados? Classificar as funcionalidades da solução direciona o desenvolvimento e fornece um roteiro. Assim, o retrabalho será contornado.
A comunicação entre as equipes envolvidas é crucial, pois, ao ter que pagar uma dívida técnica, as prioridades e cronogramas serão afetados.
Estabelecer estratégias inicialmente, com clareza, possibilita que os riscos, que neste momento é esperado que já tenham sido quantificados e expostos, não afetem as funcionalidades da solução.
Implementar o DevOps
Suporte de DevOps é uma prática de engenharia de software que tem como intuito prezar por práticas ágeis, eficientes e de alta qualidade, com ciclos menores de desenvolvimento e maiores números de implementação.
Assim, o DevOps objetiva uma melhor integração entre desenvolvedores de softwares e a equipe de infraestrutura.
Implementando práticas do DevOps as equipes podem ser beneficiadas com uma menor suscetibilidade de erros, alcançam produtos elaborados de forma mais definida e conquistam maiores chances de atender às necessidades finais do cliente.
A sua aplicação na construção de software indica os melhores caminhos para que um produto final ineficiente seja evitado.
Havendo a necessidade de revisão de códigos, é possível que as alterações sejam analisadas, se garanta que sejam legíveis, compreensíveis e atendam aos padrões de codificação.
Espalhe a conscientização
Quanto mais desenvolvedores e clientes estiverem cientes dos efeitos da dívida técnica, maior será a prioridade em não tê-la. Porém, muitas vezes, a decisão pela dívida técnica não parte desse time, mas do comercial ou social.
O suporte não só deve vir da equipe de desenvolvimento, mas também da gerência, para que o projeto seja construído com qualidade.
Quantificar e explicar os efeitos da dívida é importante e deve partir tanto da equipe de desenvolvimento para o idealizador do produto, quanto do idealizador para o restante dos envolvidos no negócio.
Uma ação corretiva dificilmente será levada em consideração pelo cliente se ele não entende a necessidade dela. Por mais ansioso que esteja com o lançamento de sua solução, se ela é colocada no mercado antes que apresente uma boa performance, a vida útil da proposta certamente será afetada.
Por mais que seja possível aprimorar o produto depois, o cliente deve estar ciente que a imagem de seu negócio pode ser posta em risco e que um novo lançamento pode não ter a mesma notoriedade do que se fosse um lançamento de qualidade. Qualidade deve ser priorizada em relação ao prazo.
Resista à tentação de economizar tempo
De acordo com uma pesquisa da Salesforce, dependendo do setor, falhas no lançamento nas plataformas de novos produtos variam entre 30% a 80%.
Ou seja, o trabalho necessário para inaugurar um produto de sucesso ocorre muito antes de seu lançamento. Postergar o lançamento de um produto pode, na verdade, ser um grande aliado para que ele seja uma solução que tenha e apresente valor.
Torne o distanciamento ao Technical Debt uma prioridade
Uma vez que ignorada, a dívida técnica tende a só diminuir a produtividade e qualidade de uma equipe. Desenvolver um plano de gerenciamento e desvio do Technical Debt é essencial para que a equipe alcance e mantenha velocidade com qualidade. Se a dívida técnica faz parte da sua equipe, a priorize para que possa ser prontamente solucionada.
Conclusão
Se o que precisa ser desenvolvido ainda é apenas um protótipo e está em fase de validação, o Technical Debt até pode ser benéfico. Nesses momentos uma reconstrução será feita de qualquer forma, seja corrigindo, reajustando ou aprimorando uma Prova de Conceito.
Mas, de maneira geral, o Technical Debt que até pode começar com boas intenções, tem seu fim baseado em grandes falhas de sistema. Em casos onde o produto já foi validado, a prática pode ser muito prejudicial à construção do código. Um tempo ganho no presente que significa tempo perdido no futuro.
Antes, as mudanças eram lenta e metodicamente implementadas nos softwares, verificações quanto a erros eram realizadas com cautela e testadas pela equipe de usabilidade antes que fossem disponibilizadas ao público.
Hoje, muitos lançam mão desse cuidado em favor da renovação rápida e contínua do software.
De qualquer forma, se o que você busca desenvolver é uma solução com qualidade, bem aceita pelos usuários, que permita uma boa escalabilidade do seu negócio e que dure mais do que uma temporada, o Technical Debt deve ser evitado em todo o desenvolvimento.
O alinhamento entre o time de desenvolvimento e tomadores de decisão é sempre necessário. Ajustar os objetivos de ambas as partes e fugir de decisões imediatistas serão os primeiros passos para que um software de valor seja desenvolvido e este atinja os objetivos traçados.
