Guia aprofundado
Simulador de perda de velocidade por dívida técnica: quanto o retrabalho custa à sua equipe de engenharia
Análise executiva do setor
A dívida técnica é o custo acumulado dos atalhos: código que funciona, mas é difícil de alterar, testes ausentes, dependências emaranhadas e sistemas antigos que ninguém entende. Ela raramente aparece em um orçamento. Em vez disso, aparece como a sensação de que tudo leva mais tempo do que antes. As estimativas escorregam, pequenas mudanças quebram coisas sem relação e a equipe passa sprints em um trabalho que não cria nada de novo. A fatura chega não como uma cobrança, mas como um número menor de funcionalidades entregues por mês pela mesma folha de pagamento.
A estrutura do problema é um imposto sobre a capacidade. Se um quinto de cada sprint vai para gambiarras e retrabalho, a equipe se comporta como se fosse um quinto menor, enquanto os salários permanecem iguais. A dívida também se acumula. Cada nova funcionalidade construída sobre uma base frágil acrescenta mais complexidade, de modo que a parcela perdida cresce, a menos que algum esforço seja dedicado à quitação. Pagar a dívida custa produção agora, e é por isso que sempre é tentador adiar e que a decisão merece números.
O modelo de dominó acompanha a perda. A parcela do sprint perdida com a dívida reduz a capacidade disponível para trabalho novo, o que reduz as funcionalidades entregues. Menos funcionalidades reduzem o valor entregue por dólar de folha, e o peso do retrabalho, do combate a incêndios e da rotatividade cresce com a dívida. A última caixa compara o valor entregue com o custo verdadeiro da equipe. Uma elevação modesta da dívida pode transformar um retorno saudável em prejuízo, porque a folha é fixa e o valor não é.
O iceberg mostra o que a linha da folha esconde. Visível é a própria folha. Abaixo da linha d'água ficam a parte da folha gasta em retrabalho, o combate a incêndios que a dívida causa em produção, a rotatividade dos engenheiros que abandonam bases de código cansadas e o valor das funcionalidades que nunca foram construídas. O último item é um custo de oportunidade que nunca aparece na contabilidade, mas costuma ser o maior. Use o simulador para encontrar o nível de dívida em que a equipe deixa de se pagar e para testar se um plano de quitação vale a pena.
Fórmulas e metodologia
O modelo é uma visão mensal de uma equipe de produto. A folha é os engenheiros multiplicados pelo custo total. Uma parcela do sprint vai para a dívida e outra para a quitação deliberada, e o restante constrói novas funcionalidades. As funcionalidades entregues são os engenheiros multiplicados pelas funcionalidades por engenheiro e por essa parcela restante, valorizadas pelo valor por funcionalidade. A dívida também causa incidentes, como uma parcela do custo do retrabalho, e eleva a rotatividade, precificada em quatro meses de salário total por reposição. Na projeção, a dívida sobe a cada mês, a menos que a quitação seja financiada.
- Parcela de construção
- c = 1 − dívida − quitação
- A parte do sprint que vai para novas funcionalidades.
- Funcionalidades entregues
- F = engenheiros × funcionalidades por engenheiro × c
- Novas funcionalidades entregues em um mês.
- Custo do retrabalho
- R = folha × dívida
- A folha que não comprou nenhum valor novo.
- Custo da rotatividade
- A = engenheiros × (1% + 0,06% × pontos de dívida) × 4 meses × custo
- Custo mensal esperado de repor engenheiros, crescendo com a dívida.
- Resultado líquido
- Líquido = F × valor − folha − 0,15 × R − A
- Valor entregue menos o custo verdadeiro da equipe. O ponto de ruptura é onde ele chega a zero.
Elasticidade em cascata
A parcela de dívida é a variável mais elástica, porque reduz a produção e aumenta os custos de incidentes e de rotatividade ao mesmo tempo. O valor por funcionalidade e as funcionalidades por engenheiro escalam todo o retorno. O custo da folha importa porque é a base fixa que o valor precisa superar.
Três estudos de caso reais
Início com recursos próprios
Uma equipe pequena com uma base de código limpa
Uma equipe de três pessoas mantém a dívida baixa, entrega rápido e valoriza muito cada funcionalidade em relação à folha. O retrabalho é pequeno. Carregue o caso para ver a vantagem inicial de uma base limpa e quão pouca dívida é preciso para começar a corroê-la.
Médio porte em expansão
Uma equipe grande que investe em quitação
Uma equipe de quarenta e cinco pessoas carrega uma dívida moderada, mas reserva um décimo de cada sprint para a limpeza. As funcionalidades saem em bom ritmo e os incidentes permanecem baixos. Carregue o caso para ver por que uma quitação disciplinada escala.
Crise de cisne negro
Uma base de código em crescimento rápido que ninguém consegue alterar
Uma equipe de vinte e cinco pessoas herdou anos de atalhos. Mais da metade de cada sprint vai para retrabalho e incidentes, a rotatividade é alta e o tempo de quitação é zero. Carregue o caso para ver uma folha grande produzindo pouco e qual alavanca recupera o mês.
Matriz de referências do setor
| Métrica | Zona de perigo | Média do setor | Elite dos 10% melhores |
|---|---|---|---|
| Parcela do sprint perdida em retrabalho | Acima de 40% | 15–25% | Abaixo de 10% |
| Tempo reservado para quitar a dívida | Zero | 5–10% | 15–20% quando necessário |
| Valor entregue por dólar de folha | Abaixo de 1,0 | 1,2–1,6 | Acima de 2,0 |
| Rotatividade mensal de engenheiros | Acima de 2,5% | 1–1,5% | Abaixo de 1% |
| Trabalho com incidentes como parcela do custo do retrabalho | Acima de 25% | 10–15% | Abaixo de 8% |
Variáveis e alavancas
Engenheiros na equipe
Desenvolvedores que trabalham no produto, contados como equivalentes de tempo integral.
Alavanca: Não contrate engenheiros primeiro para uma equipe com muita dívida, pois cada nova pessoa herda o mesmo arrasto e atrasa a integração.
Custo total por engenheiro por mês
Salário mais encargos, benefícios, equipamentos e despesas gerais de um engenheiro em um mês.
Alavanca: Mantenha os salários no nível do mercado, mas corte as despesas ocultas, porque cada hora perdida com dívida é paga pelo custo total.
Sprint perdido com dívida e retrabalho
Parcela do tempo de engenharia gasta com gambiarras, correção de bugs, builds lentos e brigas com código antigo em vez de novas funcionalidades.
Alavanca: Torne a dívida visível: liste os piores módulos, estime as horas de retrabalho e corrija primeiro os que afetam mais funcionalidades.
Funcionalidades por engenheiro por mês (sem dívida)
Quantas funcionalidades relevantes um engenheiro entregaria em um mês se nenhum tempo fosse perdido com dívida.
Alavanca: Remova o atrito de build, de testes e de revisão, porque a experiência do desenvolvedor define quantas funcionalidades uma pessoa consegue entregar.
Valor mensal de uma funcionalidade entregue
Receita, economia ou retenção que uma funcionalidade típica acrescenta por mês depois de entregue, segundo a sua própria estimativa.
Alavanca: Entregue funcionalidades que movam a receita ou a retenção; se o valor entregue é baixo, nenhuma velocidade torna a equipe lucrativa.
Sprint investido em quitar a dívida
Parcela do sprint gasta deliberadamente para reduzir a dívida. Custa produção agora e reduz a dívida depois.
Alavanca: Reserve uma fatia constante de cada sprint, muitas vezes de dez a vinte por cento, para a dívida que bloqueia o trabalho futuro.
Como usar este simulador
- 1Comece pela predefinição realista ou informe o tamanho da equipe, o custo total e a parcela estimada de retrabalho.
- 2Leia as cinco caixas do dominó para ver se a velocidade ou o peso da dívida ficam vermelhos primeiro.
- 3Pressione Encontrar meu ponto de ruptura para ver a parcela de dívida que torna a equipe deficitária.
- 4Compare o plano atual com o plano de quitação no gráfico de 24 meses.
- 5Meça o retrabalho durante alguns sprints e revise o modelo a cada trimestre.
Erros a evitar
- Tratar o tempo perdido com dívida como gratuito porque os salários são fixos, quando cada hora carrega o custo total.
- Contratar engenheiros para uma base de código lenta e esperar que a velocidade suba na mesma proporção.
- Planejar uma grande reescrita em vez de quitar a dívida de forma constante onde ela bloqueia o trabalho futuro.
- Ignorar a rotatividade, que é um custo real e recorrente de um código desagradável.
Perguntas frequentes
Como estimo a parcela do sprint perdida com a dívida?
Etiquete os tíquetes e os pull requests que são retrabalho, correção de bugs ou gambiarras durante alguns sprints e depois divida esse tempo pelo tempo total de engenharia. Peça à equipe um número aproximado como conferência.
Toda dívida técnica é ruim?
Não. Tomar um atalho para aprender mais depressa ou cumprir um prazo pode ser uma boa troca, desde que você a registre e a quite. A dívida se torna um problema quando não é gerenciada e se acumula.
Quanto tempo devemos gastar com a quitação?
Depende do nível de dívida e do trabalho futuro. De dez a vinte por cento de forma constante é comum, mas gaste esse tempo na dívida que bloqueia funcionalidades planejadas, e não em limpeza pela limpeza.
Como valorizo uma funcionalidade?
Estime a receita mensal, a retenção ou a economia de custos que ela acrescenta, ainda que de forma aproximada. Se não for possível, use o crescimento médio da receita dividido pelas funcionalidades entregues como ponto de partida.
Como encontro o nível de dívida em que a equipe perde dinheiro?
Pressione Encontrar meu ponto de ruptura. A ferramenta move cada entrada em direção ao seu pior extremo e informa o valor em que o lucro mensal chega a zero.
Qual é a precisão disto?
É um modelo educacional com premissas declaradas, e não aconselhamento de gestão. Os resultados reais de engenharia dependem de muitos fatores. Substitua os valores pelos seus próprios dados.
Este é um modelo educacional de planejamento, com premissas declaradas. Não constitui aconselhamento financeiro, tributário ou jurídico. Substitua os dados pelos seus próprios números e confirme decisões importantes com um profissional qualificado.