O problema das expectativas infinitas em projetos técnicos
Eu já vi muita gente se quebrar com isso. Não é sobre preguiça, nem sobre má vontade. É sobre um padrão que nunca é atingido porque o solo se move toda vez que você chega perto dele.
a quem não basta pouco nada basta
Isso que a gente chama de "a quem não basta pouco nada basta" aparece com frequência absurda em revisões de código, em briefings de design e, principalmente, em avaliações de performance de sistemas. O cliente pede otimização. Você entrega redução de 40% no tempo de carregamento. Ele responde que ainda está lento. Quando você mostra os números, ele diz que a experiência não parece rápida. O paradoxo é que os números estão certos. A percepção dele também está. Já tive um caso específico com um painel administrativo onde o usuário final exigia que todas as tabelas carregassem em menos de meio segundo, mesmo com mais de dois milhões de registros. Expliquei que o gargalo não era o banco de dados, era a rede. O navegador precisava receber, parsear e renderizar uma quantidade brutal de células HTML. A solução que encontrei foi implementar paginação virtual com buffer de 50 linhas e pré-carregamento agressivo via Web Workers. O resultado caiu para 120ms em média. Ele ficou satisfeito por três semanas. Depois pediu que a pesquisa em tempo real não bloqueasse a interface. Isso era tecnicamente impossível sem manter duas cópias dos dados em memória, o que dobraria o consumo. Recusei. Trocamos de projeto.
O que poucas pessoas entendem é que esse comportamento não é sobre a solução em si. É sobre o frame mental de quem recebe a solução. Quando alguém opera no modo "nada basta", cada melhoria vira mero cumprimento de expectativa mínima. Você entrega algo excelente e ela trata como o piso, não como o teto. Na prática, existem alguns sinais claros de que você está lidando com esse perfil. O primeiro é quando o feedback sempre começa com "mas" em vez de "e". O segundo é a mobilidade constante dos critérios. Hoje o requisito é velocidade. Amanhã é flexibilidade. Antontem era simplicidade. Todas essas coisas podem coexistir em um produto bem construído, mas quem não fica satisfeito com pouco raramente reconhece isso.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Uma coisa contra-intuitiva que aprendi na marra é que tentar agradar esse perfil com mais dados nunca funciona. Mostra um gráfico de métricas, ele pergunta por que o gráfico não é interativo. Mostra um protótipo funcional, ele pede para o protótipo rodar em um navegador que você sabe que ninguém usa. A tática inversa, que funciona em cerca de sessenta por cento dos casos, é estabelecer limites explícitos desde o início e tratar qualquer solicitação posterior como uma mudança de escopo, não como uma correção do trabalho anterior. O problema é que muitos profissionais aceitam esse padrão como normal. Já vi engenheiros trabalhando fins de semana inteiros apenas para ajustar pixel de um modal porque o stakeholder "tinha uma sensação" de que estava desalinhado. Não era desalinhado. Era a cor primária que não combinava com o novo branding que ninguém comunicou oficialmente. Gastou-se dois dias de desenvolvimento em algo que nunca deveria ter sido aberto para revisão naquela fase.
Se você lida com isso no dia a dia, a recomendação prática é simples e difícil de executar. Documente. Não no sentido burocrático, mas no sentido de criar um registro público de decisões. Todo ajuste pedido, todo critério alterado, toda sugestão depois do prazo deve ser registrado com data, contexto e impacto estimado. Isso serve para duas coisas. Primeira, você cria um filtro natural contra pedidos impulsivos. Segunda, quando o projeto estoura, você tem evidência de onde o desvio aconteceu. Existe também uma limitação importante que precisa ser dita claramente. Esse tipo de relacionamento profissional não tem solução definitiva. Você pode mitigar, pode estabelecer barreiras, pode sair quando conveniente, mas não vai transformar o padrão de quem recebe. Tentar convencer racionalmente alguém que opera por insatisfação crônica é como tentar explicar física quântica para um parâmetro de configuração. O parâmetro não quer entender. Ele quer ser sobrescrito.
O que funciona melhor na maioria das vezes é reduzir a exposição. Entregar menos, revisar menos, participar de menos reuniões de alinhamento. Quanto menos pontos de contato, menor a superfície de ataque para demandas que nunca serão suficiente. Isso reduz a qualidade percebida do seu trabalho por quem não conhece o processo, sim, mas protege seu tempo e sua saúde mental. E em muitos casos, paradoxalmente, melhora o produto final porque você para de gastar energia contentando quem nunca vai ser contornado e passa a gastar com quem realmente se importa. Se você está no lado oposto, ou seja, é a pessoa que nunca fica satisfeita, aqui vai uma perspectiva que talvez não queira ouvir. O mercado técnico atual favorece execução consistente sobre perfeição esporádica. Um sistema que funciona razoavelmente bem e evolui continuamente vence um projeto impecável que nunca sai do papel porque alguém esperava que a versão seguinte fosse perfeita. Isso não é consolo. É matemática aplicada a prazos de mercado.
