O que o teu programador não te diz (e que devias perguntar-lhe)

Confias no teu programador, e é normal

Encontraste um programador. Freelancer, agência ou interno. É competente, reativo, entrega o que pedes. Confias nele. E é perfeitamente normal.

Mas a confiança não substitui a visibilidade.

Já vi demasiados projetos em que o PM descobre, ao fim de seis meses, que a aplicação não tem um único teste automatizado. Que a base de dados nunca foi guardada em backup. Que o código não está documentado em lado nenhum e que mais ninguém além do programador atual consegue compreendê-lo. Seis meses de desenvolvimento, dezenas de milhares de francos investidos, e um dia o dev deixa de estar disponível. Ou o projeto precisa de evoluir. E aí vem o balde de água fria.

Não é uma questão de má-fé. É uma questão de comunicação. E na relação cliente/programador, há coisas que quase nunca surgem espontaneamente.

"Está tudo a correr bem"

É provavelmente a frase mais perigosa num projeto tech.

Quando o teu programador te diz que está tudo a correr bem, na maioria dos casos é verdade. Mas por vezes significa outra coisa. Significa: "Tenho um problema, mas acho que consigo resolvê-lo." Ou: "Há dívida técnica a acumular-se, mas não é o momento de falar nisso." Ou ainda: "Estou bloqueado há dois dias num problema, mas não quero parecer incompetente."

Os programadores não escondem problemas por malícia. Fazem-no por hábito, por otimismo, ou porque consideram que o cliente não compreenderia os detalhes técnicos. E, honestamente, muitas vezes têm razão nesse último ponto. Mas isso não significa que devas ficar às escuras.

O verdadeiro desafio não é compreender cada linha de código. É fazer as perguntas certas para teres uma visibilidade real sobre o estado do teu projeto.

As perguntas que devias fazer regularmente

Estas perguntas não exigem qualquer competência técnica. Exigem apenas o reflexo de as fazer. E as respostas, mesmo que não compreendas todos os detalhes, vão dar-te sinais muito claros sobre a saúde do teu projeto.

"O projeto tem testes automatizados? Quantos?"

Um projeto sem testes é um projeto em que cada alteração é uma aposta. Mudas uma coisa aqui, parte ali, e ninguém se apercebe até um utilizador reportar o bug em produção. Os testes automatizados são a rede de segurança. Se o teu dev te diz que não há, ou que "não teve tempo", é um sinal de alarme. Não porque seja grave hoje, mas porque vai tornar-se.

"Se desaparecesses amanhã, outro dev conseguiria retomar em quanto tempo?"

Esta pergunta costuma causar desconforto, e é exatamente por isso que deve ser feita. A resposta honesta costuma ser "algumas semanas". Se for "alguns dias", estás numa boa posição. Se for "alguns meses" ou um silêncio constrangedor, tens um problema de dependência que te vai custar caro mais cedo ou mais tarde.

"Qual é a dívida técnica atual?"

A dívida técnica é o conjunto dos compromissos feitos para ir mais depressa. Todos os projetos a têm. Não é um problema em si. O problema é quando ninguém a mede e ninguém a paga. Pede ao teu dev que ta descreva em termos simples. Se a resposta for "não há nenhuma", ou o teu dev é um génio ou não quer falar nisso.

"O código está versionado e é possível fazer deploy automaticamente?"

O versionamento (Git) é o mínimo dos mínimos. Permite voltar atrás se algo correr mal, trabalhar a várias pessoas no mesmo código e ter um histórico de todas as alterações. O deploy automático (CI/CD) é a capacidade de colocar uma nova versão online em poucos minutos, de forma fiável e reprodutível. Se o teu dev faz deploy copiando ficheiros para um servidor, estás em 2010.

"O que te está a bloquear ou a atrasar neste momento?"

Esta pergunta é uma prenda que fazes ao teu programador. Dá-lhe permissão para falar dos problemas reais. Talvez esteja às voltas com uma API externa mal documentada. Talvez as especificações não estejam claras e esteja a improvisar. Talvez passe 30% do tempo a contornar uma decisão técnica tomada há seis meses. Não podes ajudar se não souberes.

"Os dados dos utilizadores estão seguros?"

É a pergunta que ninguém faz até ao dia em que há uma fuga de dados. As passwords estão com hash? Os dados sensíveis estão cifrados? Os acessos às API estão protegidos? Os backups estão em funcionamento? Se o teu dev não consegue responder claramente a estas perguntas, tens um problema. E na Suíça, com a LPD (a lei de proteção de dados), esse problema é também jurídico.

"Qual é a coisa que farias de forma diferente se recomeçasses?"

A minha pergunta favorita. Porque a resposta revela tudo. Se o teu dev tem uma resposta precisa e ponderada, significa que tem distanciamento sobre o seu trabalho, que vê os compromissos feitos e que é capaz de autocrítica. É o sinal de um bom profissional. Se a resposta for "nada, está tudo perfeito", desconfia. Nenhum projeto é perfeito. Quem afirma o contrário, ou não vê os problemas, ou não os quer ver.

Os sinais de alerta que podes detetar sem saber programar

Não precisas de ler código para sentir que um projeto vai contra a parede. Há sinais observáveis, concretos, que não enganam.

As estimativas são sempre ultrapassadas. Não de vez em quando, sistematicamente. "Demora dois dias" transforma-se numa semana. "Está quase pronto" arrasta-se por três semanas. Não é necessariamente incompetência. É muitas vezes o sintoma de um código que se tornou demasiado complexo para evoluir. Cada alteração demora mais porque o projeto acumula dívida técnica não gerida.

As "pequenas alterações" demoram dias. Quando mudar a cor de um botão ou acrescentar um campo a um formulário se torna uma operação de dois dias, a arquitetura já não aguenta. Um projeto bem estruturado permite fazer mudanças simples de forma simples.

O teu dev tem medo de mexer em certas partes do código. "Funciona, não se mexe." Esta frase devia fazer-te levantar as antenas. Código que ninguém ousa modificar é código que ninguém compreende. E código que ninguém compreende é uma bomba-relógio.

Não há demos regulares. Se só vês o produto quando está "terminado", descobres os problemas tarde demais. Um bom ritmo é uma demo a cada uma ou duas semanas, mesmo que incompleta. Permite corrigir a rota antes que o projeto siga na direção errada.

Não consegues aceder ao código-fonte. Este é o red flag supremo. O código é aquilo que estás a pagar. Deves ter acesso permanente, num repositório que controlas. Se o teu prestador recusa, ou te diz que "está no computador dele", tens um problema de propriedade intelectual para além de um problema técnico.

Como te tornares um melhor cliente tech

Fazer estas perguntas não é micro-management. É o oposto. É dar ao teu programador o enquadramento para ser transparente, para reportar os problemas cedo e para tomar as decisões técnicas certas sem ter de as esconder.

Os melhores projetos em que trabalhei foram com clientes que faziam perguntas, que aceitavam ouvir más notícias cedo e que investiam na qualidade mesmo quando não se via no ecrã. Clientes que compreendiam que a segurança, os testes e a documentação não são tempo perdido, mas tempo investido.

Não precisas de te tornar técnico. Precisas de te tornar exigente com a transparência. De pedir provas, não promessas. De preferir um dev que te diz "é mais complicado do que previsto, e eis porquê" a um dev que te diz "está tudo bem" durante seis meses antes de anunciar que o projeto precisa de ser refeito.

E se o teu dev for uma IA?

Se leste o meu artigo anterior sobre projetos feitos com vibe coding, sabes que cada vez mais pessoas constroem os seus produtos com IA. E tudo o que acabei de dizer aplica-se também nesse caso. Talvez até com mais razão.

E se o teu dev for o Claude, o ChatGPT ou o Gemini, não hesites em fazer-lhe estas mesmas perguntas. Podes descobrir coisas interessantes. Pergunta-lhe se há testes. Pergunta-lhe qual é a dívida técnica. Pergunta-lhe o que faria de diferente se recomeçasse. As respostas podem surpreender-te.

Porque o problema nunca é a ferramenta. O problema é não fazer as perguntas certas.

E se as respostas te deixarem perplexo, venham elas de um humano ou de uma IA, um olhar externo de algumas horas pode fazer toda a diferença.