Entreviste-me

Visão Geral

O que as pessoas pedem e o que elas realmente querem são coisas diferentes. Elas pedem "um painel" porque é o que se pede, não porque um painel resolve o problema delas. Elas dizem "faça mais rápido" sem um número para atingir.

O momento mais barato para encontrar essa lacuna é antes que qualquer plano, especificação ou código exista. Assim que você começar a construir, os custos de mudança são reais, e o usuário vai racionalizar a coisa errada em algo "bom o suficiente". O desalinhamento fica travado.

Essa habilidade fecha a lacuna antes que custe qualquer coisa. As outras habilidades da fase de Definição assumem que você já sabe mais ou menos o que quer: idea-refine gera variações a partir de uma ideia, spec-driven-development escreve os requisitos, doubt-driven-development testa um plano sob estresse depois que você o esboçou. Entreviste-me é a parte anterior a tudo isso, onde você faz uma pergunta por vez, com sua melhor suposição anexada, até que você consiga prever o que o usuário vai dizer antes que ele diga.

Quando Usar

Aplique esta habilidade quando:

• A solicitação estiver faltando pelo menos um dos seguintes: quem é o usuário, por que ele quer isso, como é o sucesso, qual é a restrição limitante
• A solicitação é convencional em vez de específica ("construa X para mim", "faça mais rápido") e você não consegue desempacotar a convenção sem adivinhar
• Você for tentado a começar com suposições que não foram reveladas
• O usuário não disse qual valor ele está otimizando quando dois valores razoáveis estão em tensão (simplicidade vs. flexibilidade, custo vs. velocidade)
• O usuário invoca explicitamente: "entreviste-me", "me interrogue", "antes de começarmos, temos certeza?", "teste meu raciocínio"

Quando NÃO usar:

• A solicitação é inequívoca e autônoma ("renomeie esta variável", "corrija este erro de digitação")
• O usuário pediu explicitamente velocidade em vez de verificação
• Solicitações puras de informação ("como X funciona?", "o que este código faz?")
• Operações mecânicas (renomeações, formatações, movimentações de arquivos)
• Você já tem ≥95% de confiança; releia a condição de parada abaixo antes de assumir que não tem

Carregando Restrições

Esta habilidade precisa de um usuário ativo e responsivo. Não invoque em contextos não interativos como pipelines de CI, execuções agendadas, /loop ou loops autônomos. Se você estiver em um desses e a solicitação for subespecificada, sinalize isso como um bloqueador para o usuário em vez de adivinhar.

O Processo

Etapa 1: Hipotetize, com um número de confiança

Antes de perguntar qualquer coisa, anote sua melhor leitura atual do que o usuário quer em uma frase, mais um número de confiança honesto (0–100%):

HYPOTHESIS: You want a way to answer "how are we doing?" in standup, and "dashboard" was the convention that came to mind.
CONFIDENCE: ~30% — missing: who it's for, what "metrics" means in context, and what success looks like

O número força a honestidade. Se você escreveu um número alto, mas não consegue prever as reações do usuário às próximas três perguntas que faria, o número está errado. Comece no nível de confiança que você pode defender.

Quando a confiança for inferior a ~70%, anexe um breve motivo na mesma linha — o que ainda está em aberto ou faltando. Isso diz ao usuário exatamente o que a entrevista precisa revelar e impede que o número seja um sinal vago.

Etapa 2: Faça uma pergunta por vez, cada uma com uma suposição anexada

Formato:

Q: <one focused question>
GUESS: <your hypothesis for the answer, with the reasoning that produced it>

Espere a reação do usuário antes de fazer a próxima pergunta.

Por que uma por vez, não em lote:

• O usuário não pode reagir às suas hipóteses se você as enterrar em uma lista
• Lotes incentivam a leitura superficial e a obtenção de respostas
• A terceira pergunta geralmente depende da resposta da primeira; fazer todas de uma vez trava o enquadramento errado
• A energia do usuário para pensar cuidadosamente é finita; gaste-a uma pergunta por vez

Por que anexar uma suposição:

• O usuário reage mais rápido a uma suposição errada do que gera uma resposta do zero
• Isso o compromete com uma hipótese sobre a qual você pode estar visivelmente errado, o que o mantém honesto
• Isso revela suas suposições, que é o que a entrevista deve expor

O risco aqui é um usuário educado concordar com sua suposição para ser agradável. Mitigue isso estando visivelmente disposto a errar e, ocasionalmente, suponha em uma direção sobre a qual você espera que o usuário retruque.

Etapa 3: Ouça por "querer vs. deveria querer"

As respostas mais perigosas são aquelas em que o usuário diz o que uma resposta pensada soa como em vez do que ele realmente quer. Observe: