Sustentação cresceu até consumir 40, 60, às vezes 80% da capacidade do time. Você não está sozinho, e o culpado também não é falta de QA, senioridade ou ferramenta. Sustentação é o boleto que chega quando o flow foi pulado. Toda dúvida que não virou spec antes do código vira ticket depois. Todo acoplamento que não virou plan antes do PR vira incidente em produção.
Este post explica como o ciclo Spec, Plan, Ship redireciona o trabalho para a janela em que defeito ainda é barato, e o que fazer com o passivo de sustentação que você já carrega hoje.
1. A sustentação é o passivo de um flow ausente
Existe uma janela de tempo em que cada defeito custa entre 1x e 5x para corrigir: antes do código existir. Depois do merge, o mesmo defeito custa 10x. Depois do deploy, 50x. Quando vira sustentação recorrente, vira passivo permanente, com juros compostos em hora-homem.
Times com sustentação alta têm uma característica em comum: o trabalho que deveria acontecer antes do código (especificar regra, mapear acoplamento, definir observabilidade) está acontecendo depois, sob a forma de ticket, incidente e refactor de emergência. Não é falha de execução, é falha de janela. O time não está executando mal, está executando no momento errado da linha do tempo.
A consequência prática é cruel: quanto mais sustentação, menos tempo sobra para o flow que reduziria a sustentação. É um ciclo de realimentação negativa, e ele só quebra com uma decisão estrutural de redirecionar o trabalho para a janela barata.
2. Spec: corta a ambiguidade antes do código existir
Spec não é documento, é o gate que impede que dúvida vire bug. Uma boa spec define três coisas: invariantes (o que sempre tem que ser verdade), casos de erro nomeados (o que fazer quando X acontece) e contratos (entrada, saída, side effects). Se essas três peças estão escritas, o desenvolvedor não tem espaço para ‘ah, eu achei que fosse assim’.
O que NÃO entra na spec: implementação. Spec descreve o problema, não a solução. Se você está escrevendo qual ORM usar ou onde colocar o cache, parou de especificar e começou a desenhar. Misturar os dois acopla a regra de negócio à tecnologia, e gera retrabalho na primeira migração ou troca de stack.
Heurística prática: se um PR abre discussão sobre ‘o que deve acontecer se X’, a spec daquela feature falhou no ponto X. Não é falha pessoal, é dado. Marque, ajuste a spec, e siga. Spec é viva, não é entregável de auditoria que ninguém relê depois de aprovado.
3. Plan: ataca o acoplamento antes do diff
Plan é o mapa de blast radius da mudança. Quais arquivos serão tocados, em qual ordem, o que pode quebrar lateralmente, qual é o ponto de não retorno. Um plan bom responde antes do código: ‘se este PR der errado, o que volta junto?’
Sem plan, refactor é cirurgia às cegas. Com plan, é checklist. A diferença prática: refactor sem plan gera 3 a 5 incidentes de sustentação nas semanas seguintes ao deploy, porque acoplamentos invisíveis foram pisados sem aviso. Plan torna esses acoplamentos visíveis ANTES de virarem ticket, em uma sessão de 20 minutos com café, não em um war room às 3 da manhã.
Plan não precisa ser longo. Cinco linhas que listem: arquivos tocados, ordem de mudança, riscos laterais, telemetria a adicionar, condição de rollback. Quem não consegue escrever essas cinco linhas ainda não entendeu o problema, e vai descobrir isso em produção, com público.
4. Ship: é gate, não meta
Ship é o passo mais maltratado dos três. Ship não é ‘deu deploy’. Ship é a entrega com fallback, telemetria e rollback. Se você não consegue desligar a feature em 2 minutos, você não fez ship, deixou um problema futuro com nome bonito.
A sustentação invisível nasce aqui. Feature sem flag de desligar exige correção emergencial em produção quando dá ruim. Feature sem telemetria não denuncia o próprio fracasso, e você só descobre via ticket de usuário irritado, 3 semanas depois, quando o estrago já está distribuído. Feature sem rollback documentado obriga o time a inventar procedimento sob pressão. Tudo isso vira hora-homem de sustentação no mês seguinte, com pico no final de sprint.
Gate mínimo de ship: (1) flag ou kill switch, (2) métrica de saúde da feature exposta em dashboard, (3) plano de rollback de uma linha. Se algum dos três falta, o ship é dívida disfarçada de entrega.
5. Mitigar a sustentação que já existe
O flow Spec, Plan, Ship resolve o passivo futuro. Mas você já tem um passivo no presente, e tentar liquidá-lo de uma vez é o que mata times. Sustentação herdada precisa de triage, não de mutirão.
Triagem em três dimensões: frequência (quantas vezes o ticket reaparece por mês), custo unitário (quanto tempo cada ocorrência consome) e volatilidade (com que frequência o código relacionado muda). Os ‘muros de carga’ do passivo são os que pontuam alto nas três. Esses entram em sprint de erradicação, com spec retroativa escrita ANTES do refactor. O resto vira hotfix tabelado ou aceita-se como custo de operação até a próxima revisão.
O erro clássico é tentar zerar o backlog de sustentação. Não dá, e tentar gera mais sustentação (refactor de emergência cria novos bugs em código já frágil). O alvo é reduzir o fluxo de entrada, não esvaziar a fila. Fluxo de entrada cai quando spec e plan entram no ciclo. Fila se reduz por consequência, em meses, não em semanas.
6. Métricas que mostram que o flow está funcionando
Três sinais que você pode medir em qualquer time, sem ferramenta nova, com planilha:
- Bugs por entrega: bugs reportados em produção nas 2 semanas pós-deploy, dividido pelo número de features entregues. Tendência de queda significa spec funcionando.
- Percentual de tickets que pedem spec retroativa: quantos tickets revelam ‘ninguém sabia que era pra ser assim’. Tendência de queda significa ciclo de spec amadurecendo.
- Tempo até o primeiro fix pós-deploy: se está caindo, a observabilidade do ship está pegando antes do usuário reclamar, e a sustentação reativa está virando proativa.
Não é vaidade de dashboard. São os três únicos números que dizem se o flow está cortando sustentação ou só rearranjando trabalho de lugar.
7. O reframe
Sustentação não desaparece. Mas para de ser destino. A diferença entre um time que vive em modo apagar incêndio e um time que entrega features é onde o trabalho está alocado na linha do tempo: antes do código ou depois do deploy. Não é talento, não é stack, não é metodologia da moda. É janela.
Spec, Plan, Ship não é metodologia, é uma decisão de despesa: você paga agora, com 5 linhas de spec e 5 linhas de plan, ou paga 10x depois, em hora-homem de sustentação. O flow é o redirecionador. Quem ignora, continua pagando o boleto que chega todo mês com a etiqueta ‘imprevisto’, e jurando que da próxima vez vai dar tempo de fazer direito.
