Кеневин
Часто управленец пытается решать задачу неподходящим способом. Человек по фамилии Сноуден (не тот, другой) придумал модель Cynefin, по-нашему — Кеневин. Валлийское слово, примерно переводится как «среда обитания».
Модель помогает менеджеру определить, в какой среде он работает, и выбрать подходящий метод принятия решений. Выделяют пять сред, или доменов: очевидный, осложненный, сложный, хаотичный, беспорядочный.
Очевидный домен
Задачи простые, причина и следствие очевидны, решение лежит на поверхности. Такие задачи можно закрыть по инструкции: выявить проблему, сопоставить с известными решениями, применить типовые подходы.
Сменить перегоревшую лампочку, добавить памяти перегруженному серверу, отправить стандартный договор клиенту в ответ на запрос — это задачи из очевидного домена.
Просто возьми инструкцию и фигачь по ней.
Осложненный домен
Есть проблема, и решение неочевидно, но поддается анализу. Нужны эксперты, они разберутся в данных, выберут подходящий вариант. Здесь может быть несколько решений, но все они логичны и объяснимы.
Например, оптимизировать налоги, написать код сортировки массива, выявить неисправность оборудования, создать архитектуру айтишной системы.
Подключи экспертов и получи решение.
Сложный домен
Правильного ответа нет, его можно найти только через пробы и анализ, даже эксперты не знают точного решения. Придется экспериментировать, выявлять закономерности и на их основе выстраивать стратегию.
Примеры: вывод продукта на рынок, запуск рекламной кампании в новой нише.
Проверяй гипотезы и получи решение.
Хаотичный домен
Ситуация нестабильна и критична, на анализ нет времени. Нужно быстро действовать и локализовать проблему.
Примеры: пожар в серверной, упало приложение в проде, ключевой клиент внезапно ушел к конкуренту.
Немедленно исправляй, разберешься потом.
Беспорядочный домен
Это когда вообще непонятно, в каком ты домене. Команда тупит, клиенты недовольны, начальство что-то требует.
Определи, в каком ты домене, потом действуй.
Зачем нужна модель Кеневин? Чтобы определить тип задачи и выбрать верный способ управления. Бессмысленно решать задачи, требующие проверки гипотез с помощью «наилучших отраслевых практик». Не сработает, даже если позвать сто экспертов.
Давайте теперь разберемся, как применяют модель. Вот менеджер Марианна. Ее команда готовится выкатить обновление приложения для курьеров. За пару дней до релиза кто-то замечает: карты загружаются медленнее обычного.
Вроде проблема простая: не хватает мощности серверов. Это легко проверить, надо посмотреть загрузку. Ой, да! Сервер не справляется. Решение очевидно: добавляют ресурсы, карты снова работают быстро.
Через час проблема возвращается. Значит, дело не только в мощности. Осложненная ситуация: требуется анализ. Марианна подключает разрабов, те смотрят логи. А-а-а, изменился алгоритм загрузки карт, сервер перегружен ненужными запросами. Решение найдено, разрабы правят код.
Все хорошо? Не-а. Теперь у части пользователей приложение вообще не запускается. Разрабы не понимают, в чем дело, аналитики тоже. Это уже сложная ситуация, причин может быть много. Нужно выдвигать гипотезы, тестировать. У Марианны глаза цвета спелой клубники. Тут команда выясняет, что проблема в несовпадении версий чего-то там. Разрабатывают патч, все в порядке.
Релиз в проде и... хаос! Продукт массово вылетает у пользователей, поддержка погребена под трехметровым слоем жалоб. В панике команда пытается исправить обновление, но все только ухудшается. Это хаотичная зона, действовать надо быстро. Марианна приказывает отключить проблемные функции, команда стабилизируют систему. Все начинают разбираться, что пошло не так. И вдруг... Ладно, оставим Марианну за этим занятием.
Важно не только решать проблемы, но и понимать, с чем именно ты имеешь дело. Простому — инструкция. Осложненному — эксперт. Сложному — эксперимент. Хаосу — быстрые действия.
