Anatomia de uma implementação: o que acontece nas 8-12 semanas

Quando um cliente vê o sistema funcionando, ele vê o resultado de 8 a 12 semanas comprimido numa interface limpa.

Não vê os 15 dias que levamos mapeando como a Carmem faz o fechamento de pedido toda sexta. Não vê a migration que transformou 4 planilhas bagunçadas em uma base de dados limpa. Não vê os 3 dias de treinamento por equipe antes de qualquer usuário tocar o sistema em produção.

Esse post abre a caixa preta.

Vou descrever cada fase de uma implementação real — não com o cliente real (anonimato absoluto, sempre), mas com o padrão que se repete em projetos de distribuidoras, varejistas e prestadores de serviço B2B com 20 a 80 colaboradores.

O case que vou usar ao longo do texto é uma distribuidora de bebidas regional com 80 colaboradores, 4 filiais, operação misturada entre ERP legado e 6 planilhas paralelas. Empresa madura, dono com visão clara do problema, time técnico interno mínimo. Padrão que aparece com frequência.

Fase 1: Mapeamento (semanas 1 a 2)

Essa é a fase que o cliente menos vê e a que mais determina o resultado.

Antes de uma linha de código, preciso entender como a operação realmente funciona — não como o dono acha que funciona, não como está no organograma, não como foi desenhado quando a empresa tinha 12 pessoas.

Na distribuidora do nosso case, o processo de pedido descrito pelo dono levou 7 minutos. O processo real, descoberto em sessão com a Carmem (supervisora de vendas interno) e com o Rodrigo (financeiro), levou 3 horas para mapear — e tinha 9 exceções não documentadas em nenhum lugar.

O que acontece nessa fase:

• Sessões de 90 minutos com cada perfil que vai usar o sistema (separadas por função — dono não sabe o que vendedor sabe, e vice-versa)
• Mapeamento dos fluxos de exceção (o que acontece quando cliente pede produto fora de estoque, quando pagamento atrasa, quando filial abre pedido que outra filial já aprovou)
• Identificação das “regras da Joana” — decisões não-escritas que uma pessoa-chave toma todo dia e ninguém mais sabe explicar com precisão
• Glossário de campos que geram briga no preenchimento (na distribuidora, “tipo de cliente” tinha 4 interpretações diferentes entre os vendedores)

Tempo médio: 5 a 15 dias úteis, dependendo da quantidade de perfis e regras de exceção.

Onde trava: cliente que cancela sessões de mapeamento porque “está corrido essa semana”. Cada semana de atraso no mapeamento empurra o go-live uma semana. Mapeamento incompleto gera retrabalho na fase de desenvolvimento — o tipo mais caro de retrabalho porque afeta arquitetura.

Quem decide: o cliente, nas sessões. Eu facilito e registro. Nenhuma regra de negócio é decidida por mim — sou arqueólogo, não legislador do processo.

Fase 2: Arquitetura e wireframes (semanas 2 a 3)

Com o mapeamento em mãos, monto a arquitetura do sistema e os wireframes das telas principais.

Wireframe não é design. É fluxo. Mostra quem vê o quê, em qual ordem, com quais campos. É nessa fase que o cliente consegue visualizar o sistema antes de existir — e é aqui que aparece a maioria das correções de rota antes de custarem código.

Na distribuidora do case, o wireframe revelou um problema que o mapeamento não havia explicitado: o fluxo de aprovação de pedido interestadual precisava de uma tela que o gerente regional acessava de celular. Não havia sido mencionado porque “todo mundo sabia” — exceto eu, que estava chegando do lado de fora.

Três dias de conversa sobre wireframe evitaram duas semanas de retrabalho de desenvolvimento.

O que acontece nessa fase:

• Estrutura de dados (quais tabelas, quais relações, quais permissões por perfil)
• Wireframes das 5 a 15 telas principais por perfil de usuário
• Sessão de revisão com o cliente — geralmente 2 a 3 rodadas de ajuste fino
• Validação das integrações necessárias (quais APIs externas, qual ordem de prioridade)

Tempo médio: 5 a 8 dias úteis.

Onde trava: escopo cresce. Cliente que na fase de wireframe começa a pedir funcionalidades não previstas no mapeamento (“ah, já que vai ter esse painel, podia ter também…”). Cada funcionalidade nova que entra aqui precisa ser avaliada contra o escopo original. Se entrar, entra com prazo e custo revisados — não entra de graça, porque nenhuma feature é gratuita em termos de arquitetura.

Quem decide: o cliente aprova o wireframe. Eu proponho a arquitetura. Aprovação documentada fecha o escopo para desenvolvimento.

Fase 3: Desenvolvimento (semanas 3 a 6)

Essa é a fase que o cliente imagina ser a maior. Raramente é.

Com mapeamento completo e wireframe aprovado, o desenvolvimento é a parte mais previsível. IA generativa (Claude Code, Cursor) entrega 60-70% do código bruto. O dev sênior arquiteta, revisa e refina. O que em 2019 levava 3 meses de equipe hoje leva 2 a 4 semanas com método.

Mas há uma condição: o mapeamento precisa ter sido feito bem. Código gerado a partir de briefing raso é código que vai ser reescrito.

O que acontece nessa fase:

• Desenvolvimento em ciclos curtos (entregáveis parciais a cada 3 a 5 dias úteis)
• Demos intermediárias com o cliente — não espera tudo pronto pra mostrar
• Codificação das regras de negócio mapeadas na fase 1 (incluindo as 9 exceções da Carmem)
• Integrações com sistemas externos (gateway de pagamento, NF-e, ERP legado via API)
• Testes automatizados cobrindo os fluxos críticos

Tempo médio: 10 a 20 dias úteis, dependendo da complexidade do escopo.

Onde trava: mudança de escopo no meio. Cliente que vê o sistema parcial rodando e quer modificar o que já foi construído. Mudança de escopo durante desenvolvimento é o item que mais causa atraso e atrito em projetos — qualquer casa de software seria honesta em dizer isso. A proteção é o wireframe aprovado da fase anterior: funciona como contrato de escopo.

Quem decide: durante desenvolvimento, qualquer dúvida de regra de negócio vai para o cliente — e volta respondida antes de codificar. Nenhuma regra de exceção é inventada por mim.

Fase 4: Testes e validação (semanas 6 a 7)

Sistema rodando não é sistema pronto.

Antes de qualquer usuário real tocar o sistema, faço testes internos cobrindo os fluxos felizes e os fluxos de exceção mapeados na fase 1. Na sequência, o cliente faz testes com um grupo pequeno (3 a 5 pessoas, geralmente as que participaram do mapeamento).

Na distribuidora do case, os testes internos encontraram 2 bugs de regra de negócio (a lógica de aprovação interestadual tinha uma borda que não havia sido mapeada explicitamente) e 1 ajuste de UX (o campo de observação do pedido estava em lugar não-intuitivo para o vendedor mobile).

Esses 3 itens foram corrigidos antes do sistema chegar à equipe mais ampla. Com time grande, cada bug encontrado em produção custa 10x mais que o mesmo bug encontrado em teste.

O que acontece nessa fase:

• Testes automatizados (unitários + integração) rodando nos fluxos críticos
• Testes manuais de todos os fluxos de exceção mapeados na fase 1
• UAT (User Acceptance Testing) com grupo restrito do cliente
• Correção dos itens encontrados em UAT — geralmente 3 a 7 ciclos de ajuste fino
• Validação final do cliente antes de liberation para toda a equipe

Tempo médio: 5 a 8 dias úteis.

Onde trava: cliente que pula UAT e vai direto pra go-live. “Confiamos em vocês, pode subir.” Essa decisão parece economizar tempo. Na prática, transforma bugs de UAT em incidentes de produção — que param a operação e desgastam a adoção do sistema.

Quem decide: o cliente decide se o sistema está aprovado para ir ao ar. Não vou fazer go-live sem aprovação formal do cliente. Não é burocracia — é proteção de ambos os lados.

Fase 5: Migration de dados (semanas 7 a 8)

Essa é a fase mais subestimada de qualquer implementação.

Migration é transferir o histórico de dados do sistema anterior para o sistema novo — com limpeza incluída. PME com anos de planilha costuma ter dados inconsistentes: o mesmo cliente cadastrado três vezes com grafia diferente, produto com dois SKUs ativos em simultâneo, pedidos sem status padronizado.

Na distribuidora do case, a migration de 4 planilhas paralelas para o sistema novo levou 6 dias úteis. Não por volume — mas por qualidade dos dados de origem. 30% dos registros de clientes precisaram de deduplicação manual. 15% dos produtos tinham campos obrigatórios em branco.

A migration em si (importar dados limpos para o sistema novo) levou meio dia. A limpeza levou 5 dias e meio.

O que acontece nessa fase:

• Auditoria dos dados de origem (qual é o sistema de origem, qual o formato, qual o estado de qualidade)
• Limpeza e padronização (deduplicação de cadastros, preenchimento de campos obrigatórios faltantes)
• Mapeamento de campos antigos para estrutura nova (o campo “tipo cliente” da planilha velha vira qual campo no sistema novo?)
• Importação em ambiente de teste (nunca na primeira tentativa em produção)
• Validação pelo cliente antes da importação final

Tempo médio: 2 a 8 dias úteis, dependendo do volume e da qualidade dos dados de origem.

Onde trava: dados mais bagunçados do que o esperado. Na distribuidora, o dono tinha dito “os dados estão organizados nas planilhas”. Estavam — para olho humano. Para migração automatizada, 30% dos registros precisaram de intervenção manual. Dado ruim de entrada gera dado ruim de saída. Não tem atalho.

Fase 6: Treinamento e go-live (semanas 8 a 12)

A última fase e a que mais determina se o sistema vai realmente funcionar depois que eu sair.

Sistema tecnicamente impecável com time que não sabe usar é sistema que vai ser abandonado em 3 semanas e as planilhas vão voltar. Já vi isso acontecer com sistemas construídos por casas competentes — o problema não era o código, era a adoção.

O que acontece nessa fase:

Treinamento não é “reunião de 2 horas para explicar o sistema”. O protocolo que funciona:

1. Sessão por perfil, separada — vendedor aprende a tela de vendedor, financeiro aprende a tela de financeiro, gerente aprende a tela de gerente. Sessão misturada de todos ao mesmo tempo distrai e não aprofunda nenhum perfil.
2. Rodagem paralela de 5 a 10 dias úteis — sistema novo rodando em simultâneo com o processo antigo. Equipe lança no sistema novo e confere no sistema antigo se o resultado bate. Isso constrói confiança antes de cortar o sistema antigo.
3. Suporte on-demand na primeira semana de operação real — disponível para dúvida em tempo real, não só por ticket. Primeira semana em produção gera as perguntas reais que treinamento não antecipou.

Na distribuidora do case, o treinamento levou 3 dias para cobrir 5 perfis diferentes (vendedor interno, vendedor externo mobile, supervisor de vendas, financeiro, gerente regional). A rodagem paralela durou 8 dias úteis. Go-live limpo aconteceu na semana 10.

Tempo médio: 3 a 6 semanas (treinamento + rodagem paralela + go-live + primeira semana de suporte).

Onde trava: resistência do time que “preferia como era antes”. Isso é normal e previsível — qualquer mudança de sistema gera fricção. A contra-medida é ter uma pessoa interna designada como “campeão do sistema” (geralmente quem participou do mapeamento) que responde às dúvidas dos colegas. Campeão interno reduz o tempo de adoção em 40-60%.

Por que o projeto tropeça — os 3 pontos de risco mais comuns

Em todos os projetos que acompanhei, os problemas se concentram em três padrões:

Ponto 1 — O mapeamento foi feito com quem aprova, não com quem executa. Dono conta o processo como ele imagina que funciona. A Carmem que opera o processo todo dia sabe de 9 exceções que o dono não sabe que existem. Mapeamento efetivo exige falar com quem faz, não só com quem decide.

Ponto 2 — Escopo cresce durante desenvolvimento sem revisão formal. “Já que está construindo o painel de vendas, podia ter um painel de metas também?” Cada pedido novo que entra sem revisão de escopo adiciona dias de trabalho sem adicionar prazo e custo no contrato. Resultado: projeto atrasa, ambos os lados frustram. Proteção é o wireframe aprovado funcionar como contrato de escopo, com processo formal para mudanças.

Ponto 3 — Migration foi adiada até o último momento. “A gente faz a migration depois que o sistema estiver pronto.” Migration descoberta tardia revela qualidade de dados que impede go-live. Regra prática: migration começa na semana 5 no máximo, em paralelo com testes. Nunca na véspera do go-live.

O que esse processo significa para você

Se você está avaliando contratar um sistema sob medida e tem dúvida operacional — “isso vai travar?”, “vai sair do orçamento?”, “minha equipe vai usar?” — o processo que descrevi acima é o que diferencia projeto que entrega de projeto que tropeça.

As proteções estruturais são simples:

• Mapeamento feito com quem executa (não só com quem aprova)
• Wireframe aprovado antes de código (escopo travado por escrito)
• Testes com usuário real antes de go-live (UAT não é opcional)
• Migration auditada antes, não depois (qualidade de dados é o cronograma real)
• Treinamento por perfil, com rodagem paralela (adoção não é técnica)

Esses 5 pontos não são luxo de projeto grande. São o que separa sistema que 3 meses depois ainda está sendo usado de sistema que virou mais um arquivo de pasta abandonada.

Se você está no estágio de “quase decidindo, mas com dúvida sobre como funciona na prática” — faz sentido conversar antes de qualquer compromisso.

Manda “quero entender o processo” no nosso WhatsApp ou acessa /sistemas. Em 15 minutos você entende se o escopo da sua operação cabe em 8 semanas ou exige mais tempo — e por quê.

Posts relacionados:

• Quanto custa sistema sob medida pra PME em 2026 — a leitura financeira do projeto
• Antes de pedir orçamento, mapeie a regra da Joana — o mapeamento que destrava a Fase 1
• Template de briefing de software em 90 minutos — o entregável da Fase 0

Sobre o autor: Lucas Américo é sócio-fundador da Adrion Sistemas. Operou 20 anos em telecom corporativo (GVT, Brasil Telecom, Oi, Vivo Empresas), entregou sistema próprio para cinco grupos empresariais reais, e hoje toca pessoalmente cada projeto Adrion — escopo fechado, prazo cravado, código no seu nome. Casa pequena, por escolha. LinkedIn · Sobre o Grupo Adrion.