Neste artigo
Um software sob medida de porte médio leva de 60 a 120 dias entre o primeiro contato e o sistema rodando com usuário real. Um sistema interno bem recortado sai em 30 a 60 dias, e integração pesada com sistema de terceiro não tem prazo confiável antes de uma sondagem técnica. O que atrasa quase nunca é a construção, é a decisão que não veio e o acesso que não chegou.
Este texto abre as fases uma a uma, com prazo típico de cada uma e o que costuma travar exatamente ali. A soma dos pisos dá pouco mais de um mês e a soma dos tetos passa de quatro, o que explica por que faixa larga é a resposta honesta. Fornecedor que responde com número único e fechado na primeira conversa está chutando com aparência de compromisso.
Quanto tempo leva cada fase do projeto?
As fases se sobrepõem bastante na prática, e separá-las serve para enxergar onde o tempo realmente vai. A construção costuma ser a fase mais curta do projeto inteiro, o que surpreende quem nunca acompanhou um de perto. A maior parte do calendário é consumida por decisão, validação e espera por disponibilidade de gente. Reconhecer isso muda onde o cliente deve concentrar esforço para acelerar.
| Fase | Prazo típico | Quem costuma travar |
|---|---|---|
| Discovery e especificação | 5 a 15 dias | Disponibilidade de quem conhece a regra |
| Arquitetura e decisões base | 2 a 5 dias | Definição de integração e volume |
| Construção do sistema | 15 a 45 dias | Escopo que muda no meio |
| Migração de dado legado | 3 a 20 dias | Qualidade da planilha antiga |
| Teste de aceite e ajuste | 5 a 15 dias | Agenda de quem vai validar |
| Treinamento e virada | 2 a 10 dias | Resistência da equipe à troca |
| Fonte: prazos medidos em projetos sob medida que entreguei, apurado em setembro de 2026. | ||
A coluna da direita mostra um padrão que vale destacar, porque ele contraria a expectativa comum. Em quatro das seis fases, quem trava o andamento está do lado do cliente e não do fornecedor. Isso não é transferência de culpa, é informação acionável para quem quer o projeto pronto mais cedo. Cliente que organiza essas quatro frentes antes do início corta semanas do calendário sem gastar a mais.
Por que discovery parece perda de tempo e não é?
O discovery parece improdutivo porque nada visível acontece nele, e cliente mede progresso por tela pronta. O efeito dessa fase aparece depois, na forma de ausência de retrabalho, que é difícil de perceber. Trocar uma regra durante o discovery custa uma conversa de vinte minutos. Trocar a mesma regra com o sistema construído custa dias de reconstrução e novos testes.
Essa assimetria é a razão de eu não fechar preço antes dessa etapa em projeto de qualquer porte. Orçar sem entender o problema significa embutir uma gordura grande de risco ou aceitar prejuízo depois. Nenhuma das duas opções serve bem ao cliente, porque a primeira encarece e a segunda gera conflito. O detalhe desse argumento está em discovery técnico antes do preço.
O que mais atrasa projeto na prática?
A lista de causas reais de atraso é curta, previsível e se repete em praticamente todo projeto. Nenhuma delas tem a ver com velocidade de programação, o que costuma surpreender quem contrata. Todas podem ser antecipadas e reduzidas com organização antes do início. O item mais caro é sempre a espera, porque ela consome calendário sem consumir trabalho.
Acesso que não chega: credencial de sistema de terceiro, ambiente de teste e permissão de rede param projeto inteiro por semanas seguidas. Esse tipo de espera raramente aparece em cronograma e é a causa mais comum de atraso. Resolver todo acesso na primeira semana é a medida isolada de maior impacto no prazo. Vale listar cada credencial necessária já na assinatura e testar todas antes de precisar.
Decisor ausente: quando quem pode dizer sim está sempre ocupado, cada dúvida pequena vira uma espera de dias. Comitê que se reúne a cada quinze dias multiplica o prazo de qualquer decisão. Nomear uma pessoa com autoridade e agenda reservada resolve boa parte do problema.
Dado legado sujo: planilha de dez anos com a mesma coluna preenchida de seis jeitos custa mais que a tela que vai exibir aquele dado. A limpeza exige decisão de negócio sobre casos ambíguos, e só o cliente pode tomá-la. Começar essa limpeza antes do projeto adianta a fase mais imprevisível de todas.
Escopo crescendo em silêncio: pedido pequeno somado a pedido pequeno vira um mês a mais sem ninguém ter percebido a soma. O problema não é a mudança, é a mudança que entra sem registro de impacto no prazo. Anotar cada pedido com o custo em dias mantém a conversa honesta dos dois lados.
Dá para acelerar sem baixar a qualidade?
Dá, e quase todo o ganho vem de preparar o que não depende do fornecedor. Cliente organizado corta semanas do prazo sem gastar um real a mais no contrato. As quatro medidas abaixo custam pouco tempo interno e devolvem muito calendário. Nenhuma delas exige conhecimento técnico, apenas decisão e organização prévia.
Separe o dado antes: ter a planilha limpa e a regra escrita no dia um adianta a fase mais imprevisível do projeto inteiro. Esse trabalho vai precisar ser feito de qualquer forma, e fazê-lo antes tira do caminho crítico. É a preparação com melhor retorno que existe.
Nomeie um decisor único: uma pessoa com autoridade e agenda reservada vale mais que um comitê grande que se reúne raramente. Decisão rápida e às vezes imperfeita supera decisão perfeita que chega três semanas depois. Ambiguidade de autoridade é o que mais gera retrabalho de especificação em projeto de empresa. Duas pessoas respondendo diferente para a mesma pergunta custa mais que a resposta errada.
Peça entrega em partes: colocar o primeiro fluxo em produção cedo revela problema enquanto ele ainda é barato de corrigir. Entrega única no fim concentra todo o risco no pior momento possível. Fatiar também melhora a previsibilidade das fases seguintes, porque o primeiro ciclo mede o time. A estimativa do segundo módulo nasce de dado real e não de suposição.
Resolva o acesso na primeira semana: credencial pendente é o atraso mais comum e simultaneamente o mais fácil de evitar. Listar todos os acessos necessários já na assinatura do contrato elimina esse risco. Testar cada um deles antes de precisar confirma que funcionam de verdade. Credencial que existe no papel e não autentica no ambiente certo é a armadilha mais comum.
O que muda quando a IA participa da construção?
A fase de construção encurta bastante, e as outras cinco continuam praticamente iguais. Isso muda a proporção do projeto e deixa as fases de decisão ainda mais determinantes para o prazo total. Um projeto que antes tinha construção como fase dominante passa a ter discovery e validação como gargalo. Quem espera que a IA corte o prazo pela metade costuma se frustrar exatamente por esse motivo.
O ganho real aparece na velocidade de ajustar durante o teste de aceite, quando o retorno do cliente vira alteração no mesmo dia. Essa agilidade encurta o ciclo de validação, que é uma das fases mais longas do calendário. Também reduz o custo de experimentar duas abordagens antes de escolher uma. O prazo total cai, e cai bem menos do que a propaganda sugere.
Como saber se o prazo prometido é realista?
Pergunte o que acontece se a integração com o sistema de terceiro não funcionar como esperado. Fornecedor que responde com um prazo firme sem ter testado aquela integração está chutando com confiança. Resposta boa envolve sondagem curta e paga antes do compromisso de prazo total. Só depois desse teste o número passa a significar alguma coisa verificável.
Outro teste rápido é pedir a lista de premissas que sustentam o prazo apresentado. Prazo honesto vem acompanhado de condições, como disponibilidade de decisor e entrega de acesso em determinada data. Prazo sem premissa nenhuma é promessa e não estimativa. O custo de uma sondagem é sempre menor que o de um projeto que estoura, e o comparativo de custo total está em quanto custa desenvolver um software sob medida. O cone de incerteza em estimativa de projeto explica por que faixa larga no início é tecnicamente correta.
