5 erros que mataram um contrato em 10 dias

Uma empresa americana contacta-me para retomar um projeto. Negociamos os termos do contrato, o meu papel é claro no papel, apenas desenvolvimento. Eles já têm equipas para a infraestrutura e o resto. O projeto está 90% terminado, o objetivo é pô-lo online o mais depressa possível.

Eu fico entusiasmado. Trabalhar com o Tio Sam, acho isso fixe. Uma boa aventura para viver, mesmo à distância. E quem sabe, a longo prazo, iria visitá-los de férias. California!

O contrato durou 10 dias. Parámos de comum acordo.

Podia contar esta história dando-me o papel bonito. O cliente por aqui, o contexto por ali. Seria fácil, e sobretudo inútil. Porque a verdadeira questão é porque é que eu, com a minha experiência, não vi chegar o que ia acontecer. Aqui estão os 5 erros que cometi, e o que farei de forma diferente da próxima vez.

Erro 1. Assinei sem clarificar os papéis e as responsabilidades

No papel, tudo era simples. Eu no desenvolvimento, eles na infraestrutura e no resto.

Na prática, desde os primeiros dias, precisava de acessos aos servidores, ao DNS, aos serviços de terceiros. Ninguém tinha definido quem fornece o quê, nem quando, nem como. Então fiz o que muitos independentes fazem, vesti o chapéu em falta. O chapéu devops juntou-se ao contrato, sem acessos completos, sem perímetro, sem que o enquadramento fosse rediscutido.

Está dentro das minhas competências, por isso disse que sim. Devia ter dito que não. Não porque não soubesse fazer, mas porque aceitar uma responsabilidade sem os meios que vêm com ela prejudica o projeto. Cada chapéu acrescentado a meio do caminho sem renegociar o enquadramento é mais uma zona cinzenta. E as zonas cinzentas são onde os projetos morrem.

O que retiro disto. A definição dos papéis não é uma formalidade de contrato. É a entrega número zero. Se o perímetro muda, o enquadramento deve ser rediscutido no próprio dia, não sofrido em silêncio.

Erro 2. Aceitei trabalhar sem acompanhamento de projeto

No kickoff, a mensagem foi direta. Nada de acompanhamento, tem de ir depressa. Se precisar de informação, pergunto. O único output esperado é a publicação online, com bugs ou sem eles, corrigimos depois.

Ouvi "menos admin, mais código" e achei quase confortável. Grande erro.

O acompanhamento de projeto, tento sempre pô-lo em prática, e na realidade nem sempre funciona bem, eu sei. Mas no arranque de uma colaboração, é insubstituível. Não é para ficar bonito. É para construir confiança mostrando o progresso, para documentar o trabalho, para criar uma linguagem comum entre o que eu faço e o que o cliente percebe.

Sem acompanhamento, quando o ritmo pareceu lento do lado do cliente, não tinha nada para mostrar. Sem rasto, sem marcos, sem realidade partilhada. Apenas a minha palavra contra uma impressão.

O que retiro disto. O acompanhamento não é negociável no início de uma colaboração. É precisamente quando o cliente quer ir depressa que mais precisa dele, porque é a única coisa que torna a velocidade visível.

Erro 3. Não garanti o envolvimento do cliente

Ser dono de um projeto e delegar a sua execução não significa desligar-se a 100%.

O projeto tinha sido vibe coded. Não é esse o problema, eu retomo projetos vibe coded, tornou-se até parte do meu trabalho. O problema é a quantidade. Uma massa enorme de código, de documentação e de versões. Um histórico de alguns meses de prompts que, há apenas três anos, teria representado o trabalho de uma equipa inteira durante vários trimestres.

Numa massa destas, surgem decisões todos os dias. Que versão faz fé. Que funcionalidade está abandonada. Que comportamento é um bug e qual é intencional. Essas decisões, só o cliente as pode tomar. E se o cliente não está disponível, ou já não tem a visão de conjunto sobre o seu próprio projeto, tudo pára.

Não tinha previsto nada para isso. Sem reuniões de decisão, sem prazo de resposta acordado, sem pessoa identificada como árbitro.

O que retiro disto. Antes de começar, garanto a disponibilidade do cliente. Quem decide, em que prazo, em que canal. Delegar a execução exige mais envolvimento do cliente no arranque, não menos.

Erro 4. Deixei a experiência do cliente substituir a auditoria

"O projeto está 90% terminado." Neste ofício, toda a gente sabe o que vale esta frase. Eu também. Ninguém acredita num "90% terminado", é quase uma piada recorrente entre programadores.

Então porque é que não fui ver mais fundo? Porque o número vinha de um cliente técnico, com longos anos de IT e de gestão de projeto. Disse a mim mesmo que ele sabia o que "terminado" quer dizer, que a sua estimativa era informada, que o enquadramento se aguentava. Não foi no número que acreditei, foi na experiência de quem o anunciava.

A realidade debaixo da superfície era código morto, documentação desatualizada porque o enquadramento inicial nunca tinha sido consolidado, funcionalidades que só funcionavam no caminho ideal. E casos limite impossíveis de reproduzir, aqueles que transformam os 10% restantes em 90% do trabalho.

Não fiz auditoria antes de me comprometer. Sem balanço inicial, sem definição partilhada do que "terminado" quer dizer. A credibilidade do cliente serviu-me de garantia, e deixei essa garantia substituir a minha própria verificação.

O que retiro disto. A experiência do cliente não substitui a auditoria. Mesmo técnico, mesmo sénior. Sobretudo técnico e sénior, na verdade, porque quanto mais credível é o cliente, mais as suas estimativas passam sem controlo. Um ou dois dias faturados para estabelecer o estado real do projeto é o que protege as duas partes. A confiança não dispensa a verificação.

Erro 5. Não fiz a pedagogia do meu próprio trabalho

Este erro é o espelho do anterior. Acreditei na experiência dele sem a verificar. E assumi que a minha se via sem a explicar.

O terreno era conhecido desde o início. O projeto vivia na Vercel com um Supabase serverless, e tinha de passar para self-hosted, na Suíça, com uma verdadeira arquitetura numa infraestrutura soberana. Eu sabia-o quando assinei. Não é esse o problema.

O problema é a distância entre os dois mundos. Fazer deploy na Vercel é fixe, funciona, vai depressa. Sobretudo quando é o Claude que o faz por ti. A segurança, os backups, logo se vê. O self-hosted é outro desporto. Configurar um DNS, ativar um SSH, ir buscar as variáveis de ambiente certas, ligar cada serviço como deve ser. O devops é minucioso. Uma má indicação à IA, e nada funciona.

Esse desfasamento, eu conhecia-o. Mas explicar porque é que uma infraestrutura limpa demora dois ou quatro dias a alguém que acabou de ver 95% do trabalho fazer-se num só, parecia estar a justificar-me. Então não o fiz. Nem orçamentado, nem planeado, nem anunciado. Deixei o meu trabalho tornar-se invisível, e o mal-entendido instalou-se exatamente aí.

O que retiro disto. A pedagogia faz parte do trabalho, mesmo perante um especialista, porque a especialidade dele não é a minha. Tornar visível o trabalho invisível, orçamentado, planeado, explicado em voz alta, não é justificar-se. É a única coisa que impede que uma diferença de perceção se transforme numa rutura.

O que este contrato me ensinou

No dia 10, falámos honestamente e parámos de comum acordo. Sem conflito, sem rancor. Apenas a constatação de que as condições não permitiam fazer bom trabalho.

Podia invocar circunstâncias atenuantes, e existem. Não mudaria nada no essencial. Antecipar estes cinco pontos era o meu trabalho. É exatamente isso, aliás, ser independente. A especialidade não pára no código, inclui o enquadramento que protege o projeto, e a coragem de dizer não quando esse enquadramento não existe.

Este contrato rendeu-me uma checklist que aplico agora em cada retoma de projeto. Uma auditoria antes de me comprometer. Os acessos desde o primeiro dia. Um acompanhamento não negociável no arranque. Um decisor identificado e disponível. E a pedagogia do trabalho invisível, orçamentada e anunciada desde o início, mesmo quando o cliente é um especialista.

A aventura americana pode esperar. Da próxima vez, irei com um contrato melhor. E talvez, mesmo assim, de férias.

Se tens um projeto vibe coded que precisa de passar de protótipo a produto, ofereço uma auditoria gratuita. Olho para o teu produto, digo-te honestamente onde está, e o que os últimos "10%" escondem realmente. Sem compromisso, sem jargão. É exatamente esse o propósito da minha oferta Do protótipo ao produto.