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

A arte de resolver problema com o que está disponível

A maioria dos erros em projetos técnicos não vem da falta de conhecimento, mas da insistência em esperar pelas condições ideais antes de começar. Quem não tem cão caça com gato é o princípio mais subestimado em engenharia, gestão de produtos e até desenvolvimento de software. Não é sobre aceitar a mediocridade. É sobre reconhecer que solução imperfeita no ar vale mais que solução perfeita no papel. Eu trabalhei em um projeto de integração de APIs onde precisávamos conectar três sistemas legados que não tinham documentação técnica adequada. A equipe passou seis semanas tentando mapear cada endpoint com precisão cirúrgica. O resultado foi nada. Zero entregas. Depois, cortei o planejamento e fiz o que chamamos de "caça com gato": construí um middleware mínimo usando Python com requests e logging básico, conectei o sistema A com o B através de uma API intermediária que eu criei em dois dias, e deixei o sistema C rodando manualmente enquanto resolvia sua integração gradualmente. O prazo foi cumprido com 70% da funcionalidade esperada. Os 30% restantes vieram nos dois meses seguintes, quando os dados coletados mostraram exatamente onde estavam os gargalos. O ponto que ninguém enfatiza é que a abordagem improvista gera dados reais mais rápido do que qualquer plano detalhado. Você descobre problemas que não estavam nos documentos porque está lidando com o sistema de verdade, não com uma representação dele.

Como aplicar na prática sem virar improvisação desorganizada

Existem etapas concretas. A primeira é mapear o que você realmente tem antes de listar o que não tem. Eu costumo usar uma planilha simples com três colunas: recursos disponíveis, lacunas identificadas e soluções possíveis para cada lacuna usando apenas o que está na coluna um. Isso parece óbvio, mas a maioria das pessoas pula direto para a segunda coluna e trava. Recurso crítico: tempo de iteração. A diferença entre improviso profissional e amadorismo é a velocidade de feedback. Se você está gastando mais de três dias em uma solução antes de testá-la contra o problema real, algo está errado. Soluções improvisadas devem passar pelo ciclo projeto-implementação-teste em no máximo 48 horas para problemas pequenos e 5 dias para problemas médios. Eu já vi equipes inteiras perderem semanas montando infraestrutura de CI/CD completa para um projeto que nunca saiu do ambiente local. O custo de oportunidade aqui é enorme. Um script bash simples de deploy manual, testado em produção com rollback preparado, resolve o mesmo problema em algumas horas e permite que o produto chegue ao usuário três semanas antes.

Vantagens e desvantagens reais

A abordagem quem não tem cão caça com gato funciona bem em ambientes com restrições claras de orçamento, prazo ou tecnologia. O problema aparece quando as restrições são mal definidas. Se você improvisa sem registrar as decisões tomadas, o conhecimento fica apenas na cabeça de uma pessoa. Quando essa pessoa sai, o sistema desaba. Eu corrigi isso documentando cada decisão em um arquivo README técnico dentro do repositório, com datas e justificativas. Leva quinze minutos por semana e evita horas de reconstrução de contexto. O principal ponto cego é o viés de sustentabilidade. Soluções improvisadas tendem a acumular débito técnico rapidamente. Não significa que não devam ser usadas, mas exige um plano claro de refatoração ou substituição. Defina desde o início quanto tempo aquela solução improvisada vai existir. Se for seis meses, trate como solução temporária desde o dia um. Se for permanente, invista nos mesmos padrões que usaria para uma solução tradicional. A alternativa quando o improvviso não funciona é buscar parcerias externas ou adiar o lançamento. Ambas têm custos próprios. Parceiros externos cobram caro e introduzem dependência. Adiar significa perder mercado para quem estava disposto a começar com o que tinha. A decisão depende do setor. Em software B2B com contratos de longo prazo, cada trimestre de atraso custa significativamente mais do que um MVP mal polido. Em produtos B2C saturados, a velocidade de lançamento muitas vezes determina se a empresa existe ou não no mercado um ano depois.

O provérbio português resume uma verdade que cursos e certificações raramente ensinam: recursos limitados não são obstáculo, são o cenário padrão. A habilidade separada entre profissionais que constroem resultados consistentes e os que apenas planejam construções que nunca saem do papel é a disposição para começar com o disponível e ajustar conforme os dados aparecem.