При выполнении текущих задач любите ли вы отвлекаться на решение «срочных» вопросов в рабочих чатах? Мы думаем, что нет! Представьте ситуацию: вы запускаете задачу, но вас отвлекает уведомление в чате, в котором вас срочно просят помочь с вопросом пользователя.
И вот вы уже участвуете в активном обсуждении и разбираетесь, баг это или фича.
А теперь представьте, что помимо вас в этом чате присутствует целый отдел разработки, состоящий из 80+ человек, и в этих обсуждениях участвует каждый из участников.
В SuperJob в любой непонятной ситуации наша техподдержка сразу писала в чаты в Slack и тем самым отвлекала всех участников от текущих дел.
Поэтому мы, отдел тестирования, постарались изменить процесс работы с ошибками со стороны пользователей.
Раньше наш процесс работы с ошибками от пользователей был таким: 
- в отзыв поступила жалоба от пользователя и была передана специалисту технической поддержки;
- специалист техподдержки выяснил подробности, но не стал воспроизводить проблему, а сразу создал задачу в Jira в проекте техподдержки;
- задание выкладывалось в отдельный чат в Slack (а таких чатов у нас, кстати, было 6: по проблемам соискателей, работодателей и по каждой платформе в приложениях);
- в чате тестировщик взял это задание и начал разбираться, локализовать проблему и придумывать, как оно должно работать;
- Помимо тестировщика в чат заходили и заинтересованные разработчики, которые принимали активное участие в обсуждении;
- После всех уточнений тестировщик перенес задачу в нужный проект разработки, изменил название и скорректировал описание.
Также описание задачи не всегда позволяло быстро понять суть проблемы, поэтому приходилось открывать переписку между техподдержкой и пользователем, а затем тратить больше времени на редактирование этой задачи.
Многие проблемы не были ошибками и вообще не должны были дойти до разработчиков.
Но при этом разработчики уже были вовлечены в процесс обсуждения, отвлекаясь от своих задач.
Мы решили, что нужно изменить этот процесс и сделать техподдержку более независимой.
Первый то, что мы хотели изменить, это избавиться от многократной перепроверки бага тестером.
Решение было так: мы описали рабочий процесс, по которому работают тестировщики, немного его преобразовали и передали специалистам техподдержки.
Теперь через это пришлось пройти при работе с проблемой от пользователя.
Если кратко описать этот рабочий процесс, то теперь специалист техподдержки самостоятельно перепроверяет требования перед внесением ошибки, обязательно воспроизводит ошибку и добавляет задачу в проект разработки.
Если ситуация не воспроизводится, задача добавляется в проект техподдержки и «приостанавливается» до следующего обращения пользователя.
При появлении новых запросов пользователей технологу необходимо еще раз попытаться воспроизвести проблему, а если она воспроизводится, то передать задачу в проект разработки.
Если повторная жалоба также не воспроизводится, то задача все равно передается в проект разработки с обязательным комментарием о том, что проблему воспроизвести невозможно.
Возможно, в такой ситуации разработчики со своей стороны смогут разобраться и решить проблему.
Таким образом, мы не тратим много времени на одиночные запросы и только в случае повторных запросов привлекаем разработчиков.
Плюсы: мы экономим время специалиста по тестированию, а зачастую и разработчиков, которые увидели вопрос в чате и присоединились, чтобы его узнать.
Наша вторая проблема был дизайн самих жучков который имел малоинформативное название, сумбурное, а иногда и просто загадочное описание.
Например: 
Решение: Мы рассказали и показали на примерах, как мы создаём имя багу с помощью команды «Что? Где? Когда?".
Например, заголовок задачи «проблема с «Вакансии на вашем сайте»» после доработки стал более прозрачным: «Вакансии не отображаются в блоке «Вакансии на вашем сайте» при переходе в раздел трансляции».
Что за «беда» случилась, всем стало понятно уже из названия.
Мы договорились использовать шаблоны описаний.
Мы добавили их в Jira. При создании ошибки вам необходимо выбрать необходимый шаблон в зависимости от платформы и заполнить его.
Вся информация записана в инструкции в Confluence, к которой вы всегда можете обратиться.
Плюсы: Искать баги в Jira стало проще, а по названию можно сразу определить, в чем проблема, не вдаваясь в задачу.
Описание стало структурированным и более понятным для разработчиков.
Третий отвлекая всех фактор - Этот наличие нескольких чатов с технической поддержкой.
Решение: «Еще больше чатов!» 
Мы решили сделать только один чат #поддержки и закрыть все остальные.
Теперь все внутренние сотрудники пишут туда найденные проблемы, а отвечают там только ребята из техподдержки.
Они также проводят перекрестные проверки и создают задачи.
Плюсы: Теперь есть одна точка входа, куда вы можете сообщить об обнаруженной проблеме.
Раньше разработчики могли видеть какой-то баг, но просто не знали, куда о нем сообщить.
Сначала мне нужно было выяснить, в какой чат его отправить.
Сложно.
Поэтому некоторые просто не заморачивались и оставляли всё как есть (или особо совестливые передавали испытателям).
Но, конечно, были определенные трудности в реализации такого подхода.
Например, специалист техподдержки не всегда может правильно локализовать проблему и определить, бэкенд она или фронтенд. И из-за этого есть риск внести ошибку не в тот проект или не в ту команду, а потом снова потерять время на перенос задач из одного раздела в другой.
Еще есть ошибки в описаниях и названиях багов.
Поэтому пока надо смотреть задачи по устранению этих недостатков, но их количество не столь критично.
После всех нововведений наш рабочий процесс выглядит так: 
- специалисты техподдержки стали более независимыми, им не нужно ждать, пока ошибка будет перепроверена тестировщиками;
- ошибка от пользователя быстрее регистрируется в Jira и может быть раньше принята в разработку;
- тестировщики и разработчики не отвлекаются от своих задач;
- разработчики теперь могут устраивать холивары и общаться в чатах на более интересные темы.
Как в вашей компании организован процесс борьбы с ошибками со стороны пользователей? Поделитесь своими примерами :) Теги: #баги #Управление разработкой #тестирование #Тестирование ИТ-систем #рабочий процесс #техническая поддержка #процессы в нем
-
Создание Контента Для Видео
19 Oct, 24 -
Волоконная Оптика
19 Oct, 24 -
Типы Гейм-Дизайнеров
19 Oct, 24 -
Веб-Авторизация: Что Это Может Быть?
19 Oct, 24 -
Приближения Иррационального
19 Oct, 24
