Como resgatar um projeto de software travado

Quando um projeto de software trava, a reação natural é trocar o fornecedor. Antes disso, faça duas coisas na ordem certa: assegure os ativos e descubra a causa real. Trocar de time sem diagnóstico costuma reproduzir o mesmo travamento seis meses depois, porque em boa parte dos casos a causa está no processo de decisão, não na qualidade do código.

Passo 1: garanta os ativos antes de qualquer conversa difícil

Enquanto a relação ainda é cordial, obtenha:

• Acesso ao repositório de código com sua própria credencial de administrador.
• Dump completo do banco de dados e verificação de que ele abre.
• Acesso ao painel do servidor, com você como proprietário da conta.
• Lista de credenciais de terceiros, gateway, e-mail, APIs, e em que conta foram criadas.
• Domínio transferido para o CNPJ da empresa.

Peça isso como parte de uma rotina de governança, não como ultimato. Se houver resistência, você já descobriu uma informação relevante sobre a relação, e descobriu ainda a tempo.

Passo 2: descubra a causa real, sem acusar ninguém

Projetos travam por cinco motivos principais, e eles se distinguem por sintomas diferentes:

Para identificar, colete evidências objetivas: histórico do repositório (com que frequência houve commit nos últimos três meses), atas ou mensagens dos marcos combinados, lista de pedidos feitos fora do documento original e tempo médio de resposta dos dois lados.

Essa última medida costuma surpreender. É frequente descobrir que o fornecedor ficou semanas esperando uma definição que só o cliente podia dar.

Passo 3: faça um diagnóstico técnico independente

Contrate um profissional sênior de fora, nem o fornecedor atual, nem o candidato a substituto, para responder cinco perguntas em uma ou duas semanas:

1. Quanto do que existe funciona de fato? Não o que está escrito no relatório, mas o que roda.
2. A arquitetura suporta o que falta? Ou o que falta exige refazer a base?
3. Existe teste automatizado? Sem testes, qualquer mudança futura é aposta.
4. Dá para publicar uma versão a partir do repositório, hoje? Se ninguém consegue, o código está incompleto ou depende de segredos que não foram entregues.
5. Quanto tempo um time novo levaria para se localizar? Isso mede a qualidade da documentação e da organização, que é o que define o custo da troca.

O diagnóstico deve terminar com um número: percentual aproveitável do que existe e estimativa de horas para concluir a partir dali.

Passo 4: escolha entre os quatro caminhos

Com o diagnóstico na mão, a decisão fica objetiva:

Continuar com o fornecedor atual, com processo novo. Escolha isso quando o diagnóstico mostrar código razoável e a causa for de processo, escopo aberto, ausência de decisor, falta de marcos. Renegocie com marcos curtos, homologação formal e registro escrito de mudanças. É o caminho mais barato quando aplicável, e é aplicável com mais frequência do que se imagina.

Trocar de fornecedor e aproveitar o que existe. Escolha quando o código é aproveitável mas a relação não é recuperável, atrasos crônicos, ausência de comunicação, perda de confiança. Reserve de duas a quatro semanas para transição: o time novo precisa entender o que existe antes de prometer prazo.

Trocar de fornecedor e reescrever partes. Comum quando a base é razoável mas um módulo específico está insustentável. Reescreve-se o módulo, mantém-se o resto.

Recomeçar do zero. Só se justifica quando o diagnóstico apontar que menos de um quarto é aproveitável, que não existe documentação nem teste, e que a arquitetura impede o que falta. É a decisão mais cara e a mais tentadora, desconfie da vontade de recomeçar, ela costuma vir do desconforto com o código alheio, não da análise.

Passo 5: reinicie com um contrato diferente

Independentemente do caminho, o reinício precisa mudar as condições que produziram o travamento:

• Marcos curtos. Nada com mais de três semanas entre entregas verificáveis.
• Pagamento atrelado a homologação. Você testa e aprova antes de liberar a parcela.
• Um decisor nomeado do seu lado, com autoridade e agenda reservada para o projeto.
• Registro escrito de mudanças, com estimativa e impacto de prazo antes de entrar.
• Escopo reduzido para o que resolve a dor principal. Projeto travado quase sempre está tentando fazer demais.
• Acesso permanente ao repositório e ao ambiente, com commits frequentes e visíveis.

O erro de recomeçar sem mudar nada além do fornecedor

O padrão mais caro que se repete em resgates: a empresa troca o time, mantém o mesmo escopo mal definido, mantém a mesma ausência de decisor e mantém pagamento por cronograma em vez de por entrega. Doze meses depois, o segundo projeto trava no mesmo ponto.

Antes de assinar com qualquer novo fornecedor, escreva uma página respondendo: o que fizemos, do nosso lado, que contribuiu para o travamento? Se a resposta for "nada", o diagnóstico não terminou.

O que fazer nas próximas 48 horas

Se você tem um projeto travado agora:

1. Peça acesso de administrador ao repositório e um dump do banco.
2. Verifique em nome de quem estão domínio, servidor e chaves de API.
3. Liste tudo o que foi pedido fora do documento original.
4. Meça quantos dias, em média, o fornecedor esperou por respostas suas.
5. Marque uma conversa de diagnóstico, sem cobrança, apenas para mapear onde cada lado entende que o projeto está.

Essas cinco ações custam dois dias e mudam completamente a qualidade da decisão que vem depois.