Приручи свою техподдержку

    Нравится ли вам при выполнении текущих задач отвлекаться на решение “срочных” вопросов в рабочих чатах? Думаем, что нет!

    Представьте себе ситуацию: вы приступаете к задаче, но вас отвлекает уведомление в чатике, в котором вас срочно просят помочь с вопросом от пользователя. И вот вы уже участвуете в активном обсуждении и разбираетесь, баг это или фича.

    А теперь представьте, что помимо вас в этом чатике присутствует весь отдел разработки, состоящий из 80+ человек, и каждый из участников вовлекается в эти обсуждения.

    У нас в SuperJob техподдержка в любой непонятной ситуации сразу же писала в чаты в Slack и тем самым отвлекала всех участников от текущей деятельности. Поэтому мы — отдел тестирования — попробовали изменить процесс работы с багами от пользователей.

    image

    Раньше процесс работы с багами от пользователей у нас был такой:

    image

    • в обратную связь поступала жалоба от пользователя и передавалась специалисту техподдержки;
    • специалист техподдержки выяснял подробности, но не воспроизводил проблему, а сразу заводил задачу в Jira в проекте техподдержки;
    • задача скидывалась в отдельный чатик в Slack (а чатиков таких, к слову, у нас было 6: по проблемам соискателей, работодателей и для каждой платформы в приложениях);
    • в чате эту задачу брал тестировщик и начинал разбираться, локализовывать проблему и выяснять, как должно работать;
    • кроме тестировщика в чат заходили также неравнодушные разработчики и принимали активное участие в обсуждении;
    • после всех выяснений тестировщик переносил задачу в нужный проект разработки, менял название, корректировал описание.

    В итоге получалось, что тратится много времени на обсуждение и перепроверку одной проблемы сразу несколькими специалистами. Также описание задачи не всегда позволяло быстро вникнуть в суть проблемы, поэтому приходилось открывать переписку техподдержки с пользователем, а затем еще тратить время на редактирование этой задачи.

    Многие проблемы не являлись багами и вообще не должны были дойти до разработчиков. Но при этом разработчики уже включались в процесс обсуждения, отвлекаясь от своих задач.

    Мы решили, что нам нужно изменить этот процесс и сделать техподдержку более самостоятельной.

    Первое, что нам захотелось изменить — это избавиться от повторной перепроверки бага тестировщиком.

    Решение было таким: мы описали workflow, по которому работают тестировщики, немного преобразовали его и передали специалистам техподдержки. Теперь они должны были проходить по нему при работе с проблемой от пользователя.

    image

    Если коротко описать этот workflow, то теперь специалист техподдержки самостоятельно перед заведением бага перепроверяет требования, обязательно воспроизводит ошибку и заводит задачу в проект разработки.

    Если ситуация не воспроизводится, задача заводится в проекте техподдержки и “подвешивается” до следующего обращения пользователей. Если есть новые обращения от пользователей, техподу необходимо еще раз попробовать воспроизвести проблему, и если она воспроизводится, то перенести задачу в проект разработки.

    Если повторная жалоба также не воспроизводится, то все равно задача переносится в проект разработки с обязательным комментарием о том, что проблему не удалось воспроизвести. Возможно в такой ситуации разработчики со своей стороны смогут разобраться и решить проблему.

    Так мы не тратим много времени на единичные обращения и только в случае повторного обращения подключаем разработчиков.

    Плюсы: мы экономим время специалиста по тестированию, а часто ещё и разработчиков, которые видели вопрос в чате и подключались к выяснениям.

    Второй нашей проблемой было оформление самих багов, которые имели
    неинформативное название, сумбурное, а порой и просто загадочное описание.
    Например:

    image

    Решение: на примерах рассказали и показали, как мы составляем название для бага, используя принцип ”Что? Где? Когда?”.

    Например, название задачи «трабла с “Вакансии на вашем сайте”» после переработки стало более прозрачным: «Не отображаются вакансии в блоке “Вакансии на вашем сайте” при переходе в раздел трансляции». Что за “трабла” произошла, стало уже всем понятно только из названия.

    Договорились использовать шаблоны для описания. Они у нас добавлены в Jira. При создании бага необходимо выбрать нужный шаблон в зависимости от платформы и заполнить его.

    image

    Всю информацию зафиксировали в инструкции в Confluence, к которой всегда можно обращаться.

    Плюсы: баги стало легче искать в Jira, а по названию сразу можно определить, в чем суть, не заходя в задачу. Описание стало структурированным и более понятным для разработчиков.

    Третий отвлекающий всех фактор — это наличие нескольких чатиков с техподдержкой.

    Решение: «Ещё больше чатиков!»

    image

    Мы решили сделать только один чат #support, а все остальные закрыть. В него теперь скидывают найденные проблемы все внутренние сотрудники, а отвечают там только ребята из техподдержки. Они же проводят перепроверки и заводят задачи.

    Плюсы: теперь есть одна точка входа, куда можно сообщить о найденной проблеме.

    Раньше разработчики могли увидеть какой-то баг, но просто не знали, куда о нем сообщить. Для начала нужно было разобраться, в какой чат это скинуть. Сложно… Поэтому некоторые просто не заморачивались и оставлять все как есть (ну или особо сознательные скидывали тестировщикам).

    Но, конечно, не обошлось и без определенных сложностей при внедрении такого подхода. Например, специалист техподдержки не всегда может правильно локализовать проблему, определить, это backend или frontend. И из-за этого есть риск завести баг не в том проекте или не на ту команду, а потом снова потерять время на переносе задач из одного раздела в другой.
    До сих пор есть ошибки в описаниях и названиях багов. Поэтому пока приходится отсматривать задачи для устранения этих недочетов, но их количество не такое критичное.

    После всех нововведений наш workflow выглядит так:

    image

    • специалисты техподдержки стали более самостоятельными, им не нужно ждать перепроверки бага тестировщиками;
    • баг от пользователя заводится в Jira быстрее и может быть раньше взят в разработку;
    • тестировщики и разработчики не отвлекаются от своих задач;
    • разработчики теперь могут устраивать холивар общаться в чатиках на более интересные темы.

    image

    А как у вас в компании устроен процесс работы с багами от пользователей? Делитесь своими примерами :)
    SuperJob.ru
    85,00
    Интернет-сервис для поиска работы
    Поделиться публикацией

    Комментарии 12

      –1
      Так, вообще-то, техподдержка и должна работать так, как указано в конце статьи. Иначе это не техподдержка, а горячая линия какая-то. Хоть у нас и не разработка, но техподдержка является тем, кто обрабатывает и проверяет всю информацию, а уже потом либо решает на месте, либо направляет в нужный отдел для решения.
        0
        Как ваш специалист техподдержки понимает соответствие требованиям? У вас нет аналитиков (бизнес и технических) как класса? Кто у вас разбирается с ТЗ?

        Вы пишите: «если ситуация не воспроизводится, задача заводится в проекте техподдержки и “подвешивается” до следующего обращения пользователей». У вас техподдержки есть весь спектр устройств, чтобы проверить все мобильные приложения на всех версиях андроида, например? Ну и планшеты, само собой.
          0
          Под уточнением требований у нас понимается обращение к ФТ, которые хранятся в Confluence, или непосредственно к аналитикам.

          Конечно у техподдержки нет всего спектра устройств, но есть самые популярные модели (по статистике устройств наших пользователей). Ну и в сложных ситуациях техподдержка всегда может обратиться за помощью к тестировщикам.
            0
            А то, что у них поприбавилось обязанностей практически в разы, сопроводилось ростом ЗП? Просто любой начальник отдела зарубил бы на корню любую идею связанную с увеличением обязанностей его штата, по этому не приминимо к другим организациям…
              0
              Ну у них прибавились те обязанности, которые они и так должны выполнять, перепроверка бага и уточнение требований в ФТ, а не выяснение в чате у разработчиков и тестировщиков, более правильный процесс. «Увеличение обязанностей» только лишь улучшило качество работы отдела техподдержки и систематизировало процесс.
          0
          У нас объединённая служба тестирования и технической поддержки. Существует, безусловно, некоторое разделение и особенности, но такой подход позволяет решать большинство проблем не привлекая разработчиков. Плюсы.
          1. Распределение времени: нет задач по поддержке — занимаешься тестированием, написанием сценариев/автотестов.
          2. Репутация у клиентов. Высокий уровень «первой» линии, т.к. по-сути, она же и 2+. Быстрое и точное решение большинства вопросов.
          3. Точное описание проблемы: вот если вылезает реальный баг, то он передаётся разработчикам уже «облизанным» со всех сторон: и в какой части, и как воспроизвести, и ссылки на посмотреть, и предположения возникновения и несколько проведённых экспериментов.
          Из минусов — уровень специалистов тех. поддержки должен быть существенно выше, чем уровень классической 1-ой линии. Но у нас специфика такова, что безумного потока скриптовых вопросов нет.
            0
            спасибо, что поделились своим опытом!
            0
            Скажите пожалуйста, это плагин для шаблонов или встроенная функция Jira? Где ее найти? Спасибо!
              0
              У нас плагин power-scripts for jira, и через live fields подгружен js скрипт, который прямо в момент отображения формы немного её допиливает. Cделать все это нам помог наш DevOps.
              0
              Ок, спасибо! Значит нам придется просто пока default текст прикрутить. Но идея понравилась все равно!
                0
                У нас у техподдержки своя Jira, у разработки и тестирования своя, поэтому это несколько усложняет процесс. Но в целом наша техподдержка достаточно адекватная, специалисты со второй линии могут сами полезть в серверные логи, найти информацию, при необходимости запросить у пользователей логи с устройств и передать нам.

                Общение есть в небольшом чате который связан с нашей частью продукта, где наша скрам команда и пара человек из саппорта + из ops человек, так что особо не отвлекаемся.

                Есть еще правда бета, куда выделенные пользователи отправляют вопросы, жалобы и предложения. Мы его выборочно просматриваем, но нам в отдельный tg чатик присылают жалобы уже по согласованному шаблону, и дальше мы смотрим, что с этим делать. В целом хаоса еще много, но уже лучше, чем было полгода назад :)

                Спасибо за статью, интересный опыт трансформации взаимодействия между отделами.
                  0
                  Спасибо!
                  Здорово когда получается немного упорядочить хаос :)

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое