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

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

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

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



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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

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


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

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

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

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

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

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

А как у вас в компании устроен процесс работы с багами от пользователей? Делитесь своими примерами :)