Entrevistarquemfazotrabalhomanualantesdeautomatizar

Num escritório de advocacia, os advogados já usavam IA para ler dossiês, cada um no seu chat, com um conjunto de instruções escritas pelo próprio escritório. Quando fui construir o agente jurídico para eles, a pergunta era qual parte desse trabalho automatizar primeiro.

Eu não perguntei como eles queriam o produto. Documentei como eles já trabalhavam, a partir das telas de uma sessão real. Desse retrato saíram os requisitos que mais se perdem numa migração: a conclusão binária (“eu ajuizaria hoje?”), a lacuna documental acompanhada da defesa que ela abre para o outro lado, a obrigação de declarar o que não se conseguiu ler. Nenhum deles teria saído de “o que você gostaria que o sistema fizesse?”.

A segunda rodada veio com o produto no ar, quando levei ao advogado que o usa uma lista de pendências. A devolutiva dele mudou regras que eu achava fechadas.

Uma delas era pequena e constrangedora. A esteira de casos tinha um alerta amarelo, e a legenda da tela dizia “7 dias úteis”. O código contava 10 dias corridos. Quem apontou a diferença foi a pessoa que trabalha com prazo todo dia. Outra era de fundo: o parecer que ele usava como referência de qualidade era deliberadamente conservador em prognóstico. Se a máquina saísse mais afirmativa do que ele, isso não era uma melhoria. Era um erro a corrigir. A frase virou critério de avaliação do sistema.

Nada disso teria aparecido se eu tivesse perguntado “o que você está achando do produto?”. Apareceu porque a conversa foi sobre o trabalho dele, com o material dele na mesa. Este artigo é sobre como provocar esse tipo de conversa com quem faz o trabalho manual que você quer automatizar: quem chamar, o que perguntar, o que não perguntar e o que fazer com as anotações.

Para que serve uma entrevista

Entrevista é boa para entender comportamento passado, contexto e motivação: como a pessoa resolve o problema hoje e o que já tentou.

Entrevista é ruim para:

• Prever comportamento futuro. “Você pagaria por isso?” gera um sim barato.
• Validar usabilidade. Para saber se a pessoa consegue usar uma tela, coloque a tela na frente dela e observe.
• Medir. Poucas conversas mostram padrões e hipóteses, não percentuais.

Para quem quer automatizar, isso tem uma consequência prática. O que vale automatizar primeiro é o que a pessoa faz hoje, do jeito que faz, com o custo que tem. Não é o que ela imagina que um sistema poderia fazer. Por isso a entrevista olha para trás, e não para o produto.

Recrutamento: quem você ouve decide o que você aprende

Se o recrutamento chamar as pessoas erradas, o melhor roteiro do mundo não salva. Os critérios que considero mais importantes:

• Quem faz, não quem pede. O gestor sabe que o trabalho existe. Quem executa sabe onde ele trava, e é ali que a automação vai ou não funcionar.
• Comportamento, não demografia. “Protocolou uma execução no último mês” filtra melhor do que “advogado de 30 a 45 anos”.
• Recência. Quem viveu o problema na semana passada lembra dos detalhes.
• Fugir do usuário favorito, e incluir quem desistiu. Um representa pouco a média; o outro explica o que nenhum usuário ativo explica.

Um produto feito para um escritório só tem um limite óbvio aqui: o universo de usuários é pequeno, e uma pessoa concentra boa parte do conhecimento. Isso torna ainda mais importante separar o que ela faz do que ela diz que faz, porque não há uma segunda amostra para desempatar.

O roteiro

O roteiro é uma lista de temas, não um questionário lido em voz alta. Para conversas de 30 a 45 minutos:

1. Abertura (2 a 3 min). Quem você é, para que serve a conversa, pedido para gravar.
2. Contexto (5 min). O papel da pessoa, a rotina, onde o tema entra no dia dela.
3. A última vez (15 a 20 min). Reconstruir, passo a passo, a última situação real em que o problema apareceu.
4. Tentativas e custos (5 a 10 min). O que já tentou, o que usa hoje, o que a fez trocar.
5. Fechamento (3 min). “Tem algo que eu deveria ter perguntado e não perguntei?”

Com um produto já em uso, a “última vez” ganha uma forma melhor: o último caso real. As pendências que levei ao advogado não eram perguntas abstratas sobre o produto. Eram situações concretas da esteira, e ele respondeu a cada uma com o que faz na prática.

Pergunte sobre o passado, não sobre o futuro

O livro The Mom Test, de Rob Fitzpatrick, resume a ideia: sua mãe vai dizer que a sua ideia é ótima, porque ela te ama. Uma boa pergunta é aquela que nem a sua mãe consegue responder com uma mentira gentil. Três regras:

• Fale sobre a vida da pessoa, não sobre a sua ideia.
• Pergunte sobre situações específicas do passado, não sobre intenções futuras.
• Fale menos e escute mais.

Na prática, a diferença está na formulação. Os exemplos abaixo são ilustrativos:

Pergunta ruim	Por que é ruim	Pergunta boa
Você usaria um sistema que redige a petição?	Pede uma previsão, e a resposta educada é sim	Me mostra a última petição que você protocolou. De onde veio cada parte dela?
Você acha que isso seria útil?	Pede opinião sobre a sua ideia	Como você resolve isso hoje?
Quanto você pagaria por isso?	Preço hipotético não é preço	Você já paga por alguma ferramenta para isso? Qual, e por quê?
Você tem dificuldade para controlar os prazos?	Sugere a resposta e cabe num sim ou não	Qual foi o último prazo que apertou? Como você descobriu?
O que você gostaria que existisse?	Transfere o design para o entrevistado	O que você fez na última vez que isso deu errado?
Com que frequência você faz isso?	Gera uma média inventada	Quando foi a última vez? E a vez anterior?

A pergunta mais útil é quase sempre alguma versão de “me conta a última vez que…”, ou, melhor ainda, “me mostra”.

O pedido esconde a necessidade

Uma variação do mesmo problema: o pedido pronto. O escritório pediu, logo no começo, que “os agentes aprendessem”. Tomado ao pé da letra, o pedido levaria a treinar um modelo. Pesquisei esse caminho e ele não fechava: sem oferta para os modelos atuais, caro de manter e arriscado com dado de cliente.

Por trás do pedido havia outra pergunta: como o sistema fica melhor com o nosso jeito de trabalhar? Essa tinha outra resposta. O modelo fica fixo e o contexto evolui: lições curtas aprendidas das correções do escritório, propostas pela máquina e promovidas por um sócio. Tratar o pedido como hipótese, e não como requisito, foi o que abriu essa alternativa.

Os vieses que mais estragam uma conversa

Viés de confirmação

Você chega com uma hipótese e presta mais atenção no que a confirma. Eu vivi a versão automatizada desse viés: uma auditoria automática do projeto marcou como defeito crítico a página de trabalho que a minuta leva no fim (“excluir antes do protocolo”). Pelo padrão do escritório, essa página é justamente o que a casa manda fazer. O critério da auditoria era a minha suposição, não a prática dele. A correção foi manter a página e limpar só o jargão do corpo.

O antídoto é escrever a hipótese antes da rodada e procurar ativamente o que a derrubaria.

Pergunta indutora e viés de cortesia

“Não seria mais fácil se isso fosse automático?” já contém a resposta. E elogio, entusiasmo e “com certeza usaria” são o sinal mais fraco numa entrevista. Perguntas curtas e neutras (“como foi?”, “o que aconteceu depois?”) e a volta ao comportamento resolvem os dois.

Durante a conversa

• Duas pessoas, papéis separados. Uma conduz, a outra anota.
• Silêncio. Depois de uma resposta, espere três segundos antes da próxima pergunta.
• Peça para mostrar. Uma peça, uma planilha, um documento real valem mais do que qualquer descrição.
• Anote a palavra dele, não a sua. O vocabulário é dado.

O último ponto teve efeito direto no produto. Depois do manual do advogado, a interface trocou de vocabulário: “Aprovar” virou Homologar, “briefing” virou Orientação para a peça, e os tipos de análise ganharam os nomes que ele usa. A peça passou a seguir regras de linguagem que só alguém da prática explicita: os nomes das partes mudam conforme a classe da ação e nunca se misturam, a lei aparece sempre por extenso, e é “contrarrazões”, nunca “contraminuta”.

O mesmo princípio vale fora do Direito. Numa distribuidora de lubrificantes, o pedido chegava como foto de uma anotação no WhatsApp, e alguém redigitava tudo do outro lado. O ponto de partida não foi perguntar como os compradores queriam pedir, e sim descrever o que a operação já fazia. O sistema manteve o gesto de fotografar e tirou a redigitação, e aprendeu o vocabulário do balcão: “balde” é 20 litros, “tb” é tambor.

Sintetizar logo depois de cada conversa

A memória de uma conversa se degrada rápido. Reserve 15 minutos logo depois para uma síntese curta, separando fatos (o que a pessoa fez e contou), regras (o que ela explicitou como obrigatório), vocabulário e perguntas abertas.

Fatos 3

• A legenda prometia 7 dias úteis; o sistema contava 10 corridos
• Um campo que eu esperava na planilha de lote é cadastro em outro sistema
• A página “excluir antes do protocolo” no fim é padrão da casa

Regras 3

• Máquina mais afirmativa que o advogado é erro, não refinamento
• Na dúvida, monitória, com o motivo
• Recurso dispensado com fundamento nunca vira peça

Vocabulário 3

• Aprovar → Homologar
• Briefing → Orientação para a peça
• Contrarrazões, nunca contraminuta

Perguntas abertas 3

• Os nomes das partes na busca e apreensão
• O valor da causa nesse tipo de ação
• O fecho padrão muda conforme o tipo de peça?

As perguntas abertas não ficaram num caderno. Foram anotadas dentro das próprias instruções que redigem aquele tipo de peça, para que a próxima pessoa a mexer ali saiba que a regra ainda não foi validada.

O ciclo inteiro

Entrevista não é um evento isolado. É um ciclo curto, que se repete enquanto cada rodada ainda ensina algo novo.

1. 01Levar o real

   Casos, telas e documentos do próprio usuário, não uma apresentação.

2. 02Perguntar pela prática

   O que você faz nesse caso? Por que essa página existe?

3. 03Sintetizar

   Fatos, regras, vocabulário e perguntas abertas, no mesmo dia.

4. 04Devolver no produto

   Cada regra vira comportamento; cada dúvida fica anotada onde será usada.

O que eu faria diferente

• Levar o produto ao usuário mais cedo, com o material dele. O erro da legenda e o da auditoria só apareceram quando o advogado confrontou o sistema com a própria prática. Uma rodada assim antes teria custado menos.
• Perguntar “por que isso existe?” antes de chamar algo de defeito. A página de trabalho no fim da minuta era uma decisão da casa. Eu a classifiquei sem perguntar.
• Conferir o documento do usuário como confiro o meu. O manual dele foi a melhor fonte do projeto, e ainda assim tinha duas imprecisões. Fonte boa também se verifica.

Checklist para a próxima rodada

• A triagem filtra por comportamento recente, e não por perfil?
• A conversa parte de um caso, um documento ou uma tela real do usuário?
• As hipóteses do time foram escritas antes das conversas?
• O roteiro pergunta sobre a última vez, e não sobre o que a pessoa faria?
• Os pedidos prontos (“quero que aprenda”) foram tratados como hipótese?
• Existe alguém só para anotar, e as palavras do usuário foram anotadas literalmente?
• O que a pessoa diz que faz foi conferido com o que ela de fato produz?
• Cada pergunta aberta ficou registrada no lugar onde a resposta vai ser usada?

Se o time sair da rodada com uma lista de desejos e nenhuma história concreta de trabalho feito, as entrevistas não falharam por falta de gente. Falharam na pergunta.