Imagine A Seguinte Situação

Como usar a técnica de scenario para resolver problemas técnicos

A expressão "imagine a seguinte situação" não é apenas um recurso de comunicação. É uma ferramenta prática que engenheiros, técnicos e consultores usam há décadas para explicar falhas complexas, treinar equipes e validar soluções antes de implementá-las. O problema é que a maioria das pessoas usa isso de forma improvisada, sem estrutura, e o resultado é uma explicação que confunde mais do que esclarece. Eu já passei por isso várias vezes. Quando eu era responsável por resolver incidentes em servidores de produção, eu via colegas tentarem explicar um bug usando "imagine que..." sem contexto claro. O time perdia tempo imaginando cenários irreais enquanto o problema real continuava rodando. A técnica funciona, mas só quando aplicada com precisão.

Imagine a seguinte situação: o problema real

O primeiro passo é descrever o cenário com dados concretos, não com abstrações. Se você vai usar a técnica em uma apresentação técnica, em um relatório de incidente ou em documentação, comece com os fatos mensuráveis. Por exemplo, em vez de dizer "o sistema estava lento", você pode estruturar assim: "Imagine a seguinte situação — estamos às 14h30, o throughput do banco de dados caiu de 12 mil queries por segundo para 800, e o tempo de resposta das APIs saiu de 45ms para 3 segundos. Os logs mostram lock contention na tabela de usuários." Isso faz diferença porque define limites claros. Quem está ouvindo ou lendo sabe exatamente onde o problema começa e onde termina. Sem essa delimitação, a discussão se perde em suposições. O que eu aprendi na prática é que a técnica é mais eficaz quando o cenário tem três componentes obrigatórios: o estado normal anterior ao problema, o gatilho que mudou esse estado, e o efeito observável no sistema ou no processo. Faltar qualquer um desses elementos transforma a explicação em especulação.

Por que a técnica falha na maior parte das vezes

O erro mais comum é usar "imagine a seguinte situação" como atalho para não fazer o trabalho de diagnóstico. Quando você ainda não tem dados, criar um cenário hipotético não resolve nada — apenas mascara a falta de informação. Eu vi times inteiros gastarem duas reuniões inteira debaterem cenários imaginários porque não tinham coletado logs ou métricas suficientes. No final, o problema era um índice de banco de dados desatualizado que poderia ter sido identificado em quinze minutos. Outro problema frequente é a falta de especificidade. Frases como "o sistema ficou lento" ou "algo deu errado" não são cenários. São vagas generalizações que não permitem que ninguém reproduza, analise ou resolva o problema. Um cenário útil precisa conter timestamps, identificadores de recurso, valores numéricos e condições reproduzíveis. Também existe o risco de criar cenários que soam plausíveis mas são tecnicamente impossíveis. Já me deparei com colegas propondo explicações baseadas em situações que violavam as restrições conhecidas do sistema. Por exemplo, sugerir que um deadlock ocorresse em uma transação que, pela arquitetura definida, nunca faria lock em múltiplas tabelas simultaneamente. Isso gera confusão e desvia o foco do problema real.

Como aplicar a técnica de forma estruturada

Na prática, eu sigo um fluxo simples que funciona para a maioria dos contextos técnicos. Primeiro, defino o que é o comportamento esperado. Segundo, descrevo o que aconteceu de diferente. Terceiro, listo os dados que tenho disponíveis. Quarto, proponho hipóteses que sejam testáveis com esses dados. Quinto, indico como cada hipótese pode ser validada ou descartada. Um exemplo prático: durante um incidente de latência em um serviço de autenticação, eu escrevi no canal de emergência: "Imagine a seguinte situação — entre 09h e 09h47, o serviço de auth apresentou 23% de requests com timeout acima de 5 segundos. O padrão de erro é intermitente, não contínuo. Os logs mostram que os timeouts ocorrem predominantemente contra o backend de validação de tokens, não contra o banco de dados principal. Tenho acesso aos traces do Jaeger. Vou testar se há perda de pacotes na rede entre o serviço de auth e o validador." Esse formato economiza tempo porque já direciona a investigação para uma ação específica. Quem lê não precisa perguntar "e agora o que a gente faz?". O próximo passo está implícito na última frase.

Para quem usa essa técnica em documentação ou treinamento, a regra é a mesma: sempre termine com uma consequência ou ação testável. Cenários que terminam em aberto são memórias ruins que ninguém consulta depois.

Quando a técnica não deve ser usada

Existem situações em que "imagine a seguinte situação" piora a comunicação. Em incidentes ativos de alta severidade, onde cada minuto conta, a tendência natural é querer explicar o problema de forma narrativa. Mas nesse contexto, o time de resposta precisa de dados brutos, não de enredos. Um relatório de estado com os fatos consolidados é mais útil do que qualquer cenário bem escrito. Também não funciona bem em contextos onde o público-alvo não tem familiaridade técnica suficiente para avaliar a plausibilidade do cenário. Se você está explicando um problema de API para stakeholders de negócio, usar jargão técnico dentro de um cenário hipotético gera mais confusão do que clareza. Nesse caso, traduza o cenário para consequências de negócio — tempo de inatividade, impacto em receita, risco de compliance — em vez de detalhes de implementação. Um limitante importante que poucas pessoas consideram: a técnica depende da qualidade da memória e da atenção de quem ouve. Se o cenário tiver muitas variables simultâneas, o cérebro humano tem dificuldade de manter todas elas em mente ao mesmo tempo. O limite prático é cerca de cinco a sete variáveis. Além disso, a carga cognitiva aumenta exponencialmente com cada variável adicional.

Alternativas quando a técnica não é suficiente

Se o problema que você está tentando descrever envolve muitas variáveis interconectadas, considere usar diagramas de sequência ou timelines visuais em vez de texto descritivo. Um desenho simples mostrando o fluxo de requisições entre serviços pode comunicar em dez segundos o que levaria dois parágrafos para escrever. Ferramentas como Mermaid,draw.io ou até um quadro branco funcionam bem. Para problemas recorrentes, a melhor alternativa é transformar o cenário em um procedimento de diagnóstico padronizado. Ao invés de explicar o problema de novo toda vez, crie um checklist que leve o investigador do sintoma à causa raiz. Isso elimina a necessidade de reinventar a explicação a cada ocorrência. A técnica de "imagine a seguinte situação" continua sendo uma das mais úteis disponíveis quando aplicada com rigor. O diferencial entre quem domina e quem apenas repete o formato está na capacidade de transformar uma ideia abstrata em algo testável, mensurável e acionável. O resto é apenas ruído.