Entendendo o Problema…
Olá,
Sempre é difícil entender um problema seja ele qual for. Quando temos que analisar uma demora na resposta de uma query ou uma procedure que está muito lenta temos ferramentas ótimas para isso (eu sou fã do trace/tkprof), mas e quando os problemas estão relacionados a Negócios?
“Preciso que contabilização do Material seja credora no caso de devolução e o Sistema não faz isso..” – Gerente de Contabilidade
“O cálculo do PIS/COFINS/CSLL na retenção do Contas a Pagar está sendo efetuado errado…” – Supervisora Financeira
“O Sistema não apurou todas as despesas da Campanha de Vendas número 128371899/2009” – Diretor de Marketing
Essas situações são verídicas e os nomes foram omitidos para preservar os profissionais, mas quem nunca passou por algo parecido? Quem nunca teve uma reclamação destas? Do mesmo jeito que “quem nunca usou um POG, que atire o primeiro mouse” (POG – Programação Orientada a Gambiarras )
Você pode optar por duas formas de abordar isso para tentar entender e resolver isso com os seus clientes.
1) Usar o Fluxograma Master Solucionador de Problemas:
Riscos:
O Cliente pode querer te bater na hora mesmo… eu sei que às vezes dá uma vontade danada, mas resista bravamente e vamos para forma seguinte.
2) Existe um método que nomeei como “Arqueologia Reversa” (Homenagem ao meu Amigo Alex Lana que criou esta expressão). Ela consiste de alguns passos que otimizam muito para entender realmente o problema. Existe ainda alguns aspectos comportamentais sobre como reagir nestas situações, mas isso ficará para outro post.
Fase 1 – Detalhando:
Procure deixar claro para o cliente que Perguntas Genéricas podem e ter e terão Respostas Genéricas. Peça todos os detalhes sobre o problema, mesmo que você não entenda tudo, mas documente tudo mesmo.
Fase 2 – Documentando
Como dito na Fase 1, detalhe o máximo e documente tudo, peça e-mails esclarecendo (sempre com a desculpa de poder se esquecer depois se for apenas verbalmente). Normalmente nesses casos o Cliente nunca quer escrever, então faça você mesmo um e-mail e envie para eles com cópias para outras pessoas sempre.
Fase 3 – Analisando
Com posse destas valiosas informações vamos a prática. Todo problema tem uma causa e um efeito. O ponto está em identificar a causa raiz. Às vezes a causa raiz está oculta em outros problemas, e com isso são apresentados os problemas, mas a causa raiz não está nele.
Exemplo:
“Preciso que contabilização do Material seja credora no caso de devolução e o Sistema não faz isso..“
1) Não faz ou nunca fez?
2) Há uma configuração para isso?
3) Alguém já testou?
Já tive que analisar uma procedure que tinha tantos problemas de performance que as queries que realmente tinham problemas foram aparecer depois de umas 15 modificações na procedure, ou seja, o tkprof me mostrava alguns problemas mas a causa raiz era uma query mal construída. Mas vamos a fase seguinte para achar a causa raiz.
Fase 4 – Identificando
A regra das perguntas (para não ter um valor infinito de possibilidades) é utilizar o 5W1H (What,Who, When, Where, Why e How) ou O que? Quem?, Quando?, Onde?, Por que? e Como? Não há necessidade de seguir uma ordem específica, apenas use a criatividade nas perguntas sobre o problema mas pergunte SEMPRE para o Gestor ou Gerente da Área
Com estas 6 perguntas complementadas com as informações que vocês já conseguiram é possível começar a entender o real problema.
Dica:
Se a área ou o Gerente for Financeiro use a técnica 5W2H e acrescente uma resposta (e não pergunta) How much? Ou Quanto custa? nesse caso já venha com os valores… isso não falha nunca…
Bom, sei estes passos às vezes não podem ser seguidos, mas com disciplina e esforço realmente se conseguem bons resultados disso.
Abraços
Ótimo post! Suas dicas são valiosas, pois eu as uso se me dar conta. Agora foi mostrar seu post aos meus parceiros de trabalho para seguirmos sua filosofia.
Abraços