Suporte técnico Miran: como funciona

O fogo no qual você queima deve ser mantido.
V.O. Pelevin, "Geração P"



Olá Habr! Meu nome é Alexander Soloviev, sou o chefe de suporte técnico dos data centers da Miran.

Diga-me, você já tentou escrever livros didáticos? Eu não No entanto, o texto abaixo é uma espécie de manual de treinamento para organizar o suporte técnico. Como parte do artigo, gostaria de lhe dizer qual é o suporte técnico dos data centers da Miran: que tipo de "engrenagem" gira e por que ela gira dessa maneira, e não o contrário.


Para conveniência do leitor, dividirei este artigo em várias partes semânticas.

  1. No primeiro, falaremos sobre os elementos básicos do trabalho do TP - equipe, ciclo de vida do aplicativo, priorização.
  2. Na segunda parte, abordaremos as questões de manutenção do conhecimento dos engenheiros de suporte técnico em um determinado nível.
  3. Na terceira parte final, falaremos sobre como fazer com que tudo isso funcione.

Falarei sobre motivação, em particular, não financeira, e darei algumas dicas sobre como organizar recompensas e punições corporativas.

Noções básicas de suporte técnico


Para organizar o trabalho de suporte técnico, você precisa responder a algumas perguntas simples:

  1. Requer suporte para um produto (serviço) ou é sobre suporte a vários produtos, ou seja, suportando vários produtos completamente diferentes?
  2. Qual SLA é necessário para chamadas de suporte técnico?
  3. É necessário suporte 24 horas por dia?


Primeiro


O suporte a monoprodutos requer um número mínimo de especialistas. Por exemplo, se você espera cerca de dez aplicativos por turno, pode tentar mudar o suporte para um engenheiro especializado.
O suporte a vários produtos requer a seleção de especialistas em produtos ou a separação do tráfego de chamadas por complexidade, expressa na organização de várias linhas de suporte.
Adotamos o caminho de dividir os engenheiros de acordo com seus conhecimentos e competências em três componentes: a primeira, a adicional e a segunda linhas de suporte técnico.

Segundo


Quanto mais rigoroso o SLA, mais recursos a empresa precisará para cumprir. Existem vários recursos: engenheiros qualificados, sistemas de informação, equipamentos, documentos regulatórios etc. Considere a questão da equipe. Para atender aos requisitos de SLA, a equipe deve ser proporcional ao número médio de chamadas de suporte técnico, levando em consideração o tempo e os padrões de qualidade.

Com base no exposto, a equipe de nossos engenheiros é a seguinte:
• primeira linha - 10 pessoas;
• linha adicional - 4 pessoas;
• segunda linha - 5 pessoas.

Terceiro


O suporte técnico 24 horas por dia é um serviço caro. O desempenho de alta qualidade desse serviço no modo 24x7x365 exigirá pelo menos 5 engenheiros e, no caso mais simples, ou seja, no caso de suporte a um único produto. Se você precisar organizar o suporte 24 horas, sinta-se à vontade para multiplicar os custos por 5. Mas, antes de tudo, pense se você precisa (você pode fazer isso sem um portal de autoatendimento, etc.). Se você ainda precisar, é possível terceirizar.



O que todas essas pessoas estão fazendo


A tarefa dos engenheiros de primeira linha é processar rápida e eficientemente o apelo do cliente. Processar significa classificar e enviar corretamente para o trabalho.
Após o processamento, o engenheiro da primeira linha resolve o aplicativo por conta própria, se for da seção "faça-o rapidamente, aqui e agora", ou transfira o aplicativo para outra linha se for "de longa duração" ou se for um "mau funcionamento".
A tarefa dos engenheiros de linha adicionais é trabalhar com aplicativos que levam mais de um dia para serem concluídos.
A tarefa dos engenheiros de segunda linha é solucionar o mais rápido possível e resolver aplicativos complexos "aqui e agora".

Modos de engenharia


Primeira linha : horário - 2/2, turnos de 12 horas, das 08:00 às 20:00.
Linha adicional : programação - cinco dias, turnos de 8 horas, das 08:00 às 12:00.
Segunda linha : horário - 2/2, turnos de 12 horas das 08:00 às 20:00.

As programações de turno de engenheiro são mantidas pelo Google Agenda.



Ciclo de vida e status das aplicações no TP


A maneira mais fácil de acompanhar o ciclo de vida do aplicativo é de acordo com este esquema:


Vou explicar separadamente cada um dos pontos.

  • O status novo é adquirido por qualquer aplicativo recebido de uma fonte externa. A tarefa do engenheiro da primeira linha é processar inicialmente o aplicativo recebido e transferi-lo para o contratado.
  • O status de aberto é atribuído ao aplicativo quando um especialista está ocupado com a decisão.
  • Se o aplicativo foi identificado como spam, ele adquire o status excluído .
  • Se o aplicativo não for spam, mas não contiver um apelo essencial ao suporte técnico, será atribuído o status rejeitado .
  • O status resolvido é atribuído ao aplicativo após a resolução do problema / problema de acordo com o executor.
  • O status parado significa que o trabalho no aplicativo é suspenso temporariamente por iniciativa do cliente ou de acordo com ele.
  • O status fechado é atribuído após o cliente considerar que sua tarefa foi resolvida com êxito.


Digitação de aplicativo


O tipo de aplicação é o critério mais importante. Ele determina a taxa de reação e o tempo para resolver o problema indicado no ticket. No Miran, de acordo com o ITIL, as solicitações são divididas nos seguintes tipos. Dou-os em ordem de importância:

Incidentes
Os incidentes incluem mau funcionamento e mau funcionamento do equipamento, bem como outros eventos que implicaram uma deterioração significativa na qualidade dos serviços. Aplicativos deste tipo são executados em ordem de prioridade e têm precedência sobre outros tipos de aplicativos. Somente incidentes podem ter precedência sobre o processamento.

Exemplos de incidentes: indisponibilidade de serviço, falha de hardware.

RFS - Solicitação de Serviço
O cliente precisa de um serviço como parte dos serviços prestados. A solicitação não está relacionada a uma falha ou falha na infraestrutura de TI. É realizado imediatamente na fila geral na ausência de aplicativos prioritários.

Exemplo: uma solicitação para reiniciar o servidor.

RFC - Solicitação de mudança
Solicitação de alteração na composição e / ou escopo dos serviços prestados ao cliente. O tempo de processamento é determinado pela gerência da empresa individualmente, de acordo com o cliente.

Exemplos: uma solicitação para trocar de equipamento.

RFI - Solicitação de informações
Foram solicitadas informações sobre o serviço, incluindo relatórios sobre o volume de consumo de energia, relatórios de serviço etc. É realizado imediatamente na fila geral na ausência de aplicativos prioritários.

A prioridade do aplicativo, afetando a velocidade da reação e da decisão, é calculada com base nas informações recebidas do cliente, levando em consideração várias regras e pedidos internos. Existem duas prioridades: inicial e final. A prioridade inicial é definida de acordo com o cliente e determina a velocidade do processamento do incidente. A prioridade final é definida pelo engenheiro após a conclusão do trabalho e reflete o nível real de degradação dos serviços. Muitas vezes, essas prioridades não são iguais.

As prioridades são alocadas da seguinte maneira:

  • o funcionamento do segmento de rede está quebrado (o centro de comunicação está indisponível, o comutador básico está com defeito) - 40;
  • degradação significativa de vários serviços prestados ao cliente - 30;
  • degradação significativa de um dos serviços prestados ao cliente - 20;
  • degradação dos serviços, que não tem impacto significativo em sua natureza - 10;
  • nenhuma influência no atendimento ao cliente - 0.

Eu acho que isso pode terminar sem problemas a análise da teoria. Nos bastidores, haverá tempos de reações a incidentes e solicitações, níveis de escalação, motivação financeira e outras informações, mais ou menos padrão para outras empresas. Vamos para coisas mais interessantes.

Manutenção do nível de conhecimento necessário


No trabalho do serviço de suporte técnico, nos esforçamos para regular tudo o que é regulamentado, para ser transparente para o cliente e também para formalizar e digitalizar qualquer informação que possa ser útil e aplicável no futuro. Feedback dos clientes, o nível de conhecimento de nossos funcionários, suas realizações e facaps - tudo isso é meticulosamente digitalizado, analisado e subsequentemente afeta as decisões de gerenciamento.

Durante vários dias de folga, um engenheiro de suporte técnico pode alterar alguns regulamentos, novos "introdutórios" serão exibidos, o que significa que no início do turno é necessário verificar a relevância do conhecimento dos engenheiros. Isso é feito com a ajuda da tecnologia de modelagem situacional, treinando para resolver situações nas quais o conhecimento especificado está em demanda. Chamamos uma situação de caso. No início do turno, o engenheiro recebe uma parte de vários casos de usuários. Essa abordagem permite que os engenheiros mantenham o conhecimento necessário em suas mentes e os atualizem constantemente. Como resultado, a qualidade do trabalho aumenta. Para reduzir o estresse, o prazo para resolver casos de usuários é definido no final do turno, embora, na verdade, sejam suficientes dez minutos para um especialista.

Em que consiste exatamente um caso típico de usuário?

Existem 4 blocos semânticos no total:

  1. Bloco de informações
    Ele contém informações úteis que precisam ser aprendidas.
  2. Pacote de blocos
    Este bloco permite associar novas informações ao "transporte" dessas informações na memória humana.
  3. Opções de resposta
    De fato, este é o "transporte" de informações na memória.
  4. Link de prova
    Um link para uma fonte confiável onde você pode aprender essas informações.



É assim que um caso de usuário padrão se parece no exemplo de material histórico

Todos os blocos da base de usuários estão relacionados em significado e tema. Idealmente, o bloco de informações deve conter uma dica de uma opção de resposta e, para esclarecimento, você precisa abrir o link da prova e estudar em detalhes a pergunta que está sendo examinada lá.

Introduzindo essa prática, deparei-me com um momento desagradável: não existe uma única ferramenta completa no mercado que permita manter uma base de conhecimento, distribuir “de maneira inteligente” os casos de usuários pelos funcionários e verificar suas respostas.

Atualmente, estamos usando várias ferramentas.

  • Request Tracker (RT) - define a lógica da interação dos sistemas.
  • O Google Calendar by API "distribui" a lista de funcionários e o número de casos de usuários para cada um.
  • As planilhas do Google fornecem informações para a formação de um caso de usuário.

De fato, o sistema funciona da seguinte maneira:

  1. Uma lista de funcionários envolvidos no treinamento do conhecimento é formada.
  2. Para cada funcionário, tópicos de casos de usuários são definidos.
  3. Um caso de usuário é criado para cada tópico e transferido para o funcionário.
  4. Durante o dia útil, o engenheiro deve resolver todos os casos de usuários.
  5. As respostas são verificadas e o resultado da verificação de cada caso de usuário é armazenado no sistema.

Um bom engenheiro resolve um caso de usuário em cerca de um minuto. Trapacear e "contar" é bastante problemático, cuidamos de nosso próprio sistema anti-trapaceiro.

Lembre-se: em nenhum caso, tente administrar o nível de conhecimento dos funcionários nos departamentos em que você não controla a motivação.

Arma, papagaios e motivação


Falei com detalhes suficientes sobre como o serviço de suporte técnico funciona. Resta entender outro ponto importante: por que isso funciona? :)

Tudo repousa sobre dois pilares. Esses pilares são uma motivação não financeira e financeira.

O famoso gangster Al Capone disse: "Com uma palavra gentil e uma arma, você pode conseguir muito mais do que apenas uma palavra gentil". Lamentavelmente, nessa metáfora, motivação financeira é uma boa palavra e não financeira já é uma arma “boa e velha”.

Motivação não financeira



Três pilares da motivação não financeira: fome, frio e paz, objetividade da avaliação, evidência de competência, facilidade de administração

Qualquer pessoa reage muito negativamente às multas expressas em dinheiro ... mas, felizmente, é muito mais fácil se preocupar com multas em "papagaios". Enquanto isso, papagaios, se você pode cozinhá-los, motivam muito, muito significativamente os funcionários.

Nós escolhemos como qualidade. o papagaio está desligado, mas teoricamente você pode escolher outra coisa. O tempo de lazer é bom porque o sentimos por todos os funcionários, é procurado para o objetivo pretendido e não há necessidade de explicar aos subordinados o que é e para que serve. Antes de tudo, ao escolher uma unidade de conta, deve-se proceder do fato de que não deve ser um “cavalo esférico no vácuo”. A unidade contábil deve ser tangível para o empregado.

No âmbito da motivação não financeira, os funcionários são privados não de dinheiro, mas de folgas e, consequentemente, da oportunidade de usar os benefícios da motivação não financeira. Isso é desagradável, mas não como uma multa: existe um incentivo para crescer e a lealdade de uma pessoa à empresa não sofre. "Talentos" são incentivados por folga. Um funcionário pode usar o dia de folga para o objetivo a que se destina: por exemplo, ficar deitado em casa, mas isso não é tão interessante. É mais interessante ir a um cassino com blackjack e mademoiselle para dedicar algum tempo a eventos significativos para você ou sua empresa, por exemplo: serviços médicos fora do VHI, obtenção de certificados profissionais, fitness ou pacotes turísticos, finalmente.

O único menos tempo de folga comparado ao dinheiro é que cada caso de uso, em termos diretos ou monetários, precisa ser verificado separadamente pelas autoridades, o que nem sempre é conveniente. O preço do tempo de folga de nós é de 3000 rublos, você pode ter mais ou menos. O principal é o conforto mútuo do uso de uma unidade de motivação não financeira.

Deixe-me dar um exemplo vivo quando um trabalho específico é concedido de forma não financeira.

A elaboração de bons documentos com casos de usuários para a base de conhecimento não é tanto uma tarefa como um processo. Todo mês, algo novo aparece: clientes, equipamentos, software. Tudo isso, pelas razões já mencionadas acima, requer cuidadosa atenção e documentação.

Se, no início, eu mesmo trabalhei na compilação desses documentos, agora o sistema de reabastecimento da base de conhecimento funciona quase de forma autônoma. Minha tarefa é orientar os funcionários na direção certa, fornecer um vetor de movimento e executar o controle de saída.

Minha experiência mostra que o "preço" de um bom documento equipado com um número suficiente de casos de usuários é de três dias de folga.

Um engenheiro recebe dois dias de folga por um documento que não requer correções significativas.

Uma pessoa recebe um dia de folga se forem necessárias muitas correções, e é mais fácil fazê-las do que explicar como fazê-las corretamente.

Tentamos dar mais tempo para esse trabalho - a partir de 10 dias ou mais. Mas a prática mostrou que uma recompensa demais assusta, e praticamente não há pessoas que querem recebê-la. Portanto, é importante não exagerar na promoção dos funcionários. Pode levá-lo de lado da maneira mais inesperada. Experimente, mas faça-o com cuidado.

Motivação financeira


Cada inscrição concluída por um engenheiro da TP é recompensada com bônus. O valor do bônus é diretamente proporcional à complexidade do aplicativo e às qualificações necessárias para sua implementação. O salário final de um engenheiro é determinado pela soma desses bônus. Obviamente, no caso de um preenchimento "torto" do aplicativo, o bônus por ele queima.

Outra nuance: o salário de um engenheiro está sempre na faixa determinada por sua posição. No mês mais preguiçoso, uma pessoa não receberá menos que o limite inferior desse intervalo, nem receberá mais que o limite superior no mais produtivo. No entanto, ninguém ficará ofendido: todos os batentes são punidos e o processamento é incentivado por motivação não financeira.

Resumir


O artigo acabou sendo inesperadamente volumoso, mas isso não é surpreendente: examinamos a vida do suporte técnico de Miran quase inteiramente, omitindo apenas os detalhes mais chatos ou gerais. No entanto, se eu ainda me esqueci de escrever sobre algo interessante para você ou, durante a sua leitura, você teve perguntas sobre a organização do serviço TP, ficarei feliz em respondê-las nos comentários.

Materiais relacionados


Source: https://habr.com/ru/post/pt464137/


All Articles