Привет! Я - Катя Леханова, менеджер проектов в компании iSpring. 

В компании iSpring одна из главных ценностей -  удовольствие клиента от использования наших продуктов.

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

Такой процесс действует до сих пор и упрощает обработку поступающих запросов.

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

Кроме того, мы развиваем направление on-premise решений платформы онлайн-обучения. Это означает, что аккаунты клиентов развернуты на клиентской инфраструктуре. Поддержка таких аккаунтов также требует внимания, и решением задач по обращениям от клиентов on-premise аккаунтов занимается дежурная команда.

И - вишенка на торте - амбициозные планы по выпуску новых фич, нового функционала, новых продуктов. Разработчики и QA-специалисты задействованы в этом развитии и, конечно, мы стремимся работать над обновлениями, а не править баги.

В итоге - рост клиентской базы, наращивание функционала, развитие новых решений привели нас в декабре 2023 года к увеличению числа обращений в саппорт.

Число задач в пуле превысило 50. Для сравнения, ещё в июле 2023 года в очереди на решение было 10 задач, которые можно было решить за 2-3 дня работы дежурного разработчика. 

Нужны были решительные действия! Как мы с этим справились?

Первый шаг. Анализ.

Когда мы поняли, что пул открытых задач насчитывает более 50 тикетов (невиданная ситуация!) - собрали рабочую группу.

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

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

• Количество обращений в саппорт;

• Прирост активных пользователей продукта;

• Прирост клиентов с on-premise решениями (на данный момент у нас более 100 действующих развернутых серверов);

• Соотношение приоритетов в саппортовых задачах (blocker/critical/major);

• Тип задач, которые решала дежурная команда;

• Пропорция затраченного времени по типам задач;

• Крупные релизы за год. При релизе большого продуктового апдейта затрагивается много модулей и возрастает вероятность допущения ошибки.

После анализа мы выявили причины возросшего количества клиентских запросов:

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

2. Не было четкого регламента реагирования на алерты системы мониторинга ошибок. 

3. Неоптимальная обработка событий в аккаунтах. 

Второй шаг. Что делать сейчас?

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

Решительное действие - дергаем стоп-кран!

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

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

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

Третий шаг. Совершенствование процессов. Support 2.0

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

1. Взяли в продуктовый план разработки задачи по оптимизации обработки доменных событий.

2. Создали новую схему работы дежурной команды разработчиков.

Область ответственности дежурного разработчика:

• хотфиксы (быстрые правки, которые помогут клиенту прямо сейчас);

• диагностика клиентских задач (дежурный вникает в суть задачи, заводит задачу на правку или исследование корневой причины);

• рутинные задачи, не связанные с багфиксом. Например, подключение алиаса домена или выгрузки для системных аналитиков.

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

3. Настроили процесс мониторинга и диагностики алертов  (дежурный реагирует на каждый алерт - оставляет комментарий в специальном чате):

а) если причину можно установить быстро, или она понятна сразу - описывает, что случилось.
б) если нужно исследовать причину - заводит задачу, которая отправляется в одну из продуктовых команд

Результат.

1. На 27% сократилось количество задач, поступающих в дежурную команду, благодаря оптимизациям и устранению ряда проблем на корню;

2. За 2024 год мы решили саппортовых задач на 24% больше, чем в 2023;

3. Возросла ответственность команд: если баг попадает на прод - он в итоге отправляется на решение в команду, ответственную за фичу или сервис.