Cynefin – интригующий фреймворк, он базируется на теории сложности и принципе, согласно которому разные ситуации требуют существенно разных подходов. Его создатель, Дейв Сноуден (Dave Snowden), кратко описывает это как «осознать сложность, чтобы действовать».

Сноуден создал фреймворк в 1999 году, когда работал в IBM, а в 2003 опубликовал широко известную статью «Комплексные акты познания». Он оставил IBM в 2005 году, чтобы основать Cognitive Edge.

Cynefin привлекает значительное внимание DevOps-сообщества. Модель также вызывает интерес у ITSM-профессионалов, особенно с учетом грядущей эволюции (или замены) привычных фреймворков, таких как ITIL.

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

В этой статье будет показано, как техническая поддержка на основе Swarming может быть организована и оптимизирована именно вокруг принципов Cynefin.

Cynefin: быстрый обзор

Так что же такое Cynefin? Во-первых, давайте поговорим о произношении! Cynefin – это валлийское слово, не имеющее точного перевода на английский язык (его ближайший эквивалент часто называют «средой обитания», хотя Сноуден утверждает, что это «множество факторов в нашей среде и наш опыт, которые влияют на нас способами, которые мы никогда не сможем понять“). Он произносится как «ку-нев-ин».

Cynefin классифицирует любую взятую проблему или сценарий принятия решения в одну из пяти областей, как показано на этой иллюстрации:

Отличный обзор этих областей от самого Сноудена можно найти в первых десяти минутах этого подкаста 2015 года. Вкратце:

• Очевидные и Сложные – это «области порядка», в которых всё имеет повторяющиеся взаимосвязи между причиной и следствием. В каждой из этих областей порядка, как говорит сам Сноуден (6m50s):

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

• В Комплексной области понимание проблемы требует экспериментов и исследований. Комплексные системы терпят неудачу комплексно. Утверждать что-то можно только в отношении настоящего, а не будущего, и общее решение становится очевидным только после его обнаружения. Со временем допустима возможность формирования достаточного объема знаний и ограничений для перехода ситуации от Комплексной к Сложной.
• Хаотичные сценарии драматичны и не ограничены. Приоритетом здесь является ограничение распространения и сокращение ущерба, и любое первоначальное решение сосредоточено в первую очередь на достижении этого. Следовательно, целью является перемещение проблемы в любую из других областей.
• Пятая область – это Беспорядок. Это состояние непонимания того, какая область подходит к текущей ситуации. Приоритетом на этом этапе является поиск фактов, необходимых для перемещения в другую область.

Swarming – краткий обзор и пример

Swarming в контексте клиентской поддержки обычно использует сетевое взаимодействие вместо традиционной многоуровневой структуры, основанной на эскалации (которая обычно формируется по принципу: «Уровень 1» поддержки с эскалацией до «Уровня 2» поддержки и команд «Уровня 3» с конкретными отдельными областями компетенции, в качестве окончательного варианта эскалации).

Не существует единой, окончательной структуры Swarming. Swarming, по определению, динамичен. Предприятия, которые используют Swarming для технической поддержки, имеют несколько типов swarm (роев), чтобы применять различные типы сценариев. Тем не менее, даже эти структуры могут быть непостоянными. Команды сами по себе ориентированы на достижение результатов ценой большей гибкости, а не приверженности строгим правилам.

В предыдущей статье о Swarming, описаны три структуры, используемые в BMC для разных ситуаций. Кратко:

Рой «Критичность 1» (Severity 1 Swarm): используется для небольшого процента вопросов, которые являются достаточно значимыми, чтобы оказать влияние на бизнес. Этот Рой аналог модели «war room» традиционных структур поддержки. Назначенный руководителем поддержки добавляет необходимых людей в рабочую группу и они вместе работают над задачей, пока она не будет решена.

Диспетчерский рой (Dispatch Swarm), иногда его называют Triage Swarm: небольшая группа сотрудников поддержки, как правило, с различным уровнем опыта, которая решает проблемы по мере их поступления. Они встречаются часто, по нескольку раз на протяжении дня, и мониторят входящий поток. Этот рой играет две роли: во-первых, они отбирают задачи, которые могут быть решены действительно быстро, а во-вторых, выступают валидаторами качества данных для проблем, которые будут переданы в продуктовые группы поддержки.

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

Применение Swarming для реализации Cynefin

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

Беспорядок

В этом состоянии природа проблемы совершенно неизвестна. Cynefin не предлагает никаких конкретных действий, кроме как найти соответствующую область, в которую нужно поместить проблему. Первая попытка определения области делается человеком, первым столкнувшимся с проблемой, при её возникновении.

Очевидные

Для простых задач из области Очевидных, Cynefin рекомендует Осмыслить, Классифицировать и Ответить. Решение, как правило, уже определено и понятно, и его легко можно идентифицировать. Идентификация типа проблемы может способствовать самостоятельному решению или дать возможность сотруднику поддержки работать на основе простого шаблона или документа из базы знаний. В идеале, пути решения очевидных задач, которые возникли впервые, должны быть занесены, как статьи в базы знаний.

Сложные

В сложной области проблема не идентифицируется и не разрешается однозначно, но сохраняется четкая взаимосвязь между причиной и следствием. Следовательно, всё равно имеет место быть решение, которое можно записать и повторять. Вместо простой категоризации, требуется анализ (Осмыслить, Анализировать, Ответить).

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

Комплексные

Для задач, лежащих в области комплексных (Исследовать, Осмыслить, Ответить), решения не предопределены. Поиск решений таких задач требует экспериментов и итераций. Возможно, потребуется собрать данные из нескольких источников, часть из которых впоследствии может быть отброшена.

В результате, комплексные задачи очень хорошо подходят для Swarming, нежели традиционной многоуровневой модели поддержки. В то время как последняя больше ориентирована на переназначения между фиксированными группами с отдельными ролями, Swarming делает «команду» динамичной, позволяя ей определять текущее состояние изучения проблемы, управлять своим временем, чтобы иметь возможность вести параллельные исследования. Этот пример показывает работу Swarming под руководством Swarm Lead при помощи ассистента.

После первоначального анализа фактов, рой немного расширяется, привлекая людей, которые могут строить гипотезы о том, что вызывает проблему. Это позволяет параллельно вести исследование по нескольким путям, при этом рой делится на подгруппы (наличие помощника позволяет группе руководителя поддерживать диалог с другой подгруппой).

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

Хаотичный

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

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

Резюме

Swarming отлично сочетается с принципами Cynefin. В частности, он предлагает подход, который намного лучше работает с недетерминированными областями Cynefin: Complex и Chaotic. Эти области описывают ситуации, которые меняются, требуют адаптивных и итеративных подходов, к которым тяжело адаптировать жесткую модель предписаний.

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

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

Автор Джон Холл (Jon Hall), оригинал Combining Cynefin with Swarming for better Incident Management