Я — тестировщик, которому в апреле 2024 года пришлось примерить на себя роль спасителя технической поддержки, так как с ней у нас были большие проблемы. Решение для клиентов поступало слишком медленно, из‑за этого от нашего сервиса попросту отказывались. Cитуацию нужно было исправлять и исправлять срочно.

Структура технической поддержки

Для понимания дальнейшего доклада я немного расскажу о самой структуре технической поддержки в каноничном понимании. Есть три линии поддержки пользователя

Первая линия — те, кто напрямую общается с пользователями по разным каналам связи, будь то телефония, чаты и электронная почта. Эдакая передовая, если ребята из первой линии не могут решить проблему пользователя, они передают обращение уже сотрудникам второй линии.
Вторая линия — члены команды, которые обладают знаниями уже на уровне экспертов продукта. У них больше доступов и, соответственно больше инструментов для решения проблемы (админка и прочее). И если уже эти ребята не способны решить вопрос пользователя, они передают задачу дальше, на третью линию.
Третья линия — всемогущая команда разработки, баг пофиксят, фичу разработают, сроки дадут.

Как это было в нашей команде

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

Разработчики время от времени конечно разбирали Support, но так, между делом. В качестве трекера был заведен отдельный проект в Jira и туда условная вторая линия и передавала задачи. На момент, когда я взялся за исправление ситуации главное проблемой было наличие более трёхсот открытых задач, половина из которых находилась в ревью. Они были назначены на авторов задач, то есть вроде бы и решены, но обратной связи так и не поступило.

С чего начали

Было очень важно расчистить доску в первую очередь, ведь когда у тебя на доске миллион задач фокус сильно размазывается и ты можешь упустить что-то действительно важное. Порядок действий был следующий:

Задачи в ревью, ожидающие фидбека от авторов

Закрыть без обратной связи задачи, решенные раньше чем за последние три месяца, раз за такое долгое время не обратились, значит проблема не актуальна.
Взять задачи за последние три месяца и посмотреть, в чем проблема, на чем остановились. Задача может быть решена и ожидает подтверждения, разработка может ждать ответа на какой-либо уточняющий вопрос. Тут надо вести себя уверенно и, местами, радикально. Достаешь пингамёт и пингуешь авторов каждой задачи с просьбой дать ответы на вопросы/апдейты. И пишешь, мол если не дадут никакой обратной связи, то задача будет закрыта условно через 2 дня.

На этом этапе серьезных проблем не возникло, напористость действительно помогла. Чтобы начать делать нормально, нужно отрезать и позакрывать всё что сейчас нам мешает.

Итак, чистка завершена и у нас от 300+ задач остались какие-то жалкие 120. Переходим к следующему этапу.

Разделение задач по тегам

Наша багтрекинговая система поддерживает такую функцию как добавление тегов к задаче, ими я и воспользовался. Изучил оставшиеся задачи и разделил их по проектам, это вот Android, iOS, а тут проблема в вебе.

Проведя это разделение я смог выявить:

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

И вот имея понимание, что из себя представляют задачи, было решено, что делать по всем трем направлениям.

Важные задачи

Передаем в разработку, определяем спринт, даем автору задачи ориентировочные сроки решения. Почему сроки важны? Чтобы первая линия могла эти сроки сообщить пользователю, согласитесь, намного легче ждать решения, когда тебе дают понять, сколько нужно ждать. Если клиенту ответить «Мы не знаем, когда-нибудь будет», он попросту откажется от сервиса.

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

Повторяющиеся кейсы

Тут давайте с примерами:

пользователь не разобрался, нажал не туда и сейчас это надо исправить;
приложение крашится и данные стираются;
нужно восстановить данные после краша.

Основная задача это уменьшить такие обращения:

делаем раз — не даем пользователю безответственно нажимать на злополучную кнопку, при нажатии выводим алерт с жирнющим подтверждением «А вы уверены? Если да, то с вашими данными случится то‑то и то‑то»;

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

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

Кейсы, которые фиксит разработка в самом коде

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

Когда мы вплотную взялись за наведения порядка у нас было более 40 задач, где нужно было восстановить отчет и все они были назначены на одного человека! Ведь только он мог это дело исправить.

Более того, чтобы получить id этого отчета для восстановления, нужно было идти к другому разработчику и у него уже эту инфу добывать.

Уверенно идем к разработчикам, смотрим в глаза и берем их за руку и говорим «сделайте инструмент в самом интерфейсе приложения, чтобы мы могли сами это фиксить без вашей помощи». И вот, спустя один или два спринта у нас уже есть готовый инструмент и все эти обращения решаются меньше чем за 10 минут каждое.

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

Проблемы с которыми я столкнулся

Слишком много тегов

Помимо проектных тегов (android, iOS, Server) были заведены ещё куча тегов:

Вопрос к разработчику;
Ожидает разработки;
Пинг для закрытия - на уточнение даётся 2 дня, уже после того как задача решена;
Пинг для уточнения - на уточнение даётся неделя, автор должен ответить на вопрос;
Ожидает релиза;
Тег с номером релиза, в который планируется исправление.

И ещё пачка тегов, которыми в последствии просто не использовались. Эту проблему решил просто. Перестал использовать что-либо кроме тегов с проектом и номером релиза. Добавили две колонки на доску “Ожидает релиза” и “Ожидает разработки”. И вот, всё выглядит более лаконично.

Отслеживание задач

Изначально все задачи, которые требовали помощи разработки заносились в таблицу.

Ссылка на задачу в Support	Ссылка на связанную задачу в проекте	Предполагаемый релиз, куда это войдет	Предполагаемые даты этого релиза	Статус задачи

Предполагалось, что разработчики сами будут проверять эту таблицу и заполнять информацию в третьем и четвертом столбце, но у них на это не было ни времени ни желания. Также практика показала, что мониторить таким образом не удобно. Когда список задач в этой таблице разросся до 40–50 — мониторить везде актуальность статусов стало попросту невозможно.

От таблицы этой было решено отказаться, после чего я и стал использовать теги с номером версии и колонки «Ожидает релиза» и «Ожидает разработки». Как ни крути, но на доске это всё же более наглядно и удобно, прыгать по ссылка не нужно.

Сроки обратной связи

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

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

Сейчас мы действуем так:

Задача ASAP — обсуждаем её сразу после появления, вместе думаем над сроками и отдаем их продажам;
Задача с приоритетом ниже — даём сроки в течении недели.

Что нам еще помогло

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

На данный момент наши продажники более не заводят задачи в проекте Support, куда смотрят разработчики, они заводят их в отдельном проекте. Я как ответственный за этот проект смотрю задачи и только действительно невыполнимые кейсы передаю разработке на ресёрч/фикс/разработку.

Таким макаром сейчас у нас на доске проекта Support не бывает больше 15 задач. Я сразу уточняю все детали и уже после передаю задачу разрабам.

Планирование каждую неделю с разработкой

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

Помимо этого у нашей компании есть такая особенность. Разработка у нас сидит в РФ, а продажи и клиенты по большей части на территории США. Разница с ними у нас 12 часов. Выходит, что задачи в Support нам приходят ночью. Поэтому с утра перед дейликом надо задачи эти обработать и вопросы для разработчиков подготовить.

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

Ежедневные созвоны с продажами

Как писалвыше, в начале работы над Support я разобрал около двух сотен решённых задач, по которым не было апдейтов. И даже после всего этого возникали абсурдные ситуации, когда задача вроде бы ASAP, мы берём её в работу, хотим уточнить некоторые детали, а ответа от продажников нет несколько недель. То есть задача и не ASAP вовсе

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

Текущие сложности

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

Для обычных пользователей/кассиров/официантов сервис, который предлагает моя компания, может показаться сложным. С первоначальной настройкой наши продажи помогают, но этого, порой не достаточно. Людям не понятно и они попросту отказываются от сервиса в пользу другого, более простого.
Большие мануалы они будто бы читать не хотят, видео на Ютубе смотреть не желают. Им проще позвонить и часик-другой посидеть на трубке. Что же делать?
Неизвестно, с чем пользователи звонят в поддержку. В отчете за месяц мы видим, что звонков с вопросами было около тысячи. При том, что нам было передано 20-30, то есть 2-3% от всех обращений.
Это проблема, ведь зная подробный сценарий всех звонков, можно, опять же, сыграть на опережение, и исправить положение, чтобы звонков стало меньше. Как пример, выяснилось, что очень часто пользователи не могут найти как сделать добавление чаевых к уже совершенной продаже. Узнав об этом было сделано две вещи:
1. Фича эта выведена в более видное место;
2. Я начал работать над более удобной системой обучения пользователей.
То есть с мертвой точки мы уже сдвинулись. По остальным же вопросам мы подключим CRM, для транскприпции звонков и их автоматического разделения на группы по вопросам.

Слабоумие и отвага

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

Порядок рекалькуляции такой:

Собрать всю инфу;
Сгенерировать отчет;
Удалить старый нулевой отчет;
Отчитаться.

Для того, чтобывоспользоваться инструментом, нужны следующие данные:

Z‑report ID — идентификатор самого отчета в системе
POS ID — идентификатор девайса в системе
Даты открытия отчета и закрытия (первая продажа и последняя)

POS ID и даты со списком продаж мы получаем в запросе для техподдержки, Z-report ID же нам нужно выяснить/сгенерировать самостоятельно.

Грабли № 1 — семь раз отрежь, померишь потом

На тот момент идентификатор отчета о закрытии смены нигде в интерфейсе не отображался. Для того, чтобы сгенерировать новый идентификатор нужно чекбоксом выделять нужные продажи в истории и нажать «Сменить Z‑report guid».

Кто-то уже видит, в чём тут проблема? Отсутствие чекбокса для выделения всей страницы. У меня буквально были случаи, когда нужно было прокликать 6 тысяч продаж при том, что пагинацию можно настроить максимум на 100 записей.

Ещё одна забавная штука с пагинацией. Выделил 100 записей, перешёл на другую страницу, выделил ещё 100 записей и нажал на нужную кнопку для генерации Z‑report guid. Новый guid присвоился 100 продажам с текущей страницы, но не с предыдущей. Чекбоксы с первой страницы просто сбросились, поэтому порядок был такой:

Прокликать продажи на одной странице;
Сменить им идентификатор;
Прокликать продажи на другой странице;
Вставить идентификатор с прошлой страницы.

Можно сгенерировать новый ID, или можно вставить из буфера обмена

Это дело мы исправили, теперь Z‑report id можно посмотреть и в карточке продажи и в списке самих отчетов. Пагинацию правда до сих пор не исправили.

Грабли № 2 — выйди и зайди нормально

Отчеты пересчитали, торжественно об этом объявили и нас поблагодарили. Затем, в течении нескольких месяцев было по 2–3 запроса на пересчёт в неделю. Мы это дело пересчитывали и чувствовали себя победителями.

Но случилось то, чего мы не ожидали, но стоило. Мы, кхм, обделались.

В сервисе есть возможность из списка отчетов перейти в список продаж, включенных в этот отчёт.

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

Причина была весьма интересной. Я пересчитывал Z‑report на своем девайсе, авторизовываясь в торговой точке пользователя. И вот транзакции, сделанные клиентом, содержат идентификатор девайса клиента, а наши пересчитанные отчеты содержат мой идентификатор.

Исправив это, мне пришлось пройтись по ВСЕМ задачам и заново пересчитать отчеты, хорошо хоть данные для пересчета уже все были приложены в этих задачах, но всё равно, заняло это прилично времени.

Грабли № 3 — пытались зрить в корень проблемы, но при этом моргнули

«Хватит» — решили мы. No more. Последние запросы на рекалькуляцию случаются из‑за того, что пользователи месяцами не закрывают отчет, а когда закрывают — приложение крашится из‑за объёма в несколько тысяч продаж и отчет остаётся с нулем.

Нотификации о необходимости закрыть смену пользователи просто скипают, надо действовать настойчивее. Берём все эти девайсы, которые не закрывали смену в течении трёх месяцев и накатываем им всем автозакрытие смены. Указываем часом автозакрытия полночь, то есть 00:00. Что может пойти не так?

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

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

Итоги

Что‑то уже исправлено, что‑то только предстоит исправить, но направление задано верное и главное по нему двигаться. Ключом же почти‑успеха является диалог. С разработкой, с продажами и с клиентами. Нужно помнить, что вы все в одной команде и работа ваша направлено на одно и то же, а именно доставить пользователю простое, удобное и рабочее решение.

Как я подружил техническую поддержку с командой разработки