Tame your tech support

    Do you like to be distracted by solving urgent issues in work chats when performing current tasks? We think not!

    Imagine a situation: you are starting a task, but you are distracted by a notification in the chat, in which you are urgently asked to help with a question from the user. And now you are already participating in an active discussion and understand if this is a bug or a feature.

    Now imagine that in addition to you, this chat room has the entire development department, consisting of 80+ people, and each of the participants is involved in these discussions.

    In our SuperJob, technical support in any incomprehensible situation immediately chatted in Slack and thereby distracted all participants from current activities. Therefore, we, the testing department, tried to change the process of working with bugs from users.

    image

    Previously, the process of working with bugs from users was as follows:

    image

    • feedback received from the user and was passed to a technical support specialist;
    • a technical support specialist found out the details, but did not reproduce the problem, but immediately started a task in Jira in the technical support project;
    • the task was thrown into a separate chat room in Slack (and there were 6 such chatrooms, by the way: on the problems of applicants, employers, and for each platform in applications);
    • in the chat, the tester took this task and began to understand, localize the problem and figure out how it should work;
    • in addition to the tester, the developers also took part in 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, and corrected the description.

    In the end, it turned out that a lot of time was spent discussing and double-checking one problem at once by several experts. Also, the task description did not always allow you to quickly understand the essence of the problem, so you had to open technical support correspondence with the user, and then spend more time editing this task.

    Many problems were not bugs and should not reach the developers at all. But at the same time, the developers were already involved 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 double-checking of the bug by the tester.

    Decisionit was like this: we described the workflow that testers work on, slightly transformed it and handed it to technical support specialists. Now they had to go through it when working with a problem from the user.

    image

    Briefly describe this workflow, now the technical support specialist independently rechecks the requirements before starting the bug, necessarily reproduces the error and puts the task into the development project.

    If the situation does not reproduce, the task is started in the technical support project and is “suspended” until the next user contact. If there are new requests from users, the tech needs to try again to reproduce the problem, and if it reproduces, then transfer the task to the development project.

    If the repeated complaint is also not reproduced, then the task is still transferred to the development project with the obligatory comment that the problem could not be reproduced. Perhaps in this situation, the developers, for their part, will be able to figure out and solve the problem.

    So we do not spend a lot of time on single calls and only in the case of repeated calls we connect developers.

    Pros: we save the time of the testing specialist, and often also the developers who saw the question in the chat and connected to the clarifications.

    Our second problem was the design of the bugs themselves , which had an
    uninformative name, a chaotic, and sometimes just a mysterious description.
    For example:

    image

    Solution: through examples, they told and showed how we compose a name for a bug using the principle of “What? Where? When?".

    For example, the task name “Trouble from“ Jobs on your site ”after processing has become more transparent:“ Jobs in the block “Jobs on your site” are not displayed when you go to the broadcast section ”. What kind of “trouble” happened, it became clear to everyone only from the name.

    We agreed to use templates for description. We have them added to Jira. When creating a bug, you need to select the desired template depending on the platform and fill it out.

    image

    All information is recorded in the instructions in Confluence, which can always be accessed.

    Pros: it became easier to search for bugs in Jira, and by the 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 distraction all factor - is the presence of several chatik tech support.

    Solution: “More Chatrooms!”

    image

    We decided to make only one chat #support, and close the rest. Now all internal employees are thrown off the found problems, and only the tech support guys answer there. They conduct rechecks and start tasks.

    Pros: now there is one entry point where you can report a problem found.

    Previously, developers could see some kind of bug, but simply did not know where to report it. First you had to figure out which chat to throw it off. It’s difficult ... Therefore, some simply didn’t bother and leave everything as it is (well, or especially conscious ones were thrown off to testers).

    But, of course, there were some difficulties in implementing this approach. For example, a technical support specialist can not always correctly localize a problem, determine whether it is a backend or frontend. And because of this, there is a risk of getting a bug in the wrong project or on the wrong team, and then again losing 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 through the tasks to eliminate these shortcomings, but their number is not so critical.

    After all the innovations, our workflow looks like this:

    image

    • technical support specialists have become more independent, they do not need to wait for testers to double-check the bug;
    • a bug from the user starts up in Jira faster and can be taken into development earlier;
    • testers and developers are not distracted from their tasks;
    • developers can now arrange holivar to chat in chat rooms on more interesting topics.

    image

    And how is the process of working with bugs from users arranged in your company? Share your examples :)

    Also popular now: