.:: dotnetwork.com.br ::.

Começando a segunda parte da série, vamos falar agora sobre a Análise do Problema.

O 1o passo na análise do problema é clarificar ao máximo o que o usuário disse e depois definir qual é o objeto e o problema (aqui chamado de desvio).

Vamos nós concentrarmos no exemplo do último post: Estou com dificuldade ao abrir o documento XXXXXXX.docx no Word.

Neste exemplo, poderíamos redigir da seguinte forma: O usuário ABCD DA SILVA está tendo dificuldades ao abrir o documento XXXXXXX.docx no computador ABCD-PC.

Depois de feita a clarificação, passamos para o segundo passo que é definirmos o objeto e o desvio:

Neste exemplo sabemos que o objeto é o documento XXXXXXX.docx e o desvio é a impossibilidade de abertura.

Agora é hora de sabermos o contrario, o que não é o objeto e o que não é o desvio, isto é, o que poderia ser o problema e não é.

Em relação ao objeto, podemos colocar: outros documentos .DOC e .DOCX

E no desvio poderíamos colocar: documento abre incompleto, fontes não são exibidas corretamente, marca d’água não parece, etc.

Ao invés de utilizarmos etc., devemos utilizar uma abreviatura que nós diga que se precisa de mais informação, como por exemplo, PMD (precisa-se de mais dados)

Note que para todas as perguntas temos a também a parte do NAO e está parte é muito importante para podemos restringir ao máximo a nossa área de atuação:

As principais perguntas que devem ser feitas são:
Onde Geograficamente? (exatamente qual a cidade/estado/rua/etc., esta pergunta é muito útil quando existe site remoto, ou possibilidade de acesso vindo de diferentes localidades)
Onde no objeto? (esta é apenas uma pegadinha, pois vai depender muito de cada problema, neste nosso exemplo, poderíamos utilizar qual o caminho do arquivo, servidor XYZ, etc.)

Quando começou?
Isto já foi visto antes? Quando? (está pergunta é muito importante, pois pode-se estar tratando de algo que nunca funcionou antes)
Desde que começou, quais as outras vezes que se pode visualizar o mesmo comportamento?
Quando na vida útil do objeto?

Quantos objetos?
Número de ocorrências? (por exemplo, se o erro não é sempre, quantas vezes foi visto?)
Qual a tendência? (numero de ocorrências esta aumentando?, esta constante?, diminuindo?..)
Por hoje ficamos por aqui, num outro post continuaremos a falar sobre a Análise do Problema

Começando esta semana de uma forma diferente, falando sobre troubleshooting.

Para quem não sabe, troubleshooting significa fazer um diagnóstico para resolução de problemas.

Existem diversas técnicas que muitas vezes já usamos, mesmo que seja de uma forma diferente. Essas técnicas existem para minimizarmos por tempo gasto e é independente de tecnologia/problema, pois muitas vezes podemos aplicá-las na vida real.

O primeiro passo num troubleshooting é saber o que precisa ser verificado.

Em termos de Informática quando temos que resolver um problema, nem sabemos por onde começar, pois a pessoa/usuário que esta com o problema fala assim: “Estou com um problema no meu computador, aparece uma mensagem que eu não me lembro o que estava escrito!”, mas nunca nós diz qual é o problema/mensagem e espera que nós, os mágicos e leitores de mente, decifremos o que esta acontecendo. Nesses momentos, algumas perguntas ajudam:
qual é mesmo o problema?
Poderia ser mais específico?
O que você quer dizer com ….?
Existe alguma evidencia de que isto é um problema?
Qual decisão precisa ser tomada?

Aqui não estamos querendo saber quando começou, mas sim qual o problema. Se deixarmos em aberto, vamos acabar fazendo um troubleshooting sobre ligar o computador e não sobre o real problema que pode ser quando o usuário abre a internet ou o word.

A partir do ponto em que a pergunta do usuário estiver formulada de uma forma mais legível, ex. Estou com dificuldade ao abrir o documento XXXXXX.docx no word. Tente evitar o uso da palavra problema para não criar um “problema” no futuro.

Depois que existe uma clara visão da necessidade, as seguintes perguntas devem ser respondidas:
Isto é um problema?
A causa é desconhecida?
Precisa-se saber a causa?

Você pode estar se perguntando, mas porque dessas perguntas? Isto é muito simples, às vezes o usuário só quer informação ou a causa do problema já é conhecida e nesse caso não existe troubleshooting.

Se as 3 perguntas forem respondidas com SIM, devemos partir para a análise do problema, que vermos em um outro post.