Swarming (Роение) 🐝

Товарищи из serviceinnovation.org пишут: интеллектуальное роение (Intelligent Swarming ) — это более разумный способ объединить людей с работой.
Звучит красиво. Теперь посмотрим, что нам предлагают инновационного и интеллектуального.

Первое, что хочу отметить, нет готовой инструкции, как правильно построить сворминг. Каждая компания идет своим путем.

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

Severity 1 Swarm(Рой «Критичность 1»)
Основной фокус: Обеспечить немедленный ответ и решить как можно скорее.

Рой «Критичность 1» сосредоточен на наиболее критичных обращениях. Рой координирует решение критичных задач, распределяя их «правильным» людям, чтобы обеспечить решение настолько быстро, насколько возможно. По сути, нечем не отличается от Incident management по ITIL.

Dispatch Swarm(Диспетчерский рой)
▪️ Основной фокус: «сборщики вишни». Какие из новых заявок можно решить немедленно?
▪️ Вторичный фокуc: проверка заявок перед назначением группам поддержки продуктовых линеек.

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

Тут нужно понимать, что рой - это кроссфункциональное объединение инженеров, т.e. В рой могут входить инженеры L1,L2 и L3.
Какие это дает дополнительные плюсы?
Специалисты начальных линий быстрее обучаются. Специалисты старших линий становятся ближе к клиентам.
В BMC данный рой решал 30% заявок от общего объема.

Остальные заявки улетали в рой третьего типа.
Backlog Swarm (Бэклог рой)
• Основной фокус: рассмотреть сложные заявки, переданные из групп поддержки продуктов.
• Вторичный фокус: заместить отдельных экспертов по предмету.

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

Итого:
Минусы 3-х уровневой системы поддержки
▪️ Разрыв между первой линией и DevOps-командой может приводить к
задержкам маршрутизации заявок и ошибкам их категоризации.
▪️ Отсутствие понимания всех инструментов (DevOps) для младших линий. Старшие линии не в курсе болей клиентов.
▪️ Попытка сформировать жесткую вертикальную и горизонтальную разделённую структуру приводит к созданию барьеров для кросс-функционального сотрудничества, которое является залогом внедрения «правильных» практик DevOps.

Swarming:
▪️ Динамичное кросс-функциональное сотрудничество, объединяющее специалистов с различными компетенциями в команды.
▪️ Гибкая структура команд вместо жёстких иерархических структур.
▪️ Высокий уровень автономии вместо жёстко регламентированных процессов (ключевой пример – «сборка вишни» в Диспетчерском рое).
▪️ Акцент на предотвращении роста бэклога незавершённых задач.
▪️ Кросс-функциональный обмен навыками и опытом между сотрудниками.