Roadmap de Maturidade em Manutenção de Software

Quatro fases progressivas. Elas descrevem por onde começar e em que ordem evoluir a capacidade de manutenção do seu time. É um roadmap por maturidade, não por datas — você avança quando cumpre os critérios de saída, não quando o calendário vira.

Não pule fases. Testes automatizados (Fase 2) sem visibilidade básica (Fase 1) é construir o segundo andar sem fundação. Cada fase habilita a próxima.

Mapa de Aplicação — o roadmap em uma página

O framework inteiro, condensado. Use isto para se localizar; o detalhe de cada fase vem logo abaixo.

Fluxo completo (com os desvios)

        urgente > normal?
             │ sim
             ▼
      ┌─────────────┐   estanca e
      │ MODO CRISE  │   devolve ao fluxo
      └─────────────┘ ───────────┐
                                 ▼
   ● FASE 1  ──►  ● FASE 2  ──►  ● FASE 3  ──►  ● FASE 4
   Estabilizar    Prevenir       Otimizar       Escalar
   "parar o       "rede de       "pagar a       "cultura e
    sangramento"   segurança"     dívida"        autonomia"
                                    │
                     sem doc? ──────┘
                     suporte refém do dev?
                                    ▼
                        ┌──────────────────────┐
                        │  CONHECIMENTO PRESO   │
                        └──────────────────────┘

Os retângulos são desvios situacionais, não fases: Modo Crise (quando você está abaixo da Fase 1) e Conhecimento Preso (quando a falta de documentação trava o suporte, tipicamente na Fase 3).

Quadro-mestre

Como começar (hoje)

1. Diagnostique sua fase. Leia de cima para baixo o "Você está nesta fase se…" de cada fase abaixo — a primeira em que você se reconhece é a sua. Se a demanda urgente já supera a normal, comece pelo Modo Crise.
2. Escolha 1–2 ações. Pegue as "Ações-chave" da sua fase e priorize com a Matriz Impacto × Risco × Esforço. Não tente fazer tudo de uma vez.
3. Comece a medir e persiga a saída. Acompanhe a "Métrica-foco" da sua fase (mesmo que na mão, numa planilha) e trabalhe rumo aos critérios de saída. Só então avance de fase.

Fase 1 — Estabilizar

"Parar o sangramento"

Objetivo: Sair do modo de pânico. Ganhar visibilidade e controle mínimo para que os incêndios parem de pegar você de surpresa.

🔥 Se a demanda urgente já supera a normal e o time só apaga incêndio, você está abaixo desta fase — passe primeiro pelo Modo Crise para estancar, depois retome aqui.

Você está nesta fase se:

• Descobre que o sistema caiu porque o cliente reclamou
• Deploys são manuais, tensos e às vezes irreversíveis
• Diagnosticar um problema é adivinhação
• Não há backup confiável ou ambiente reproduzível

Ações (checklist):

• Centralizar logs em um único lugar consultável
• Instalar rastreamento de erros (ex: Sentry ou similar)
• Configurar alertas mínimos: fora do ar, pico de erros, recursos no limite
• Garantir backup testado (backup que nunca foi restaurado não é backup)
• Tornar o ambiente reproduzível (documentar/automatizar como subir o sistema do zero)
• Registrar incidentes num lugar só, com o básico: o que aconteceu e como foi resolvido

🧩 Templates para esta fase: Registro de Incidente + Postmortem blameless.

Pilares ativados: Visibilidade & Monitoramento (1), início de Conhecimento Distribuído (5)

Critérios de saída (pronto para a Fase 2):

• ✅ Você fica sabendo dos problemas por alertas, não pelo cliente
• ✅ Consegue subir o sistema do zero seguindo um passo a passo
• ✅ Backup existe e já foi restaurado com sucesso pelo menos uma vez

Fase 2 — Prevenir

"Criar a rede de segurança"

Objetivo: Parar de introduzir novos problemas. Construir a malha de proteção que dá confiança para mudar o código sem medo.

Você está nesta fase se:

• Tem visibilidade (Fase 1 ✅), mas cada mudança ainda é uma aposta
• Não há testes automatizados, ou eles são raros e não confiáveis
• Deploy depende de uma pessoa lembrar dos passos certos
• Ninguém revisa o código antes de ir pra produção

Ações (checklist):

• Escrever testes automatizados para os fluxos críticos primeiro (não busque cobertura total)
• Montar um pipeline de CI que roda os testes a cada mudança
• Automatizar o deploy (CD): reproduzível e reversível com um clique
• Tornar code review obrigatório antes de mergear
• Adicionar verificação automática de vulnerabilidades nas dependências
• Criar rotina de atualização incremental de dependências

🧩 Templates para esta fase: Checklists operacionais (code review, atualização de dependências, deploy readiness).

Pilares ativados: Qualidade Automatizada (2), Segurança & Dependências (4)

Critérios de saída (pronto para a Fase 3):

• ✅ Fluxos críticos cobertos por testes que rodam automaticamente
• ✅ Deploy é rotineiro, automatizado e reversível — não um evento tenso
• ✅ Nenhuma mudança chega em produção sem passar por CI + review

Fase 3 — Otimizar

"Pagar a dívida com consciência"

Objetivo: Com a rede de segurança montada, agora dá para melhorar o que existe sem medo. Reduzir dívida técnica de forma deliberada e priorizada.

Você está nesta fase se:

• Tem testes e CI/CD (Fase 2 ✅) e já consegue refatorar com segurança
• Sente a velocidade caindo por causa de dívida técnica acumulada
• Há gargalos de performance conhecidos mas não tratados
• A documentação ainda é frágil

Ações (checklist):

• Tornar a dívida técnica visível num backlog dedicado
• Reservar ~20% da capacidade de cada ciclo para manutenção/refatoração
• Priorizar dívida por Impacto × Risco × Esforço (dor real, não perfeccionismo)
• Refatorar os pontos de maior atrito (onde o time mais sofre)
• Atacar gargalos de performance com base em dados (não em achismo)
• Estabelecer documentação mínima viável e ADRs (registro de decisões)

🧩 Templates para esta fase: Registro de Dívida Técnica, Matriz de Priorização e ADR.

📚 Se a documentação é inexistente e o suporte depende do dev para tudo, ataque isso de forma incremental com Conhecimento Preso — documentação sob demanda.

Pilares ativados: Dívida Técnica sob Controle (3), Arquitetura Manutenível (6), aprofunda Conhecimento Distribuído (5)

Critérios de saída (pronto para a Fase 4):

• ✅ Dívida técnica é rastreada e paga de forma contínua, não em crises
• ✅ A velocidade do time está estável ou crescendo (não caindo)
• ✅ Decisões importantes estão documentadas e o bus factor é > 1 nos módulos críticos

Fase 4 — Escalar

"Cultura e autonomia"

Objetivo: Fazer a manutenção deixar de depender de heroísmo individual e virar um hábito coletivo. O sistema se mantém saudável porque a cultura e os padrões garantem isso.

Você está nesta fase se:

• As fases 1–3 estão sólidas e a manutenção já não é caótica
• O desafio agora é consistência conforme o time e o produto crescem
• Boas práticas dependem de pessoas específicas em vez de serem o padrão

Ações (checklist):

• Padronizar arquitetura e convenções (guias, templates, linters automáticos)
• Cultivar cultura de qualidade: manutenção é responsabilidade de todos, não de um "time de bombeiros"
• Dar autonomia aos times para manter suas próprias áreas com segurança
• Automatizar o que ainda é manual (atualizações, checagens, deploys entre ambientes)
• Revisar periodicamente os pilares e métricas — melhoria contínua
• Transformar a regra dos ~20% em hábito inegociável, não em exceção

Pilares ativados: Priorização & Equilíbrio (7) plenamente, consolida todos os anteriores

Sinal de maturidade plena:

• ✅ Manutenção é contínua e invisível — não gera crises
• ✅ Um novo dev entra e se torna produtivo em dias, não meses
• ✅ O CTO gasta o tempo em estratégia, não apagando incêndios

Resumo

Para a visão condensada de tudo (fluxo, pilares, ações, templates e métricas por fase), volte ao 🗺️ Mapa de Aplicação no topo.

➡️ Para acompanhar sua evolução em cada fase, veja metricas.md.