Manutenção evolutiva: o que vem depois do lançamento

O sistema foi lançado, o time comemorou, o contrato de desenvolvimento terminou. Nos meses seguintes, chegam os pedidos: um campo novo aqui, um relatório ali, uma mudança na regra fiscal, uma biblioteca com falha de segurança anunciada. Cada pedido é pequeno. Juntos, sem organização, viram uma fila que nunca anda, um sistema que ninguém tem coragem de atualizar e, alguns anos depois, um novo projeto de "modernização".

Software não é obra entregue. É um ativo em produção, que precisa de cuidado contínuo para continuar valendo o que custou. A seguir, os tipos de manutenção, as práticas de engenharia que mantêm o sistema saudável e as formas de organizar esse trabalho sem transformar a evolução numa fila infinita.

Software não fica pronto, fica em produção

O lançamento é o momento em que o sistema começa a encontrar a realidade. Usuários fazem coisas que ninguém previu. O volume de dados cresce. O negócio muda de processo. A legislação muda. O navegador, o sistema operacional do celular e o provedor de nuvem mudam também.

Um sistema que não acompanha nada disso não fica parado: ele se deteriora. As dependências ficam desatualizadas e acumulam vulnerabilidades conhecidas. Os usuários criam contornos em planilhas. A distância entre o que o sistema faz e o que a operação precisa aumenta, até que alguém decide que "o sistema não serve mais".

A boa notícia é que a manutenção bem organizada é justamente o que evita esse ciclo. O sistema pode ficar melhor com o tempo, em vez de pior.

Corretiva, adaptativa, preventiva e evolutiva

A classificação é clássica em engenharia de software e ajuda a organizar a conversa:

• Corretiva: consertar defeitos. Um cálculo errado, uma tela que quebra em certa situação, uma integração que falha com um caractere especial.
• Adaptativa: ajustar o sistema a mudanças no ambiente. Nova versão de uma API de parceiro, novo leiaute de documento fiscal, atualização obrigatória de um componente, mudança de provedor.
• Preventiva: melhorar o sistema para evitar problemas futuros. Atualizar dependências, melhorar testes, simplificar um trecho de código que todo mundo evita tocar, ajustar consultas que vão ficar lentas com o crescimento do volume.
• Evolutiva: adicionar ou mudar funcionalidades para atender necessidades novas do negócio. Um novo fluxo de aprovação, um módulo, uma integração, um aplicativo para a equipe de campo.

O erro mais comum é enxergar só a primeira e a última. A corretiva aparece porque alguém reclama; a evolutiva aparece porque alguém pede. A adaptativa costuma chegar como urgência, porque ninguém acompanhou o calendário de mudanças externas. E a preventiva fica sempre para depois, até que a falta dela aparece como lentidão, incidentes e estimativas cada vez maiores. É exatamente o mecanismo que descrevemos em dívida técnica explicada para gestores.

Atualizações de segurança e de dependências com calendário

Todo sistema moderno é construído sobre dezenas ou centenas de bibliotecas de terceiros: frameworks, drivers de banco, bibliotecas de autenticação, geração de PDF, integração com nuvem. Cada uma delas recebe correções de segurança e, de tempos em tempos, deixa de ter suporte em versões antigas.

Dois caminhos são possíveis:

• Atualizar continuamente, em passos pequenos, como parte da rotina. Cada atualização é pequena, testável e reversível.
• Atualizar só quando não tem jeito, em saltos de várias versões. Cada salto vira um projeto, com mudanças incompatíveis acumuladas, e o risco faz a decisão ser adiada de novo.

O primeiro caminho é quase sempre mais barato e mais seguro. Na prática, ele se organiza assim:

• Ferramenta automática de verificação de dependências, que avisa quando uma biblioteca tem vulnerabilidade conhecida ou versão nova.
• Calendário de atualização, com um momento recorrente reservado para isso, e não apenas quando surge um alerta grave.
• Tratamento imediato para falhas críticas de segurança, fora do calendário, quando uma vulnerabilidade é explorável no seu contexto.
• Acompanhamento do fim de suporte das versões de linguagem, framework e banco de dados, com a migração planejada antes que o suporte termine.

O mesmo vale para a infraestrutura: sistema operacional, versão do banco de dados, certificados, imagens de contêiner.

Testes automatizados: o que permite mexer sem medo

A pergunta que define a saúde de um sistema em manutenção é simples: a equipe tem coragem de mexer?

Sem testes automatizados, cada mudança é uma aposta. Corrigir um cálculo pode quebrar um relatório em outro módulo, e ninguém percebe até o fechamento do mês. A reação natural é mudar o mínimo possível, contornar em vez de corrigir e evitar atualizações. O código vai ficando mais frágil justamente porque ninguém ousa melhorá-lo.

Com uma boa base de testes, a equação se inverte:

• Testes de unidade protegem regras de negócio: cálculo de imposto, comissão, prazo, desconto.
• Testes de integração verificam o que acontece com o banco de dados real e com os contratos das APIs externas.
• Alguns testes de ponta a ponta cobrem os fluxos críticos, como emitir pedido, faturar e baixar estoque.
• Pipeline de integração contínua roda tudo a cada mudança, antes de qualquer coisa chegar à produção.

Não é preciso cobrir cada linha. É preciso cobrir o que dói quando quebra. Uma regra prática útil: todo defeito corrigido ganha um teste que teria detectado o problema. Assim a base cresce onde o sistema provou ser frágil.

Para sistemas herdados, sem nenhum teste, o ponto de partida são os testes de caracterização, que registram o comportamento atual antes de qualquer mudança.

Backlog com dono do lado do negócio e ciclos curtos

A fila infinita de pedidos quase sempre tem a mesma causa: ninguém do lado do negócio é dono da prioridade. Cada área manda seus pedidos direto para a equipe técnica, todos marcados como urgentes, e a equipe decide sozinha o que fazer primeiro, ou faz o que chegou por último.

O que resolve:

• Um dono de produto do lado da empresa, com autoridade para dizer o que vem primeiro e o que não vai ser feito. Não precisa ser técnico. Precisa conhecer a operação e conseguir arbitrar entre áreas.
• Um backlog único e visível, com todos os pedidos, cada um com o problema que resolve, quem pediu e qual o impacto esperado.
• Ciclos curtos de entrega, com um conjunto pequeno de itens por ciclo, revisão do que foi entregue e repriorização do que vem a seguir.
• Critério explícito para urgências: o que interrompe o ciclo é defeito com impacto real na operação ou risco de segurança, não pedido de quem grita mais alto.
• Espaço reservado para a manutenção preventiva em todo ciclo, para que ela não perca sempre para o pedido novo.

Ciclos curtos também reduzem o risco de cada entrega. Mudanças pequenas e frequentes são mais fáceis de testar, revisar e, se necessário, desfazer.

Capacidade dedicada ou por demanda: como organizar

Existem, de forma geral, dois modelos de organizar o trabalho de manutenção com um fornecedor ou equipe:

Capacidade dedicada. Uma equipe, ou parte dela, fica reservada para o sistema de forma contínua. O backlog é priorizado a cada ciclo, e a equipe acumula conhecimento sobre o negócio e o código. Faz sentido quando o sistema é central para a operação, muda com frequência e há um fluxo constante de melhorias.

Por demanda. Cada pedido, ou conjunto de pedidos, é avaliado e aprovado separadamente. Faz sentido quando o sistema é estável, as mudanças são esporádicas e não há volume para manter uma equipe dedicada.

Os dois modelos funcionam, e muitas empresas combinam: uma base de sustentação contínua, com monitoramento, atualizações e correções, e projetos evolutivos maiores negociados à parte. O que não funciona é nenhum modelo, em que o sistema só recebe atenção quando quebra.

Em qualquer caso, a parte de sustentação, ou seja, incidentes, disponibilidade e tempos de atendimento, merece um acordo próprio, como explicamos em SLA de suporte e sustentação. E, para que a manutenção seja proativa, o sistema precisa emitir sinais de saúde, como descrito em observabilidade: logs, métricas e traces.

Quando a manutenção vira sinal de modernização

Manutenção bem feita prolonga a vida útil de um sistema por muito tempo. Mas há sinais de que o esforço de manter já não compensa:

• a linguagem, o framework ou o banco de dados estão sem suporte e sem caminho de atualização viável;
• cada mudança pequena exige tocar em muitos lugares e sempre quebra algo inesperado;
• ninguém mais consegue contratar ou formar pessoas para trabalhar com aquela tecnologia;
• o modelo de dados já não comporta o que o negócio virou.

Nesses casos, a conversa passa a ser outra: modernizar por partes ou reescrever. Discutimos os critérios em reescrever ou refatorar um sistema legado. Mesmo aí, a resposta costuma ser incremental.

Como medir se a manutenção está saudável

• Tempo entre o pedido priorizado e a entrega em produção. Se só cresce, algo está travando.
• Defeitos que voltam depois de corrigidos.
• Idade das dependências e vulnerabilidades conhecidas em aberto.
• Frequência de entregas e proporção de entregas que precisaram ser desfeitas.
• Parcela do esforço que vai para correção, comparada com evolução.

Checklist para organizar a manutenção

• Dono de produto do lado do negócio, com autoridade para priorizar.
• Backlog único, com problema, solicitante e impacto de cada item.
• Ciclos curtos, com espaço fixo para manutenção preventiva.
• Verificação automática de dependências e calendário de atualização.
• Testes automatizados cobrindo os fluxos críticos, rodando a cada mudança.
• Acordo de sustentação separado da evolução.
• Revisão periódica do estado técnico do sistema.

Sistema vivo, cuidado contínuo

Na Pervian Tech, manutenção e evolução fazem parte do nosso trabalho de desenvolvimento web: atualizações planejadas, testes que permitem mexer sem medo, ciclos curtos de entrega e um backlog priorizado junto com quem conhece a operação. Pode ser um sistema que construímos ou um que você já tem.

Cada sistema tem ritmo e criticidade próprios, então o modelo de trabalho é sob medida e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito do estado atual do código e da fila de pedidos. Se o seu sistema está envelhecendo sem cuidado, vamos conversar.