Discovery para produtos legados: por onde começar a modernizar sem quebrar tudo

Resposta direta: Comece pelo diagnóstico, não pelo código. Um Discovery aplicado a produto legado mapeia uso real, dependências e integrações frágeis antes de qualquer decisão técnica. O resultado é uma lista priorizada por risco e retorno financeiro: o que evoluir, o que substituir e o que não tocar agora. Modernizar sem esse mapa é apostar a operação.

Todo CTO de empresa tradicional conhece a cena. O ERP tem quinze anos. A área logada foi feita por um fornecedor que não existe mais. Ninguém sabe exatamente o que aquela integração via arquivo de texto faz às 3 da manhã, só sabe que quando ela falha, o faturamento para.

E aí chega a pressão para "modernizar". Do board, do cliente, do time comercial que perde negócio porque o sistema parece de outra década.

O problema não é decidir se moderniza. É decidir por onde, sem derrubar uma operação que depende do sistema todos os dias. Este artigo trata exatamente disso: como um Discovery estratégico funciona quando o objeto é um produto legado em produção.

Por que legado é um problema diferente

Modernizar um produto novo é desenhar em terreno limpo. Modernizar um legado é operar um paciente acordado. Três características mudam tudo:

• Usuários dependentes. Centenas de pessoas construíram a rotina delas em cima das telas atuais, incluindo os atalhos e as gambiarras. Mudar sem entender esse uso real quebra produtividade no dia seguinte.
• Integrações frágeis e não documentadas. O sistema conversa com fiscal, estoque, banco, parceiros. Parte dessas conexões só existe na cabeça de uma pessoa, ou de ninguém.
• Custo de parada altíssimo. Uma hora fora do ar não é bug, é faturamento travado, pedido perdido, multa contratual.

É por isso que a resposta reflexa "vamos refazer do zero" costuma ser a mais cara e a mais arriscada. E é também por isso que congelar tudo por medo de mexer sai caro do mesmo jeito: a Dívida Técnica não fica parada, ela cobra juros. Não é à toa que ela chega a consumir até 40% do orçamento de TI. Detalhamos essa conta em quanto custa a dívida técnica de verdade.

O que o Discovery investiga num sistema legado

Num produto legado, o Discovery não pergunta "o que os usuários gostariam de ter". Pergunta primeiro o que não pode parar. A investigação roda em quatro frentes.

1. Mapa de uso real, não de funcionalidades

O legado típico acumula módulos. O uso real se concentra em poucos deles. O Discovery cruza dados de acesso, volume de transações e observação direta de usuários para separar:

• O que é usado todos os dias por muita gente
• O que é usado raramente, mas é crítico (fechamento fiscal, por exemplo)
• O que ninguém usa há anos e só adiciona complexidade

Sem esse mapa, a empresa gasta orçamento modernizando tela que ninguém abre.

2. Mapa de dependências e integrações

Antes de mexer em qualquer módulo, a pergunta é: quem quebra se isto mudar? O Discovery levanta as integrações, os fluxos de dados entre sistemas e os pontos onde uma alteração de interface muda um comportamento do qual outro processo depende. É aqui que mora o "medo de mexer", e a única cura para o medo é visibilidade.

3. Custos Invisíveis da operação atual

Legado ruim raramente aparece no DRE com nome e sobrenome. Aparece disfarçado: retrabalho manual, planilha paralela, chamado de suporte, treinamento de semanas para operar uma tela que deveria ser autoexplicativa, erro de digitação que vira prejuízo. O Discovery quantifica esses Custos Invisíveis, porque são eles que definem onde o retorno da modernização é maior.

4. Risco de cada caminho

Para cada área do sistema, a pergunta dupla: qual o custo de mexer e qual o custo de não mexer? Módulo sobre tecnologia sem suporte, sem ninguém no time que domine o código, com fornecedor extinto, carrega risco crescente mesmo parado.

Evoluir ou substituir: o critério que evita decisão emocional

A discussão "reforma ou reconstrução" costuma ser decidida por cansaço ("odeio esse sistema, joga fora") ou por apego ("funciona, não toca"). Os dois erram. O critério útil cruza duas perguntas por módulo:

• A base sustenta evolução? Se a arquitetura daquela parte aguenta mudança incremental de interface e fluxo, evoluir é mais barato e menos arriscado. Antes de decidir, vale ler o que considerar antes de refatorar a UI de um sistema digital.
• O problema é de interface ou de fundação? Fricção de uso, telas confusas, fluxo com passos demais: isso se resolve com redesenho sobre a base atual. Tecnologia sem suporte, dado inconsistente na origem, arquitetura que impede integração: isso pede substituição planejada.

O resultado prático é uma matriz simples: evoluir agora, substituir em fases, manter como está com data de revisão. Nenhum módulo fica sem veredito, e nenhum veredito vem sem justificativa de risco e retorno.

Um alerta que vale sublinhar: modernizar não é trocar tudo que parece velho. Interface conhecida é ativo de produtividade para quem opera o sistema há anos. Os grandes players entendem isso bem, e já escrevemos sobre por que eles não mudam por mudar.

A conta que muda a conversa com o board

Um exemplo com números na mesa. Imagine uma indústria com um sistema interno de pedidos usado por 400 pessoas. Refazer a plataforma inteira foi orçado em R$ 2,4 milhões e 18 meses de projeto.

O Discovery mostra outra leitura: o módulo de entrada de pedidos concentra a dor. Cada operador perde cerca de 20 minutos por dia entre retrabalho, conferência manual e erro de tela. A conta:

• 400 pessoas × 20 minutos/dia = 133 horas perdidas por dia
• A um custo médio de R$ 45/hora, são R$ 6.000 por dia
• Em 22 dias úteis, R$ 132.000 por mês evaporando em fricção

Redesenhar e modernizar só esse módulo, mantendo o resto do sistema intacto, custa R$ 400 mil e entra em produção em 4 meses. O investimento se paga em cerca de 3 meses de operação. A reconstrução total entregaria o mesmo alívio, só que 14 meses depois e por 6 vezes o preço, com a operação inteira em risco durante a troca.

É a diferença entre gastar em tecnologia e praticar Eficiência de Capital: mesmo problema, sequência diferente, resultado financeiro completamente diferente. E o potencial é grande justamente porque o retorno de UX bem aplicada é desproporcional: o ROI médio chega a 100:1.

Modernização em fatias: como não quebrar a produção

Com o mapa pronto, a execução segue princípios que protegem a operação:

• Uma fatia por vez. Módulo modernizado convive com o legado ao lado, integrado, até a fatia seguinte. Nada de big bang.
• Começar pelo módulo de maior dor e menor dependência. Retorno rápido, risco contido, e a organização aprende o processo antes de encarar as partes críticas.
• Testar com usuários reais antes de virar a chave. Quem opera o sistema há dez anos encontra em minutos o problema que o protótipo escondeu. A Nielsen Norman Group, referência mundial em pesquisa de usabilidade, documenta há décadas por que teste com usuário real é insubstituível (nngroup.com).
• Rodar em paralelo nos fluxos críticos. Faturamento e fiscal não mudam na base da fé: o fluxo novo roda junto do antigo até provar consistência.
• Medir antes e depois. Tempo de tarefa, taxa de erro, volume de chamados. Sem baseline, ninguém prova retorno, e a próxima fase da modernização vira briga de opinião.

O objetivo final não é estética. É levar cada fluxo crítico para perto da Fricção Zero e transformar um sistema que drena orçamento num Ativo Digital que sustenta crescimento. Para aprofundar o lado de interface dessa jornada, veja nosso guia de UX em sistemas corporativos.

FAQ

Discovery em produto legado demora quanto?

Depende do tamanho do sistema, do número de integrações e do acesso a dados de uso. O que define o prazo é o escopo do diagnóstico, não um pacote fechado. O erro é pular a etapa para "ganhar tempo": esse tempo volta multiplicado em retrabalho e incidente de produção.

Dá para modernizar sem parar a operação?

Sim, e essa deve ser a premissa do plano, não uma esperança. Modernização em fatias, convivência entre módulo novo e legado, testes com usuários reais e operação em paralelo nos fluxos críticos existem exatamente para isso. Quem promete a troca completa de uma vez está transferindo o risco para você.

E se o time interno defende reescrever tudo do zero?

Peça a conta dos dois cenários. Reescrita total tem custo alto, prazo longo e um risco pouco falado: reproduzir em sistema novo os mesmos problemas de fluxo do antigo, porque ninguém investigou como as pessoas realmente usam. Às vezes reescrever é a resposta certa. Mas precisa ser conclusão de diagnóstico, não ponto de partida.

O sistema é interno, só funcionário usa. UX importa mesmo?

É onde mais importa. Usuário interno não abandona o sistema, ele abandona a eficiência: retrabalho, planilha paralela, erro operacional. E os mesmos padrões valem para cliente externo em portal ou área logada, onde 88% dos usuários não voltam depois de uma experiência ruim. Dentro ou fora, a fatura chega.

Conclusão: o roteiro para começar

Modernizar legado sem quebrar a operação não é questão de coragem. É questão de sequência:

1. Levante o uso real. Dados de acesso, volume por módulo, observação de quem opera.
2. Mapeie dependências e integrações. Ninguém mexe no que não enxerga.
3. Quantifique os Custos Invisíveis. Retrabalho, suporte, erro, treinamento. É essa conta que prioriza.
4. Classifique cada módulo: evoluir, substituir em fases ou manter com data de revisão.
5. Execute em fatias, começando pela maior dor com menor dependência, sempre com baseline medido.

O maior risco de um sistema legado não está em modernizá-lo. Está em modernizá-lo na ordem errada, ou em deixá-lo drenando margem em silêncio por mais um ano fiscal.

Se a sua empresa está diante dessa decisão e as visões internas não convergem, um Discovery estratégico é o instrumento para transformar medo de mexer em plano priorizado por risco e retorno. Fale com a UX Agency e comece pelo diagnóstico.