# Projeto de software atrasado: o que fazer, passo a passo > Projeto de software atrasado? Veja o que fazer: sinais de alerta, o que exigir do fornecedor, como cortar escopo e quando renegociar ou trocar de equipe. Fonte: https://pervian.tech/blog/projeto-de-software-atrasado · Pervian Tech · publicado em 2026-10-01 O sistema deveria entrar em uso no começo do trimestre. Na reunião de acompanhamento, o fornecedor diz que "está quase", que faltam "uns ajustes" e que a demonstração fica para a semana que vem. Na semana seguinte, a demonstração vira uma apresentação de slides. Enquanto isso, o time comercial continua na planilha, o financeiro continua conciliando à mão e a diretoria pergunta a você quando aquilo vai funcionar. A sensação mais comum nesse momento é de impotência: você não programa, não sabe avaliar o que está pronto e tem medo de que pressionar só piore. A outra tentação é o oposto, romper o contrato e começar do zero com outro fornecedor, o que muitas vezes custa mais tempo do que o atraso original. Existe um caminho no meio. Este texto mostra como reconhecer um projeto atrasado antes que o atraso fique óbvio, o que o cliente pode exigir para enxergar o andamento real e quais ações tomar, em ordem, antes de pensar em trocar de fornecedor. ## A resposta curta: o que fazer quando o projeto atrasa Se você chegou aqui com um projeto já atrasado, esta é a sequência que recomendamos: 1. **Peça uma demonstração do software funcionando**, no ambiente de testes, com dados realistas. Não slides, não prints, não vídeo gravado. 2. **Peça a lista do que está pronto, em andamento e não iniciado**, por funcionalidade, em linguagem de negócio. 3. **Entenda a causa do atraso** antes de discutir culpa: escopo que cresceu, decisões que ficaram paradas do seu lado ou capacidade da equipe do fornecedor. 4. **Corte ou adie escopo** para colocar em uso, o quanto antes, a parte que já resolve um problema real. 5. **Combine um ritmo curto de entregas verificáveis**, com demonstração a cada ciclo de uma ou duas semanas. 6. **Só então avalie renegociar ou trocar**, com base no que foi entregue nesses ciclos, e não na frustração acumulada. O resto do texto detalha cada passo. ## Atraso raramente aparece de repente Um projeto não atrasa três meses no último dia. Ele atrasa um dia de cada vez, em decisões que ficam para depois, em telas que "só faltam conectar", em integrações que ninguém testou de verdade. O problema é que esse atraso fica escondido enquanto o acompanhamento for baseado em percentual de conclusão e em promessas verbais. Percentual de conclusão é o indicador mais traiçoeiro de um projeto de software. "Estamos em oitenta por cento" pode significar que todas as telas existem e nenhuma salva dados, ou que o difícil ficou para o fim. Os últimos vinte por cento costumam ser onde moram as regras de negócio, as exceções, a integração com o ERP e os testes com dados reais. Por isso, o que importa não é perceber o atraso quando ele é declarado, e sim os sinais que aparecem semanas antes. ## Sinais precoces que o cliente consegue ver Você não precisa ler código para perceber que algo vai mal. Estes sinais são visíveis para qualquer gestor: - **Demonstrações adiadas ou trocadas por slides.** Se o fornecedor não consegue mostrar o software rodando, em geral é porque ele não roda de ponta a ponta. - **Entregas que não aparecem.** Passaram semanas e você não tem acesso a nenhum ambiente onde possa clicar e testar. - **Respostas vagas para perguntas objetivas.** "Quando o cadastro de clientes fica pronto?" respondido com "estamos avançando bem" é um sinal. - **Escopo nebuloso.** Ninguém, nem você nem o fornecedor, consegue dizer com clareza o que entra na primeira versão. Cada reunião traz uma interpretação diferente. - **Perguntas básicas surgindo tarde.** No quarto mês, a equipe pergunta como funciona a devolução de mercadoria ou quem aprova um desconto. Isso deveria ter sido levantado no começo. - **Rotatividade de pessoas.** O desenvolvedor que conhecia o projeto saiu, o gerente mudou duas vezes e cada novo interlocutor precisa "se inteirar". - **Integrações sempre para depois.** A conexão com o ERP, o banco ou o gateway de pagamento é a parte mais arriscada. Se ela vive sendo empurrada para o fim, o risco está acumulando. - **Retrabalho em funcionalidades já "prontas".** Algo que foi mostrado como concluído volta para ajuste porque não atende ao processo real. Um sinal isolado pode ser só uma semana ruim. Três ou mais ao mesmo tempo indicam que o prazo combinado já não é realista, mesmo que ninguém tenha dito isso ainda. ## Causas comuns: escopo, decisões e equipe Antes de agir, vale entender de onde vem o atraso. As causas costumam cair em quatro grupos, e cada uma pede uma resposta diferente. ### Escopo que cresceu ou nunca foi definido É a causa mais frequente. O projeto começou com uma descrição genérica, como "um sistema para controlar pedidos", e ao longo do caminho foram entrando aprovação em duas etapas, relatório por filial, integração com transportadora e aplicativo para o vendedor. Cada item parecia pequeno; somados, viraram outro projeto. Quando o escopo não foi detalhado antes do desenvolvimento, a estimativa original era um palpite. Um levantamento estruturado, como o que descrevemos em [discovery de software](https://pervian.tech/blog/discovery-de-software), existe justamente para evitar isso. ### Decisões paradas do lado do cliente Essa é a causa que menos gente gosta de admitir, mas ela é comum. O fornecedor precisa saber qual regra de comissão vale, qual layout de nota usar, quem tem acesso a quê, e a resposta depende de alguém da empresa que está ocupado com outras coisas. Cada pergunta sem resposta trava uma parte do trabalho. Se o fornecedor mantém uma lista de pendências aguardando o cliente e ela é longa, parte do atraso está dentro de casa. ### Equipe insuficiente ou mal alocada O fornecedor vendeu um projeto com uma equipe e alocou outra, menor ou menos experiente. Ou a mesma equipe está dividida entre vários clientes. Isso aparece como lentidão constante, respostas demoradas e dificuldade de resolver problemas técnicos mais difíceis. ### Risco técnico subestimado Algumas partes do projeto são muito mais incertas do que outras: a integração com um ERP antigo, a migração de anos de dados de planilhas, a emissão de documentos fiscais. Quando o plano trata essas partes como "detalhes para o fim", o atraso aparece justamente na reta final, quando já não há folga. Se a integração ainda não foi testada com dados reais, o prazo que você recebeu não inclui o risco mais provável de estourar. | Causa | Como reconhecer | Primeira ação | |---|---|---| | Escopo indefinido ou crescente | Cada reunião traz requisito novo; não existe lista fechada da primeira versão | Congelar o escopo da versão atual e mover o resto para depois | | Decisões paradas no cliente | Lista de pendências aguardando sua empresa | Nomear um responsável interno com prazo para responder | | Equipe insuficiente | Lentidão constante, interlocutores trocando, problemas técnicos sem solução | Pedir a composição da equipe alocada e um plano de capacidade | | Risco técnico subestimado | Integrações e migração de dados sempre adiadas | Antecipar a parte mais arriscada e testá-la de ponta a ponta | Na prática, quase todo projeto atrasado tem um pouco de cada causa. O objetivo não é achar um culpado único, é saber onde agir primeiro. ## Como pedir visibilidade real do andamento A ferramenta mais poderosa do cliente é exigir evidência em vez de relatório. Isso não exige conhecimento técnico, só disciplina. ### O que pedir ao fornecedor - **Acesso a um ambiente de homologação** onde você e sua equipe possam usar o sistema a qualquer momento, não só durante a demonstração. - **Uma lista de funcionalidades com status**, em três colunas: pronto e testado, em andamento, não iniciado. "Pronto" significa que alguém da sua empresa conseguiu usar. - **Uma lista de riscos e pendências**, separando o que depende do fornecedor e o que depende de você. - **Demonstração ao fim de cada ciclo curto**, de uma ou duas semanas, mostrando o que mudou desde a anterior. - **Acesso ao repositório de código**, mesmo que você não vá ler. Ele mostra se há trabalho acontecendo e garante que o código está em lugar que sua empresa controla. O contrato deveria prever isso, como explicamos em [propriedade do código-fonte no contrato](https://pervian.tech/blog/propriedade-do-codigo-fonte-no-contrato). ### Como conduzir a demonstração Peça para a pessoa que vai usar o sistema no dia a dia fazer o teste, não o fornecedor. Use um caso real: um pedido com desconto, uma devolução, um cliente com cadastro incompleto. Anote o que funcionou, o que travou e o que ficou diferente do processo da empresa. Se a demonstração só funciona no roteiro que o fornecedor preparou, o software ainda não está pronto. ## Repriorizar para entregar valor antes Um projeto atrasado com escopo inteiro raramente se recupera mantendo o escopo inteiro. A saída mais eficaz costuma ser reduzir o que entra na primeira versão e colocar algo em uso o quanto antes. ### Como cortar sem perder o essencial Pegue a lista de funcionalidades e classifique cada uma com uma pergunta simples: **sem isso, a empresa consegue começar a usar o sistema?** - **Indispensável:** sem isso, o sistema não substitui o processo atual. Exemplo: registrar o pedido e enviar para o faturamento. - **Importante, mas contornável:** dá para operar alguns meses com uma solução manual. Exemplo: relatório gerencial que hoje sai de uma planilha. - **Desejável:** melhora a experiência, mas não muda a operação. Exemplo: painel com gráficos, notificações, personalização de telas. A primeira versão leva só o indispensável. O resto vira uma segunda e uma terceira entrega, com datas próprias. O raciocínio é o mesmo de um MVP, que detalhamos em [como definir o escopo de um MVP](https://pervian.tech/blog/como-definir-o-escopo-de-um-mvp). ### Por que isso funciona Colocar uma parte em produção transforma o projeto. Os usuários passam a dar retorno concreto, os problemas reais aparecem cedo e a equipe para de construir coisas que ninguém vai usar. Também devolve à diretoria algo que ela consegue ver, o que reduz a pressão e melhora as decisões. ## Quando renegociar e quando trocar Depois de alguns ciclos curtos com entregas verificáveis, você tem dados para decidir. Até lá, qualquer decisão é baseada em impressão. ### Sinais de que vale renegociar e continuar - O fornecedor reconhece o atraso, explica as causas e propõe um plano concreto. - As demonstrações dos últimos ciclos mostraram avanço real e testável. - A equipe conhece o negócio, e trocar significaria perder esse conhecimento. - O código está organizado e acessível, e outra equipe conseguiria assumir se precisasse. Nesse caso, a renegociação deve registrar o novo escopo da primeira versão, o ritmo de demonstrações, os [critérios de aceite](https://pervian.tech/blog/teste-de-aceite-de-software) e o que acontece se os próximos marcos não forem cumpridos. A conversa sobre ajuste comercial e responsabilidades contratuais deve ser feita com apoio do seu jurídico. ### Sinais de que é hora de trocar - Mesmo com ciclos curtos combinados, as entregas não aparecem. - O fornecedor não dá acesso ao código ou ao ambiente de testes. - As explicações mudam a cada reunião e não há plano. - Avaliações independentes mostram [problemas graves de qualidade](https://pervian.tech/blog/como-avaliar-qualidade-de-codigo) no que foi feito. ### Antes de romper, garanta a transição [Trocar de fornecedor](https://pervian.tech/blog/trocar-de-fornecedor-de-software) sem preparar a saída é um dos erros mais caros. Antes de qualquer rompimento, garanta: 1. **Cópia completa e atualizada do código-fonte**, com histórico, em um repositório da sua empresa. 2. **Acessos a todos os ambientes**: servidores, banco de dados, domínios, contas de nuvem, lojas de aplicativo. 3. **Documentação mínima**: como rodar o sistema, quais integrações existem, quais credenciais são usadas. 4. **Uma avaliação técnica independente** do que foi entregue, para saber se o próximo fornecedor vai aproveitar ou refazer. Um [CTO as a service](https://pervian.tech/blog/cto-as-a-service-ou-cto-contratado) pode fazer esse papel. Sem esses quatro itens, o novo fornecedor começa às cegas, e parte do tempo que você ganharia com a troca se perde reconstruindo o que já existia. ## Como evitar no próximo projeto A maior parte dos atrasos se previne antes da assinatura do contrato: - **Faça um levantamento antes de estimar.** Prazo dado sem entender o processo é palpite. - **Defina a primeira versão por escrito**, com o que entra e o que fica de fora. - **Contrate ciclos curtos com demonstração**, não um único marco de entrega no fim. - **Exija acesso ao código e aos ambientes desde o primeiro dia.** - **Nomeie um responsável interno** com tempo e autoridade para tomar decisões. - **Ataque a integração e a migração de dados cedo**, porque é ali que os riscos maiores costumam estar. - **Avalie o fornecedor pelo método, não pela promessa de prazo.** Os critérios estão em [como escolher uma software house](https://pervian.tech/blog/como-escolher-uma-software-house). Outros textos sobre contratação estão na categoria [contratação](https://pervian.tech/blog/categoria/contratacao). ## Checklist para a próxima reunião com o fornecedor - Consigo usar o sistema agora, em um ambiente de testes, sem depender do fornecedor? - Existe uma lista de funcionalidades com status que eu entenda? - Sei quais pendências dependem da minha empresa e quem vai resolvê-las? - A primeira versão tem escopo fechado e por escrito? - As integrações mais arriscadas já foram testadas com dados reais? - O código está em um repositório ao qual minha empresa tem acesso? - Há uma demonstração marcada para daqui a uma ou duas semanas? Se a maioria das respostas for "não", o próximo passo não é cobrar prazo, é pedir visibilidade. ## Perguntas frequentes ### Posso rescindir o contrato por atraso no projeto de software? Depende do que o contrato prevê sobre prazos, marcos e penalidades, e essa avaliação deve ser feita com o jurídico. Antes de rescindir, garanta a cópia do código-fonte, os acessos a todos os ambientes e uma avaliação técnica independente do que foi entregue, para que a transição para outro fornecedor não comece do zero. ### Quanto tempo um projeto de software atrasado leva para se recuperar? Depende da causa do atraso e de quanto escopo pode ser adiado. Com a primeira versão reduzida ao indispensável e entregas verificáveis a cada uma ou duas semanas, em poucos ciclos fica claro se o projeto de software está se recuperando. Prazo de recuperação prometido sem software funcionando não deve ser aceito. ### Como saber o andamento real de um projeto de software? Não confie no percentual de conclusão informado pelo fornecedor. O andamento real de um projeto de software se mede por funcionalidades prontas e testadas por alguém da sua empresa, num ambiente de homologação acessível a qualquer momento. Uma lista com o que está pronto, em andamento e não iniciado vale mais do que qualquer porcentagem. ### De quem é a culpa pelo atraso de um projeto de software? Quase sempre há responsabilidade dos dois lados. Escopo que cresceu sem controle, decisões paradas na empresa contratante, equipe insuficiente do fornecedor e risco técnico subestimado costumam aparecer juntos. Entender a causa antes de discutir culpa permite agir onde o atraso nasce, e a parte contratual deve ser conduzida com apoio do jurídico. ## Como a Pervian Tech conduz a gestão de projetos Na Pervian Tech, a gestão de projetos começa antes do código, no trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software): levantamos o processo, definimos a primeira versão por escrito e identificamos cedo as integrações e migrações que concentram risco. Durante o desenvolvimento, trabalhamos em ciclos curtos, com demonstração do software funcionando, ambiente de testes aberto ao cliente e código em repositório que a empresa controla desde o primeiro dia. Também apoiamos empresas com projetos em andamento que perderam o rumo: avaliamos o que foi entregue, o estado do código e o que falta, e devolvemos um plano em linguagem de negócio, seja para recuperar o projeto com o fornecedor atual, seja para preparar uma transição segura. Cada caso é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se o seu projeto está atrasado e você não sabe em que pé ele realmente está, [fale com a gente](https://pervian.tech/#contato).