Como resgatar um projeto de software que está dando errado (e quando recomeçar do zero)

Projetos raramente fracassam em um dia. Eles saem do rumo aos poucos, e cada sinal isolado é fácil de justificar. Juntos, fica difícil ignorá-los:

• Os prazos são adiados sem parar, cada vez por um motivo novo.
• Cada correção quebra outra coisa, e os mesmos bugs voltam.
• Ninguém consegue dizer com clareza quando o produto vai ser lançado.
• O desenvolvedor ou a agência demora a responder ou para de responder.
• Você não tem acesso ao código, aos servidores nem às contas.
• Desenvolvedores novos dizem que não conseguem trabalhar com o código “sem reescrevê-lo antes”.

Um desses sinais é um alerta. Três ou mais costumam significar que o projeto precisa de um resgate, não de mais um prazo.

Por exemplo, uma startup cujo freelancer parou de responder e é o único que tem a senha do servidor precisa de um resgate, mesmo que o código em si esteja bom.

A primeira semana é a base de todo o resto. Antes de qualquer trabalho técnico, vêm quatro passos:

• Pausar as funcionalidades novas. Continuar construindo sobre uma base instável encarece cada correção futura.
• Garantir os acessos. Confirme que a sua empresa controla o código, os servidores, o domínio e cada serviço do qual o produto depende.
• Registrar o que foi prometido e o que existe. Reúna a proposta, o contrato, os layouts e uma lista do que realmente funciona hoje.
• Segurar pagamentos que não estejam ligados a trabalho entregue. Se os pagamentos são por marcos, pause o próximo até existir um plano claro.

Não comece procurando culpados. Quem levou o projeto a esse ponto e por que importa muito menos do que saber o que dá para fazer agora, quanto vai custar e quando o produto vai funcionar.

Os acessos são o que mais falta aos fundadores justamente quando mais importam. Passe por cada item desta lista e anote quem o controla hoje:

• O repositório de código com todo o histórico, não um arquivo zip da última versão.
• As contas de hospedagem e de servidores, incluindo bancos de dados e backups.
• O registrador do domínio e as configurações de DNS.
• As contas de desenvolvedor nas lojas de aplicativos, se houver um app mobile.
• Os serviços de terceiros: pagamentos, e-mail, analytics, mapas, APIs de IA.
• Os arquivos de design e qualquer documentação existente.

Se o repositório estiver na conta de outra pessoa, peça a transferência. A documentação do GitHub explica como uma transferência mantém o histórico, as issues e os pull requests.

Se alguém não colaborar, recupere o que for possível do seu lado: domínio e hospedagem muitas vezes são pagos com o seu cartão ou registrados no seu e-mail, e esse é um caminho de volta.

Uma auditoria é uma análise estruturada do produto como ele realmente é, não como o último fornecedor o descreveu. Uma auditoria útil cobre estas áreas:

• Arquitetura. Como as partes se encaixam e se a estrutura aguenta as funcionalidades de que você precisa.
• Qualidade do código. Legibilidade, duplicação e o risco de cada mudança.
• Segurança. Riscos comuns, como os do OWASP Top 10, além de como segredos e dados pessoais são guardados.
• Infraestrutura. Hospedagem, deploy, backups e monitoramento.
• Testes e documentação. O que existe, o que falta e quanto custaria completar.

O resultado deve ser um veredito claro para cada parte do produto: manter, consertar ou reescrever, cada um com o seu motivo. Só então alguém consegue dar um preço que reflita o código como ele é.

Na Sakura, trabalhamos exatamente nessa ordem: primeiro a auditoria, depois o orçamento. É a única forma de não orçar um resgate com base em promessas que o código não cumpre.

O seu projeto está travado agora? Conte o que aconteceu. Vamos começar pelos acessos e pela auditoria e dizer com honestidade o que dá para salvar.

Na maioria das vezes, consertar. Código antigo que roda em produção carrega anos de pequenas correções para problemas reais, e uma reescrita joga tudo isso fora junto com as partes ruins.

Joel Spolsky explicou isso no conhecido ensaio Things You Should Never Do. Ele chamou reescrever o código do zero de “o pior erro estratégico que uma empresa de software pode cometer”, com a Netscape como exemplo: a reescrita levou quase três anos enquanto os concorrentes avançavam.

Há casos em que reescrever é a resposta honesta. Esta tabela mostra como avaliamos:

Mesmo quando a reescrita vence, raramente é preciso fazê-la de uma vez. O padrão Strangler Fig, de Martin Fowler, descreve como substituir um sistema por partes: as peças novas crescem ao lado das antigas até que o código velho possa ser desligado.

Se o desenvolvedor ou a agência anterior ainda estiver acessível, uma transição curta e tranquila economiza tempo e dinheiro. Peça três coisas: acesso a tudo, uma lista dos problemas conhecidos e uma conversa de uma hora sobre como o produto é publicado.

Mantenha a conversa nos fatos. As pessoas contam mais quando não se sentem acusadas, e os detalhes que elas lembram sobre o código valem mais do que qualquer discussão sobre quem é o culpado.

Se a equipe anterior não colaborar, não espere por ela. Recupere as contas que você controla, comece a auditoria com o que existe e registre por escrito o que foi pedido e quando.

Com o veredito em mãos, trabalhe em uma ordem rígida. Primeiro o lançamento, depois as melhorias:

• Estabilizar. Corrija os bugs críticos que derrubam o produto, perdem dados ou bloqueiam pagamentos.
• Concluir os fluxos do lançamento. Termine só o que o produto precisa para ir ao ar; o resto espera.
• Configurar deploy e monitoramento. Para que publicar vire rotina e os problemas apareçam antes que os usuários os relatem.
• Lançar. Os usuários reais vão mostrar quais dos problemas restantes importam de verdade.
• Melhorar. Trabalhe o resto da lista conforme o impacto no negócio.

Versões semanais que você pode testar mantêm o resgate honesto. Depois que um projeto já saiu do rumo uma vez, é preciso ver o progresso toda semana, e não apenas ouvir falar dele.

Por exemplo, uma startup cuja agência perdeu vários prazos pode descobrir que a maior parte do produto funciona e que três fluxos quebrados bloqueiam o lançamento. Consertando esses três primeiro, o produto vai ao ar, e o resto do backlog é planejado com dados reais de uso.

Depende do que a auditoria encontrar, por isso um orçamento honesto vem depois da auditoria, e não antes. Quem orça um resgate sem olhar o código está chutando.

Depois da auditoria, o trabalho até o lançamento normalmente pode ser orçado com escopo fechado. Assim você recebe um valor claro para chegar à produção, separado das melhorias que vêm depois.

Se você estiver comparando propostas para o próprio resgate, valem as mesmas regras de qualquer projeto. O nosso guia sobre preço fechado ou por hora explica quando cada modelo funciona.

Um projeto resgatado é a chance de colocar as proteções que faltaram da primeira vez:

• Propriedade. O repositório, a hospedagem, o domínio e as contas nas lojas ficam registrados em nome da sua empresa.
• Documentação. Ela é escrita durante o trabalho, para que o produto nunca mais dependa de uma só pessoa.
• Marcos. Os pagamentos acompanham resultados verificáveis, como uma versão funcionando em um link de teste.
• Um processo de mudanças. Requisitos novos são estimados e aprovados antes de alguém começar a trabalhar neles.
• Suporte depois do lançamento. Um plano claro para correções e atualizações, como um plano de suporte mensal.

Se você for escolher uma equipe nova para a próxima etapa, o nosso guia sobre como escolher uma agência de desenvolvimento reúne as perguntas que revelam parceiros fracos antes da assinatura.

Se você quer que o seu produto volte a andar, mande um briefing curto. Vamos começar pelos acessos e pela auditoria, para que a situação fique clara antes de qualquer compromisso grande.