Quem Não Tem Cão Caça Com Gato

Quando o orçamento aperta e o resultado precisa sair

Todo mundo já passou por um projeto em que as condições ideais simplesmente não existiam. Eu tive um caso hace alguns anos em que precisei entregar um sistema de monitoramento para um cliente menor que não tinha servidores decentes, budget pra nuvem, nem equipe de TI. A solução foi um script Python rodando num Raspberry Pi 4, coletando métricas via SNMP e enviando alertas por Telegram. Não era bonito. Tinha latência de três segundos entre coleta e reporte. Mas funcionava. E o cliente ficou satisfeito porque o problema real dele — dispositivos caindo sem ninguém perceber — parou de acontecer. O ditado quem não tem cão caça com gato existe exatamente nesse espaço entre o ideal e o possível. Ele não é sobre aceitar mediocridade como virtude. É sobre reconhecer que, com os recursos que estão disponíveis agora, existe um caminho viável. A diferença é que a maioria das pessoas aplica esse princípio de forma equivocada, e é aí que as coisas dão errado.

Quem não tem cão caça com gato: o que ninguém conta

A tradução literal seria "quem não tem cachorro caça com gato", mas o sentido vai muito além da substituição de ferramenta. Trata-se de uma lógica de sobrevivência prática. Em qualquer área — desenvolvimento, engenharia, marketing, finanças — você vai se deparar com cenários onde o recurso certo simplesmente não está acessível. O ditado orienta que se use o que existe, mesmo que seja inferior ao desejado. Eu já vi equipes inteiras travarem porque esperavam pela ferramenta perfeita. Um projeto de automação industrial ficou dois meses parado aguardando um PLC específico que tinha prazo de entrega de quatro meses. Ninguém usou o que estava disponível no estoque. Resultado: prazo estourado, cliente insatisfeito, equipe toda culpando a supply chain. Se tivessem aplicado o princípio corretamente desde o início, teriam uma solução funcional em duas semanas, mesmo que imperfeita.

Aqui vai algo que livros não ensinam: o problema real não é usar o "gato". O problema é achar que o "gato" é permanente. Eu vi gente construir toda uma arquitetura em cima de workarounds e tratar cada workaround como se fosse a solução definitiva. Isso cria débito técnico acumulado que explode tarde demais. A regra prática que eu uso é simples. Use o gato. Mas documente explicitamente que é um gato. Defina um momento futuro para substituir por um cão. Se você não tem essa data marcada, você não está caçando com gato. Você está apenas desorganizado. Outro ponto que as pessoas ignoram: nem todo problema merece ser resolvido. Às vezes o "gato" funciona tão bem quanto o "cão" porque o problema em si não é complexo o suficiente para justificar investimento maior. Eu tive um caso de um sistema de relatório interno que era usado por três pessoas, uma vez por semana. O cliente queria integração em tempo real com BI. A solução real era exportar CSV manualmente. Três minutos por semana. Trinta segundos se você souber o caminho. Gastei seis horas implementando a automação completa e o cliente nunca mais reclamou. Às vezes o melhor gato é aquele que você nem precisa caçar.

O lado que ninguém destaca

Usar recursos limitados tem um custo que raramente é contabilizado. Velocidade. Confiabilidade. Manutenção. Quando você caça com gato, o trabalho que levaria 15 minutos com ferramentas adequadas pode levar 45. Quando você está sobrecarregado, essa diferença não parece nada. Quando você tem que repetir a tarefa cem vezes, ela rouba semanas da sua vida. Eu já passei por isso. Um processo de geração de relatórios que fiz num primeiro momento com planilhas e macros VBA funcionou por seis meses. Depois cresceu demais e o VBA começou a falhar em cenários de borda que eu não tinha previsto. Levei três dias inteiros refazendo a solução em Python com pandas. O custo real não foi os três dias de refazer. Foi os seis meses em que cada execução do macro era uma loteria de saber se ia dar certo ou não. Existem situações onde o ditado não se aplica. Se a segurança está em jogo, se dados sensíveis estão envolvidos, se o produto final impacta diretamente pessoas — nestes casos, usar o "gato" é irresponsabilidade, não praticidade. Eu vi uma startup usar Firebase Free Tier para armazenar dados de saúde de pacientes porque "era rápido e não custava nada". O problema é que o free tier não tinha os controles de conformidade necessários. Precisei ajudar a migrar para uma infraestrutura adequada semanas depois, e o custo de correção foi dez vezes maior do que ter feito certo desde o início.

A aplicação correta desse princípio exige honestidade. Você precisa saber quando está sendo pragmático e quando está sendo preguiçoso disfarçado de flexível. A pergunta que eu faço antes de qualquer decisão é: isso é uma solução temporária com data de vencimento, ou é uma renúncia disfarçada? Se não conseguir responder com clareza, provavelmente está enganando a si mesmo. O que separa quem aplica bem quem não tem cão caça com gato de quem aplica mal é a consciência do custo. O gato funciona quando você sabe exatamente o que está pagando por ele e aceita pagar. Funciona pior quando você ignora o preço. E falha completamente quando você espera que o gato algum dia se transforme em cachorro sem fazer nenhum esforço para isso.