Você contrata software achando que vai pagar para construir e depois usar. Na prática, a maior parte do dinheiro vai embora mantendo o que já foi entregue funcionando. É comum que 40%, 60%, às vezes 80% da capacidade do time de tecnologia esteja ocupada consertando, ajustando, refazendo coisa que já existe. Sobra pouco para o novo. E o ‘pouco’ vira ‘nada’ no mês que tem incêndio.
Isso não é azar, não é falta de gente boa, e raramente é problema de ferramenta. É o resultado de decisões que ninguém tomou no começo. Este post explica em linguagem clara onde está o vazamento e como fechar a torneira antes do próximo orçamento.
1. O que é ‘manutenção’ e por que ela cresce sozinha
Manutenção, no mundo de software, é todo trabalho que o time gasta para manter funcionando o que já foi entregue: consertar erro que apareceu, ajustar regra que ‘não era bem assim’, refazer parte que parou de aguentar o uso, atender ticket de cliente. Não é construir o novo. É segurar o que existe.
Pense numa obra: o pedreiro entregou a casa, e toda semana volta para consertar um vazamento que ele mesmo fez. Você paga a hora dele de novo, e a casa continua não sendo ampliada. Em software acontece a mesma coisa, mas é invisível, porque o cliente final não vê o pedreiro voltando, só vê que ‘ainda não saiu a função nova’.
O resultado aparece em reuniões assim: ‘estamos sem capacidade para a função nova’, ‘o time está apagando incêndio essa semana’, ‘deu um problema crítico e travou tudo’. Esse é o boleto chegando. E ele cresce sozinho, porque cada conserto feito às pressas geralmente cria o próximo.
2. Onde está o vazamento: o trabalho foi feito na hora errada
Existe uma regra simples e cruel: cada problema custa muito menos para resolver antes do sistema existir do que depois. Em números aproximados que se repetem no mercado: o que custa 1 hora para resolver antes de programar, custa 10 horas depois de o sistema estar pronto, e 50 horas depois de estar no ar com usuários.
Quando você vê um time vivendo em manutenção, é quase certo que o trabalho que devia ter sido feito antes (combinar regras, prever casos de erro, planejar o impacto da mudança) está sendo feito depois, na forma de ticket e correção emergencial. O time não está executando mal. Está executando no momento errado da linha do tempo.
Analogia de obra: descobrir que faltou tomada na cozinha depois que o azulejo já está colocado. A tomada existe, vai existir, mas o custo de fazer ela aparecer agora é dez vezes maior do que se tivesse sido marcada na planta.
3. Combinar antes: a planta do sistema
Antes de programar uma linha, três coisas precisam estar escritas, em linguagem que o dono do negócio entende:
- As regras inegociáveis: o que o sistema PRECISA fazer sempre. Exemplo: ‘toda venda gera nota fiscal’, ‘nenhum cliente pode ver pedido de outro cliente’, ‘o estoque nunca pode ficar negativo’.
- O que fazer quando der problema: cada caso de erro precisa ter resposta combinada. ‘Se o pagamento falhar, o pedido fica em qual estado?’ ‘Se o cliente cancelar depois de enviado, quem é avisado?’
- Quem fala com quem: que sistemas trocam informação, em que momento, e o que cada um espera receber.
É o equivalente à planta assinada da obra. Sem isso, toda dúvida que aparecer durante a construção vira improviso. Improviso na construção vira ticket depois de entregue. Ticket depois de entregue vira manutenção. Manutenção vira o boleto que volta todo mês.
Quem escreve essas três peças não é só o time técnico, é o dono do negócio junto. Software bom começa com decisão de negócio bem combinada, não com tecnologia escolhida.
4. Planejar antes de mexer: ver o estrago possível
Toda vez que se vai mudar alguma coisa em um sistema que já está rodando, existe um risco: o que mais pode quebrar junto. Software é cheio de partes conectadas que nem sempre são óbvias. Mexer em uma pode parar outra que ninguém estava olhando.
Antes de qualquer mudança, o time deveria conseguir responder, em cinco linhas escritas: quais partes vão ser tocadas, em que ordem, o que mais pode quebrar junto, qual a maneira de voltar atrás se der ruim. Quem não consegue escrever isso ainda não entendeu a mudança que vai fazer. E vai descobrir o que faltou em produção, com cliente reclamando.
Analogia: reformar uma sala sem desligar o disjuntor. Pode dar tudo certo. Mas o dia em que o eletricista encostar no fio errado, para o andar inteiro. A pergunta ‘qual é o disjuntor que eu preciso desligar?’ leva dois minutos. Não fazer essa pergunta pode parar o prédio por horas.
5. Entregar com botão de desligar e painel para olhar
‘Entregar’ no mercado de software costuma significar ‘subiu para o ar, deu certo, próximo’. Esse entendimento é caro. Entrega de verdade tem três componentes que separam o conserto de 5 minutos do incidente de 5 horas:
- Botão de desligar a função: se a funcionalidade nova der problema, o time consegue desativar só ela, sem refazer o sistema, sem parar o resto. Sem esse botão, todo problema novo vira correção emergencial sob pressão.
- Painel para acompanhar: a função nova precisa ‘denunciar’ se está funcionando bem ou mal. Sem painel, o time só descobre o problema quando o cliente liga reclamando. E entre o problema aparecer e alguém perceber, passam dias.
- Plano de voltar atrás: se nada disso resolver, como voltar para a versão anterior, em quanto tempo, e quem aciona. Uma linha escrita. Quem improvisa isso na hora improvisa errado.
Sem esses três, toda entrega é uma aposta. Quando a aposta dá errado, vira fila de manutenção invisível: o problema fica no ar, ninguém vê, e custa em vendas perdidas, cliente irritado, hora de gente trabalhando à noite para arrumar.
6. O que fazer com a manutenção que você já tem
Os passos acima resolvem o passivo futuro. Mas você já tem um passivo no presente, e tentar matar ele todo de uma vez é o que destrói times. Manutenção acumulada precisa de triagem, não de mutirão.
Olhe para a lista de problemas que voltam toda semana e classifique cada um por três perguntas: com que frequência reaparece?, quanto tempo cada vez consome?, com que frequência aquela parte do sistema muda?. Os ‘muros de carga’ do passivo são os que pontuam alto nas três. Esses entram em uma temporada de correção planejada, com as regras escritas antes (mesmo que tarde). O resto vira conserto rápido tabelado ou é aceito como custo de operação até a próxima revisão.
O erro clássico é decidir ‘vamos zerar tudo’. Não dá, e tentar gera mais problema (conserto às pressas em código já frágil quebra coisa nova). O alvo é reduzir o que entra novo na fila, não esvaziar a fila. A fila reduz por consequência, em meses, quando o método de combinar e planejar antes vai virando hábito.
7. Três números que mostram se o método está funcionando
Não precisa de painel sofisticado. Três números, em planilha, contam a história:
- Quantos problemas aparecem nos primeiros 15 dias depois de cada entrega, divididos pela quantidade de coisa entregue. Se está caindo, é sinal de que combinar antes está pegando.
- Quantos tickets revelam ‘ninguém combinou que era assim’. Se está caindo, é sinal de que a planta do sistema está sendo escrita melhor.
- Quanto tempo até o time descobrir um problema. Se está caindo, é sinal de que o painel está pegando antes do cliente reclamar.
Esses três caindo juntos significam que o custo invisível está sendo cortado pela raiz, não só rearranjado de lugar.
8. O ponto principal
Manutenção não desaparece. Mas deixa de ser o destino do orçamento. A diferença entre um time que vive consertando e um time que entrega coisa nova é onde o trabalho foi colocado na linha do tempo: antes do código existir, ou depois de o sistema estar no ar.
Cinco linhas combinadas antes custam uma reunião. Cinco horas de manutenção depois custam um dia perdido, um cliente irritado, e a entrega do mês que não saiu. O método não é metodologia da moda, é uma decisão de onde gastar. Quem decide gastar antes, paga menos. Quem ignora, continua recebendo o boleto todo mês com a etiqueta ‘imprevisto’, e prometendo que da próxima vez vai dar tempo de fazer direito.
