Como entregar software no prazo: o método por trás de projetos que terminam

O Standish Group acompanha o resultado de projetos de software há três décadas. O número é desconfortável: cerca de 70% atrasam, estouram o orçamento, são entregues com escopo reduzido ou simplesmente cancelados antes de chegar ao fim. Não é exceção. É o normal da indústria. Mas o normal não precisa ser o seu.

A verdade mais incômoda é outra: a maioria dos atrasos não aparece de surpresa. Eles são previsíveis na semana 2, escondidos até a semana 12, e detonados no dia da entrega. Quando seu fornecedor liga avisando que vai atrasar uma semana antes do go-live, isso não é imprevisto — é confissão tardia.

Por que estimativas iniciais são tão erradas

Quando alguém pede "quanto tempo leva pra desenvolver X?", a resposta honesta na semana 1 é: depende de coisas que ainda não sei. A resposta desonesta — que vira atraso depois — é um número específico jogado para fechar o contrato. Software de verdade não funciona assim.

A engenharia de software documentou esse fenômeno como cone de incerteza. Na semana 1 de um projeto, a estimativa real varia entre 0,25x e 4x do número que você falou — ou seja, um projeto de 3 meses pode terminar entre 3 semanas (improvável) e 12 meses (mais provável que parece). Na semana 4, com escopo melhor definido, a variação cai para 0,67x até 1,5x. Na semana 8, com arquitetura no papel e protótipo funcional, fica em torno de ±20%.

Isso é matemática conhecida, documentada e ignorada pela maioria dos fornecedores. O resultado é projeto vendido como 3 meses que termina em 8.

O método que usamos para entregar no prazo

Não temos fórmula mágica. Temos disciplina sobre quatro decisões que muito fornecedor pula porque dão trabalho na proposta.

• Diagnóstico antes do orçamento: dedicamos 1 a 2 semanas pagas separadamente para mapear o escopo real, conhecer o sistema legado quando existe, e validar arquitetura. Sem isso, qualquer prazo é palpite.
• Orçamento fechado por etapa: você sabe o valor e o prazo de cada fase antes de começar. Nada de "descobrimos mais coisas no meio do caminho, vai custar a mais". Se o escopo mudar, replanejamos com você — não unilateralmente.
• Buffer explícito: 20% do prazo de cada fase é reservado para o imprevisto — bug raro, dependência externa que demora, integração que muda contrato. Não é gordura escondida. É planejamento honesto.
• Marcos semanais visíveis: toda sexta-feira você vê o que avançou e o que travou, sem mediação de gerente de projeto traduzindo a realidade técnica. Não tem "tá quase pronto".

Os quatro padrões que matam projetos

Em 10 anos somando experiência do time, identificamos quatro causas que aparecem em praticamente todo projeto atrasado. Reconhecê-las cedo é metade do trabalho de evitar o estouro.

Escopo elástico. "Já que vocês estão mexendo aí, adiciona só uma coisinha". Cada coisinha custa meio dia de desenvolvimento, duas reuniões e um ajuste de plano. Soma dez delas durante um projeto e você perdeu duas a três semanas sem perceber. A solução não é dizer não para tudo — é tratar pedido novo como pedido novo: avalia, estima, decide o que entra agora e o que vai para o próximo ciclo.

Estimativa otimista. O desenvolvedor estima o caminho feliz — quando tudo funciona, sem nenhum erro. Esquece que software de verdade lida com usuário que clica fora, conexão que cai, dado que vem malformado, integração que retorna em formato diferente do documentado. A regra prática que usamos: estimativa inicial vezes 1,5 já cobre a maior parte do "mundo real" pequeno e médio.

Dependência externa não rastreada. O gateway de pagamento que demora 3 semanas para liberar credenciais. A API do banco que muda contrato sem avisar. O cliente que precisa fornecer um arquivo de catálogo e demora um mês. Essas dependências precisam ter prazo, responsável definido e plano B desde o primeiro dia. Quando aparecem como surpresa na semana 6, viram desastre.

Comunicação assíncrona ruim. O time descobre que algo está atrasado quando já é tarde para corrigir. O fix é simples e barato: status semanal escrito, com vermelho/amarelo/verde por entrega. Em cinco minutos por semana o cliente vê exatamente onde o projeto está. Sem reunião de 1 hora para descobrir que tem reunião.

A regra dos três dias

Aplicamos uma regra interna que mudou o ritmo dos projetos: se uma tarefa estimada em 1 dia está rodando há 3 dias, ela não vai terminar amanhã. Ela vai estourar. A regra é: depois de 3 dias além do estimado, o desenvolvedor para, escala para o time, e replaneja em conjunto.

Não é fraqueza nem fracasso individual. É gestão de risco. A pessoa pode estar travada em algo que outro membro do time resolve em 10 minutos. Pode ser que a tarefa esteja mal especificada. Pode ser que o requisito mudou e ninguém percebeu. Em todos os casos, a melhor decisão é interromper, alinhar, ajustar — e seguir com clareza.

Atraso descoberto no fim é atraso. Atraso comunicado na semana 2 é informação acionável — ainda dá pra replanejar, negociar, ajustar.

O que você deve cobrar do seu fornecedor de software

Mesmo que você não contrate a Oryxi, esta seção pode te economizar meses. Quando avaliar uma proposta de desenvolvimento, exija o seguinte por escrito:

• Marcos com data específica, não promessas vagas como "em breve" ou "próxima sprint". Cada entrega importante tem uma data alvo e um critério de aceite claro.
• Acesso ao backlog em tempo real. Você deve poder ver, sem pedir, o que está pronto, o que está em andamento e o que está na fila. Trello, Linear, GitHub Projects — qualquer ferramenta serve, contanto que seja viva.
• Demonstração semanal funcional. Trinta minutos toda semana para ver o produto crescer. Se em qualquer semana não dá pra demonstrar nada novo, algo está errado e precisa ser dito.
• Aviso prévio de risco. Nada de surpresa na semana da entrega. Risco de atraso deve aparecer pelo menos duas semanas antes da data prometida.
• Plano B documentado. O que acontece se a integração com o banco X não estiver pronta? Existe caminho alternativo? Quem decide?

Times pequenos terminam antes

Em 1975, Fred Brooks escreveu "O Mítico Mês-Homem" e cravou uma frase que continua válida cinco décadas depois: adicionar pessoas a um projeto atrasado o atrasa ainda mais. A coordenação cresce em ritmo quadrático enquanto a capacidade cresce em ritmo linear. Times de 3 a 5 pessoas alinhadas entregam mais que times de 10 que se reúnem o dia inteiro.

Quando você fala com a Oryxi, você fala com quem constrói. Sem camada intermediária de gerente de projeto traduzindo o que você pediu até virar telefone sem fio. O contexto chega íntegro a quem escreve o código, a decisão técnica é rápida, e o cronograma não evapora porque alguém esqueceu de avisar.

Isso não escala infinitamente — e tudo bem. A gente prefere ser excelente para um número limitado de clientes a ser medíocre para todos. Por isso fechamos no máximo dois ou três projetos novos por trimestre.

O ritmo de um projeto na prática

Para quem nunca trabalhou com a gente, este é o cronograma típico de um projeto de porte médio (um sistema interno ou um aplicativo com integrações):

• Semanas 1 e 2 — Diagnóstico: imersão no negócio, mapeamento de fluxos, desenho da arquitetura, definição de escopo e cronograma. Saída: documento com escopo, marcos e orçamento fechado por fase.
• Semanas 3 a 6 — MVP: construção do núcleo funcional. Demos semanais. Ajustes incrementais conforme o cliente usa.
• Semanas 7 a 10 — Hardening: testes automatizados, observabilidade, performance, segurança. Preparação para produção.
• Semana 11 — Go-live: deploy gradual, monitorado. Ajustes em tempo real conforme o uso real aparece.
• A partir daí — Sustentação: suporte com SLA, melhorias incrementais, evolução planejada.

Imprevisto vai acontecer. O método é como reagimos.

Não somos mágicos. Em todo projeto algo vai dar errado: um requisito vai ser mal entendido, uma dependência externa vai atrasar, um bug raro vai aparecer no momento errado. A diferença entre o projeto que entrega e o projeto que se arrasta não é ausência de imprevisto — é como o time reage quando ele aparece.

O método acima — diagnóstico antes, orçamento por fase, buffer honesto, marcos visíveis, comunicação semanal, regra dos três dias — não evita 100% dos atrasos. Mas evita 90%, e os 10% restantes você descobre cedo, com plano de mitigação no bolso. Para a maioria dos negócios, isso é a diferença entre entrega no prazo e projeto fantasma.

Pronto para começar um projeto que termina?

Em Foz do Iguaçu, atendendo clientes no Brasil, Paraguai e Argentina, ajudamos empresas a tirar projetos do papel sem virar dor de cabeça. Se você está cansado de fornecedor que promete e não entrega, vamos conversar sem compromisso. A primeira conversa é uma hora, não custa nada, e você sai com clareza sobre o que dá ou não dá pra fazer no seu tempo.