Projeto de software atrasado: como retomar sem começar do zero

O sistema deveria estar no ar há meses. A cada reunião, a data anda mais um pouco. O fornecedor diz que falta pouco, mas você não consegue ver o que está pronto. A vontade é jogar tudo fora e começar de novo. Quase nunca é o melhor caminho, e nunca é o primeiro passo.

Atraso é mais comum do que parece. Em abril de 2024, a BCG ouviu executivos de 25 setores e quase metade disse que mais de 30% dos projetos de tecnologia da empresa estavam atrasados ou acima do orçamento. Quase um em cada cinco disse que o resultado ficava abaixo do esperado em mais da metade das vezes. O que muda o desfecho é a ordem das decisões. Este guia mostra essa ordem.

Sinais de que o atraso não é pontual

Todo projeto atrasa um pouco em algum momento. O problema é quando o atraso vira padrão. Fique atento se:

• A data já mudou mais de uma vez e ninguém explica o motivo.
• Você só vê prints e vídeos, nunca o produto rodando.
• Cada entrega corrige uma coisa e quebra outra.
• O fornecedor não sabe dizer o que falta, só que “está quase”.
• A pessoa que programava saiu e ninguém sabe onde estão as coisas, como quando o freelancer some com o projeto.
• Você não tem acesso ao repositório do código.

Se mais de um item soa familiar, o atraso não vai se resolver sozinho.

Primeiro passo: tudo em nome da empresa

Antes de qualquer conversa difícil, garanta os acessos. Se a relação com o fornecedor azedar, são eles que seguram o projeto. Confira:

• Código: o repositório (GitHub, GitLab ou Bitbucket) fica numa conta da empresa, com você como dono, não só como convidado.
• Domínio: o titular registrado é o CNPJ da empresa. Para domínios .br, o registro fica no Registro.br.
• Hospedagem e nuvem: conta em nome da empresa, cobrança no cartão da empresa.
• Banco de dados e backups: onde ficam, quem acessa e quando foi o último backup.
• Serviços ligados ao produto: e-mail transacional, gateway de pagamento, lojas de app, ferramentas de análise.
• Senhas e chaves: num cofre de senhas da empresa, não numa conversa de WhatsApp.

Sem esses acessos, qualquer decisão depois fica refém de uma pessoa só.

O que pedir ao fornecedor atual

Seja direto e peça tudo por escrito:

1. Lista do que está pronto, do que está em andamento e do que não começou.
2. Acesso ao produto rodando num ambiente de teste.
3. Documentação mínima: como instalar, como publicar e quais serviços externos o sistema usa.
4. A causa do atraso, na visão dele.
5. O que falta, com uma data para cada parte.

A forma como ele responde já diz muito. Fornecedor que entrega lista, acesso e documentação está disposto a resolver. Fornecedor que resiste a mostrar o código está escondendo o estado real do projeto.

Auditoria: o que existe de verdade

Auditoria é olhar o código, não as telas. Ela separa o que funciona, o que funciona mal e o que só parece funcionar. Uma boa auditoria cobre:

• Fluxos principais: testados de ponta a ponta, com dados reais.
• Segurança: começando pelo controle de acesso. Na edição 2025 do OWASP Top 10, a lista de riscos em aplicações web mantida pela fundação OWASP, falha de controle de acesso é o risco número 1, e 100% das aplicações testadas tinham alguma forma dela.
• Dados: estrutura do banco, consistência e backups.
• Manutenção: outra equipe consegue entender e mexer no código?
• Infraestrutura: como o sistema é publicado, quanto custa e o que acontece se cair.

O resultado é uma lista do que fica, do que conserta e do que refaz. É essa lista que vira preço e data.

Consertar ou refazer: como decidir

Consertar faz sentido quando:

• O banco de dados está bem modelado.
• Os fluxos principais funcionam.
• Outra equipe consegue ler e manter o código.
• A tecnologia usada ainda recebe atualizações.

Refazer faz sentido quando:

• Cada correção quebra outra parte.
• Não dá para publicar uma atualização sem medo.
• A estrutura de dados não aguenta o que o negócio precisa.
• Corrigir a segurança exige mexer em quase tudo.

Muitas vezes a resposta é mista. Dá para preservar os dados, o design e as regras de negócio e reescrever só as partes que travam. Refazer uma parte não significa perder o que já foi pago: o que o projeto ensinou sobre o negócio continua valendo.

Nova data no contrato, e como não atrasar de novo

A nova data precisa vir com escopo escrito. Data sem escopo é só outra promessa.

O mesmo estudo da BCG aponta duas práticas que mudam o resultado. Alertas precoces de prazo e orçamento aumentaram a taxa de sucesso em até 16 pontos percentuais. Times completos, sem posições-chave vagas, tiveram desempenho 76% maior do que times com cargos importantes em aberto.

Na prática, isso quer dizer:

• Ver o produto rodando com frequência, não só em reunião de status.
• Ter um responsável que avisa antes de estourar, e não depois.
• Contar com um time inteiro, e não com uma pessoa sozinha.
• Cortar escopo para caber na data. O que não é essencial para o lançamento vai para a fila seguinte.

Como fazemos no Studio

O resgate começa pelos acessos e pela auditoria. Lemos o código, testamos os fluxos principais, conferimos segurança e dados, e listamos o que fica, o que conserta e o que refaz. Essa lista vira preço fechado e prazo escrito no contrato. Código, arquivos e acessos ficam em nome da empresa, e a equipe de devs é do próprio Studio.

Também sabemos juntar o que já existe em vez de jogar fora. Na LCX, empresa de turismo com operação em mais de 10 países da América do Sul, um sistema por país virou um sistema só, no ar em 29 dias. E todo sistema sai com um agente de IA que roda todo dia, aponta falhas, sugere melhorias e confere se os dados fazem sentido. É o alerta precoce que faltou no projeto que atrasou.

Se o seu projeto de software está atrasado e você quer retomar sem jogar fora o que já foi pago, o resgate de projeto do Studio começa pela auditoria.