Entrevistar

Entrevistar

Visão geral

O que as pessoas pedem e o que elas realmente querem são coisas diferentes. Pedem "um dashboard" porque é o que se costuma pedir, não porque um dashboard resolve o problema. Dizem "deixe mais rápido" sem um número a atingir. O momento mais barato para encontrar essa lacuna é antes de existir qualquer plano, spec ou código — depois que a construção começa, o custo de mudar é real e o desajuste fica travado.

Esta skill fecha a lacuna antes que ela custe algo: uma pergunta por vez, sempre com o seu melhor palpite anexado, até você conseguir prever o que o usuário vai responder antes de ele responder. As demais skills da fase Definir assumem que você já sabe aproximadamente o que quer: refinar-ideia gera variações, especificar escreve os requisitos, questionar estressa um plano já rascunhado. entrevistar vem antes de todas elas.

Quando usar

• Falta ao pedido pelo menos um destes: quem é o usuário, por que ele quer isso, o que é sucesso, qual é a restrição determinante
• O pedido é convencional em vez de específico ("construa X", "deixe mais rápido") e você não consegue desdobrar a convenção sem chutar
• Você está tentado a começar com suposições que não verbalizou
• O usuário não disse qual valor está otimizando quando dois valores razoáveis estão em tensão (simplicidade vs. flexibilidade, custo vs. velocidade)
• Invocação explícita: "me entreviste", "questione meu raciocínio", "antes de começar, temos certeza?"

Quando NÃO usar: pedidos inequívocos e autocontidos ("renomeie esta variável"), pedidos puros de informação, operações mecânicas, ou quando você já tem ≥95% de confiança (releia o critério de parada antes de assumir que não tem). Exige usuário vivo e responsivo — nunca invoque em contextos não interativos (CI, execuções agendadas, loops autônomos); nesses casos, sinalize o pedido subespecificado como bloqueio em vez de chutar.

O fluxo

Etapa 1: Hipótese, com número de confiança

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

HIPÓTESE: Você quer responder "como estamos indo?" na daily, e "dashboard" foi a convenção que veio à mente.
CONFIANÇA: ~30% — falta: para quem é, o que "métricas" significa aqui e o que é sucesso.

O número força honestidade: se você escreveu um número alto mas não consegue prever as reações do usuário às três próximas perguntas, o número está errado. Abaixo de ~70%, anexe na mesma linha o motivo — o que ainda está em aberto. Isso diz ao usuário exatamente o que a entrevista precisa revelar.

Etapa 2: Uma pergunta por vez, cada uma com palpite anexado

P:       <uma pergunta focada>
PALPITE: <sua hipótese de resposta, com o raciocínio que a produziu>

Espere a reação antes da próxima pergunta.

Por que uma por vez: o usuário não reage às suas hipóteses se elas vêm enterradas numa lista; lotes induzem leitura dinâmica e respostas rasas; a terceira pergunta costuma depender da resposta à primeira; a energia do usuário para pensar com cuidado é finita.

Por que anexar o palpite: reagir a um palpite errado é mais rápido do que gerar uma resposta do zero; o palpite compromete você com uma hipótese na qual pode estar visivelmente errado; e expõe as suas suposições — que é o que a entrevista existe para revelar. O risco é o usuário educado concordar por gentileza; mitigue mostrando-se visivelmente disposto a errar e, de vez em quando, chutando numa direção em que espera contestação.

Etapa 3: Escute o "quero vs. deveria querer"

As respostas mais perigosas são as que soam como uma resposta pensada em vez de expressar o que o usuário quer. Fique atento a:

• Respostas que imitam discurso de boa prática ("quero que seja escalável", "arquitetura limpa") sem especificidade
• Respostas que se apoiam em convenção ("do jeito que a maioria dos apps faz", "a abordagem padrão")
• Frases como "eu deveria...", "acho que é o esperado...", "boas práticas dizem que..."
• Buzzwords como objetivo — quando "moderno", "escalável", "robusto" substituem um resultado concreto

Quando ouvir isso, a pergunta certa é:

"Se você não precisasse justificar isso para ninguém, o que você realmente iria querer?"

Essa única pergunta costuma render mais que as cinco anteriores.

Etapa 4: Reformule a intenção nas palavras do usuário

Quando a confiança estiver alta, devolva o que você agora acha que o usuário quer. Curto (5–8 linhas), na linguagem dele, estruturado para confirmação linha a linha:

Eis o que agora entendo que você quer:

- Resultado:      <uma linha>
- Usuário:        <uma linha — quem se beneficia>
- Por que agora:  <uma linha — o que mudou>
- Sucesso:        <uma linha — como saberemos que funcionou>
- Restrição:      <uma linha — o limite determinante>
- Fora do escopo: <uma linha — o que explicitamente NÃO faremos>

Sim / não / refinar?

Incluir "Fora do escopo" é inegociável. Metade do desalinhamento é discordância silenciosa sobre o que não está sendo construído.

Etapa 5: Confirme — um "sim" explícito, não "faça como achar melhor"

O portão é um "sim" explícito. Não contam como sim:

• "Faça como achar melhor." → Delegação: o usuário também não tem 95% de confiança. Reapresente com duas opções concretas como escolha.
• "Parece bom." / "Beleza, vamos." → Ambíguo ou saída educada. Pergunte: "Refinaria alguma coisa?" Silêncio não é confirmação.
• Silêncio seguido de "ok, pode começar." → O usuário desistiu da entrevista, não convergiu. Pare e pergunte o que você deixou passar.

Se ele corrigir, incorpore a correção e reformule. Repita até obter o sim explícito.

O critério de parada dos 95%

Você terminou quando responde sim a esta pergunta:

Consigo prever a reação do usuário às três próximas perguntas que eu faria?

Se sim, há entendimento compartilhado: pare de entrevistar e produza a reformulação. Se não, faça a próxima pergunta. É um teste verificável, não uma sensação. E tem um piso: se após várias rodadas você ainda não consegue prever, isso é informação sobre o pedido, não motivo para insistir. Diga: "Fiz X perguntas e ainda não consigo prever suas reações. Algo fundamental está faltando. Quer dar um passo atrás?"

Saída

O entregável é uma declaração de intenção confirmada: a reformulação da Etapa 4 com o sim explícito da Etapa 5. Specs, planos e listas de tarefas ficam a jusante e consomem essa intenção. Se o usuário quiser persistir a intenção (projeto multissessão, passagem para outro colaborador), ofereça salvar em docs/intencao/[tema].md — só salve se ele confirmar.

Exemplo

Sem entrevistar: o usuário pede "construa um dashboard das nossas métricas" e o agente já propõe bibliotecas de gráficos — assumindo em silêncio para quem é, quais métricas e o que é sucesso.

Com entrevistar:

Agente:
HIPÓTESE: Você quer responder "como estamos indo?" na daily, e "dashboard" veio à mente por ser a resposta convencional.
CONFIANÇA: ~30% — falta: para quem é, quais métricas e o que é sucesso.

P:       Quando você diz "como estamos indo?", quem pergunta — você, o time na daily, ou alguém acima (gestor, executivo)?
PALPITE: o time na daily, porque "nós" costuma delimitar assim. Se for para executivos, as métricas e o enquadramento mudam muito.

Usuário: Na verdade é para mim. Vivo perdendo o controle de quais experimentos estão rodando e do sinal inicial de cada um.

Agente:
Leitura atualizada: não é dashboard de time — é um rastreador pessoal de experimentos. Confiança: ~60% — falta: o que é "sinal inicial" e o que é pronto.

P:       A lacuna é não saber quais experimentos existem, ou não conseguir ver os resultados num só lugar?
PALPITE: a segunda — você tem a lista em algum lugar, mas os resultados vivem em cinco ferramentas.

Usuário: A primeira. Eu literalmente não tenho a lista; está espalhada em vários documentos.

Duas perguntas depois, o pedido real não é "um dashboard" — é "uma lista". Artefato diferente, escopo diferente. O dashboard teria sido a coisa errada.

Interação com outras skills

• refinar-ideia: a jusante — se a intenção confirmada é "quero X mas não sei escopar", passe para refinar-ideia gerar variações contra a intenção agora explícita.
• especificar: a jusante — se a intenção confirmada é concreta, passe para especificar colocá-la por escrito.
• planejar: dois passos a jusante (depois da spec).
• questionar: extremo oposto da linha do tempo — entrevistar extrai intenção pré-decisão; questionar revisa artefatos pós-decisão.
• fontes-oficiais: ortogonal — entrevistar esclarece o que o usuário quer; fontes-oficiais verifica fatos de framework.

Racionalizações comuns

Racionalização	Realidade
"O pedido está claro o suficiente"	Se você não consegue escrever o resultado desejado em uma frase agora, não está claro. Rode a Etapa 1 antes de decidir.
"Muitas perguntas desperdiçam o tempo dele"	4–6 perguntas dirigidas custam pouco. Construir a coisa errada custa muito — e quem paga é o usuário.
"Descubro construindo"	Após existir código, o custo de mudar é 10x. Descoberta durante a implementação é retrabalho.
"Ele disse 'faça como achar melhor', então decido eu"	Isso é delegação, não decisão. Reapresente duas opções concretas como escolha.
"Vou dar várias opções para ele escolher"	Opções funcionam quando o usuário já sabe o que quer e escolhe trade-offs. Ele ainda não sabe. Listar opções amplia a busca; perguntar estreita.
"Anexar meu palpite é induzir a resposta"	Induzir é o objetivo: reagir é mais rápido que gerar. O risco é bajulação, não indução; mitigue mostrando-se disposto a errar.
"Já conversamos o bastante, entendi"	Teste: você prevê as reações às três próximas perguntas? Se não, ainda não entendeu.
"O usuário disse sim, acabou"	Se o sim veio após reformulação vaga ou um "parece bom", é um sim oco. Reformule concretamente e reconfirme.

Sinais de alerta

• Três ou mais perguntas numa única mensagem: isso é lote, não entrevista
• Pergunta sem sua hipótese anexada: isso é questionário, não compromisso
• Aceitar "faça como achar melhor" como resposta final
• Produzir spec, plano ou lista de tarefas antes do sim explícito à reformulação
• Perguntas do tipo "qual seria a boa prática?" em vez de "o que você realmente quer?"
• Aceitar resposta-vitrine ("escalável", "limpo", "moderno") sem sondar se é o que o usuário quer de fato
• Três ou mais rodadas sem a confiança subir visivelmente: você está fazendo as perguntas erradas — recue e reenquadre
• Confiança abaixo de ~70% sem motivo anexado: o usuário não pode ajudar a fechar uma lacuna que não conhece
• Salvar o documento de intenção antes da confirmação (o documento implica um sim que não foi dado)
• Pular a linha "Fora do escopo" na reformulação

Portão de aprovação

Apresente: a reformulação da Etapa 4 (Resultado / Usuário / Por que agora / Sucesso / Restrição / Fora do escopo) nas palavras do usuário. O humano aprova: a declaração de intenção completa, com um "sim" explícito — "parece bom", "faça como achar melhor" e silêncio não contam. Só avance após aprovação explícita. Qualquer correção volta ao ciclo de reformulação antes de seguir para refinar-ideia ou especificar.

Verificação

• Uma hipótese explícita com número de confiança foi declarada no primeiro turno
• Toda confiança abaixo de ~70% veio acompanhada do motivo em uma linha
• As perguntas foram feitas uma por vez, cada uma com o palpite do agente anexado
• Ao menos uma sondagem "o que você realmente iria querer?" rodou quando o usuário deu resposta-vitrine ou convencional
• Uma reformulação concreta (Resultado / Usuário / Por que agora / Sucesso / Restrição / Fora do escopo) foi devolvida ao usuário
• O usuário confirmou a reformulação com um sim explícito
• No ponto de parada, o agente conseguia prever as reações às três próximas perguntas
• Qualquer passagem para skill a jusante (refinar-ideia, especificar) foi enquadrada na intenção confirmada, não no pedido original subespecificado