Um Provérbio Diz Quem Pode Pode Quem Não Pode Se

Como funciona na prática o ditado "quem pode pode, quem não pode se vira"

Muita gente ouve esse provérbio e acha que é só um conselho motivacional de esquina. Na realidade, ele descreve uma dinâmica de recursos que aparece em qualquer área onde há limitação. Quem tem acesso ao recurso resolve. Quem não tem, improvisa. Isso não é filosofia, é logística pura. O ditado completo varia conforme a região. Em Portugal costuma aparecer como "quem pode pode, quem não pode se vira". No Brasil, às vezes ouço "quem não pode, se desvirar". O núcleo é o mesmo: a capacidade de ação depende diretamente dos meios disponíveis. A versão encurtada que o usuário citou já carrega essa ideia, mesmo truncada. Eu já vi gente levar anos para entender isso em processos operacionais porque achava que o problema era falta de esforço. Não era. Era falta de acesso a um recurso específico que outro grupo já tinha resolvido há décadas.

O mecanismo por trás

O provérbio aponta para uma assimetria estrutural. Quando dois atores enfrentam o mesmo obstáculo, mas um tem ferramentas e o outro não, o resultado é previsível. O primeiro converte vantagem em solução. O segundo converte necessidade em engenharia caseira. Isso se manifesta em várias escalas. Num projeto de TI, por exemplo, vejo isso todo dia. Uma equipe tem licença de uma ferramenta de orquestração. Outra recebe o mesmo requisito e recebe um orçamento zero. A segunda equipe acaba montando um conjunto de scripts bash com cron jobs. Funciona. Até o dia em que precisa escalar e o custo de manutenção dispara. A parte que ninguém conta é que o "se virar" tem um limite técnico. Ele funciona bem para problemas pequenos e isolados. Para problemas que precisam de repeated execution com alta disponibilidade, o improviso colapsa. Não por preguiça. Por arquitetura.

Exemplo real que eu enfrentei

Há uns anos precisei lidar com um sistema de geração de relatórios que rodava em três filiais diferentes. Cada filial tinha um servidor com acesso direto ao banco de dados central. Uma filial recebeu permissão de leitura. As outras duas não. A diretoria achava que o ditado resolvia: quem não podia, que se virasse. Os times das filiais sem acesso criaram um processo manual. Extraiam dados de uma interface web, montavam planilhas, enviavam por e-mail. Funcionava para relatórios simples. Quando o requisito mudou e passou a exigir joins complexos entre tabelas de regiões diferentes, o método manual travou completamente. Levou três semanas para o relatório que deveria ser feito em dez minutos. A solução que eu implementei foi simples e chata. Criei uma view materializada no banco central com os dados agregados que as filiais precisavam, e liberei acesso de SELECT apenas nela. Ninguém precisou mais "se virar". O tempo de geração caiu de três semanas para cerca de quatro minutos. O custo de infraestrutura adicional foi praticamente zero.

O que os iniciantes geralmente erram

O erro mais comum é tratar o "se virar" como virtude permanente. Ele é uma tática de sobrevivência, não uma estratégia. Pessoas e equipes que se apegam ao improviso como identidade acabam acumulando technical debt invisível. Cada solução caseira é um débito que rende juros até o dia em que o sistema pede algo que o improviso não suporta. O segundo erro é inverso: achar que ter recursos resolve tudo. Ter a ferramenta não garante que você saiba usá-la dentro das restrições do ambiente. Já vi licenças caras ficarem instaladas e subutilizadas porque o time não tinha documentação ou knew how interno. O recurso existia, mas a capacidade de operá-lo não.

Quando o ditado falha completamente

Existem cenários em que o "se virar" simplesmente não gera saída. Problemas que exigem certificação regulatória, assinatura digital com certificador credenciado, ou integração com sistemas legados que não têm API pública. Nesses casos, não adianta ter habilidade técnica. O recurso em si é a restrição. Tentar burlar com solução caseira nesses contextos gera risco compliance, não economia. Nesses casos específicos, a alternativa mais honesta é negociar o acesso diretamente com o proprietário do recurso. Argumentar com base em custo-benefício costuma funcionar melhor do que tentar contornar. Eu já vi orçamentos serem aprovados em dias quando o problema foi apresentado com métricas de perda real. Verbas que ficavam paradas por meses quando a solicitação vinha genérica.

Como aplicar isso de forma prática

Primeiro passo é mapear onde você está. Se o problema pode ser resolvido com improviso e o impacto de falha é baixo, vá em frente. Teste a solução caseira. Documente o que fez. Quando o sistema crescer, você terá registro do que funcionou e do que precisa ser substituído. Se o problema tem alto custo de falha, não confie no ditado. Use ele como diagnóstico, não como destino. O provérbio serve para identificar rapidamente onde está o gargalo: falta de recurso ou falta de habilidade. São caminhos diferentes. Falta de recurso pede negociação ou redistribuição. Falta de habilidade pede treinamento ou contratação. O que eu vejo acontecer com frequência é gente tratandofalta de recurso como falta de esforço. Isso gera culpa desnecessária e piora a performance porque a pessoa gasta energia tentando superar uma limitação estrutural com vontade. Não funciona. Ajustar a Expectativa e buscar o recurso apropriado resolve mais rápido.

O ditado em si não julga. Ele apenas descreve. Quem tem, age. Quem não tem, adapta. O trabalho inteligente é saber qual lado da frase você está e escolher a próxima jogada com base nisso, não com base em otimismo.