Модель Кеневина (Cynefin): как выбирать подход по контексту

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

Кеневин (Cynefin) — разработанный Дэйвом Сноуденом фреймворк осмысления ситуации и поддержки решений. Его часто называют моделью, но он не предсказывает поведение системы: он помогает выбрать способ действий и понять, когда его менять. Это не шкала размера проекта: множество деталей само по себе не делает результат непредсказуемым.

Контексты модели

Русские переводы названий различаются. Ниже рядом с рабочими русскими обозначениями сохранены английские термины.

Контекст	Что известно	Как действовать
Ясный — Clear	Причины и последствия очевидны, практика повторяема	Распознать ситуацию и применить проверенный порядок действий
Сложный, но анализируемый — Complicated	Зависимости существуют, для их понимания нужна экспертиза	Собрать данные, провести анализ, выбрать решение
Комплексный — Complex	Результат взаимодействий нельзя надёжно предсказать заранее	Провести ограниченные пробы, наблюдать и корректировать действия
Хаотический — Chaotic	Эффективные ограничения и управляемость отсутствуют	Действовать для стабилизации, оценивать последствия и уточнять следующие шаги
Неясный — Confused / Aporetic	Ещё непонятно, к какому контексту относится ситуация	Разобрать противоречия и разделить ситуацию на части для осмысленного выбора действий

Неясность не равна хаосу. В современной модели область aporia также используется для пересмотра привычных объяснений и выхода из ошибочного понимания ситуации. Подробнее — в описании доменов Cynefin.

Как это выглядит в веб-разработке

Следующие примеры — применение модели к разработке. Контекст определяется тем, что команда знает о конкретной ситуации, а не названием технологии или задачи.

Ясный: повторить известное действие

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

Но типовая формулировка не гарантирует типового контекста. «Обновить плагин» может потребовать исследования, если есть неизвестные зависимости и доработки. Важно проверить предпосылки перед применением привычного рецепта.

Анализируемый: разобраться до реализации

Например, нужно найти причину медленного запроса. Команда собирает измерения, изучает план выполнения и проверяет зависимости. Решение требует экспертизы, но может стать достаточно определённым после анализа.

Здесь полезен отдельный этап диагностики. Его результат — подтверждённая причина и обоснованный план работ, после чего реализацию можно оценить и согласовать.

Комплексный: получить знание через пробы

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

В Cynefin для такого контекста используют safe-to-fail probes — ограниченные эксперименты, последствия неудачи которых допустимы. Проверяют несколько обоснованных гипотез, усиливают полезные проявления и ограничивают нежелательные. Подробности — в описании метода.

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

Хаотический: сначала вернуть управляемость

Например, магазин перестал принимать заказы, а масштаб сбоя ещё неизвестен. Сначала команда ограничивает ущерб: останавливает неудачный релиз, отключает проблемную интеграцию или восстанавливает доступность. Конкретное действие зависит от ситуации и доступных механизмов восстановления.

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

Неясный: разделить разные задачи

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

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

Как выбирать способ организации работы

Модель описывает контекст решений; она не предписывает договор, оплату или календарь команды. Для разработки из неё можно вывести практические ориентиры:

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

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

Ограничения и частые ошибки

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

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

Не называть любой спринт экспериментом. Разбиение заранее определённого плана на короткие отрезки не создаёт исследования. Для проверки нужны гипотеза, наблюдение и возможность изменить последующее решение.

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

Связанная страница

• Dual-Track Agile — цикл Discovery и Delivery для непрерывной проверки продуктовых предположений.

Материалы и источники

• Cynefin — обзор фреймворка — назначение, происхождение, динамика контекстов и распространённые неверные трактовки.
• Cynefin Domains — контексты, границы применимости и переходы между ними.
• Safe-to-fail probes — ограниченные эксперименты в комплексном контексте.