Como comenta o diretor de tecnologia Jean Pierre Lessa e Santos Ferreira, em algum momento de praticamente todo projeto de software, alguém no time de desenvolvimento usa a expressão dívida técnica para descrever código que precisa ser reescrito, arquitetura que precisa ser revisada ou testes que nunca foram escritos, mas deveriam ter sido. A reação mais comum de lideranças de produto e de negócio a esse diagnóstico é uma mistura de desconforto e impaciência: desconforto porque o problema parece vago e difícil de quantificar, e impaciência porque a solução proposta envolve dedicar tempo do time a trabalho que não entrega nenhuma funcionalidade visível para o usuário.
Ao longo deste artigo, você vai entender o que é dívida técnica em termos que fazem sentido para quem não escreve código, quais são as formas em que ela se manifesta como problema de negócio e como times de produto e de engenharia podem construir um processo de tomada de decisão sobre dívida técnica que seja transparente, baseado em dados e alinhado com os objetivos da organização.
Continue lendo: se você é product manager, executivo ou fundador e nunca entendeu muito bem o que seu time de engenharia quer dizer quando fala em dívida técnica, este artigo foi escrito para você.
O que é dívida técnica em termos que fazem sentido para quem toma decisões de produto e de negócio?
A metáfora da dívida é mais precisa do que parece à primeira vista. Assim como uma dívida financeira, a dívida técnica tem principal e juros. O principal é o trabalho que precisaria ser feito para colocar o código, a arquitetura ou os processos de desenvolvimento no estado que deveriam ter desde o início. Os juros são o custo adicional que toda nova funcionalidade, toda correção de bug e todo processo de manutenção paga por causa das deficiências do estado atual do sistema. Esses juros se manifestam como lentidão na entrega, como bugs mais frequentes e mais difíceis de diagnosticar, como onboarding demorado de novos desenvolvedores e como resistência crescente do sistema a mudanças que deveriam ser simples.
Como destaca Jean Pierre Lessa e Santos Ferreira, é importante distinguir a dívida técnica intencional da acidental, porque as duas têm origens diferentes e merecem respostas diferentes. A dívida técnica intencional é aquela gerada por uma decisão deliberada de sacrificar qualidade técnica de curto prazo em troca de velocidade de entrega. Lançar um produto com arquitetura simplificada para validar uma hipótese de mercado antes de investir na versão definitiva é um exemplo de dívida técnica intencional que pode ser uma decisão correta. O problema começa quando a decisão de tomar essa dívida não é acompanhada de um plano explícito para pagá-la, fazendo com que o sistema que deveria ter sido temporário se torne permanente por inércia.
Como a dívida técnica se manifesta como problema de negócio e como quantificá-la de forma que faça sentido para stakeholders não técnicos?
Segundo Jean Pierre Lessa e Santos Ferreira, a manifestação mais direta de dívida técnica como problema de negócio é a redução da velocidade de entrega ao longo do tempo. Times que começam um projeto conseguindo entregar várias funcionalidades por sprint e que progressivamente entregam menos pelo mesmo esforço sem que haja mudança óbvia no time ou no escopo estão frequentemente pagando os juros da dívida técnica acumulada. Essa desaceleração é mensurável: a comparação da velocidade média do time em diferentes momentos do ciclo de vida do projeto é uma forma direta de tornar visível o custo que a dívida técnica está impondo ao ritmo de desenvolvimento.
Jean Pierre Lessa e Santos Ferreira
A frequência e o custo de resolução de bugs são outros indicadores que traduzem dívida técnica em termos de negócio. Sistemas com alta dívida técnica tendem a ter bugs que aparecem em partes do código inesperadas, que se revelam mais difíceis de diagnosticar do que deveriam e que, quando corrigidos, frequentemente geram novos bugs em outras partes do sistema. O rastreamento do tempo médio de resolução de bugs ao longo do tempo e a análise de quais áreas do sistema geram desproporcionalmente mais problemas produzem uma evidência concreta do custo da dívida que qualquer stakeholder pode compreender sem precisar entender código.
Assim como pontua Jean Pierre Lessa e Santos Ferreira, a quantificação de dívida técnica em horas de desenvolvimento que precisariam ser investidas para colocar o sistema em um estado saudável é uma abordagem que, embora imperfeita, tem o mérito de tornar o problema comparável com outras alocações de tempo do time. Quando a liderança de produto entende que o sistema atual carrega uma dívida equivalente a três meses de trabalho de dois desenvolvedores, e que cada sprint sem endereçar essa dívida adiciona mais algumas semanas de trabalho futuro, a decisão de alocar tempo para pagamento de dívida técnica passa a ser uma decisão de negócio com parâmetros compreensíveis, e não uma concessão opaca feita ao time técnico.
Como times de produto e engenharia podem construir um processo compartilhado de tomada de decisão sobre dívida técnica?
O primeiro passo para um processo colaborativo de gestão de dívida técnica é a criação de uma linguagem comum que não exclua nenhum dos dois lados da conversa. Termos técnicos como refatoração, acoplamento excessivo e cobertura de testes são opacos para quem não tem formação em desenvolvimento. Mas os impactos de negócio que esses conceitos descrevem, como risco de entrega, custo de manutenção e capacidade de escala, são completamente compreensíveis para qualquer pessoa de produto ou negócio. Traduzir o diagnóstico técnico para consequências de negócio concretas é a responsabilidade do time técnico nessa conversa, e é uma habilidade de comunicação que engenheiros e tech leads raramente desenvolvem de forma sistemática.
A inclusão de itens de redução de dívida técnica no processo de priorização de produto, com critérios de avaliação explícitos, é o segundo passo. Conforme Jean Pierre Lessa e Santos Ferreira, quando a decisão sobre quanto tempo dedicar ao pagamento de dívida técnica é tomada pelo time técnico isoladamente, sem visibilidade de produto e de negócio, ela inevitavelmente perde para as demandas de funcionalidades novas que têm stakeholders visíveis e pressão de prazo evidente. Quando a mesma decisão é tomada com participação de produto e de negócio, com clareza sobre o que está sendo trocado e por quê, ela pode ser tomada de forma muito mais alinhada com as prioridades reais da organização.
A revisão regular da saúde técnica do sistema, com métricas acompanhadas ao longo do tempo e compartilhadas com toda a liderança do produto, é o componente final de um processo de gestão de dívida técnica que funciona. Assim como indicadores financeiros e de produto são revisados em reuniões de liderança com regularidade, indicadores de saúde técnica, como velocidade do time, taxa de bugs em produção, tempo de onboarding de novos desenvolvedores e cobertura de testes, deveriam ser parte da mesma conversa. Quando a dívida técnica deixa de ser um problema do time de engenharia e passa a ser uma métrica de saúde do produto que toda a liderança acompanha, o processo de decisão sobre ela muda de natureza de forma que beneficia tanto o produto quanto o time técnico.
Autor: Diego Rodríguez Velázquez
