6 min de leitura
Por que projeto de software atrasa, e o que muda quando a data está no contrato
O atraso não é acidente de execução. É o resultado previsível de um contrato que paga por tempo gasto. Como a conta muda quando a data vira obrigação de quem entrega.
Você já viveu esta cena. Contratou uma empresa séria, com portfólio real e gente competente. Perguntou quando entrega. Ouviu uma estimativa. Repassou essa estimativa para o seu sócio, para o conselho ou para o seu próprio cliente. E três meses depois estava explicando, de novo, por que a data mudou.
O incômodo não é o atraso. É ter defendido publicamente um prazo que você não controlava.
Este texto é sobre por que isso acontece com tanta regularidade, e o que precisa mudar na estrutura do acordo, não no esforço das pessoas, para que pare de acontecer.
O atraso não é falha de execução
A explicação confortável é que o time era ruim, que faltou gestão, que o mercado é assim. Nenhuma delas explica a regularidade do fenômeno. Times bons atrasam. Empresas grandes atrasam. Projetos com gerente dedicado atrasam.
Quando um resultado se repete independentemente de quem executa, o problema não está na execução. Está no desenho.
O desenho é este: o contrato mais comum de software fatura por tempo gasto. Hora, ponto de função, alocação de squad: o nome muda, a mecânica não. Quanto mais tempo o projeto leva, mais o fornecedor fatura.
Isso não faz de ninguém desonesto. Faz do atraso uma consequência que o contrato não pune. E o que não é punido não é priorizado.
Repare no que acontece quando surge uma dúvida de escopo no meio do projeto. Num contrato por hora, esperar a resposta do cliente por duas semanas é receita: o time segue alocado. Num contrato com data fechada, essas duas semanas saem do bolso de quem entrega. A mesma dúvida, o mesmo time, o mesmo cliente, e dois comportamentos opostos, porque o contrato premia coisas diferentes.
A palavra “estimativa” é a cláusula mais cara do contrato
Faça um teste na próxima conversa com um fornecedor. Pergunte quando o projeto entrega e escute a estrutura da resposta.
Se a resposta contém “estimativa”, “previsão”, “expectativa” ou “a depender de”, você não comprou uma entrega. Comprou um esforço com prazo indicativo. São produtos diferentes com preços parecidos, e a diferença só aparece no quarto mês.
A palavra “estimativa” não é hedge de linguagem. É a transferência formal do risco de prazo do fornecedor para você. Depois dela, todo atraso é fato da natureza, e a conversa sobre data vira uma conversa sobre esforço: “o time está dedicado”, “estamos avançando”, “a complexidade era maior que a prevista”.
Todas essas frases podem ser verdadeiras. Nenhuma delas te devolve a data que você prometeu para o seu conselho.
Por que a indefinição custa mais que a programação
Aqui está a parte contraintuitiva, e é a que decide se um prazo curto é realista ou é promessa vazia.
Projeto de software raramente demora porque escrever código é lento. Demora porque ninguém decidiu o que era.
Um escopo que diz “área do cliente com relatórios” não é escopo. É um título. Entre esse título e algo que se possa construir existem quarenta decisões: quais relatórios, com que filtros, quem vê o quê, o que acontece quando não há dados, exporta para onde, quem aprova. Cada uma dessas decisões é uma pergunta que alguém vai ter que responder.
Num contrato por hora, essas quarenta perguntas são feitas ao longo do projeto, uma de cada vez, com o time parado esperando cada resposta. Cada semana de espera é faturada. O projeto não está avançando. Está sendo descoberto, no relógio, e você paga a descoberta.
É por isso que o levantamento de requisitos não pode acontecer depois da assinatura. Se ele acontece depois, o contrato não tem escopo. Tem intenção. E prazo sem escopo é aritmética sobre um número que ninguém sabe.
O que muda quando a data está no contrato
Uma data em cláusula muda três coisas, e nenhuma delas é o time digitar mais rápido.
O levantamento vira pré-requisito, não primeira fase. Não dá para assinar uma data sobre um escopo que ainda não existe. Isso força a especificação para antes da assinatura, que é o único lugar onde ela é barata, porque ainda não há time alocado esperando.
A indefinição vira custo de quem entrega. Se o escopo está fechado e a data é obrigação minha, cada ambiguidade que sobrou no documento é prejuízo meu, não fatura sua. Isso muda radicalmente o cuidado com que o documento é escrito. Ninguém revisa um escopo com atenção quando a imprecisão é faturável.
A recusa vira parte da oferta. Este é o ponto que soa estranho até você pensar por trinta segundos. Quem promete data tem que recusar projeto: projeto sem decisor definido, escopo que depende de aprovação de terceiros ao longo do caminho, integração com sistema legado sem documentação nem responsável, produto que ninguém ainda sabe descrever.
Um fornecedor que aceita tudo não está sendo flexível. Está sinalizando que a data dele não custa nada.
O que o contrato precisa exigir de você
Uma data só é honesta se as obrigações são das duas partes. A parte do prazo que não depende de código depende do contratante, e isso precisa estar escrito com a mesma clareza que a data:
- Um decisor único, com autoridade para aprovar. Não um comitê. Quando cinco pessoas precisam concordar, o prazo é o tempo de agenda delas, não o tempo do trabalho.
- Resposta a dúvida de escopo em até dois dias úteis. Uma dúvida parada é uma frente parada.
- Aprovação de entrega parcial em até três dias úteis.
- Acessos, credenciais e contas de loja no início. Publicação em loja trava por credencial com uma frequência que surpreende quem nunca publicou.
- O conteúdo e os textos que só existem do seu lado.
Isso não é letra miúda para escapar depois. É o oposto: sem essas janelas escritas, a data não é defensável por nenhuma das partes. Com elas, fica claro de quem é cada dia.
O que isso não significa
Não significa que software é rápido. Não é, e desconfie de quem disser que é.
Um prazo curto não vem de velocidade de digitação. Vem de tirar a indefinição da conta antes de começar e de recusar o que não cabe. É subtração, não aceleração. O trabalho leva o tempo que leva. O que encolhe é tudo aquilo que não era trabalho: a espera por decisão, a refação por mal-entendido, a semana perdida esperando um acesso.
Também não significa que nada pode mudar no caminho. Mudança dentro do escopo entra, é normal e está previsto. O que não entra sem custo é funcionalidade nova, e a razão é aritmética: funcionalidade nova consome os dias que estavam reservados para o que foi contratado. Ela vira um novo ciclo, com data própria. É justamente isso que protege a data atual.
A pergunta que vale a conversa
Você não precisa mudar de fornecedor para aplicar nada disto. Precisa de uma pergunta na próxima reunião:
“A data que você me deu está no contrato, com consequência definida, ou é estimativa?”
A resposta não vai ser evasiva por má-fé. Vai ser evasiva porque, na maioria dos contratos de software, a resposta honesta é “é estimativa”, e todo mundo no mercado se acostumou a chamar isso de prazo.
Quando a data está no contrato, ela deixa de ser risco seu e vira obrigação de quem entrega. Essa é a única diferença que importa. E é a diferença inteira.