26 de Junho de 2006

The Muns Report: Documentação de Incidentes

A longa (e desnecessária) descrição de incidentes na área de suporte

Você já se perguntou por que a descrição de incidentes na área de suporte técnico é sempre tão confusa? Por que é difícil obter (apenas) os fatos importantes? Por que é tão difícil conseguir uma descrição sucinta de incidentes similares, registrados por diferentes agentes? Por que será que sempre encontramos descrições cheias de comentários pessoais ao invés de registros relevantes necessários para a resolução do problema?

Bem, a razão mais importante para que isto ocorra é que talvez não treinemos nossos analistas na documentação dos problemas e soluções de acordo com os padrões da empresa. Ainda que tenhamos estruturado muitas atividades na área de suporte, ainda não desenvolvemos padrões adequados para a descrição do incidente ou treinamento para o analista. A adoção de padrões e um treinamento apropriado para os profissionais de linha de frente em como escrever uma descrição correta, pode poupar tempo e aperfeiçoar o mecanismo de busca e reutilização da informação.

Elementos básicos para a documentação de incidentes

A estrutura desta edição do Muns Report foi retirada do guia “Basic Writing Skills for the Support Professional”, produzido por Julia Neider, editora do HDI – US. Ron adaptou os conceitos deste guia a uma situação comum no momento de documentação do incidente.
Os conceitos básicos da documentação de incidentes envolve as seguintes perguntas:

• Qual é o propósito?
• Quem vai ler este documento?
• O que este leitor/agente está esperando?
• Como a informação vai ser usada?
• Como seu texto deveria ser organizado?
• Qual é o melhor estilo de documentação?

Qual é o propósito da documentação de incidentes?

Aqui é o momento em que o agente documenta a descrição do problema ou serviço realizado pelo usuário, bem como o contexto relativo a estas solicitações. Isso permite que a informação possa ser reutilizada no futuro e auxilia na identificação de problemas comuns.

Quem é o leitor?

Normalmente, quem deverá ler é alguém do segundo nível do suporte, escalado para resolver o incidente, mas poderá incluir também agentes da linha de frente. ou mesmo clientes, se sua base de conhecimentos for aberta. Descrições simples, orientadas ao fato (usando a linguagem do cliente) pode funcionar para todos os grupos.

O que o leitor está esperando?

O leitor está esperando objetividade na descrição, juntamente com informação contextual que simplifique a busca para a solução. De novo, seja objetivo, claro e use frases ou até um formulário com descrições muito claras do que documentar. Vale qualquer coisa que faça nosso trabalho ser mais rápido e melhor. Então, evite palavras ou frases desnecessárias.

Como a informação vai ser usada?

A informação será usada para:

• Esclarecer o problema
• Documentar os erros e testes executados
• Detalhar a natureza do problema (Windows XP, versão...)
• Fornecer um guia para os próximos passos
A informação que não deve ser usada para:
• Mostrar opiniões pessoais ou sobre o cliente
• Descrever comentários sobre políticas da empresa, defendendo seus pontos de vista ou culpando outros

Como você deve organizar ou estruturar sua descrição?

A estrutura exata não é tão importante quanto o fato de se usar uma padrão. Uma estrutura padrão vai economizar tempo na documentação e revisão. Por exemplo, as regras poderiam:

• Descrever o que está funcionando
• Descrever os resultados e testes executados
• Descrever o contexto/ambiente da situação
• Fornecer links ou anexos para mais informações, por exemplo: detalhes de configuração ou telas capturadas

Qual é o melhor estilo para escrever?

Isto vai depender dos padrões da sua organização, mas seja direto, claro, use frases simples e objetivas. Você deve obviamente usar uma ferramenta de busca para localizar a descrição de incidentes e isto irá aumentar o índice de “documentos encontrados”. Deverá ainda usar sua documentação para divulgar sua base de conhecimento, juntamente com a solução encontrada. Assim, quanto mais direto melhor. Como disse, adotando um estilo mais conciso certamente ajudará a reduzir o tempo global de atendimento.

Conclusão

Sempre procuramos por respostas complexas e elegantes, mas no processo, não podemos esquecer os conceitos mais simples. As regras fundamentais de documentação são extremamente importantes. Isto afeta o tempo necessário do segundo nível receber a informação, a habilidade de se reutilizar a informação, a agilidade em disponibilizar informação para os sistemas de auto-ajuda e agrupa incidentes comuns em erros conhecidos, que podem ser resolvidos através de “fixes” permanentes. Então, sugiro que você revisite os conceitos básicos discutidos aqui e faça com que toda sua equipe desenvolva uma descrição útil e estratégica para todos.

Boa sorte!

Ron Muns
CEO and Founder
HDI, Leading IT Service and Support