Você gosta de se distrair resolvendo problemas urgentes nas conversas de trabalho enquanto executa as tarefas atuais? Achamos que não!
Imagine uma situação: você está iniciando uma tarefa, mas é distraído por uma notificação no bate-papo, na qual é urgentemente solicitado que você ajude com uma pergunta do usuário. E agora você já está participando de uma discussão ativa e entende se isso é um bug ou um recurso.
Agora imagine que, além de você, esta sala de bate-papo possui todo o departamento de desenvolvimento, composto por mais de 80 pessoas, e cada um dos participantes está envolvido nessas discussões.
Com a gente no SuperJob, o suporte técnico em qualquer situação incompreensível conversava imediatamente no Slack e, assim, distraía todos os participantes das atividades atuais. Portanto, nós, o departamento de testes, tentamos alterar o processo de trabalhar com erros dos usuários.
Anteriormente, o processo de trabalhar com erros dos usuários era o seguinte:
- Feedback recebido do usuário e transmitido ao especialista de suporte técnico;
- um especialista em suporte técnico descobriu os detalhes, mas não reproduziu o problema, mas iniciou imediatamente uma tarefa em Jira no projeto de suporte técnico;
- a tarefa foi lançada em uma sala de bate-papo separada no Slack (a propósito, havia 6 salas de bate-papo: sobre os problemas de candidatos, empregadores e para cada plataforma nos aplicativos);
- no bate-papo, o testador pegou essa tarefa e começou a entender, localizar o problema e descobrir como ele deveria funcionar;
- Além do testador, os desenvolvedores também participaram do bate-papo e participaram ativamente da discussão;
- após todos os esclarecimentos, o testador transferiu a tarefa para o projeto de desenvolvimento desejado, alterou o nome e corrigiu a descrição.
No final, verificou-se que muito tempo foi gasto discutindo e verificando novamente um problema de uma vez por vários especialistas. Além disso, a descrição da tarefa nem sempre permitia que você entendesse rapidamente a essência do problema; portanto, era necessário abrir a correspondência do suporte técnico com o usuário e gastar mais tempo editando essa tarefa.
Muitos problemas não eram bugs e geralmente não deveriam chegar aos desenvolvedores. Mas, ao mesmo tempo, os desenvolvedores já estavam envolvidos no processo de discussão, distraindo suas tarefas.
Decidimos que precisamos mudar esse processo e tornar o suporte técnico mais independente.
A primeira coisa que queríamos mudar era nos
livrar da verificação dupla do bug pelo testador.A solução foi a seguinte: descrevemos o fluxo de trabalho em que os testadores trabalham, o transformamos levemente e o entregamos a especialistas em suporte técnico. Agora eles precisavam passar por isso ao trabalhar com um problema do usuário.
Descreva brevemente esse fluxo de trabalho, agora o especialista em suporte técnico verifica independentemente os requisitos antes de iniciar o bug, necessariamente reproduz o erro e coloca a tarefa no projeto de desenvolvimento.
Se a situação não se reproduzir, a tarefa será iniciada no projeto de suporte técnico e será "suspensa" até o próximo contato do usuário. Se houver novas solicitações dos usuários, o centro de tecnologia precisará tentar novamente reproduzir o problema e, se ele reproduzir, transfira a tarefa para o projeto de desenvolvimento.
Se a reclamação repetida também não for reproduzida, a tarefa ainda será transferida para o projeto de desenvolvimento com o comentário obrigatório de que o problema não pôde ser reproduzido. Talvez nessa situação, os desenvolvedores, por sua vez, sejam capazes de descobrir e resolver o problema.
Portanto, não gastamos muito tempo em chamadas únicas e somente em caso de chamadas repetidas conectamos os desenvolvedores.
Prós: economizamos o tempo do especialista em testes e, geralmente, também dos desenvolvedores que viram a pergunta no bate-papo e se conectaram aos esclarecimentos.
Nosso segundo problema foi o
design dos próprios bugs , que tinham
nome não informativo, caótico e, às vezes, apenas uma descrição misteriosa.
Por exemplo:
Solução: através de exemplos, contamos e mostramos como compomos um nome para um bug usando o princípio “O quê? Onde Quando?
Por exemplo, o nome da tarefa "Problema de" Trabalhos em seu site "após o processamento se tornou mais transparente:" Trabalhos no bloco "Trabalhos em seu site" não são exibidos quando você vai para a seção de transmissão ". Que tipo de "problema" aconteceu, ficou claro para todos apenas pelo nome.
Concordamos em usar modelos para descrição. Nós os adicionamos a Jira. Ao criar um bug, você precisa selecionar o modelo desejado dependendo da plataforma e preenchê-lo.
Todas as informações são registradas nas instruções do Confluence, que sempre podem ser acessadas.
Prós: ficou mais fácil procurar bugs no Jira e, pelo nome, você pode determinar imediatamente qual é a essência sem entrar na tarefa. A descrição tornou-se estruturada e mais compreensível para os desenvolvedores.
A terceira distração de todas é a
presença de várias salas de bate-papo com suporte técnico.
Solução: “Mais salas de chat!”Decidimos fazer apenas um bate-papo #support e fechar o resto. Agora, todos os funcionários internos são expulsos dos problemas encontrados e apenas os funcionários do suporte técnico respondem lá. Eles realizam novas verificações e iniciam tarefas.
Prós: agora existe um ponto de entrada onde você pode relatar um problema encontrado.
Anteriormente, os desenvolvedores podiam ver algum tipo de erro, mas simplesmente não sabiam onde denunciá-lo. Primeiro você tinha que descobrir qual o bate-papo para iniciá-lo. É difícil ... Portanto, alguns simplesmente não se incomodaram e deixaram tudo como estão (bem, ou pessoas especialmente conscientes jogaram fora os testadores).
Mas, é claro, houve algumas dificuldades na implementação dessa abordagem. Por exemplo, um especialista em suporte técnico nem sempre pode localizar corretamente um problema, determinar se é um back-end ou front-end. E, por causa disso, existe o risco de ocorrer um erro no projeto ou na equipe errada e, novamente, perder tempo na transferência de tarefas de uma seção para outra.
Ainda existem erros nas descrições e nomes dos erros. Portanto, embora seja necessário analisar as tarefas para eliminar essas deficiências, mas seu número não é tão crítico.
Depois de todas as inovações, nosso fluxo de trabalho fica assim:
- especialistas em suporte técnico tornaram-se mais independentes, não precisam esperar que os testadores verifiquem o bug;
- um bug do usuário inicia no Jira mais rapidamente e pode ser levado ao desenvolvimento mais cedo;
- testadores e desenvolvedores não se distraem de suas tarefas;
- os desenvolvedores agora podem
organizar o holivar para conversar em salas de bate-papo sobre tópicos mais interessantes.
E como o processo de trabalhar com erros de usuários é organizado em sua empresa? Compartilhe seus exemplos :)