Swarming: devops-friendly подход к технической поддержке

Краткое изложение основных идей Swarming в технической поддержке.

Рассмотрим общепринятый подход к оказанию поддержки, состоящий из трех линий.

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

swarming

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

Но посмотрим на подобную структуру с другой стороны.

Что не так с многоуровневой поддержкой?

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

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

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

swarming

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

Swarming

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

  1. Поддержка не должна быть многоуровневой
  2. Не должно быть эскалаций от одной группы к другой
  3. Тикет напрямую передается тому, кто, скорее всего, сможет решить проблему
  4. Тот, кто взял тикет, доводит до конца решение проблемы

Severity 1 swarm не сильно отличается от процесса работы на критическими задачами в традиционной схеме. Есть лид и пара помощников. Состав команды меняется каждую неделю. Основной фокус такой команды – дать немедленный ответ и решить проблему ASAP, привлекая при необходимости экспертов в предметной области самого различного профиля.

swarming

Local Dispatch Swarm уже интереснее – это продуктовая, либо региональная команда поддержки, которая состоит, например, из опытного аналитика и пары мидлов. Основной фокус этой команды – быстро решить те проблемы, которые могут быть решены быстро и не отправлять в долгий ящик очередную очередь то, что может быть решено за пять минут . Если решить быстро по каким-то причинам невозможно – передать в Product Backlog Swarm, где решаются наиболее сложные задачи. Координационные встречи этой команды проходят каждые час-полтора. Если кто-то уже обратил внимание, – да, это похоже на вывод третьей линии поддержки на передовую.

И наконец – Product Backlog Swarm. Сюда попадают те проблемы, которые Local Dispatch Swarm не смог решить за разумно-быстрое время. Суть в том, что Local Dispatch Swarm не имеет права назначить тикет на конкретного эксперта в предметной области, тикет попадает в бэклог, с которым работает команда опытных специалистов. Эта команда может состоять, например, из двух опытных аналитиков и нескольких разработчиков. Координационные встречи проходят на ежедневной или еженедельной основе. Основной фокус этой команды – решение проблем, полученных из Local Dispatch Team, а не менее важный вторичный фокус – заменить собой потребность в эксперте в предметной области.

Дополнительные материалы:

Share

Добавить комментарий