Introdução

Por que escrevi esse livro?

Entender e atender às necessidades do cliente é uma tarefa desafiadora para muitas pessoas. Muitas vezes, os clientes não sabem como expressar exatamente o que eles desejam. E mesmo quando conseguimos entender o que eles querem, muitas vezes não conseguimos entregar uma solução realmente útil, pois estamos apenas atendendo aos desejos do cliente, e não suas necessidades reais. Para os leigos, entender, identificar e atender às necessidades reais do cliente pode parecer quase impossível. Este livro fornece uma abordagem estratégica para superar esses desafios e entregar soluções que realmente atendam às necessidades do cliente.

Procurei livros, blogs, vídeos, e infelizmente não encontrei nada que eu pudesse utilizar para treinar os nossos colaboradores. Assim, resolvi arregaçar as mangas…

Apresentação

Coloquei nesse livro uma compilação de conhecimentos adquiridos ao longo dos anos como Analista de Sistemas, onde trabalhei com clientes de vários segmentos e tamanhos. O meu objetivo é apresentar ferramentas para que você consiga entender a Necessidade do Cliente e com isso desenvolver a Solução Ideal para cada problema.

Espero que, além de facilitar o seu trabalho, você tenha maior satisfação no trabalho. Essa é uma atividade prazerosa e instrutiva, pois a cada Levantamento nós aprendemos algo novo, seja em relação ao Cliente, à sua área de trabalho, sobre pessoas, sobre perguntas bem feitas, sobre empatia, etc.

Um Levantamento bem feito sempre gera uma Solução melhor do que o Cliente imaginou inicialmente. Além disso, evitará o transtorno de fazer algo que nunca será utilizado ou que muitas vezes os clientes reclamam: - Não era nada disso que eu queria…

O foco deste livro é o Levantamento de melhorias em um sistema, ou a criação de um novo módulo em um sistema já existente. Mas tenho certeza que também o ajudarão a criar: definições de processos, elaboração de sistemas maiores, definições de requisitos mínimos, etc.

Dependendo da política da sua empresa, uma Solicitação de Cliente é:
1- uma Ordem, para ser feita sem questionar
2- uma fonte de renda, que deve ser feita para aumentar o faturamento
3- uma forma de melhorar o sistema para o cliente, e torná-lo fiel (ingenuidade…)
4- uma forma de melhorar o sistema para todos os clientes

Para as empresas do tipo 1, acredito que não sejam o público alvo deste livro.
Para as empresas do tipo 2, por favor, desconsiderem alguns capítulos e comentários que falam em pesquisar se “a Solicitação é Importante para o Sistema”.
Escrevi este livro pensando em empresas do tipo 3 e 4.

Do que estou falando

O que é Levantamento

O Levantamento é o entendimento da “Necessidade” do cliente. Pode parecer óbvio quando falado, mas esse Levantamento precisa ser feito com o Cliente. Destaco isso porque já vi muitas pessoas acreditando que entenderam “TUDO”, apenas lendo a Solicitação do Cliente e já definiram a solução perfeita.

Exemplo:
O cliente pede: Preciso de um sistema de controle de locação
O Analista: Entendi. Já posso começar a desenvolver. Vou criar 3 tabelas, 2 telas e 2 relatórios

O Levantamento normalmente nasce de uma Solicitação do Cliente, que pode ser para uma Melhoria, Alteração ou Criação de um recurso no Sistema. Nesse Levantamento, iremos tentar entender profundamente o que o cliente realmente precisa, através de perguntas, demonstrações, análises, protótipos, documentações, pesquisas, etc.

Um Levantamento não é um processo onde apenas “o cliente” fala e apresenta o que ele “imagina” que resolverá o seu problema. Esse é o modo como normalmente são feitos os Levantamentos por pessoas sem os conhecimentos e atitudes listados neste livro. Isso é feito por quem acredita que o Cliente sabe bem o que está pedindo e que o Cliente sempre tem razão, mas desse modo, isso nem pode ser considerado um Levantamento.

Uma visão importante, que é pouco encontrada na literatura, é a relação entre o que o cliente Quer e o que ele Precisa. Para os leigos, as duas palavras são sinônimos.
Um livro ótimo sobre este tema é A Fórmula da Eficácia - Alisson Vale.
Fiquei feliz em encontrar neste livro algo que eu falo há muito tempo (mas poucas pessoas entendem e concordam), e que vou detalhar nos próximos capítulos.

Para conseguirmos entender o que deve ser desenvolvido ou alterado no Sistema, precisamos fazer várias perguntas, e algumas vezes, teremos que convencer o cliente que o que ele está pedindo não irá funcionar, pelo menos, não desse modo.

• Devo dizer que o cliente está errado?
• Sim, quando necessário, mas com técnicas que farão ele te agradecer no final.

Para fazermos boas perguntas, nós precisamos entender o que o cliente está solicitando, entendendo a sua linguagem (semântica), as suas certezas, dúvidas e sonhos, e ao mesmo tempo avaliar o impacto da alteração dentro do sistema. E após entendermos o que ele precisa, faremos perguntas com as possíveis soluções imaginadas, de preferência fazendo que ele acredite que foi ele quem pensou naquela alternativa - esse é o modo mais fácil de convencer alguém de que aquela é uma “Ótima Ideia”.

Importância para sua Empresa

Antes de você iniciar um Levantamento, você deveria conversar internamente para identificar se as Solicitações que serão Levantadas são interessantes para a sua empresa.

Talvez você precise fazer um Pré-Levantamento para entender o que o cliente pretende, quando a Solicitação não estiver clara.

O ideal é que o time que irá debater seja compostos por pessoas com conhecimentos complementares, como Desenvolvedores, Analistas, Suporte, Implantação, etc. Importante trazer para a reunião quem mais conhece o Cliente e quem mais conhece o tipo de negócio deste Cliente.

Para cada tópico, todos devem debater o que entenderam da Solicitação e avaliar:
1- Não contraria alguma política de desenvolvimento? (Ex: Rotinas Ilegais)
2- É possível fazer? (Alguns recursos são inviáveis pela complexidade, custo, hardware, pessoal, etc)
3- É importante para o Sistema? Vai atender outros clientes?
4- Qual o tamanho do desenvolvimento? (com o conhecimento atual, e isso deve mudar após o Levantamento)
5- Alternativas atuais para resolver o problema do cliente (quando possível)

Com estes entendimentos em mente, você poderá conduzir a reunião de Levantamento questionando o que foi identificado como problema, por exemplo:

• Se contraria a Política da Empresa, confirme com o cliente se o que vocês entenderam é o que ele pretendia, afirmando que não poderão desenvolver nada Ilegal.
• Se parece inviável, veja o que pode ser feito que ajude-o parcialmente.
• Se não é importante para o Sistema, tente identificar o que pode ser feito com alguma integração com outro sistema, por exemplo.
• Se o desenvolvimento for muito grande, o que pode ser feito como um MVP.
• Se foi identificado que, por exemplo, uma Planilha pode resolver o problema do cliente, confirme se o cliente possui os programas necessários e o conhecimento para utilização.

Se a Solicitação for uma Imposição Legal, você deve avaliar na reunião se a empresa é obrigada a atender. O ideal é levantar com o Responsável pelo seu Sistema se esta alteração legal está coberta ou não por algum contrato de manutenção. E o fato de ser uma Imposição Legal não torna obrigatório o seu desenvolvimento, pois algumas vezes o cliente tem outras formas de atender essa solicitação.

Necessidade para o Cliente

A primeira informação que precisamos obter, antes de nos aprofundarmos em um Levantamento, é quanto o cliente está pensando em investir ($) no desenvolvimento da sua solicitação.

Destaco isso, pois já ouvi inúmeras vezes a frase:

• Mas se o cliente está pedindo algo, é porque ele precisa, né?

Nem sempre. Vários clientes pedem coisas sem pensar no Custo/Benefício. Outros não tem noção da complexidade de algum recurso. Outros são mimados e pedem tudo que querem, e querem de graça. Outros acreditam que é você quem deve pagar pelo conhecimento que ele está te dando.

Para descobrir isso, não basta questionar o cliente:

• Qual o nível de Importância para vocês?
• Muito Importante - responderá o Cliente.

Você precisará descobrir indiretamente, com perguntas como:

• Quantas vezes isso será utilizado?
• Quantas pessoas irão utilizar?
• Quanto tempo/dinheiro irá economizar?

etc

Normalmente será você quem precisará identificar em qual das categorias a Solicitação se enquadra.

Vou dividir as Solicitações do cliente em 3 categorias: Imprescindível, Importante e Interessante, ou respectivamente: Preciso, Quero e Gostaria (hehehe).

Imprescindível: É uma necessidade que precisa ser atendida, pois irá reduzir o tempo de algum processo ou aumentar a qualidade das informações, em processos de alta ocorrência.

Este tipo de recurso será utilizado e normalmente atenderá outros clientes.
(Se você estranhou o “Será utilizado”, é porque não sabe quantos desenvolvimentos nunca ou raramente são usados nos Sistemas.)

Também se enquadram nessa categoria algumas alterações impostas por lei ou por um grande cliente ou fornecedor (do seu cliente). Mesmo que o seu Cliente não tenha um ganho de produtividade com o Recurso, ele precisa atender o que foi solicitado. Veja no próximo capítulo mais sobre isso.

O cliente não teria problema em investir no desenvolvimento.

Importante: Resolveria algum problema menor do cliente, e ele investirá se o custo for compatível com o benefício. Normalmente são processos com baixa frequência, como tarefas semanais ou mensais, ou que não trarão uma grande economia financeira para o cliente. Normalmente atende alguns poucos clientes, mas muitas vezes nem chega a ser utilizado por quem solicitou.

Interessante: O cliente acredita que melhoraria algum processo, mas normalmente não pretende investir no desenvolvimento. Muitos clientes dizem que essas solicitações são apenas sugestões de melhoria quando apresentamos uma previsão de custo. Provavelmente nunca será utilizado por ninguém.

Veja exemplos abaixo, considerando o meu interesse (pode rir se discordar). Eu não pagaria pela linha do Interessante, mas aceitaria se fosse grátis.

	Para o meu carro é
Imprescindível	Consertar o freio
Importante	Consertar o vidro elétrico
Interessante	Pintar um pequeno risco

Espero que você tenha percebido porque é necessário identificar o nível de interesse do cliente. O que eu costumo repetir com frequência:

• Se o cliente não pretende custear o desenvolvimento, não é realmente Importante para ele. E se não é Importante para ele, também não deve ser para outros clientes.

Mas também não se iluda com o cliente que aceita pagar por qualquer “coisa”, mesmo as Interessantes. Não é porque ele quer pagar que ela se tornará Imprescindível. Um recurso do tipo Interessante pode se tornar um problema no sistema, e só a experiência te ensinará que não compensa o que foi cobrado.

Muito cuidado para não consumir seu tempo em levantamentos assim. E pior, desenvolver algo que nunca será utilizado, inchando o seu sistema e tornando a manutenção e suporte mais difícil.

Esse nível de necessidade (Imprescindível, Importante e Interessante) deve estar destacado na Documentação, mesmo sabendo que esta percepção pode mudar para o Cliente ao longo do tempo, e essa percepção também pode ser diferente entre os Stakeholders.

Essa diferença da percepção de necessidade entre as pessoas é muito fácil de perceber quando nos encontramos em uma reunião com vários setores ou níveis gerenciais. Para alguns, algo é Imprescindível enquanto para outros não é nem Interessante.
Por exemplo: Quem lança dados no sistema quer telas simples, enquanto quem gerencia a empresa quer informações relevantes para tomada de decisão.

Existe também a diferença na percepção de valor e investimento de acordo com o nível gerencial e a alçada de cada colaborador. Como exemplo: um colaborador pode se assustar com o custo de um Desenvolvimento e ser aceito como normal pelo gerente dele.

Atenção: Algumas (raras) vezes, uma ideia que o cliente não pretende custear, pode gerar um recurso que seja um Diferencial Competitivo. Mas aposte nisso com muito cuidado e depois de conversar com outros especialistas.

Atenção 2: Também não caia no Conto do Vigário, quando o cliente garantir que todas as empresas do ramo irão comprar a sua solução se tiver tal recurso. Já ouvi muito isso (e cai em alguns).

Nível de Certeza do Cliente

Quando a conversa inicia, o cliente apresenta a sua ideia e afirma que já pensou em tudo, e que aquilo irá resolver todos os seus problemas. Basta uma pergunta para confirmarmos que ele só pensou no Caminho Feliz.

Caminho Feliz, Happy Path, Fluxo Básico, Fluxo Principal, etc - É um conceito da UML, no Caso de Uso, com a descrição do processo sem nenhum problema ou exceção. A ideia do cliente ter pensado no Caminho Feliz é uma referência apenas, pois não espero que o cliente entenda de Casos de Uso.

Na primeira pergunta: “Mas e se …” já quebra as pernas do cliente. E ele responde: “É, tem essa situação que eu não havia pensado, mas é SÓ ESSA exceção”. E o segundo “E se …” volta um: “Sim, tem isso também, mas é só isso”, e assim vai. Logo o cliente percebe que o que ele está pedindo não é tão simples assim, e principalmente, que não foi bem avaliado.

Muitos imaginam que os sistemas têm uma Inteligência mágica, que nem precisa definir o que fazer nas exceções. Ou pensam que nós somos Especialistas no negócio deles e saberemos o que eles precisam e como resolver.

E se você não tem experiência em Levantamento, ficará surpreso como alguns clientes não tem ideia de como funciona nem o seu próprio negócio.

Com isso, não quero dizer que o cliente tem pouco conhecimento ou não gosta de pensar. O cliente não precisa entender de Sistema ou “dessas coisas de Computador”. Também não podemos esperar que ele tenha o pensamento lógico e abrangente. Tudo isso é obrigação nossa. Assim como quando vamos ao médico, é ele quem tem que nos fazer perguntas e entender o que temos. Do mesmo modo, nós é que temos que entender o cliente e o que ele precisa. E de preferência, ter um bom conhecimento da área de atuação do cliente…

Por que precisamos investir em Levantamento com o Cliente?

Não seria mais simples só pegar o e-mail do cliente e abrir um Ticket (ou qualquer outro nome que vocês utilizem para registro de Desenvolvimento)? Por que gastar nosso tempo falando com o cliente e fazendo várias perguntas, se o cliente já disse bem o que ele quer? Nos próximos tópicos, você entenderá que o cliente normalmente não consegue ser tão preciso assim. Mas antes, vamos apresentar alguns números:

Algumas pesquisas mundiais apontam que, de cada software, 50% Nunca são utilizados, outros 30% raramente são, sobrando apenas 20% sendo utilizado frequentemente.

Dos projetos de sistemas, aproximadamente: 20% são abandonados durante o desenvolvimento (com muita perda de dinheiro, tempo, pessoal, etc) e menos de 20% são concluídos no prazo e custo originais. Se quiser saber mais, pesquise por “chaos manifesto”.

Outro número que deve te convencer o porquê um bom levantamento é importante são “os Tickets Cancelados” da sua empresa. Se você verificar o número de Solicitações nesse Status e a quantidade de horas “perdidas”, você entenderá que muitas “necessidades” dos clientes não eram tão importantes assim. Quando esses Tickets foram criadas, pareceram importantes, mas por diversas razões, acabaram cancelados.

Para evitar desenvolver algo que nunca será utilizado, é importante entender o que o cliente realmente precisa e avaliar se isso será util para o Sistema. Como dito no capítulo anterior, o cliente não tem muito conhecimento para fazer uma Solicitação “pronta para ser Desenvolvida”. O nosso conhecimento, que é mais amplo, irá ajudar o cliente a perceber algumas Possibilidades e Complicações, e definir, e redefinir (várias vezes), até chegar a uma solução mais otimizada para o seu problema.

Conhecimentos

Pré requisitos para entender o que o Cliente está solicitando

Para entender a solicitação do Cliente, é necessário conhecer bem o “teu” Sistema e (pelo menos superficialmente) o Processo do Cliente.

Conhecimento do seu Sistema
Se o cliente está solicitando uma alteração no Pedido, por exemplo, é necessário conhecer os Recursos que o Sistema já disponibiliza, tanto para este cliente quanto para os outros. Talvez a Solicitação seja apenas uma configuração para habilitar uma funcionalidade, ou a apresentação de um Botão que faz o que o cliente está precisando. Algumas vezes, existe um recurso parecido com o Solicitado, e esse deve ser demonstrado para o cliente e verificar se o formato atual atende, e caso não seja exatamente o que o cliente está pensando, já atenda a necessidade, pelo menos parcialmente.

Conhecimento dos Processos do Cliente
O conhecimento de como o cliente trabalha ajuda a avaliar se o que o Cliente está pedindo vai realmente melhorar o trabalho dele. Uma melhora no trabalho do Cliente é encontrada quando:

1. Reduz o tempo para executar uma Ação
2. Aumenta o Segurança ou a Qualidade das Informações (talvez aumentando o tempo do processo)

Conhecimento da Área do Cliente
Sabendo como outras empresas da mesma área trabalham, você conseguirá identificar o que trará algum ganho e as solicitações que não irão ajudar a empresa. Muitas vezes o cliente solicita melhorias que são “piorias” (desculpe a palavra, mas é como brincamos sobre algumas ideias ruins).

Talvez não seja intuitivo, mas muitos clientes pedem alterações que não trazem nenhum benefício (exemplo: mudar o nome de um Menu), e outras, que só geram mais trabalho sem nenhum ganho de qualidade (exemplo: informar uma senha cada vez que alguma situação acontece - isso é ruim para os usuários, e temos outras maneiras de controlar isso sem uma senha).

A importância da Semântica

Para conversar com o cliente, e gerar um bom entendimento, precisamos nos preocupar com a Semântica.

Semântica é o significado que cada pessoa ou grupo de pessoas tem em relação às palavras. Uma palavra pode ter significados diferentes conforme o Contexto, o conhecimento das pessoas, o Tipo de Negócio, etc. Um exemplo é a palavra: Pedido. Para a maioria das pessoas, essa palavra representa o ato de pedir, como em “Posso te fazer um Pedido?”, ou “Pedido de Casamento”. Mas em um Sistema, Pedido normalmente representa um Pedido de Compra, que é um documento com os dados do que foi solicitado, com os itens, preços e condições da compra.

Mas “Pedido de Compra” representa o quê dentro de um sistema? Para algumas pessoas, é o documento que é criado quando os nossos clientes querem adquirir algum produto ou serviço que a nossa empresa oferece. Para outras, é o oposto, é o que precisamos comprar de outra empresa, o que em muitos sistemas é chamado de “Ordem de Compra”.

Com o exemplo anterior, você pode perceber como é importante o entendimento “unificado” de cada palavra ou conceito. Pensando em ERP, se uma pessoa estiver falando em “Ordem de Compra”, mas chamando-o de Pedido, a outra entenderá que é “Pedido do Cliente”, e provavelmente nenhuma das duas perceberá o engano, pois as telas e recursos são muito parecidas para os usuários.

Para evitar esta falha de comunicação, precisamos “unificar” o vocabulário, ou a Semântica. Isso é feito “principalmente” no início das interações com o cliente, e deve ser feito com cada usuário. Essa unificação normalmente é um processo rápido, bastando uma reunião, pois os usuários aprendem rápido e logo começamos a falar a mesma linguagem. Mas fique sempre atento, pois palavras novas aparecerão no futuro, e também deverão ser alinhadas.

A unificação da Semântica tem que ser de Feedback Imediato, isso é, na primeira oportunidade você deve:

• Ou explicar o termo correto
• Ou entender o novo termo do cliente

Você também precisará ficar atento para perceber se o cliente “realmente” está entendendo o que você está falando, e entendendo corretamente. No exemplo da palavra “Pedido”, se você falar para um cliente que chama a OC de Pedido, talvez ele “acredite” que está entendendo. Por isso, precisamos ficar atentos e na menor dúvida, confirmar se estamos falando do mesmo assunto.

Mas como conseguir alinhar a Semântica? Já citei anteriormente que precisamos Explicar os nossos termos e Entender os termos do cliente.
Para entender os termos do cliente, não podemos ter vergonha de perguntar:

• O que isso significa?
• Desculpe, mas não entendi. Você pode explicar mais? Tem algum exemplo?
• Como se escreve esta palavra?
• O que essa sigla representa?

O ideal é que isso seja feito junto com o cliente, naquele momento, e não deixar para depois pesquisar no Google. Pois muita coisa pode ser falada sobre esse assunto, e se você não tem ideia do que é, provavelmente não vai conseguir entender tudo que foi dito. Se você deixar para ver quando terminar a reunião, talvez entenda a palavra, mas não conseguirá lembrar tudo que foi dito sobre o assunto.

Do mesmo modo, se você perceber que o cliente está entendendo de forma diferente o que você está falando, ou pior, não tem ideia do que você está falando, você tem que agir imediatamente. Perceba que muitas pessoas têm receio de dizer que não entenderam algo, principalmente na frente de outras pessoas, tanto colegas quanto pessoas distantes.

Assim, a sugestão é fazer algumas perguntas para verificar se as pessoas estão entendendo “corretamente” os termos que podem ser estranhos para o cliente. Alguns exemplos de perguntas que podem ser feitos, usando o exemplo da palavra “Pedido”:

• Você entendeu que estou falando do documento que vocês enviam para os clientes?

Como vocês chamam esse documento aqui? No meu sistema, chamamos isso de “Pedido”, simplesmente “Pedido”. Se você falar “Pedido de Compra”, talvez gere alguma dúvida no nosso Suporte.

• Como vocês chamam a Ordem de Compra, que é o documento que vocês enviam para solicitar produtos dos fornecedores? No meu sistema, chamamos isso de Ordem de Compra ou simplesmente OC.

Talvez você pense que a Semântica vai se formar espontaneamente, e isso até pode acontecer, mas se você não agir com o Feedback Imediato, talvez muitos problemas sejam criados por falhas no entendimento, de ambas as partes.

Você percebeu que são conhecimentos para os dois lados, tanto o cliente que deve usar palavras que a nossa empresa entenda, tanto Implantação, Suporte e Desenvolvimento, quanto palavras que são do negócio do cliente, e que precisamos conhecer para entender novas solicitações. Podemos exemplificar com um termo de Cliente, que hoje até é bastante utilizado internamente: OPME. Na primeira vez que alguém escuta este termo, não tem como imaginar do que se trata. Temos que perguntar o que significa.

Isso levanta outro ponto importante na nossa formação: Precisamos estudar os termos e siglas que o Sistema já atende. No exemplo de OPME, você já deve saber o que significa, pois consta nas nossas documentações. E se você encontrar termos no Sistema ou na Documentação que não entenda ou que tenha dúvida se entendeu corretamente, pesquisar na Internet não é a melhor solução. Pergunte para alguém mais antigo na empresa, pois a explicação de alguém da própria empresa normalmente será mais direcionada a forma que usamos internamente.

Não poderia finalizar sem falar algo que acontece com quem tem um grande conhecimento sobre um assunto: Nós não percebemos que algo é muito comum para nós, mas é completamente desconhecido por quem não é da área. Tente usar sempre palavras conhecidas, e somente se for necessário, apresentar ao cliente novos termos, confirmando que ele entendeu bem.

Como entender o que o Cliente está solicitando

Na grande maioria das situações, o ideal é o cliente demonstrar o que está pedindo, de acordo com cada situação, como exemplos:

Incluir informações em uma tela
O cliente deve apresentar a tela que deseja a alteração e descrever o que pretende, onde ele espera ver a informação, como chegar naquela informação (pode ser um cálculo ou um dado existente em outro ponto do sistema), etc. Por exemplo, se deseja que na tela de Pedido, o sistema apresente o Valor em aberto do Contas a Receber do Cliente, ele poderia demonstrar na tela onde espera ver isso, e mostrar o relatório que ele tira para verificar este dado.

Um Relatório Novo
O ideal é o cliente criar uma Planilha com os dados que ele imagina, e de preferência com informações reais de pelo menos uma linha. Na Planilha, também podem ser usadas fórmulas ou indicações de onde podem ser encontrados aqueles dados no Sistema. Nesse caso, o cliente poderia sugerir o nome do Relatório, os Filtros, etc.

Cálculo de Comissão
Deve ser apresentado o formato de Cálculo que eles usam para definir cada comissão. Provavelmente este cálculo tem várias configurações, de acordo com o Tipo de Cliente, do Representante, etc. O ideal é que essa informação fosse enviada em uma planilha, com todas as possíveis variações. Outras informações que precisam ser levantadas são:

1. Quando é paga a Comissão: Na emissão da Nota ou quando o cliente paga cada parcela?
2. O valor da Comissão é baseado no valor final da Nota ou no Valor dos Produtos sem os Impostos e outros Custos?
3. Se a Venda for Cancelada, a Comissão será estornada?

Veja neste exemplo como é importante conhecer o Negócio do Cliente, esse módulo do Sistema e o que já atendemos hoje para conseguir fazer esta série de perguntas.

O importante aqui é entender que não precisamos aceitar que o cliente faça solicitações sem explicar o que deseja. O ideal é mostrar, tanto no sistema, apontando as informações e onde ele imagina o novo recurso, ou desenhando em papel, ou qualquer outro formato que seja fácil visualizarmos o desejo dele e do mesmo modo, que possamos interagir com este recurso, apontando alternativas na tela, ou desenhando junto com ele. Lembre, um desenho vale por mil palavras.

Importante ter em mente que se o cliente não quer “definir” o que precisa, normalmente é porque ele não precisa de verdade (e provavelmente nem pretende pagar o desenvolvimento). É apenas uma ideia, que ele não tem bem formatada, e nem gastou muito tempo pensando nisso. Ele quer só jogar no nosso colo e espera que façamos a mágica de transformar uma frase aberta em uma Bala de Prata.

Sem entender bem o que o cliente precisa, como poderemos dar uma estimativa de desenvolvimento? E quando entregarmos algo que não foi “bem levantado”, qual será a utilidade disso para os clientes?

O que perguntar para o Cliente e como?

Como dito anteriormente, para fazer boas perguntas, é preciso ter bom conhecimento do Sistema e de suas possibilidades. Além disso, precisamos ter em mente que: o cliente não sabe o que precisa, o cliente não conhece o sistema, o cliente não conhece bem o seu processo, etc. O que irei apresentar agora poderá parecer estranho e contra-intuitivo, e eu mesmo levei muito tempo para perceber essa verdade em muitas situações.

1. O cliente não conhece o seu próprio processo

Muitas vezes, quem está fazendo a solicitação, pode ser alguém novo na empresa ou que não tem o conhecimento de todos os processos. Outras vezes, a empresa é nova, e ninguém lá tem experiência suficiente para conhecer o mercado. Já presenciamos empresas que durante uma reunião com vários setores começaram a debater como aquela Solicitação deveria ser implementada, cada um com uma visão completamente diferente dos outros (se você presenciar isso, peça para voltar outro dia, quando tiverem resolvido). Temos também muitos clientes que acreditam que podem fazer algo que a Lei não permite ou que não precisam fazer algo que é obrigatório.
Em muitos casos, acabamos trabalhando como consultores, e apresentamos como o Sistema é usado pelos outros Clientes da mesma área.

2. O cliente não conhece bem o nosso Sistema

Mesmo em clientes que utilizam o Sistema há muitos anos, não tem o conhecimento de todas as possibilidades no Sistema. Muitos clientes solicitam recursos que já existem. Alguns reclamam que o sistema não atende por falta de conhecimento. Outros fazem solicitações que não fazem muito sentido aos processos do Sistema. Temos que ficar atentos para perceber que o que está sendo solicitado tem uma solução mais simples do que pode parecer para o Cliente.
Mas atenção, não estamos dizendo que o cliente deveria conhecer o Sistema tão bem quanto nós. Eles não precisam entender. Quem tem que apontar as soluções somos nós, através deste tipo de reunião de levantamento, e com muita empatia.

3. O cliente quer do modo que está acostumado

Alguns clientes, principalmente os Novos, pedem recursos iguais aos que usavam em outro sistema. Nesses casos, devemos demonstrar o que o nosso Sistema oferece.
Mas e se o cliente disser que não quer usar daquele modo, pois está acostumado com o outro formato? (obs: Normalmente ele vai dizer isso de modo indireto) Então, de forma educada e com muita empatia, devemos pedir que o cliente use assim durante um tempo para avaliar, e em breve voltaremos a falar. Praticamente todas as vezes o assunto é esquecido.

4. O cliente não sabe o que algo é Ilegal ou Obrigatório (ou Sabe?)

Alguns clientes fazem solicitações por desconhecimento (ou má fé) de operações Ilegais ou perigosas. O que perguntar se o cliente solicitar algo que pareça Ilegal ou Estranho? Neste caso, temos que pedir que o cliente apresente a documentação comprovando a informação da Legalidade, sem deixar transparecer que ele está pedindo algo Ilegal.

5. O cliente não sabe o que quer

Muitas solicitações de clientes não fazem sentido quando são analisadas friamente. Uma situação frequente é o cliente pedir um relatório que apresente os clientes que poderiam comprar mais. Quando pedimos para eles explicarem como podemos definir esses clientes, eles não tem ideia. Ou quando pedem para ter um relatório gerencial, mas não sabem que informações deveriam ser apresentadas.
Temos que fazer o cliente perceber que ele não sabe como chegar no resultado que ele gostaria, e desse modo, não temos como ajudar. Podemos pedir um tempo para pesquisar e voltar a reunião em outra ocasião.

6. O cliente que não quer saber

Alguns clientes não querem saber da complexidade da Nota Fiscal, por exemplo, e pedem para simplificar. Acreditam que estas configurações de impostos são complicações do nosso Sistema. Outros querem que o sistema calcule a Produção, sem ter que informar os dados. Ou que importe um XML sem ter que configurar as informações.
Novamente, empatia. Demonstrar para o cliente a complexidade da situação e solicitar exemplos de outros sistemas onde isso seja simplificado. Quem sabe encontramos um modo melhor de fazer? Temos muito interesse que os clientes nos deem indicações para simplificar os nossos processos, mas isso muito raramente acontece.

7. O cliente que pede algo que quer, e não o que precisa

Esse é um ponto polêmico, que será discutido detalhadamente mais à frente.

8. O cliente está dando uma sugestão

Muitas Solicitações são feitas como Sugestão, e o cliente não pretende Investir no desenvolvimento da funcionalidade. Nesses casos, precisamos entender que o cliente não está Solicitando um Desenvolvimento, mas que gostaria de ter aquele recurso sem custo. Isso deve estar descrito na SD, se for aberta, conforme orientação da gerência. Veja acima o tópico “Nível de Necessidade”

1. O cliente acredita que o sistema tem um erro

Alguns clientes podem encontrar problemas no sistema, e abrimos como um Ticket de Correção. Infelizmente, de forma ingênua (ou por má fé), alguns dizem que é um Erro algo que eles precisam e o nosso Sistema não atende, dizendo que isso deve ser corrigido sem custo. Nesse caso, é importante conhecer bem o Sistema e saber até onde o Sistema tem a obrigação de atender. A regra geral é: Se o nosso Sistema não tem um recurso, é sempre Desenvolvimento Faturável.
Se o cliente aceitar abrir um Ticket de Desenvolvimento, descreva no Ticket que o cliente informou inicialmente como Erro.
Se o cliente não quiser abrir um Ticket, solicite orientação da gerência sobre o que fazer.

10. O cliente solicita algo muito grande

Quando a solicitação do cliente parecer muito complexa, que exija a participação de outros Analistas, peça para o cliente apresentar resumidamente a solicitação e junte o que o cliente possuir de documentação adicional. Diga que você irá falar com o Setor de Desenvolvimento e voltarão a falar do assunto em outra ocasião. Após finalizar a coleta dessas informações, continue com as outras solicitações do cliente.

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…

Por que é tão importante descobrir a Causa Raiz?

Se não conseguirmos identificar a Causa Raiz da solicitação do cliente, nós teremos vários problemas. Veja um quadro comparativo:

Obs: Desculpe a tabela abaixo. Não tenho como formatar melhor nessa versão.

Mas se temos tantos benefícios, por que o cliente não solicita direto a Causa Raiz?
Porque ele não conhece nada sobre Análise de Sistema, e nen precisa conhecer. Essa é a nossa obrigação.

Como avaliar se estamos entendendo e se estamos “sendo entendidos”?

O que você verá a seguir pode parecer bobo e até perda de tempo, mas talvez seja o melhor conselho de todo este documento.

A comunicação entre pessoas é complexa e sujeita a muito mal entendido. Pode parecer que estamos entendendo e que estamos sendo compreendidos, mas um pequeno desvio pode gerar muita confusão.
Para evitar essas diferenças, a cada período de tempo devemos fazer uma “Revisão do Acordado até o Momento”, onde você deve “repetir” o que foi definido até o momento, desde o início da reunião. E na segunda vez, repetir novamente, tudo, desde o início da reunião. E assim até a última vez. Claro que esse repetir é um resumo do que foi definido, mas que deixe claro os detalhes do que você entendeu e do que pretende fazer. Também deve ser citado o que foi definido que as outras partes devem fazer.
Muitas vezes, na primeira pausa para validação do entendimento, temos algumas definições, e na segunda, algumas dessas primeiras definições já foram alteradas, e novas ideias apareceram. É normal o cliente discordar do que é apresentado na “Revisão do Acordado” e essa discordância deve ser resolvida antes de voltar a novos assuntos. Muitas vezes o cliente diz que não foi isso que ele entendeu que seria feito, ou que não era isso que ele estava pensando, e você ficará feliz de ter feito essa Revisão. Quanto mais cedo forem levantadas essas diferenças, melhores serão as decisões finais.

• Mas qual é o período ideal entre cada Validação?

Imagine que você conversou por 3 horas, fez a revisão só no final da reunião e neste momento percebe que algumas definições foram mal entendidas. E agora, ainda haverá tempo de redefinir? E tudo que foi discutido baseado em um entendimento equivocado, será que tem alguma validade?

Se você conversar por 15 minutos e parar para revisar, pouca coisa pode ter ficado mal entendida. Será rápido ajustar e continuar as definições. 15 minutos é uma sugestão, e dependerá do ritmo da reunião.

Não foi citado que você deve estar anotando os tópicos, definições, tarefas, prazos, etc. É isso que você irá repassar com os participantes.

Então, a cada período, você faz uma Pausa e diz:

• Até agora definimos que … e que faremos isso … e que vocês farão isso… Todos concordam?

E no final da reunião, você repete essa frase, relendo cada tópico que você anotou.

Finalizando

Ainda em trabalho

Caro leitor,

Gostaria de saber o que você achou até aqui, pois tenho outras dicas para escrever.
Por favor, me responda através do e-mail: robertobrum@yahoo.com.br.

E agora?

Só com a prática você perceberá muita coisa do que foi dito aqui, e se surpreenderá quando acontecer alguma das situações que foram descritas.

A minha sugestão é que você releia de tempo em tempo, e provavelmente você entenderá melhor algumas colocações.

Também pretendo que este documento seja ampliado com mais exemplos reais, e mais conhecimento, e por isso, valeria uma releitura.