O grande dilema do Débito Técnico e a Geração de Valor
Como atender às necessidades técnicas sem deixar de gerar valor para o seu negócio?
Podemos definir Débito Técnico como uma demanda técnica que precisará de um esforço para ser desenvolvida ou implementada. Geralmente podemos associar um Débito Técnico com um desenvolvimento já implementado com baixa qualidade ou não desenvolvido em sua integralidade e podemos associar a demandas de atualização ou aprimoramento da infraestrutura necessária para que seu produto funcione, contudo, não gera um valor direto para ele.
De qualquer maneira, um Débito Técnico deverá ser incluído no Product Backlog e priorizado junto às outras demandas para seu desenvolvimento pelo time. É exatamente neste momento que nos deparamos com o dilema de priorização!
Sempre com uma visão evolutiva, tendemos a procrastinar o refinamento e a inclusão dos Débitos Técnicos nos ciclos, priorizando as Histórias de usuários que vão criar valor para nosso produto, contudo estamos gerando um problema futuro grave...Normalmente os DTs vão aprimorar uma funcionalidade ou até corrigir problemas de performance e segurança e estes pontos cobram “juros” altos se não forem realizados, culminando em vulnerabilidades, bugs e até indisponibilidades, gerando um grande impacto para seu produto e marca no mercado.
O Débito Técnico de hoje é a Urgência de amanhã
Temos que dar a devida atenção aos DTs, principalmente com as atualizações de segurança dos frameworks e infraestrutura que usamos, eles são cumulativos e acabamos criando uma “bola de neve” se deixarmos de lado.
Decidir não “pagar” um DT de falha de segurança é assumir um risco de dívida, pagando caro depois e tendo que focar todo o time durante muito tempo para a resolução.
Uma outra razão bastante importante para priorizar os DTS é que vamos deixar a arquitetura de nosso produto obsoleta ou fora das melhores práticas, inviabilizando sua atualização ou gerando muitos impactos e dependências na execução. Neste caso sabemos que o nosso Lead Time poderia ser bem menor, fazendo o negócio perder o timing da entrega do Valor ou até Market Share, pois o desenvolvimento de novas funcionalidades ou alterações importantes vão demandar mais tempo para serem desenvolvidas e testadas e efetivamente liberadas em produção.
Possíveis estratégias
Algumas dicas para não cair nessa armadilha
Equilibre e pondere as demandas técnicas e as de negócio
Valide e acorde com o time a quantidade de demandas técnicas devem ser incluídas em cada ciclo de acordo com as necessidades e impactos
Entenda as necessidades de geração de valor do negócio frente às demandas técnicas
Foque no processo de qualidade das entregas
O objetivo é não gerar novos DTs “conhecidos”
Revise o fluxo de testes e de Code Review com o time
Identifique demandas técnicas críticas
Demandas que podem gerar vulnerabilidade ou indisponibilidades
Estude refine as demandas com o time com grande atenção
Alinhe as expectativas com o negócio
Evite o desenvolvimento com baixa qualidade por falta de entendimento para cumprir prazos
Melhore o refinamento e estimativa das demandas gerando maior previsibilidade
OK, mas como vou conseguir engajar o time neste equilíbrio?
As demandas técnicas vão existir sempre, e temos que nos adaptar e fazer o melhor possível com este fato.
Uma boa maneira de engajar o time e a liderança nesta jornada é demonstrar o ganho em médio e longo prazo de mantermos a saúde técnica do nosso ambiente, influenciando no Lead Time e qualidade das entregas, gerando competitividade estratégica e grande diferencial no mercado.
Mantenha a transparência e pertencimento de todos nestas demandas, é muito importante que todo o time saiba o motivo da realização da história “A” e não da história “B”.
Demonstre com casos reais os custos diretos e indiretos das vulnerabilidades e da não atualização de uma arquitetura, hoje este tema é mais relevante que nunca!