Комментарии 6
А как долго уже применяется данная схема и что планируете в будущем "релизе" такой схему улучшить?
Сменные команды с дежурствами были введены с января 2021 года. На данный момент мы активно ее применяем и до сих пор оттачиваем процессы. Например, сейчас мы работаем над задачей по разгрузке отдела разработки от рутинных задач, которые может выполнять техническая поддержка 1 и 2 линии. Это позволяет отделу разработки решать более сложные кейсы клиетов, где необходимо глубокое исследование проблемы, не тратя время на рутинные.
Привет! А как обрабатываются однотипные заявки, которые требует устранить какой-то массовый баг или нестабильность системы. Куда такие запросы попадают? Сразу на разработчиков. Или чистятся на каком-то этапе техподдержки ?
Привет! Все клиентские обращения обрабатываются первостепенно в рамках техподдержки. Однотипные заявки деляться на два типа:
1. Решаются прямо в рамках 1 и 2 линии техподдержки (восстановление контента, пользователей в аккаунтах).
2. Решаются в рамках отдела разработки (если проблема имеет какой-то массовый баг или нестабильность системы, то техподдержка заводит задачу, где описывают подробный кейс и передают в отдел разработки для решения проблемы на живом).
Спасибо за ответ! Можно еще спросить: А если инцидент имеет массовый характер и в день по 30-40 штук приходит однотипных заявок. Можно ли как-то это предотвратить до устранения этой проблемы разработчиками. Или все-таки ручками приходится закрывать ? Если есть какая-та методика. Мне бы она пригодилась на моей первой работе - год назад.
В данном случае проблема касается ключевого функционала и затрагивает большое количество клиентов. Если в день приходит по 30-40 однотипных обращений, то в продукте, что-то явно сломалось. Да, у нас есть определенная методика как действовать в таких ситуациях:
1. Задача передается в отдел разработки.
2. По таблице приоритетов саппорт-задач, проектный менеджер определяет, что задача имеет приоритет Bloсker.
3. Менеджер передает задачу разработчику, сдвигая все запланированные задачи на текущий день.
4. Разработчик исследует и решает проблему локально.
5. Тестировщик проверяет в тестовом окружении, что проблема решена.
6. Менеджер определяет очередь релиза и задача выкатывается на живой.
Ценность данной методики в том, что клиент получает устранение проблемы на живом в один или максимум два дня.
Когда команда постоянно меняется: как устроен саппорт с недельными дежурствами