Resgate Técnico

A modernização de sistemas legacy começa onde o seu software está hoje: em falha, frágil ou simplesmente incapaz de acompanhar o negócio. Chamamos-lhe Resgate Técnico. Prazos falhados, uma arquitetura a ceder, um fornecedor que deixou de responder, um sistema antigo em que ninguém se atreve a mexer. Entramos em projetos em apuros e tornamo-los outra vez estáveis e previsíveis. É esse o objetivo, porque um sistema previsível é um sistema que se consegue manter, para o qual se consegue contratar e que deixa dormir descansado. E fazemo-lo sem a reescrita total.

O problema, nas suas palavras

«O fornecedor desapareceu e o projeto ficou a meio.» «Cada nova versão parte alguma coisa, e já ninguém sabe porquê.» «O sistema faz a empresa andar, mas foi feito há muitos anos e ninguém lhe quer mexer.» «Disseram-nos que a única saída é reescrever tudo de raiz.»

Quando o software passa de ativo a passivo, a empresa paga duas vezes: nos problemas em si e nas decisões que deixa de poder tomar. O instinto é deitar tudo fora e começar de novo. Às vezes está certo. Muito mais vezes é a forma mais cara de voltar ao ponto de partida.

Sinais de que precisa disto

• As publicações de novas versões são manuais, raras e assustadoras, ou pararam de todo.
• Só uma pessoa, ou um fornecedor, percebe como o sistema funciona.
• A empresa quer crescer e o software é a razão pela qual não consegue.
• Os dados vivem num sistema antigo que tem de migrar, e ninguém sabe bem o que lá está.
• Um projeto está atrasado, acima do orçamento, e todas as reuniões acabam em «está quase».
• Precisa de uma auditoria de código independente antes de decidir o que fazer.

Como trabalhamos

1. Problema. Avaliamos antes de mexer em qualquer coisa: o código, os dados, a infraestrutura, as publicações e as pessoas que dependem do sistema. Recebe uma visão honesta do que se salva e do que não se salva.
2. Ideia. Transformamos isso num plano de estabilização que pode mostrar à administração, com os riscos ordenados e os primeiros passos escolhidos para proteger o negócio, não para impressionar.
3. Desenho e construção. Primeiro estabilizar: estancar a hemorragia, proteger os dados, repor as publicações e pôr monitorização onde não havia nenhuma. Depois desemaranhar, peça a peça, com correções incrementais e testes, com o produto sempre a correr.
4. Entrega. Fica com um sistema que a sua equipa consegue manter e alterar, e com o conhecimento de como e porque foi corrigido. Quando é preciso migrar, o sistema antigo e o novo correm lado a lado até a mudança ser segura.

O que recebe

• Uma avaliação honesta do que se salva e do que não se salva, em linguagem simples.
• Um plano de estabilização com prioridades, riscos e uma sequência que pode defender perante a administração.
• Trabalho de estabilização: dados protegidos, publicações a funcionar, monitorização e as falhas mais perigosas corrigidas primeiro.
• Modernização incremental com testes, incluindo a migração de dados entre sistemas quando é necessária.
• Documentação e passagem de conhecimento, para o sistema deixar de depender de uma só pessoa ou fornecedor.

Nunca uma reescrita total, a não ser que mesmo nada sobreviva. E nesse caso dizemos-lho sem rodeios.

Como decorre o trabalho

1. Diga-nos o que está partido e com que urgência. Avaliações urgentes passam à frente.
2. Avaliação. Uma revisão focada do código, dos dados, da infraestrutura e do processo, que termina na avaliação e no plano de estabilização.
3. Estabilização. A primeira prioridade é proteger o negócio e os dados.
4. Modernização. Incremental, em iterações definidas, cada uma com âmbito e fim claros.
5. Passagem de conhecimento. A sua equipa, ou o fornecedor que escolher, leva o sistema para a frente.

A duração de cada fase depende do que encontrarmos, e o plano indica-a antes de o trabalho começar. Não fazemos contratos de manutenção corrente. O resgate tem um fim.

O que faz variar o custo. Não publicamos preços, porque não há dois resgates iguais. O que mais pesa é a dimensão e a idade do sistema, a documentação e os testes que existem, o estado e o volume dos dados, quantos outros sistemas dependem dele, se há acesso ao código-fonte ou ao fornecedor anterior e a urgência da situação. Fica tudo por escrito antes de começar.

Pedir uma proposta

Perguntas frequentes

Temos de reescrever tudo? Quase nunca. A maior parte dos sistemas legacy contém anos de regras de negócio que funcionam. Mantemos o que funciona, substituímos o que não funciona e fazemo-lo aos poucos, para que a empresa continue a trabalhar.

O nosso fornecedor anterior desapareceu. Ainda podem ajudar? Sim, desde que consigamos acesso ao código, aos dados ou ao sistema em funcionamento. Se faltar alguma parte, a avaliação di-lo e o plano contorna-a.

O sistema pode continuar a funcionar durante o trabalho? Sim. É para isso que primeiro estabilizamos e só depois desemaranhamos. As alterações entram peça a peça, com testes, e as migrações de dados são ensaiadas antes de acontecerem a sério.

Podem fazer só uma auditoria de código? Sim. A avaliação pode ser feita isoladamente, como auditoria de código independente: o estado do software, os riscos e o que faríamos a seguir.

Ficam com a manutenção depois? Não. Não fazemos contratos de manutenção corrente. Deixamos o sistema num estado que a sua equipa ou o fornecedor que escolher consegue manter, e fazemos a passagem de conhecimento como deve ser.

Serviços relacionados

• Arquitetura de Soluções: o mapa daquilo em que o sistema modernizado se deve tornar.
• Orientação Técnica e de Negócio: uma segunda opinião honesta antes de se comprometer com uma reescrita, uma migração ou um novo fornecedor.

Diga-nos o que está partido

Um sistema a arder às duas da manhã ou um que vai falhando em silêncio há anos. Diga-nos o que está partido e com que urgência. Respondemos num dia útil, normalmente com perguntas e uma primeira opinião honesta.

Começar um projeto