Por que sistema sob medida atrasa: o prazo real é o do dado

Fechei um projeto pra durar seis semanas. Levou quatro meses.

As seis semanas eram pra construir o sistema. O resto foi arrumar o dado que ele ia usar.

Ninguém avisa isso na reunião de venda. Eu também não avisei — na época, não sabia. Descobri no meio do projeto, que é o pior lugar pra descobrir qualquer coisa.

O prazo que te passam é o prazo da parte fácil

Você pede orçamento de sistema sob medida. A proposta cobre a construção: telas, regras, integração entre partes, testes. Isso é engenharia. Trabalho previsível, com prazo que se estima com razão.

O que quase nunca entra na proposta é arrumar o dado que o sistema vai usar. E isso não é engenharia. É arqueologia.

São duas obras diferentes, com riscos diferentes. Construir o sistema é risco técnico — se der errado, você sabe por quê e sabe consertar. Arrumar o dado é risco de descoberta. Você só sabe o tamanho do problema depois que já está dentro dele.

No projeto que citei, a construção coube nas seis semanas. O que não coube foi decidir qual das três versões de um mesmo registro era a correta — as três estavam em uso ao mesmo tempo, em partes diferentes da empresa.

Isso não aparece em orçamento. Ninguém mede antes de abrir a caixa.

Dado bagunçado não é abstrato — é isso aqui

“Dado bagunçado” soa genérico até você ver a lista de sintomas na sua própria empresa. Você provavelmente esbarrou numa dessas essa semana.

Campo preenchido de três formas diferentes. Um vendedor escreve “SP”, outro “São Paulo”, outro “sao paulo” sem acento. Pra você é a mesma coisa. Pro sistema, são três coisas.

Cadastro duplicado. O mesmo cliente entrou duas vezes porque alguém trocou um dígito do telefone na primeira digitação. Ninguém percebeu — nenhuma das duas versões estava errada, só estavam separadas.

Faça um diagnóstico gratuito →

Informação que só existe na cabeça de um funcionário. O sistema tem campo de status, mas o critério de quando mudar aquele status nunca foi escrito em lugar nenhum. Fulano sabe. Fulano sai de férias, ninguém mais sabe.

Planilha que não bate com o sistema de outra área. Financeiro tem uma versão do faturamento, comercial tem outra. As duas estão certas segundo a lógica de quem preenche — só que são lógicas diferentes.

Nenhum desses problemas é grave sozinho. Sua empresa convive com eles há anos porque tem um humano no meio resolvendo na hora, sem nem perceber que está resolvendo. Ele olha o cadastro duplicado e sabe, por experiência, que é a mesma pessoa. Ele olha o status errado e corrige de cabeça.

Um sistema automatizado não tem esse humano no meio. Lê o dado como está. Se o dado está em três formas, ele trata como três coisas. Se o critério não está escrito, ele não tem critério.

O trabalho invisível que seus funcionários fazem todo dia — é isso que vira o gargalo do projeto.

Por que ninguém te avisa antes de assinar

Existe uma razão estrutural pro silêncio. Não é má-fé.

Quem vende sistema sob medida também não sabe o tamanho do problema antes de abrir o dado. Ele pergunta “seu cadastro está organizado?” na reunião, e você responde que sim — porque pra você está. Sua equipe já aprendeu a conviver com as inconsistências. Ninguém mente. Ninguém tem visibilidade ainda.

O tamanho real do problema só aparece quando alguém senta e olha linha por linha, registro por registro. Isso não acontece antes do contrato. Acontece depois — quando o projeto já começou e alguém precisa usar aquele dado pra construir algo em cima.

Tem um segundo motivo, mais desconfortável: quem já passou por isso e sabe que pode acontecer de novo tem incentivo pra não assustar o cliente antes de fechar. Não é mentira. É otimismo seletivo. “Vamos ver como está quando começarmos” vende mais fácil do que “seu prazo pode dobrar dependendo do que a gente encontrar”.

O resultado é o mesmo pros dois lados. Ninguém mede antes. Todo mundo descobre durante.

Isso não te deixa impotente. Te deixa com uma pergunta que quase ninguém faz antes de assinar: o que acontece com o prazo se o dado estiver pior do que parece.

Prazo estourado por dado real ou por enrolação

Prazo que estoura tem duas causas possíveis. Parecem iguais de fora. Pedem reações opostas.

A primeira é dado real. O problema é específico, tem nome, tem tamanho. “Esse campo de endereço tem quatro formatos diferentes em oito mil registros.” “Esse cadastro tem duplicidade em quinze por cento dos casos.” Dá pra apontar o dedo pro problema exato. Dá pra medir quanto falta.

A segunda é enrolação. O atraso é genérico, sem contorno. “A equipe está sobrecarregada.” “Ainda estamos analisando.” “Surgiram outras prioridades.” Ninguém aponta o dedo pra nada específico porque não há nada específico — há só o projeto andando devagar.

O teste é simples: peça pra ver o dado bruto que travou.

Se a resposta vem rápido — uma planilha, uma tela, um exemplo concreto de registro problemático — você está diante de dado real. Alguém já olhou pra dentro e sabe onde dói. É chato, mas é honesto. Costuma ter fim visível: quando aquele campo estiver resolvido, o prazo volta a andar.

Se a resposta é vaga, ou demora, ou vem cheia de explicação sobre processo interno sem nunca chegar num exemplo — isso é enrolação. Problema real tem forma. Problema genérico não tem, porque ninguém definiu qual é o problema.

Você não precisa entender de sistema pra fazer essa pergunta. Precisa só insistir no exemplo, não na explicação.

E se o atraso for dado real, a pergunta seguinte não é “quando fica pronto”. É “quanto desse trabalho de arrumação eu já deveria ter feito antes de começar, e quanto disso é responsabilidade de quem está construindo o sistema”.

Essa divisão é o que separa um fornecedor honesto de um que está te empurrando um trabalho que era dele.

Perguntas frequentes

Por que o orçamento de sistema sob medida não inclui a arrumação do dado?

Porque construir é risco técnico, previsível de estimar. Arrumar dado é risco de descoberta: só se sabe o tamanho depois de abrir a caixa. Quem vende também não tem essa visibilidade antes do contrato começar.

Como saber se o atraso do meu projeto é dado real ou enrolação?

Peça pra ver o dado bruto que travou. Se vem rápido, com exemplo concreto de registro problemático, é dado real. Se a resposta é vaga ou cheia de explicação sobre processo sem chegar a um exemplo, é enrolação.

Minha empresa tem dado organizado, isso ainda pode acontecer comigo?

Provavelmente sim. Campo preenchido de formas diferentes, cadastro duplicado, critério que só existe na cabeça de um funcionário — sua equipe convive com isso sem perceber, porque sempre teve um humano corrigindo na hora.

Quem é responsável por arrumar o dado antes do sistema ser construído?

Depende do contrato, mas a pergunta certa não é quando fica pronto. É quanto desse trabalho já era seu antes de começar e quanto é de quem está construindo o sistema. Essa divisão separa fornecedor honesto de empurrão de trabalho.