Framework de Manutenção de Software para CTO
Guia prático de referência para CTOs e tech leads de empresas pequenas a médias que precisam garantir que o software continue funcionando, evoluindo e sem quebrar — geralmente com um time enxuto e recursos limitados.
Não é sobre "consertar bugs". É sobre construir um sistema (técnico e humano) em que a manutenção deixa de ser um incêndio constante e vira um hábito controlado.
O dilema central
Todo tempo gasto mantendo o que existe é tempo que não está construindo o que gera receita nova.
Esse é o dilema que o CTO equilibra todos os dias:
- Manutenção de menos → o produto quebra, acumula dívida técnica, perde clientes e cada mudança fica mais lenta e arriscada.
- Manutenção demais → o concorrente lança features mais rápido e você fica para trás.
Achar esse ponto de equilíbrio, com recursos limitados, é uma das partes mais difíceis do cargo nesse porte de empresa. Este framework existe para tornar essa decisão consciente e mensurável, em vez de reativa.
Os 4 tipos de manutenção
Manutenção não é uma coisa só. Entender os 4 tipos ajuda a enxergar onde seu time realmente gasta o tempo.
| Tipo | O que é | Exemplo |
|---|---|---|
| Corretiva | Consertar defeitos que já estão em produção | Bug que derruba o checkout |
| Adaptativa | Ajustar a mudanças externas | Nova versão do Android, mudança numa API de terceiros, lei nova (LGPD) |
| Perfectiva | Melhorar o que já existe e funciona | Deixar uma tela mais rápida, melhorar a UX |
| Preventiva | Evitar problemas futuros | Refatorar código frágil, atualizar dependências antes de virarem risco |
⚠️ O erro clássico em empresa pequena/média: gastar ~90% do tempo na corretiva e nunca fazer preventiva. A dívida técnica se acumula, e tudo fica mais lento e caro. O objetivo deste framework é deslocar esforço da corretiva reativa para a preventiva proativa.
Como navegar este material
O framework tem três partes que se conectam:
CONCEITOS → ROADMAP → MÉTRICAS
(o "porquê"/"o quê") (o "quando"/ordem) (acompanhamento)
| Documento | Para quê serve | Quando usar |
|---|---|---|
| conceitos-pilares.md | Os 7 pilares fundamentais da manutenção — a base conceitual | Para entender o que precisa existir e por quê |
| roadmap-maturidade.md | 4 fases de evolução por maturidade | Para saber por onde começar e em que ordem |
| modo-crise.md | Sair da sobrecarga quando o urgente engole o importante | 🔥 Se você está apagando incêndio agora, comece aqui |
| conhecimento-preso.md | Suporte refém da manutenção; extrair regras de negócio sem documentação | Quando cada dúvida do suporte interrompe o dev |
| metricas.md | Como medir saúde e progresso | Para saber se está funcionando e o que priorizar |
| templates.md | Modelos copiáveis e exemplos preenchidos | Para executar na prática: ADR, dívida técnica, postmortem, priorização, checklists |
Fluxo sugerido de leitura: comece pelos Pilares para ter a base, use o Roadmap para descobrir em qual fase você está e o que fazer a seguir, adote as Métricas correspondentes à sua fase para acompanhar a evolução, e recorra aos Templates quando for colocar cada prática pra rodar.
O roadmap em uma página
Quatro fases progressivas de maturidade — você não pula etapas. Os retângulos são desvios situacionais, não fases: entra neles quando o sintoma aparece e volta ao fluxo.
urgente > normal?
│ sim
▼
┌─────────────┐ estanca e
│ MODO CRISE │ devolve ao fluxo
└─────────────┘ ───────────┐
▼
● FASE 1 ──► ● FASE 2 ──► ● FASE 3 ──► ● FASE 4
Estabilizar Prevenir Otimizar Escalar
│
sem doc? ──────┘
suporte refém do dev?
▼
┌──────────────────────┐
│ CONHECIMENTO PRESO │
└──────────────────────┘
| Fase | O que você conquista | Você está pronto quando… |
|---|---|---|
| 1 · Estabilizar | Visibilidade e controle mínimo — parar o sangramento | Sabe dos problemas por alerta, não pelo cliente |
| 2 · Prevenir | Rede de segurança — testes, CI/CD, code review | Muda o código sem medo |
| 3 · Otimizar | Pagar a dívida técnica com consciência (~20%) | A velocidade parou de cair |
| 4 · Escalar | Cultura e autonomia — manutenção vira hábito | Manutenção é hábito, não crise |
➡️ O mapa completo (pilares, ações-chave, templates e métrica por fase) está no 🗺️ Mapa de Aplicação.
Princípio-guia
"Simples e manutenível" vence "moderno e complexo".
Numa empresa pequena/média, um monólito bem feito costuma ser mais fácil de manter do que microsserviços mal feitos. Cada decisão de arquitetura, ferramenta ou processo deve ser avaliada pela pergunta: "isso torna a manutenção mais fácil ou mais difícil daqui a 12 meses?"