«Вам звонок». Как выстроить отношения между QA и техподдержкой
Каждый из нас сталкивался с технической поддержкой. Кто-то с ней взаимодействует по работе, кто-то по своей должности совмещает тестирование и поддержку, а кто-то стоит перед вопросом — взаимодействовать или делать самому? Мы расскажем, как это сделано у нас в Юле.
У пользователей любого сервиса всегда возникают вопросы, сомнения или проблемы с использованием продукта — именно этих клиентов крайне легко потерять. Грамотно организованная служба поддержки помогает исправить ситуацию и вернуть лояльность пользователя.
В любой IT-компании поддержка ассоциируется с помощью в освоении продукта и решением разного рода клиентских проблем, как правило, технического характера. И в разных компаниях служба поддержки выполняет множество разных функций: поддержки, консультирования, сбора обратной связи. У нас она не только играет свою главную роль — помогает пользователям, —, но и занимается «пожаротушением», а также выдаёт предложения по улучшению продукта.
Помимо «обычных» ошибок, которые возникают у пользователей локально (например, ошибки платёжной системы), в любом сервисе случаются инциденты. Это может быть массовая проблема с интеграцией с каким-либо сервисом, критический баг, простой. Пока разработчики, тестировщики и аналитики расследуют инцидент, наверняка уже набралось много недовольных пользователей, которым срочно необходимо опубликовать товар, получить бонусы, выложить свою историю, купить продвижение, проверить аккаунт. В таких ситуациях при правильном подходе можно добиться сформулированного психологами результата: люди, чьи проблемы хорошо и оперативно решаются, в итоге оказываются довольнее тех, кто с проблемами совсем не сталкивался. И поэтому важно стараться сообщать пользователям конкретные сроки устранения проблемы, а не «кормить» обещаниями.
Бывают ситуации, когда пользователь первым замечает неладное, о чём сразу же уведомляет поддержку. При хорошо налаженной системе внутренней коммуникации проблема может быть решена ещё в зародыше, и в этом во многом будет заслуга службы поддержки, вовремя передавшей информацию.
Обычно все пожелания пользователей относительно продукта служба поддержки передаёт напрямую в продуктовый отдел. У нас фиксируется каждое обращение с предложениями по улучшению.
Три главных действующих лица
Эти действующие лица — наши пользователи, служба поддержки и QA. Давайте посмотрим, как они взаимодействуют между собой в Юле. Сначала разберёмся с общением службы поддержки с пользователями, а затем поговорим об общении поддержки с QA.
Выбор канала коммуникации
Мы активно боремся с мошенниками, поэтому сделали для пользователей несколько точек входа для быстрого и удобного обращения в службу поддержки. Обратиться можно:
- со страницы профиля;
- из карточки товара;
- из встроенного чата;
- и с экрана авторизации для заблокированного аккаунта.
Общаться со службой поддержки наши пользователи могут через любой из этих каналов:
- Юла;
- ВКонтакте;
- Одноклассники;
- Facebook;
- WhatsApp.
Экран профиля:
Карточка товара:
Чат:
Экран авторизации для заблокированного аккаунта:
А что делать в случае простоев? Пользователи не останутся один на один с проблемой, сотрудники поддержки всегда готовы помочь и ответить на все вопросы в соцсетях.
Уведомляем поддержку перед релизом
Зачастую техподдержка — это отдельная команда, которая может находиться отдельно от разработчиков и тестировщиков. Как им узнавать про новые фичи, сценарии оплаты и многое другое, чтобы быстро и качественно помогать пользователям, столкнувшимся с проблемами? Или что делать, если выкатили экспериментальную фичу и не понятно, когда она будет включена? Для информирования службы поддержки у нас есть общий канал со старшими сотрудниками, в котором публикуются изменения функциональности.
Когда фича становится готова к релизу? Ведь сроки могли сдвинуться. Мы каждый раз публикуем changelog, в котором отражены все задачи, которые идут в текущем релизе.
Проведение демо — один из классных ритуалов в Scrum: чинно смотрим продукт, говорим, где что поправить, обсуждаем даты релизов. Всем понятно, чем команда занималась, какая у кого роль, кто будет вносить доработки. Служба поддержки понимает, что именно отправится в эксплуатацию в ближайшее время.
Но если демо по каким-то причинам не проводят (нет времени, например), то отличным способом уведомить команду о новой фиче будет план или записанные видео основных сценариев новой функциональности с кратким описанием. Это позволит ввести всех в курс дела перед релизом;, а ещё это можно использовать для знакомства с проектом новых сотрудников поддержки.
Итак, релиз в эксплуатации. Что делать поддержке, если что-то пойдёт не так? Перейдём к жизненному циклу дефекта.
Пользователь обнаружил дефект
Все обращения пользователей о дефектах попадают в helpdesk.
Обращение получает сотрудник первой линии службы поддержки. Он классифицирует обращение и пытается решить проблему своими силами. Если сделать это в короткие сроки (5–15 минут) не удаётся, или требуются дополнительные компетенции, то инцидент передают второй линии поддержки. Её сотрудники обладают более глубокими техническими навыками и могут разобраться с более сложными проблемами. Если пользователь жалуется на какую-либо ошибку, то инженеры второй линии обязательно проводят дополнительную проверку. Это не означает, что пользователю, который столкнулся с проблемой и может находиться в состоянии стресса, повторно задают одни и те же вопросы. У него выясняют дополнительные подробности, которые помогут быстрее выяснить суть неисправности, а также не является ли эта ошибка особенностью работы сервиса. Например, спрашивают:
- модель устройства;
- версию iOS/Android;
- когда приблизительно появилась проблема;
- версию Юлы.
Сотрудник второй линии пытается воспроизвести ошибку, и если убеждается, что она существует, то создаёт задачу в Jira со всеми примерами:
Задача в Jira дублируется в общий чат для информирования разработчиков, подключения ответственных и устранения ошибки. После её устранения за задачей наблюдают пару дней, и при отсутствии обращений закрывают.
Взаимодействие службы поддержки и тестировщиков
Что делает это взаимодействие эффективным:
- Умение правильно описать проблему (по мере возможности описать по шагам воспроизведение бага, указать версию приложения и ОС, особенности при работе с приложением — соединение с интернетом, включён ли режим энергосбережения и т.д.).
- Хорошее знание приложения.
- Умение сопоставить язык обычного пользователя и язык разработчиков.
- Наличие под рукой нескольких устройств с поддерживаемыми ОС.
- Владение информацией обо всех изменениях в приложении.
Действия QA
Что делают тестировщики после того, как задача заведена и продублирована в общий канал?
Мы договорились, что тимлид или любой свободный тестировщик смотрит поступающие от поддержки обращения. Для себя мы определили, что скорость реакции на такие поступающие обращения должна составлять не более 1–2 часов. При появлении обращения мы расследуем инцидент. В качестве примера возьмём баг, который попал в один из релизов Android-приложения. Однажды поддержке стали сообщать, что в чатах не грузятся фотографии. Сотрудники выяснили, что это происходит в последней опубликованной версии и затрагивает пользователей Android 10.
Тестировщики локализовали несложный и досадный баг, создали отчёт для разработчиков. Как в таких случаях расставлять приоритеты? Делать ли хотфикс, или можно отложить закрытие бага до следующего релиза? Для пользователей Юлы критичными являются дефекты, которые прямо или косвенно влияют на публикацию, поиск и просмотр товаров, на заключение сделок, в том числе ошибки в функциональности, которая влияет на сделки косвенно — в чатах и звонках между пользователями.
В течение нескольких часов мы выпустили хотфикс, а поддержка держала оборону и успокаивала пользователей, что совсем скоро они смогут поделиться фотографиями товаров в личных сообщениях.
Магия вне Хогвартса — это инциденты, которые расследовать трудозатратно, а также которые воспроизводятся только у нескольких пользователей. Расследование таких багов порой может занимать до нескольких рабочих дней. Например, у нас была такая проблема: при создании объявления у нескольких пользователей не получалось загрузить фото из галереи, изображения не появлялись в карточке товара. Мы проверили на всех тестовых устройствах, просили коллег и родственников воспроизвести у себя — всё работает. Наконец с помощью специалистов техподдержки попросили пользователей прислать видео с шагами по воспроизведению бага. В результате мы отказались от поддержки галереи Matisse, которую использовали в проекте, и перешли на нативную.
Очень редко служба поддержки заводит задачи, когда у пользователей, скажем, не приходит какой-либо параметр с сервера. Однако техподдержка не может это воспроизвести и заводит задачу с единственным обращением. Например, пользователю в ответе от сервера не пришел блок с историями на Юле. Мы порекомендовали перезапустить приложение, и блок подгрузился.
Когда чего-нибудь не хватает или сегодня выходной
Решение проблем пользователей — стандартная ситуация в обычный рабочий день, скажете вы, и будете правы. А что же делать, когда не хватает дополнительной информации от пользователей, нет нужных устройств в отделе тестирования, либо «пожар» вообще произошёл в выходной или праздничный день?
Допустим, в отделе тестирования нет нужного устройства для воспроизведения того или иного бага. В таких случаях обычно предлагают воспользоваться онлайн-эмуляторами. А если речь о специфичном баге, который на эмуляторе не воспроизвести? У нас в компании довольно дружное сообщество тестировщиков, и каждый готов помочь и поделиться устройством из другого бизнес-подразделения.
Чего тестировщикам не стоит делать, так это напрямую общаться с пользователями. Вы не обладаете должным уровнем компетенции, и не знаете, как отреагирует пользователь на вашу просьбу. Запросите дополнительную информацию у коллег из поддержки. Они лучше знают, как получить у пользователей то, что вам необходимо, и постараются вам помочь.
А что делать в праздничные и выходные дни? Перед предстоящими праздниками у нас в Юле составляется график дежурств. Если возникает нештатная ситуация, требующая подключения специалиста по тестированию, то такой специалист будет к этому готов.
Резюме
В любой компании ставятся свои задачи, подходящие под определённые бизнес-процессы. Я рассказал об общих принципах взаимодействия команд тестировщиков и поддержки. Помните, что:
- поддержкой должны заниматься отдельные специалисты, а не отдел тестирования;
- знание проекта сотрудником поддержки ускорит решение проблемы пользователя;
- если обучить поддержку правильно описывать проблемы, то это сэкономит много времени;
- нужно стараться общаться с пользователями только через службу поддержки.
А если остались вопросы — скорее пишите в мой телеграм-канал @qa_chillout
