Suporte e desenvolvimento: como manter um bom relacionamento?

2. A criticidade do problema. Se você enviar uma tarefa para desenvolvimento sem determinar sua criticidade no início, os desenvolvedores não vão entender imediatamente qual ordem deve ser seguida para a realização das tarefas. Um problema pode esperar uma semana, mas você precisa largar tudo e correr urgentemente para ajudar por conta de outra pessoa. Não se recomenda que os desenvolvedores assumam, imediatamente, tarefas não urgentes enquanto as emergências estão juntando pó na estante. Descubram logo a criticidade da tarefa e somente aí encaminhem para desenvolvimento.

Níveis de severidade

1 Não afeta o trabalho de jeito nenhum, só cria uma inconveniência

2 Afeta o trabalho, mas não criticamente

3 Afeta criticamente o trabalho, mas você pode resistir por uns dois dias

4 Detém completamente o usuário

Exemplos de

✓ O calendário parece horrível

✓ É inconveniente selecionar um período no calendário

✓ Ao salvar as configurações, um pop-up de erro aparece, ocasionalmente, embora as configurações estejam salvas

✓ Para dez casos de uso de modelo, o layout desaparece

✓ A seção de relatórios não funciona

✓ O sistema não abre

✓ O sistema não recebe letras

✓ A regra de automatização não funciona

3. Descrição do problema usando um modelo. Sem um modelo, o operador vai escrever um ensaio sobre um assunto qualquer, e desenvolvimento vai resolver esse enigma e suar muito. Mas suponhamos que você dê um modelo ao operador. Nesse caso, tudo que você tem a fazer é preencher todos os itens: especifique o ID da empresa, anote a severidade do problema, determine o nível de criticidade, descreva todas as etapas do cliente depois da ocorrência do erro, especifique a URL do problema, adicione capturas de tela. E o desenvolvedor pode rapidamente trabalhar na estrutura familiar, entender a situação e decidir o que fazer e quando fazer.

Por exemplo, identificando que o cliente vai alertar os desenvolvedores para dar prioridade à tarefa baseada na importância do cliente para a empresa. E especificar a parte do sistema onde o problema aconteceu vai, rapidamente, ajudar a designar um executor e encontrar os pontos fracos no sistema que precisam ser retrabalhados.

Envio de tarefas no bate-papo comum, PM, ou e-mail dos desenvolvedores

Se você espalhar tarefas aleatoriamente, vai perder o controle sobre elas rapidamente, e os clientes insatisfeitos vão correr para os seus concorrentes e começar a escrever comentários negativos e arruinar o seu karma. Para manter todas as tarefas sob controle, gere solicitações em um sistema automatizado que permita a você configurar prazos finais para cada tarefa e a rastrear sua conclusão. Trabalhamos no serviço Jira, mas você pode usar qualquer um.

Para fazer esse sistema funcionar, você precisa:

1. Designar um administrador dentro de desenvolvimento. Um administrador de tarefa dentro de desenvolvimento aceita tarefas da equipe de suporte e as distribui. Se não tiver essa pessoa, os operadores vão incomodar os desenvolvedores, constantemente, e vão desconcentrá-los das suas tarefas, o que pode levar à geração de conflitos. A função do administrador pode ser assumida pelo líder do departamento de desenvolvimento, gerente de projeto, ou você pode contratar uma pessoa especialmente para cumprir essa tarefa. Ele vai controlar a carga de trabalho de cada funcionário e distribuir tarefas equitativamente, de acordo às suas complexidades e prazos finais.

2. Definição de prazos finais para diferentes tarefas. O desenvolvedor vai assumir tarefas, gradualmente, de acordo com o nível de sua criticidade. Por exemplo, tarefas com o quarto nível de criticidade são realizadas imediatamente, com o terceiro - na semana seguinte, com o segundo - em uma semana, com o primeiro - em duas semanas. Dessa maneira, os desenvolvedores vão ter uma carga de trabalha equitativa, e os operadores de assistência técnica vão ter a previsão de conclusão de todas as suas tarefas e vão poder avisar aos clientes, imediatamente, quando há um movimento no seu problema.

3. Definição de pontos de controle. De acordo com a complexidade das tarefas e com outros fatores, as datas podem ser remanejadas. Para que isso não surpreenda os operadores que estão esperando a solução de suas tarefas, você precisa definir prazos finais para a reconciliação. Por exemplo, a equipe de suporte entra em contato com o administrador todas as terças-feiras e especifica os prazo finais para as suas tarefas. Dessa forma, eles vão saber o que está acontecendo com as suas tarefas e vão comunicar as mudanças para os clientes no tempo devido.

4. Estabelecimento de resposta a desenvolvimento → suporte. Acontece quando um desenvolvedor no processo de solução de um problema tem perguntas adicionais sobre o suporte. Sem uma resposta, ele não pode continuar a trabalhar. Tivemos um caso quando os desenvolvedores escreveram perguntas para tarefas no Jira. Os comentários foram enviados à equipe de suporte no e-mail corporativo, mas eles não leram. Em consequência, começamos a ter muitas tarefas paradas. Quando verificamos, configuramos o sistema para que as mensagens com referências aos operadores chegassem a eles na forma de tickets no Usedesk, como as dos clientes, e o problema foi resolvido. Para impedir a paralisação devido a problemas de comunicação, forneça ao desenvolvimento a oportunidade de receber a resposta do suporte.

5. Crie um bate-papo separado para tarefas críticas. Temos um bate-papo particular para as tarefas especialmente essenciais, onde os operadores as colocam, logo que definem uma tarefa no Jira. E às vezes, o problema é preciso, a solução também é, mas demora um tempo para se formular um problema de acordo com um modelo. Então o operador descreve a tarefa no bate-papo, e os desenvolvedores começam, imediatamente, a vê-lo, depois disso, ele é formulado no Jira. Desenvolvimento, primeiramente, retira as tarefas do bate-papo para trabalhar nelas.