E as Perguntas?

Você percebe que são muitas possibilidades de situações e cada uma só é identificada com boas perguntas. Não podemos ter medo de perguntar, e nos aprofundarmos no entendimento da necessidade do cliente.

Se possível, tente se preparar antes de conversar com o Cliente, mas nem tente definir antecipadamente todas as perguntas na sequência, pois normalmente a resposta da primeira pergunta mudará tudo o que você havia previsto.

Algumas perguntas dependerão da resposta anterior, e outras serão independentes.

A principal função das Perguntas é entender o que o cliente realmente precisa. Uma grande parte das solicitações não resolveria o problema do cliente se fosse implementada do modo que foi inicialmente solicitado, ou geraria trabalho extra, ou reduziria a segurança, etc. Os motivos são os citados no bloco anterior: a falta de conhecimento do Cliente.

Mas como identificar o que o cliente realmente precisa, se nem ele sabe?
O melhor processo é conhecido como: “Os 5 Por ques?”
Existe muita documentação sobre este método de levantamento, e a sugestão é que sejam pesquisadas outras fontes.

Resumidamente, devemos fazer perguntas para entender por que o cliente está solicitando algo. Essas perguntas poderiam ser simplesmente “Por que?” para cada resposta, mas na prática não fazemos isso. Além disso, o método fala em 5, mas é só uma referência, podendo ser mais ou menos, conforme cada situação.

O principal é levar o cliente a retroceder até ele entender qual é a Causa Raiz do que está pedindo. Você pode achar que isso será chato para o cliente, mas ele ficará feliz em perceber que o problema está em outro ponto do sistema ou do processo. Normalmente, resolver a Causa Raiz do problema é mais simples, tanto para o Sistema quanto para o processo do cliente.

Exemplo real: Um cliente pediu uma informação nova em um relatório. Com o 1º Por que, identificamos que ele precisava informar isso para o Fornecedor. Com o 2º Por que entendemos que era quando ele estava no telefone com o Fornecedor fazendo a Cotação. No 3 º Por que, ele concordou que esta informação ficaria muito melhor na própria tela da Cotação.

Essa metodologia dos 5 Por ques normalmente não é utilizada por pessoas leigas, mas é talvez a mais importante. Com conhecimento, você perceberá o momento de iniciar, de parar, e talvez de voltar a fazer para outra demanda ou situação.

Mas também precisamos entender o que o cliente está solicitando, e pensar além do que o cliente está vislumbrando.

O que acontece na maioria das vezes é o cliente achar que aquela solução será mágica, e que fará automaticamente o que ele precisa, mesmo que ele não tenha previsto isso.
Precisamos imaginar várias situações possíveis, e perguntar o que deve acontecer em cada situação.
Exemplo:

• E se o mês tiver 31 dias? E se for menor que hoje? E se for a data de Hoje?
• E se o usuário não informar o Código? E se não informar a Qtd? E se não informar a Unidade de Medida? E se a Unidade de Medida for diferente do que está definida para o Item? E se o Item estiver Inativo ? E se o Item não Movimenta Estoque ? …

Não temos como descrever as possibilidades de perguntas, pois são infinitas, e vão variar a cada Solicitação. Pode ser apenas um cenário, ou centenas, e o cliente dificilmente pensou nisso.

Muitas vezes a primeira definição é, por exemplo: Sempre será Verde! E você pergunta: E pode ser Amarelo? E o cliente confirma que pode ser Amarelo. Agora já temos 2 possibilidades. E você continua perguntando: Pode ser Branco? Algumas vezes o cliente responde que isso é uma exceção, e você precisa perguntar: Mas o que devemos fazer nessa situação? A resposta normalmente é: Precisamos controlar isso…

Esse conhecimento de que o cliente não percebe as possibilidades é muito importante, e somos nós que precisamos fazê-lo entender que podem ocorrer e definir o que fazer em cada situação.

Outro grave problema que encontramos frequentemente é o cliente solicitar o que ele Quer, sem avaliar o que realmente ele Precisa. Quando usamos os 5 Por ques, a resposta pode ser: “Porque eu quero”.
Algumas vezes a Solicitação é para ficar como ele estava acostumado com outro sistema (já descrito anteriormente), ou porque ele acredita que é a melhor solução para uma problema e não quer pensar muito nisso, ou porque aconteceu uma vez e ele acha que vai precisar sempre, etc.

Precisamos entender o real problema do cliente, e muitas vezes esse problema não existe. Provavelmente o seu Sistema tem muita opção que foi desenvolvida e nunca foi utilizada. E foi solicitada com toda convicção do cliente que era importante, e pagou todo o desenvolvimento, e … nunca usou, porque não precisava, ou porque daria muito trabalho, ou porque acharam outro modo mais simples de fazer, etc.

O importante é entender que não queremos desenvolver recursos no Sistema somente para “Faturar o Cliente”. Nós queremos desenvolver recursos que sejam utilizados com uma boa frequência, de preferência por vários clientes. Por isso, precisamos descobrir se o que o cliente está solicitando é algo que ele realmente precisa e vai utilizar.
Obs: Um dos indicadores que o cliente não precisa é quando ele diz que não quer Pagar.

Temos que investigar o que o cliente está solicitando, e separar o que ele quer do que ele precisa. Para os leigos, isso não parece fazer sentido. “Se ele quer, é porque ele precisa” muitos devem pensar. Mas como descrito anteriormente, o cliente não entende de sistema. Assim, quando vou ao médico, não digo que remédio ele deve me receitar. O médico fará várias perguntas e irá prescrever o que acha certo.

Nós entendemos de sistema, e entendemos principalmente o funcionamento do nosso Sistema. Nós temos condições de descobrir o que ele precisa através de perguntas que direcionam a real necessidade do cliente, de modo a resolver o problema de forma muito mais simples e segura.

Após a Solicitação ter sido definida, ainda restarão algumas perguntas, como por exemplo:

1. Quem poderá ver ou usar este recurso? Talvez não precise de controle de acesso ou precisaremos criar uma Permissão Especial.
2. Quando estará disponível? Talvez somente após algum evento, como o Envio da Nota, ou o preenchimento de um campo.
3. Se for uma tarefa com agendamento: Qual a periodicidade? Talvez seja a cada hora, ou uma vez por dia, ou uma vez por mês. Se por exemplo, for uma vez por dia, qual deve ser o horário agendado, assim como que dia para agendamentos mensais.
4. Se for uma informação nova, qual é o tamanho máximo da informação em caracteres. E que validações precisamos fazer para evitar erros, como Tamanho mínimo e máximo da Informação, Limite mínimo e máximo de Números e Datas, etc
5. Você tem urgência nesse recurso? Essa é uma pergunta que deve ser feita SOMENTE quando for percebida alguma situação que geraria transtorno se fosse entregue fora de um prazo normal de entrega. E muito cuidado com os clientes que dizem que tudo é Urgente…