Tame your tech support
Do you like to be distracted when solving current tasks to solve “urgent” questions in working chats? We think not!
Imagine a situation: you start a task, but you are distracted by a notification in a chat, in which you are urgently asked to help with a question from a user. And now you are already involved in active discussion and understand, this is a bug or a feature.
Now imagine that, besides you, the whole development department, consisting of 80+ people, is present in this chatty, and each of the participants is involved in these discussions.
')
In our SuperJob, technical support in any incomprehensible situation immediately wrote to the chats in Slack and thus distracted all participants from current activities. Therefore, we, the testing department, tried to change the process of working with bugs from users.
Previously, the process of working with bugs from users, we had this:
As a result, it turned out that a lot of time is spent on the discussion and re-checking of a problem by several experts at once. Also, the task description did not always allow to quickly get into the essence of the problem, so I had to open technical support correspondence with the user, and then spend more time editing this task.
Many problems were not bugs and generally should not have reached the developers. But at the same time, developers have already been included in the discussion process, distracting from their tasks.
We decided that we need to change this process and make technical support more independent.
The first thing we wanted to change was to get rid of the repeated recheck of the bug by the tester.
The solution was this: we described the workflow for which testers work, transformed it a bit and transferred it to technical support specialists. Now they had to go through it when working with a problem from the user.
If you briefly describe this workflow, now the technical support specialist independently checks the requirements before entering the bug, necessarily reproduces the error and brings the task into the development project.
If the situation is not reproduced, the task is started up in the technical support project and “suspended” until the next request from users. If there are new requests from users, the technical needs to try again to reproduce the problem, and if it is reproduced, then transfer the task to the development project.
If the repeated complaint is also not reproduced, all the same, the task is transferred to the development project with the obligatory comment that the problem could not be reproduced. Perhaps in this situation, developers, for their part, will be able to sort out and solve the problem.
So we do not spend a lot of time on individual hits and only in the case of a second call we connect developers.
Pros: we save the time of a testing specialist, and often developers who saw the question in the chat and connected to the survey.
Our second problem was the design of the bugs themselves , which had
non-informative title, muddled, and sometimes just a mysterious description.
For example:
Solution: using examples, they told and showed how we make up the name for the bug using the principle “What? Where? When?".
For example, the name of the task “troubles with“ Jobs on your site ”” became more transparent after processing: “Jobs in the“ Jobs on your site ”block are not displayed when switching to the broadcast section”. What a “trap” happened, it became clear to everyone only from the name.
Agreed to use templates for description. We have them added to Jira. When creating a bug, you must select the desired template depending on the platform and fill it.
All information was recorded in the instructions in Confluence, which can always be accessed.
Pros: it became easier to search for bugs in Jira, and by name you can immediately determine what the essence is without going into the task. The description has become structured and more understandable for developers.
The third distracting factor is the presence of several chats with technical support.
Solution: “More Chats!”
We decided to make only one #support chat, and close the rest. All internal employees now throw off the problems they find in it, and only technical support guys are responsible there. They carry out rechecks and give birth to tasks.
Pros: now there is one entry point where you can report a problem found.
Previously, developers could see a bug, but simply did not know where to report about it. First you had to figure out which chat to throw it into. It is difficult ... Therefore, some people simply did not bother and leave everything as it is (well, or especially conscious people would throw off testers).
But, of course, it was not without some difficulties in the implementation of this approach. For example, a technical support specialist cannot always correctly localize a problem, determine whether it is a backend or frontend. And because of this, there is a risk to get a bug in the wrong project or on the wrong team, and then again lose time on transferring tasks from one section to another.
There are still errors in the descriptions and names of bugs. Therefore, while it is necessary to look at the tasks to eliminate these shortcomings, but their number is not so critical.
After all the innovations, our workflow looks like this:
And how do you work with bugs from users in your company? Share your examples :)
Imagine a situation: you start a task, but you are distracted by a notification in a chat, in which you are urgently asked to help with a question from a user. And now you are already involved in active discussion and understand, this is a bug or a feature.
Now imagine that, besides you, the whole development department, consisting of 80+ people, is present in this chatty, and each of the participants is involved in these discussions.
')
In our SuperJob, technical support in any incomprehensible situation immediately wrote to the chats in Slack and thus distracted all participants from current activities. Therefore, we, the testing department, tried to change the process of working with bugs from users.
Previously, the process of working with bugs from users, we had this:
- feedback received a complaint from the user and passed on to a technical support specialist;
- the technical support specialist clarified the details, but did not reproduce the problem, but immediately started a task in Jira in the technical support project;
- the task was thrown off in a separate chat in Slack (and there were 6 such chatics, by the way: on the problems of applicants, employers, and for each platform in the applications);
- in the chat, this task was taken by the tester and began to understand, locate the problem and figure out how it should work;
- in addition to the tester, caring developers also went into the chat and took an active part in the discussion;
- after all clarifications, the tester transferred the task to the desired development project, changed the name, corrected the description.
As a result, it turned out that a lot of time is spent on the discussion and re-checking of a problem by several experts at once. Also, the task description did not always allow to quickly get into the essence of the problem, so I had to open technical support correspondence with the user, and then spend more time editing this task.
Many problems were not bugs and generally should not have reached the developers. But at the same time, developers have already been included in the discussion process, distracting from their tasks.
We decided that we need to change this process and make technical support more independent.
The first thing we wanted to change was to get rid of the repeated recheck of the bug by the tester.
The solution was this: we described the workflow for which testers work, transformed it a bit and transferred it to technical support specialists. Now they had to go through it when working with a problem from the user.
If you briefly describe this workflow, now the technical support specialist independently checks the requirements before entering the bug, necessarily reproduces the error and brings the task into the development project.
If the situation is not reproduced, the task is started up in the technical support project and “suspended” until the next request from users. If there are new requests from users, the technical needs to try again to reproduce the problem, and if it is reproduced, then transfer the task to the development project.
If the repeated complaint is also not reproduced, all the same, the task is transferred to the development project with the obligatory comment that the problem could not be reproduced. Perhaps in this situation, developers, for their part, will be able to sort out and solve the problem.
So we do not spend a lot of time on individual hits and only in the case of a second call we connect developers.
Pros: we save the time of a testing specialist, and often developers who saw the question in the chat and connected to the survey.
Our second problem was the design of the bugs themselves , which had
non-informative title, muddled, and sometimes just a mysterious description.
For example:
Solution: using examples, they told and showed how we make up the name for the bug using the principle “What? Where? When?".
For example, the name of the task “troubles with“ Jobs on your site ”” became more transparent after processing: “Jobs in the“ Jobs on your site ”block are not displayed when switching to the broadcast section”. What a “trap” happened, it became clear to everyone only from the name.
Agreed to use templates for description. We have them added to Jira. When creating a bug, you must select the desired template depending on the platform and fill it.
All information was recorded in the instructions in Confluence, which can always be accessed.
Pros: it became easier to search for bugs in Jira, and by name you can immediately determine what the essence is without going into the task. The description has become structured and more understandable for developers.
The third distracting factor is the presence of several chats with technical support.
Solution: “More Chats!”
We decided to make only one #support chat, and close the rest. All internal employees now throw off the problems they find in it, and only technical support guys are responsible there. They carry out rechecks and give birth to tasks.
Pros: now there is one entry point where you can report a problem found.
Previously, developers could see a bug, but simply did not know where to report about it. First you had to figure out which chat to throw it into. It is difficult ... Therefore, some people simply did not bother and leave everything as it is (well, or especially conscious people would throw off testers).
But, of course, it was not without some difficulties in the implementation of this approach. For example, a technical support specialist cannot always correctly localize a problem, determine whether it is a backend or frontend. And because of this, there is a risk to get a bug in the wrong project or on the wrong team, and then again lose time on transferring tasks from one section to another.
There are still errors in the descriptions and names of bugs. Therefore, while it is necessary to look at the tasks to eliminate these shortcomings, but their number is not so critical.
After all the innovations, our workflow looks like this:
- technical support specialists have become more independent, they do not need to wait for the tester to recheck the bug;
- the user’s bug starts in Jira faster and can be taken into development earlier;
- testers and developers are not distracted from their tasks;
- developers can now
arrange holivarchat in chatik on more interesting topics.
And how do you work with bugs from users in your company? Share your examples :)
Source: https://habr.com/ru/post/441320/
All Articles