В техподдержку iSpring ежемесячно поступает 7300 запросов со всего мира. Техподдержка состоит из трёх уровней:

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

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

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

Как работают первые две линии и почему мы пришли к такому разделению техподдержки, — в статье «Как двухуровневая система техподдержки освободила отдел разработки от рутинных саппорт-задач».

Меня зовут Ринат Набиев, я — менеджер проектов саппортовой команды в отделе разработки. Что в ней примечательного: у нас нет постоянной команды, и каждую неделю к нам приходят дежурить ребята из фичёвых команд продукта. В статье поговорим, как построен саппорт с недельными дежурствами, какие плюсы и минусы у него есть. 

Почему мы перешли от постоянной команды к дежурной

Раньше в iSpring работала постоянная команда саппорта: разработчик, тестировщик и проджект-менеджер. Это было удобно: всего несколько продуктовых команд, не очень частые релизы и не так много фич. Саппорт-команда всегда была в контексте происходящего. Клиентов и задач тоже было меньше.

Потом команды разделились на несколько отдельных фичёвых команд.

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

Появились сложности:

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

2. Накапливался стресс: в 18:00 могла прийти блокирующая задача, её нужно было обязательно решить. Один-два раза — терпимо, но в постоянном режиме — выматывает.

3. Обращений в саппорт становилось больше — увеличивался общий список задач: кейсы клиентов закрывались медленнее.

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

Как итог: у бизнеса затягивается решение задач, у команды — эмоциональное выгорание. 

Мы решили уйти от постоянной саппорт-команды и попробовать сменные недельные дежурства. Дежурная команда, как и раньше, состоит из:

• Двух бэкенд-разработчиков — они отвечают за разные продукты.

• Одного фронтенд-разработчика.

• Одного тестировщика.

• Одного проджект-менеджера — это единственная роль в команде, которая меняется примерно раз в год.

Разница в том, что ребята на этих ролях работают всего по неделе — раз в 1–2 месяца. В остальное время они находятся в фичёвых командах. Срок в неделю возник неслучайно: за это время программист не успевает перегореть и выпасть из фичёвой разработки команды.

Как работает дежурный саппорт

Оценка входящих запросов клиентов

Задачи от второй линии поддержки прилетают в чат отдела разработки, связанный с саппорт-задачами. 

• Дежурный тестировщик разбирает заведённые задачи.

• Проджект-менеджер саппорта расставляет приоритеты для разработчиков по задачам.

• Разработчик решает задачи согласно выставленным приоритетам менеджера саппорта.

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

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

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

Чтобы расставлять приоритеты между саппорт-задачами, мы разработали таблицу.

В фокусе у саппорта задачи уровня «blocker», «critical» и «major». Если критических задач несколько одновременно, менеджер выставляет «dev priority»: это шкала от 1 до 10, где 10 будет у самой важной задачи. В зависимости от этого задачи выстраиваются от наиболее важной и срочной — к наименее. Когда дежурный разработчик заходит на саппорт-борду, он видит пул задач и знает, с какой начинать. 

Приоритет для решения задач должен выставлять только проджект саппорта, иначе график работ «поедет». Если тестировщик нашёл баг на живом и уверен в критичности бага, он должен сообщить проджекту саппорта, чтобы тот повысил важность задачи.

Передача задач между дежурными и ответственность за баги

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

Ситуация 1. В ходе проверки тестировщиком задачи, нашли баг от предыдущего разработчика. Кто должен его фиксить?

1. Если поправить задачу можно в течение получаса-часа, лучше, если предыдущий разработчик решит её сам: у него больше контекста. 

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

Ситуация 2. Вчера был релиз фичёвой команды продукта, сегодня в саппорт зарепортили баг по фиче,которая вчера была зерелижена. Кто должен его фиксить: команда, ответственная за релиз, или саппорт? 

Всё зависит от приоритета задачи: 

1. Если задача блокирующая, то фичевая команда незамедлительно берет задачу в работу, правит и релизит для исправления бага на живом.

2. Если проблему необходимо исследовать больше получаса-часа, то менеджер саппорта передает задачу в команду фичи.

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

Сбор статистики, анализ, автоматизация

Проджект-менеджер собирает статистику по задачам за каждую неделю. Задачи в саппорте делятся на три категории:

• рутинные, 

• воспроизводимые — когда причина бага понятна, 

• задачи на исследование — когда причина бага непонятна. 

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

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

Как отбираем разработчиков

В дежурствах принимают участие два типа разработчиков:

• Топовые разработчики продуктовых команд. Они решают задачи любой сложности. 

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

График дежурств

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

Случается, что в разгар разработки разработчик находит проблему, которую не предусмотрел в процессе планирования. А это значит, что Feature Complete затягивается, и разработчик не может уйти в запланированное время в саппорт. Тогда проджект-менеджер той команды, в которой задерживается разработчик, обсуждает с менеджером саппорт, кто из других команд может подменить его разработчика на дежурстве. 

Лайфхак 

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

Коммуникации внутри дежурной команды

Планёрка — каждый день в 9:30 утра. На ней присутствуют дежурные разработчики бэкенда, фронтенда и тестировщик. Они рассказывают, какие задачи сделали вчера, с какими проблемами столкнулись и что планируют делать сегодня — с учётом приоритетности, которую ставит проджект-менеджер. 

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

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

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

Когда оправдан сменный формат работы саппорта

На своём опыте мы поняли, что сменная команда саппорт необходима, если:

• Продукт разрабатывают несколько потоковых команд.

• Постоянно добавляется новая функциональность.

Это даёт: 

• Отсутствие риска, что контекст по продукту будет у единственного разработчика. 

• Высокую скорость решения задач. 

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

____

Расскажите, как вы решаете задачи по саппорту? Как саппорт-команды реализованы у вас?