Prazo de entrega de software: por que "quanto tempo leva" só tem resposta depois do escopo

**Prazo de entrega de software** só vira número confiável depois que existe escopo escrito. Antes disso, o que dá para oferecer é uma faixa, acompanhada das condições que precisam se confirmar para ela valer.

A pergunta "quanto tempo leva" espera um número. A resposta útil tem duas partes: a faixa e a lista do que precisa acontecer para ela se sustentar.

**Estimativa e compromisso: duas coisas diferentes que a mesma pergunta mistura**

**Estimativa** é previsão feita com a informação disponível, e carrega incerteza declarada: "entre três e seis semanas, se A, B e C acontecerem". **Compromisso** é data que alguém assume e pela qual responde. São coisas distintas, e a primeira conversa pede uma enquanto cobra a outra.

A faixa é a forma honesta de responder no primeiro contato. Sem [escopo escrito](/blog/escopo-de-projeto-de-software/), a estimativa é hipótese — exatamente como o preço é hipótese antes de existir descrição do resultado esperado.

Data cravada na primeira conversa quase sempre é uma de duas coisas. Ou chute otimista, que estoura no meio do projeto e vira conversa ruim. Ou colchão embutido, prazo inflado para caber qualquer surpresa — e você paga a espera que talvez não fosse necessária. Os dois custam caro depois, em momentos diferentes.

Este texto não é método de gestão de projeto nem promessa de prazo. É a anatomia de onde o tempo realmente vai. E a tese é desconfortável: de todas as etapas entre o "sim" e o sistema no ar, só uma depende exclusivamente de quem programa.

**Prazo de entrega de software: as cinco etapas e qual delas o fornecedor controla**

1. **Descoberta e escopo.** Transformar pedido em resultado esperado e em critério de aceite — a frase verificável que decide sozinha se algo está pronto. O ritmo depende de quem contrata responder perguntas, não de quem programa.

2. **Construção.** Escrever, revisar e testar o código. É a única etapa cujo ritmo o fornecedor controla de ponta a ponta — e, em projeto pequeno, costuma ser a menor fatia do calendário.

3. **Revisão e aprovação.** Tempo de calendário de quem aprova, não de quem constrói. Um ajuste de poucas horas de trabalho consome dias se ficar parado esperando resposta.

4. **Deploy.** Publicar a versão no servidor, com domínio apontado e HTTPS válido — HTTPS é a conexão criptografada entre navegador e servidor; sem ela, o navegador sinaliza o site como não seguro. Etapa curta em trabalho, potencialmente longa em espera de terceiros.

5. **Estabilização pós go-live.** Go-live é o dia em que o sistema entra em uso real. Depois dele vem uma janela combinada para o que só aparece com uso de verdade: navegador que ninguém tinha, dado preenchido de um jeito imprevisto, pico de acesso. Não é defeito do fornecedor; é característica de software em produção.

Quem informa só o prazo de construção está informando o prazo errado. O ciclo completo está descrito em [da descoberta ao deploy](/blog/da-descoberta-ao-deploy-com-fabrica-de-software/); aqui interessa a aritmética simples: quatro das cinco etapas dependem, em algum grau, do relógio de gente fora da engenharia.

**Caminho crítico: as dependências que não obedecem ao seu cronograma**

Caminho crítico é a sequência de tarefas que, se atrasar um dia, atrasa a entrega em um dia. O resto do projeto tem folga; ela não tem. Saber quais itens estão nesse caminho é o que separa cronograma pensado de lista de desejos com datas.

Em site e sistema pequeno, as esperas que mais empurram a data são quase todas externas à engenharia:

— **Texto e imagem que ainda não foram escritos ou produzidos.** A página não fecha sem [conteúdo definitivo](/blog/seo-de-conteudo-para-marcas-de-tecnologia-e-servicos/), e essa é a espera mais subestimada de todas: "os textos a gente manda semana que vem" é a frase que mais adia go-live.

— **Aprovação de identidade visual.** Logo, cores e tipografia pendentes travam a construção da interface inteira, não só da home.

— **Acesso a sistema de terceiros.** Quando a credencial depende do fornecedor atual, ela chega no tempo de outra empresa, que não tem nenhum incentivo para ser rápida.

— **Registro de domínio e troca de DNS.** DNS é o sistema que liga o endereço digitado no navegador ao servidor onde o site está. Mudar o apontamento é rápido de fazer e lento de alcançar todo mundo: cada provedor só busca o valor novo quando o cache do anterior expira. E [em nome de quem o domínio está registrado](/blog/titularidade-de-dominio-e-codigo-em-projeto-de-software/) decide se a troca leva minutos ou semanas.

— **Emissão do certificado HTTPS.** Hoje é automatizada na maioria das hospedagens, mas a validação mais comum exige o domínio já apontando para o servidor. Encadeia direto com o item anterior.

— **Aprovação de conta e de modelos de mensagem na WhatsApp Business Platform**, a via oficial da Meta para envio automatizado por WhatsApp. Cada modelo passa por análise antes de poder ser disparado, em fila de terceiro, sem previsão que a engenharia possa dar.

Dependência externa começa no primeiro dia do projeto, em paralelo à construção — nunca na semana da entrega. Domínio, identidade visual e aprovação de conta iniciados junto com a primeira linha de código viram espera já gasta, e não espera descoberta no fim.

**Rodadas de revisão e decisão por comitê: o tempo que sai do seu lado**

Revisão é item de cronograma, não intervalo entre etapas. Combine antes quantas rodadas entram no prazo e no preço, do mesmo jeito que se combina critério de aceite.

Cada rodada consome dois tempos: o do fornecedor ajustando e o de quem revisa. O segundo é o que escorrega, porque concorre com a rotina da empresa — revisar um site não é o trabalho principal de ninguém.

Vale a mesma fronteira do escopo: ajuste sobre o que já estava no critério de aceite é rodada; comportamento novo é item novo, e item novo move a data. Isso precisa ser dito na hora do pedido, não na véspera da entrega.

Decisão por comitê é o multiplicador silencioso. Três pessoas com opiniões contraditórias por canais diferentes transformam uma rodada em três, e nenhuma delas fecha — o fornecedor passa a arbitrar preferência alheia em vez de entregar.

A recomendação é chata e funciona: uma pessoa decide, com prazo combinado de resposta por rodada. Atraso na resposta empurra a entrega no mesmo número de dias, e isso se acorda antes.

Feedback de gosto — "não gostei", "ficou frio" — não fecha rodada. Feedback verificável fecha: "o preço precisa aparecer antes da dobra", "o botão de WhatsApp some no celular".

**Cortar teste, deploy reproduzível e observabilidade não encurta prazo — só muda quem paga**

Três termos, definidos antes do argumento. **Teste automatizado** é verificação que roda sozinha a cada alteração. **Deploy reproduzível** é publicar a mesma versão do mesmo jeito, sem passo manual lembrado de cabeça. **Observabilidade** é o log, a métrica e o alerta que mostram o que está acontecendo em produção.

Cortar teste antecipa o go-live e transfere a verificação para o usuário — que reporta por WhatsApp, em horário comercial, com informação incompleta. O trabalho não sumiu: mudou de lado e ficou mais caro de reproduzir.

Deploy manual encurta a primeira publicação e alonga todas as seguintes, inclusive a correção urgente — justamente a que você quer no ar rápido, num sábado.

Sem observabilidade, o tempo até descobrir que algo quebrou vira indeterminado. O relógio do retrabalho só começa a correr depois do prejuízo, quando alguém liga avisando.

O trade-off é declarável: há projeto pequeno em que parte disso é excesso, e vale dizer qual. Uma [landing page com botão de WhatsApp](/blog/landing-page-que-converte-whatsapp-pixel/) não precisa da mesma malha de teste de um sistema com perfis e permissões. O critério é quanto custa uma hora fora do ar — [o que se mede e se alerta](/blog/devops-observabilidade-e-confianca-entre-times-e-clientes/) se dimensiona por esse custo, não por gosto.

O que dá para encurtar de verdade é o escopo da primeira entrega, não o rigor com que ela é entregue.

**Faixas de prazo por tipo de projeto — e o que cada faixa pressupõe**

Tipo de projeto: Site institucional ou landing page · Faixa típica: 1 a 3 semanas · Até onde vai: Do escopo fechado ao go-live

Tipo de projeto: Sistema web sob medida · Faixa típica: 3 a 6 semanas · Até onde vai: Até a primeira entrega útil — não o projeto inteiro

Primeira entrega útil é a menor versão que já entra em uso real. Não é demonstração de reunião, e não é o sistema completo.

Essas faixas pressupõem quatro condições, todas do lado de quem contrata: textos e imagens disponíveis, identidade visual aprovada, uma pessoa decidindo com prazo de resposta combinado e acessos de terceiros liberados.

O que as estoura também é previsível: conteúdo sendo produzido durante o projeto, integração que depende de aprovação externa e número de perfis de usuário crescendo depois do começo — cada perfil novo é permissão, tela e caso de erro novos.

Prazo e preço andam juntos: o que encurta prazo costuma ser recorte de escopo, e recorte mexe no orçamento nos dois sentidos — para menos agora, às vezes para mais no total, se o que saiu voltar depois como item separado. As faixas de valor estão no [guia de quanto custa criar um site](/blog/quanto-custa-criar-um-site-em-2026/).

Nenhuma dessas faixas é promessa antecipada. É o que costuma caber, quando o escopo já está escrito.

**O que perguntar para saber se o prazo do fornecedor é sério**

Seis perguntas curtas, para copiar e mandar antes de aprovar qualquer cronograma:

1. O que entra na primeira entrega útil — e o que fica para depois dela?

2. O que trava se eu atrasar: quais itens do meu lado estão no caminho crítico, e quantos dias cada um empurra?

3. O que acontece com a data quando o escopo muda: a mudança é reorçada em prazo também, ou só em preço?

4. Quais dependências de terceiros existem neste projeto, e quando elas são iniciadas?

5. Quantas rodadas de revisão entram, e qual é o prazo de resposta esperado do meu lado?

6. Como é a janela de estabilização depois do go-live, e o que ela cobre?

A reação às perguntas já é informação. Fornecedor com processo responde sem rodeio e costuma devolver perguntas. Quem responde com data redonda e nenhuma condição está vendendo, não estimando — é o mesmo sinal que o [checklist para escolher uma fábrica de software](/blog/como-escolher-fabrica-de-software-alinhada-a-seu-produto/) usa para separar proposta de promessa.

Na Projask, prazo é combinado depois do escopo, com as dependências do seu lado listadas por nome. Se você já tem o escopo escrito, ou quer escrever com ajuda antes de pedir data, a conversa é pelo WhatsApp.

**Perguntas frequentes sobre prazo de entrega de software**

**Por que o fornecedor não fecha prazo já na primeira conversa?**

Porque sem escopo escrito não há o que estimar: a conta vira hipótese, do mesmo jeito que o preço. Quem crava data no primeiro contato costuma estar chutando para baixo, e o chute estoura no meio do projeto, ou embutindo colchão, e aí você paga uma espera que talvez não fosse necessária. O caminho honesto é dar faixa e dizer, item por item, do que ela depende.

**Quais são as fases reais de uma entrega de software e qual delas o fornecedor controla?**

São cinco: descoberta e escopo, construção, revisão e aprovação, deploy e estabilização pós go-live. Só a construção tem o ritmo controlado de ponta a ponta pelo fornecedor — e, em projeto pequeno, ela costuma ser a menor fatia do calendário. Descoberta e revisão andam na velocidade de quem contrata responder; deploy pode travar em espera de terceiros; a estabilização é a janela para o que só aparece com uso real. Informar apenas o prazo de construção é informar o prazo errado.

**O que é caminho crítico e quais dependências costumam travar o cronograma?**

É a sequência de tarefas sem folga: um dia de atraso nela é um dia de atraso na entrega. Os itens que mais aparecem aí vêm de fora da engenharia — textos e imagens ainda não produzidos, identidade visual pendente, credencial de sistema que depende do fornecedor atual, registro de domínio e troca de DNS, certificado HTTPS (que na validação usual exige o domínio já apontado) e a análise de conta e de modelos de mensagem na WhatsApp Business Platform. Todos devem ser iniciados no primeiro dia, em paralelo à construção.

**Dá para encurtar o prazo cortando testes, deploy reproduzível e observabilidade?**

Isso adianta o go-live e adia o trabalho, não o elimina. Sem teste automatizado, a verificação passa para o usuário, que reporta por WhatsApp e com informação incompleta. Deploy manual encurta a primeira publicação e alonga todas as seguintes, inclusive a correção urgente. Sem observabilidade, o tempo até descobrir que algo quebrou fica indeterminado. Há projeto pequeno em que parte disso é excesso, e o critério para decidir é quanto custa uma hora fora do ar. O que encurta de verdade é reduzir o escopo da primeira entrega.

**O que acontece com a data de entrega quando o escopo muda no meio do projeto?**

A data muda junto, e isso precisa ser dito na hora do pedido, não na véspera da entrega. A fronteira é a mesma do critério de aceite: ajuste sobre o que já estava escrito é rodada de revisão; comportamento novo é item novo, com preço e prazo próprios. Mudança de escopo é normal — o que azeda a relação é reorçar só o preço e deixar a data como estava. Pergunte ao fornecedor, antes de começar, se a mudança é reorçada em prazo também.

**Por que o fornecedor não fecha prazo já na primeira conversa?**

Porque sem escopo escrito não há o que estimar: a conta vira hipótese, do mesmo jeito que o preço. Quem crava data no primeiro contato costuma estar chutando para baixo — o chute estoura no meio do projeto — ou embutindo colchão, prazo inflado para caber qualquer surpresa. O caminho honesto é dar faixa e dizer, item por item, do que ela depende.

**Quais são as 5 fases da entrega de software e qual delas o fornecedor controla?**

As cinco etapas são: descoberta e escopo (ritmo depende de quem contrata), construção (única que o fornecedor controla de ponta a ponta), revisão e aprovação (tempo do aprovador, não de quem constrói), deploy (curto em trabalho, potencialmente longo em espera) e estabilização pós go-live (o que só aparece com uso de verdade).

A construção é a única etapa cujo ritmo o fornecedor controla exclusivamente — e, em projeto pequeno, costuma ser a menor fatia do calendário. As outras quatro dependem, em algum grau, do relógio de gente fora da engenharia.

**O que é caminho crítico e quais dependências costumam travar o cronograma?**

Caminho crítico é a sequência de tarefas que, se atrasar um dia, atrasa a entrega em um dia. Em site e sistema pequeno, as esperas que mais empurram a data são quase todas externas à engenharia: texto e imagem não prontos, aprovação de identidade visual pendente, acesso a sistema de terceiros, registro de domínio e DNS, emissão de certificado HTTPS e aprovação de modelos na WhatsApp Business Platform.

A recomendação é iniciar dependências externas no primeiro dia do projeto, em paralelo à construção — nunca na semana da entrega. Domínio, identidade visual e aprovação de conta iniciados junto com a primeira linha de código viram espera já gasta, e não espera descoberta no fim.

**Dá para encurtar prazo cortando testes, deploy reproduzível e observabilidade?**

Não. Cortar teste antecipa o go-live e transfere a verificação para o usuário — que reporta por WhatsApp, em horário comercial, com informação incompleta. O trabalho não sumiu: mudou de lado e ficou mais caro de reproduzir.

Deploy manual encurta a primeira publicação e alonga todas as seguintes, inclusive a correção urgente — justamente a que você quer no ar rápido, num sábado. O que dá para encurtar de verdade é o escopo da primeira entrega, não o rigor com que ela é entregue.