Quanto deve durar uma reunião de diagnóstico?

De 60 a 90 minutos com as pessoas certas costuma ser suficiente para o primeiro recorte. Mais que isso cansa e a qualidade das respostas cai; menos que isso não dá tempo de sair do pedido inicial e chegar ao problema.

Quem precisa estar na sala?

Quem decide, quem sofre com o problema e quem executa o processo hoje. A ausência de quem executa é a falha mais comum, e é justamente essa pessoa que conhece as exceções.

E se o cliente já chega com a solução pronta?

Aceite a solução como informação e volte um passo, perguntando qual problema ela resolveria. Não se trata de descartar a ideia, e sim de entender o que está por trás dela antes de orçar.

Reunião de diagnóstico: como conduzir a primeira conversa

A primeira conversa de um projeto serve para descobrir o problema, não para listar telas. Quem sai dela com um caderno de funcionalidades saiu com o pedido do cliente, que é diferente da necessidade dele, e orçar sobre pedido é a origem mais comum de projeto que entrega tudo o que foi combinado e não resolve nada.

O objetivo concreto da reunião é sair com três coisas: o processo atual descrito, um número que mostre o tamanho da dor e uma hipótese do que está causando.

Comece pelo processo, não pelo desejo

A abertura mais produtiva é pedir uma narrativa concreta:

"Me conta como funciona hoje, do momento em que o pedido chega até o cliente receber. Passo a passo, incluindo as partes que não estão em nenhum sistema."

Essa pergunta produz mais informação que qualquer questionário. Enquanto a pessoa narra, anote três categorias em colunas separadas: etapas, pontos de espera e momentos em que ela usa a palavra "aí a gente", porque "aí a gente confere", "aí a gente manda um zap", "aí a gente lança na planilha" marcam exatamente onde o processo tem remendo.

Duas perguntas de acompanhamento rendem muito:

"Quanto tempo passa entre esta etapa e a próxima?" (separa execução de espera)
"E quando não dá certo, o que acontece?" (revela o volume de exceções)

As perguntas que revelam a dor real

Nem toda pergunta traz informação nova. Estas trazem:

Pergunta	O que revela
"Me conta a última vez que isso deu errado"	Caso concreto no lugar de generalidade
"Quantas vezes por semana isso acontece?"	Frequência real, base do cálculo de retorno
"Quem descobre o problema, e quando?"	Distância entre a falha e a detecção
"O que vocês fazem hoje para contornar?"	Os controles paralelos e o custo escondido
"Se nada mudar nos próximos 12 meses, o que acontece?"	Se existe urgência de verdade
"Quem mais é afetado por isso?"	Se o problema é de uma pessoa ou da empresa
"O que já tentaram antes e não funcionou?"	Evita repetir tentativa cara

A pergunta sobre a última vez que deu errado é a mais valiosa da lista. Ela substitui a descrição idealizada por um caso datado, com nomes, valores e consequências, e é a partir dele que se consegue estimar frequência e custo.

A pergunta sobre os 12 meses testa a urgência. Se a resposta for "a gente continua tocando como está", o projeto provavelmente não vai ter patrocínio interno para sobreviver ao primeiro obstáculo.

Como sair do pedido e chegar ao problema

O cliente quase sempre chega com a solução formulada: "quero um aplicativo", "quero um dashboard", "quero integrar com o ERP". Isso não é problema, é informação sobre como ele pensou até aqui.

A técnica é encadear porquês, sem soar interrogatório:

"Quero um app para os vendedores." , O que eles fariam no app que não conseguem fazer hoje? "Consultar estoque na hora da visita." , E como fazem hoje? "Ligam para o escritório." , O que dá errado nesse caminho? "Fora do horário ninguém atende, e às vezes a informação vem desatualizada." , Quantas vendas por mês travam por isso?

A última resposta é a que decide o projeto. Se forem duas por mês, o app é caro demais. Se forem trinta, o problema é real, e talvez a solução nem seja um aplicativo, mas uma consulta pública por link com o estoque atualizado.

Esse é o uso prático dos 5 porquês fora da análise de falha: chegar da solução pedida ao problema que a motivou.

O que não fazer na primeira reunião

Quatro erros que comprometem o diagnóstico:

Apresentar o próprio portfólio nos primeiros 20 minutos. Consome o tempo em que o cliente estaria mais disposto a narrar.
Prometer prazo ou valor. Número dito na primeira conversa vira âncora e é cobrado depois, mesmo com o escopo ainda desconhecido.
Anotar funcionalidade em vez de problema. "Precisa de relatório de comissão" é pedido; "os vendedores conferem a comissão na mão e reclamam todo mês" é problema.
Falar mais que o cliente. Se você falou mais da metade do tempo, provavelmente saiu sem diagnóstico.

Como fechar a reunião

Os últimos dez minutos definem se a conversa vira projeto. Três movimentos:

Devolva o que entendeu, em voz alta. "Deixa eu repetir para ver se entendi: o pedido leva quatro dias, três deles esperando a conferência de cadastro, e isso causa X por mês." Erros de compreensão aparecem aqui, custando nada.
Combine o que falta medir. Quase sempre falta número. Defina quem levanta, o que levanta e até quando, sem esse dado, a proposta seguinte é chute.
Diga o próximo passo com data. Não "vou pensar e retorno". Um passo concreto, com prazo.

E registre tudo no mesmo dia, enquanto a memória está fresca. Um resumo de uma página com processo atual, dor com número, hipótese de causa e pendências vira a primeira versão do documento-mestre do projeto.

Na Retti Tech, essa primeira conversa segue justamente essa ordem: processo, número, hipótese. É o que permite dizer, às vezes, que o problema não precisa de software, e quando precisa, escrever um escopo que já nasce ligado a um resultado que dá para verificar depois.

O sinal de que a reunião foi boa

Você consegue explicar o problema do cliente para outra pessoa, em três frases, incluindo pelo menos um número. Se não consegue, ainda falta uma conversa, e ela é mais barata agora do que depois do orçamento assinado.