Partindo Do Pressuposto

O método que você já usa, só não sabe o nome

Na maioria dos projetos que eu já vi desandar por falta de clareza, o erro não estava na execução. Estava na fase inicial, quando todo mundo começava partindo do pressuposto de que entendia o problema antes de realmente mapeá-lo. Isso não é um conceito filosófico. É uma técnica prática de resolução que corta tempo de investigação quando aplicada com disciplina. O princípio é simples: em vez de gastar horas coletando dados sobre algo que você não tem certeza se precisa, você declara explicitamente quais são suas suposições iniciais, valida cada uma delas antes de avançar, e só então constrói a solução em cima do que sobrou como verdadeiro.

A diferença entre fazer isso bem e fazer isso mal é o motivo pelo qual alguns projetos travam nas primeiras duas semanas e outros andam sem atrito.

Por que partindo do pressuposto funciona (e quando falha)

O grande erro dos iniciantes é confundir partindo do pressuposto com "chutar e torcer". O método exige o oposto: você deve ter a coragem de escrever no papel exatamente o que está assumindo, com a mesma pressão que colocaria numa revisão de código. Cada pressuposto é uma dívida. Se você não paga essa dívida validando antes de usar, ela cobra juros caros mais tarde. Um detalhe que pouca gente menciona: este método é mais eficaz para problemas com alto custo de erro do que para problemas pequenos. Quando o impacto de errar é alto — um lançamento de produto, uma migração de banco de dados, um processo regulatório —, declarar os pressupostos antes de agir economiza, na prática, entre 40 e 60% do tempo total do projeto. O número sobe porque você evita refazer trabalho que já nasceu torto. Quando o impacto é baixo, o overhead de declarar e validar pressupostos pode ser maior que o custo do erro em si. Neste caso, uma abordagem iterativa rápida entrega resultado melhor com menos esforço.

O contra-senso que ninguém avisa é que o método exige muito mais honestidade intelectual no início do que no resto. Você precisa admitir publicamente o que não sabe. A maioria das pessoas trava exatamente aí. Elas pulam para a solução porque se sentir expostas é desconfortável. Mas é nesse ponto exato que o método se separa da adivinhação.

Como aplicar na prática

Vamos direto ao passo a passo. Não tem segredo, só tem disciplina. Passo 1: Declare o problema em uma frase. Não aceite perguntas vagas como "precisamos melhorar o onboarding". Escreva "o onboarding atual leva 47 minutos e 61% dos usuários abandonam antes do passo 3". A diferença entre as duas frases é a diferença entre resolver o problema certo e resolver um problema que você inventou.

Passo 2: Liste todos os pressupostos explícitos. Isso inclui coisas que parecem óbvias. "O usuário tem acesso à internet estável", "a equipe de suporte responde em até 2 horas", "o sistema legado não será descontinuado nos próximos 90 dias". Se você não escreveu, pode não ter pensado. E se não pensou, pode estar errado. Passo 3: Classifique cada pressuposto por risco. Use uma escala simples: baixo, médio, alto. Risco alto é o que, se estiver errado, quebra o resultado. No meu trabalho com sistemas de análise preditiva, identifiquei um pressuposto de risco alto que ninguém tinha mencionado: a premissa de que os dados históricos mantinham a mesma distribuição temporal. Os modelos estavam enviesados porque eu estava assumindoStationaridade onde não existia. Esse foi um aprendizado demorado. Depois passei a testar sempre a estabilidade distributiva antes de qualquer modelo, usando testes de estacionariedade como Dickey-Fuller aumentado. O tempo de modelagem aumentou em 15 minutos, mas evitei duas refações completas que teriam custado dias.

Passo 4: Valide com dados, não com opinião. Para cada pressuposto de risco médio ou alto, encontre uma fonte primária. Se o pressuposto diz "o cliente X consegue integrar via API em 2 semanas", a validação é conversar com o time de engenharia do cliente X, não com o gerente de contas. Opinião é dado de segunda mão. Dado de segunda mão é o que mais causa retrabalho em projetos. Passo 5: Documente o que sobrou e siga em frente. Os pressupostos validados viram base da sua solução. Os que foram falseados viram variáveis que precisam de tratamento diferente. Os que ficaram como incertos devem ter um plano B definido antes de prosseguir. Se não tem plano B para um pressuposto crítico, o projeto não está pronto para começar.

Armadilhas comuns que eu vejo todo dia

Uma das mais frequentes é o que eu chamo de "pressuposto fantasma". É aquele que alguém assume como verdade sem nunca ter registrado. Aparece muito em reuniões onde "todo mundo sabia que aquilo era verdade" mas, na prática, ninguém tinha verificado. A solução mais eficiente para isso é começar qualquer projecto com uma sessão de 30 minutos onde cada participante escreve individualmente seus pressupostos antes de discutir. A escrita individual reduz o efeito de conformidade social que domina discussões em grupo. Outra armadilha é o viés de confirmação. Você lista cinco pressupostos, encontra evidência para três, e para por aí. Os dois que restaram são os mais perigosos. Sempre insista em buscar evidência contra, não só a favor. A falsificação é mais informativa que a confirmação.

Existe ainda um cenário onde o método falha completamente: problemas genuinamente desconhecidos, onde nem os jogadores mais experientes sabem formular pressupostos sensatos. Em investigações de causa raiz de incidentes novos, onde não há baseline histórico, forçar a estrutura de pressupostos pode levar a uma falsa sensação de controle. Nestes casos, uma abordagem exploratória qualitativa, seguida de iterações curtas, entrega mais valor. O método partindo do pressuposto é uma ferramenta, não uma religião. Ele resolve bem problemas estruturados com consequências claras de erro. Ele não resolve tudo, e forçá-lo onde não cabe é tão errado quanto ignorá-lo onde seria útil. O julgamento de onde aplicar é parte do que separa quem usa o método de quem apenas o decorou.