Igor Regis, com mais de 23 anos de experiência em TI, é Especialista I no Banco do Brasil, atuando como principal referencia técnica para área de Engenharia de Software do BB
Nesta série de artigos pretendo mostrar sobre o estado atual da gestão de dívida técnica do Banco do Brasil e nossos próximos passos para amadurecer nosso processo. Mas para começarmos, vamos nivelar os entendimentos sobre o que é a dívida técnica.
Dívida é algo tratado de forma negativa em diversas culturas, mas compreender os mecanismos de funcionamento do capitalismo, ajuda-nos a entender que dívida é algo não só necessário, como bom. A dívida é um artifício de alavancagem econômica, ou seja, se você ou sua empresa precisam atingir um objetivo de curto prazo tem duas opções: (a) Poupar dinheiro pelo tempo necessário para então cumprir este objetivo ou; (b) Tomar um empréstimo para atingir este objetivo imediatamente e então seguir pagando este empréstimo ao longo dos meses seguintes, antecipando assim o início do retorno sobre o investimento. Sim, dívida é um artifício para melhorar o chamado “time to market”.
Com software temos o mesmo cenário. A dívida técnica é uma métrica usada para mensurar aspectos entendidos como negativos de um software e que “cobram seu preço” até que sejam extintos (pagos). É uma medida do quanto um software desvia de uma implementação ideal, gerando com isso alguma consequencia que pode ser estimada como custo ou risco, portanto ela irá aparecer em um software mesmo que o time não tenha decidido tomá-la; neste artigo Mark Schwartz inclusive sugere que seja usado o termo “Technical Delta”. Porém, antes de abordar sua correlação com alavancagem, vamos explorar as definições de dívidas técnicas existentes.
O que afinal é uma dívida técnica em software?
Há vários tipos de dívidas técnicas, como as facilmente detectáveis e mensuráveis, muitas vezes através de seus sintomas, como por exemplo: Uma má prática no código, como a chamada de uma API antiga ou uso de uma técnica que reduz a performance. Ferramentas de análise de código e dependências detectam e mensuram estas dívidas facilmente. Outro exemplo é uma fragilidade de segurança ou um defeito que podem ser detectados em produção ou em testes, antes mesmo do software ser implantado em produção. Em ambos os casos a detecção é clara e a mensuração dos custos para suas correções também. Em alguns casos estamos falando de apenas sintomas de uma dívida mais complexa (de design/arquitetura) e, portanto, de difícil detecção, ou simplesmente um sintoma da passagem do tempo e mudança do ambiente em torno do software.
Há também dívidas técnicas de difícil detecção e mensuração, como por exemplo: Uma arquitetura defasada, por defasada refiro-me a arquitetura de uma solução que já foi útil, mas que em determinado momento deixou de atender plenamente as necessidades do negócio ou cliente. É algo mais complexo do que simplesmente usar uma biblioteca defasada. Este exemplo de dívida aparece de forma sintomática, como por exemplo a queda de performance do software, o aumento de indisponibilidades ou até mesmo a queda da produtividade da equipe de desenvolvimento. A detecção deste tipo de dívida técnica dificilmente ocorre por meio de uma solução automatizada e muitas vezes não é clara, pois exige análise de especialistas, podendo até mesmo não haver consenso, tanto com relação a causa (identificação da dívida) quanto a solução (proposta para amortização da dívida).
Dívidas técnicas comprometem a capacidade do software em evoluir para continuar a atender as necessidades do cliente e do negócio, bem como comprometem a capacidade do software ser facilmente mantido/sustentado, tornando seu custo total elevado (TCO). Grande parte das decisões relacionadas a implementação de um software geram implicações que resultam em uma dívida técnica, como por exemplo a escolha de uma arquitetura ou um software de middleware pode ser adequada para o momento da aplicação, mas invariavelmente irá resultar em uma dívida técnica maior ou menor, em um futuro próximo. O objetivo do time e dos arquitetos de software de uma empresa deve ser tomar decisões que resultem em dívidas técnicas boas, ou seja, baratas e que resultem em riscos baixos.
Este artigo também aborda a dívida técnica como alavancagem e detalha 6 tipos de dívidas técnicas.
Dívida técnica é ruim?
No mundo empresarial uma dívida não é algo ruim, muito pelo contrário, há indicadores para determinados segmentos que mensuram o nível de endividamento de uma empresa. Estes indicadores podem ser interpretados de forma negativa caso seu endividamento esteja muito elevado ou muito baixo. Isso mesmo, uma dívida muito baixa ou inexistente é indicadora de que a empresa pode estar perdendo oportunidades de mercado e deixando de crescer, expondo-se a riscos como o de novos entrantes. A dívida é um mecanismo de alavancagem que empresas devem usar de forma a adquirir capacidade de atuar a frente de sua concorrência.
Uma boa gestão financeira é composta por uma boa capacidade de decisão com relação a quais dívidas devem ser tomadas, quais devem ser evitadas, quais são aquelas que precisam ser quitadas o mais rápido possível e quais devem ser roladas. Deve-se analisar aspectos como o risco que uma dívida impõe as finanças da empresa bem como seu “custo total”, frente aos ganhos esperados ao adquiri-la. Muitas vezes decide-se por rolar uma dívida, barata que representa baixo custo ou risco, outras vezes decide-se quitar rapidamente uma dívida cara, através da aquisição de outra dívida, mais barata. Para aproveitar uma oportunidade de mercado, uma empresa pode fazer uma dívida que parece ser cara e arriscada, mas que torna possível um negócio com retornos certos e fartos.
Os mesmos conceitos devem ser aplicados para a administração de dívida técnica, através do seu entendimento como um mecanismo de alavancagem de software ou um componente de seu custo. Isso ocorre no dia a dia de todos os times de desenvolvimento. Temos que saber identificar as dívidas técnicas de nossos softwares, saber administrá-las e compreender que um software sem nenhuma dívida técnica é um sinal tão ruim quanto um software tomado por dívidas.
Este artigo explora em mais detalhes a dívida técnica e propõem abordagens para seu “pagamento.”
Como gerenciar a dívida técnica em grandes corporações?
A clareza a este respeito é muito importante não só aos times de desenvolvimento, mas também áreas de governança e gestão de processos de TI que disciplinam a atuação destes times em grandes organizações, além dos líderes de negócio. Este conceito influencia fortemente regras que deverão ser seguidas por equipes de desenvolvimento de software. Para tornar este impacto mais claro, vamos trabalhar com alguns exemplos:
Uma dívida avaliada com estas premissas não deve ter data fixa para ser paga. O que precisamos é disciplinar indicadores que informam se um dado defeito de software é causado por uma dívida cara ou de alto risco ou barata e de baixo risco. O defeito deve ser corrigido, esta correção pode ser através do pagamento da dívida ou uma solução de contorno, rolando-se a dívida. Uma dívida que represente baixo risco e impacto para o funcionamento da aplicação, pode ser tolerado por anos, talvez seus efeitos, após uma solução de contorno sejam imperceptíveis.
Da mesma forma ao avaliar uma fragilidade de segurança sob esta ótica, precisamos identificar os fatores que as tornam arriscada e tomar a decisão a respeito de sua “quitação” baseada nestes fatores, e não quanto ao tempo decorrido de sua detecção. Fragilidades que colocam em elevado risco a sobrevivência e reputação da empresa naturalmente serão compreendidas originadas de dívidas a serem rapidamente quitadas e até mesmo inaceitáveis, ou seja, o software não deveria ser implantado com sua ocorrência. Mas esta não é uma decisão estritamente técnica, e sim de quem administra o negócio. É importante salientar que a fragilidade de segurança não é a dívida, podendo e geralmente devendo ser resolvida, com por exemplo uma solução de contorno, a exemplo do caso do defeito. A dívida geralmente é a causa raiz.
Modelar processos e indicadores que obrigam resolução (pagamento) de dívidas técnicas, baseados somente em tempo decorrido de sua detecção irá prejudicar a gestão desta dívida, gerando efeitos nocivos à saúde do software e da empresa, ao invés de benefícios. A temporalidade deve ser levada em consideração, mas ela não precisa e possivelmente não deve ser uma dimensão considerada para dívidas técnicas que representem baixo risco. O ponto polêmico será determinar em qual grau a análise do nível de risco de uma dívida, deve passar a desconsiderar sua data de detecção.
A dívida técnica de software é algo tão novo e obscuro para a administração de empresas, que precisa ser detectada, ou seja, administradores de empresas tomam estas dívidas inconscientemente! Faltam modelos de governança corporativa e disciplinas de gestão que incorporem estas dimensões nas práticas de gestão empresarial.
Ao compreender o funcionamento da sociedade capitalista, passamos a entender que uma dívida boa nós mantemos e dívidas ruins nós pagamos. A manutenção de uma dívida boa muitas vezes dá-se através do pagamento de seus juros, que muitas vezes são baixos, pagando-se o mínimo necessário do montante. Ao pagamento do montante chamamos de amortização. O mesmo pensamento deve ser aplicado a gestão de dívida técnica de um software. Pois estão presentes também, alguns conceitos como pagamento de juros e amortização. Vou fazer este paralelo a seguir.
As dívidas técnicas de um software geram dois efeitos: (a) risco, onde ela pode ou não comprometer severamente a sobrevida do software, gerando por exemplo uma indisponibilidade e causando prejuízos financeiros graves a empresa; ou (b) “juros” que se manifesta pelo aumento do TCO (custo total de propriedade) do software, este tipo de efeito pode ser visto em dívidas relativas ao uso de um arquitetura ou tecnologia obsoleta que prejudica a produtividade do time, ou que geram maior consumo de infraestrutura. Assim ao pagar esta conta não estamos amortizando a dívida, apenas convivendo com ela. Este pagamento de juros ocorre ao pagar uma conta mais elevada do seu provedor de nuvem ou adquirir um servidor mais potente, para dívidas que se manifestam na forma de performance; ou através de aumento do time de desenvolvimento, para aquelas que se manifestam como perda de produtividade.
Podemos decidir trocar uma dívida mais cara por outra que pareça mais barata, como por exemplo quando decidimos implementar uma solução “criativa” para reduzir o consumo de infraestrutura. Criamos assim uma outra dívida a ser paga, para com ela poder reduzir os juros da primeira dívida mais cara. Na maioria das vezes não eliminamos a primeira dívida, apenas aliviamos seus efeitos; ou seja, pagamos apenas seus juros ou amortizamos parcialmente, sem realizar a quitação. É uma troca de dívidas; esta implementação pode manifestar-se como perda da produtividade do time, ou aumento de instabilidade, ou seja, é uma dívida diferente com juros diferentes.
Não é melhor ficar sem dívida técnica?
Um software sem dívidas técnicas também significa um problema, este pode ser um sintoma de superdimensionamento do time que mantem este software, geralmente vejo como um sintoma de que a estratégia de negócio por trás deste software não está se alavancando o suficiente para atuar de forma arrojada no mercado em que ele é usado. Da mesma forma uma organização que persegue o zeramento das dívidas técnicas de seus softwares, está estrangulando a capacidade de alavancagem de sua estratégia de negócio.
Por outro lado, empresas com um elevado grau de dívidas técnicas em seus softwares, podem estar sofrendo do subdimensionamento de seu time, o que leva a seu corpo técnico a recorrer continuamente ao endividamento. Isso é conhecido como a temida “Death Spiral” (Espiral da Morte), se quiser conhecer mais sobre a espiral da morte, recomendo este artigo.
Todo gestor, seja empreendedor ou não, precisa administrar muito bem alguns indicadores chaves operacionais de sua empresa, como os indicadores de pessoas ou os financeiros. Neste artigo exploramos um conjunto de indicadores de software que deveriam fazer parte do portfólio estratégico de qualquer organização que possua produtos baseados em software. Indicadores de saúde na gestão de pessoas são modelados e liderados por especialistas na gestão de pessoas, porém são gerenciados por todos os administradores da organização, assim como os indicadores financeiros. No Banco do Brasil iniciamos um trabalho para termos um modelo de maturidade de gestão de dívida técnica, bem como processos organizacionais para a gestão desta dívida, incluindo aí a modelagem de indicadores. Nos próximos meses eu e outros colegas traremos novidades a respeito deste trabalho que envolve diversas áreas da TI do BB.
Está interessado em saber mais sobre o assunto? Alguns dos aspectos deste artigo são abordados de forma mais profunda e detalhada no livro Managing Technical Debt: Reducing Friction in Software Development, incluindo aí as analogias de montante e juros de dívida e a comparação com um financiamento imobiliário.
Leia também:
Kodiak: a nova tecnologia por trás do aplicativo do BB
APIs: o uso da documentação das APIs
Movimentos estratégicos: explorando o tabuleiro de xadrez do Domain-Driven Design
Comentários:
Carregando Comentários...