Модель Кеневин (Cynefin)
Разработал модель Дэйв Сноуден, сотрудник IBM (1999) с целью анализа и принятия решений руководством. Название Cynefin происходит из валлийского языка и переводится как “среда обитания” - место, к которому мы принадлежим и которое формирует наш опыт, даже если мы не осознаём это в полной мере.
Сама модель предлагает разные способы решения задач на основе “среды обитания” (
Cynefin)
Cynefin - это не классификация, а sense-making framework
Модель помогает не столько классифицировать задачи, сколько осознать контекст, в котором вы принимаете решения. Один и тот же проект может содержать задачи из разных областей одновременно.
Категории задач по модели Кеневин
Всего модель описывает 5 разных категорий задач, которые могут попасться нам как на работе, так и в целом в жизни:
- Очевидные (Clear / Simple) задачи
- Четкие причинно-следственные связи. Есть конкретные инструкции к решению проблем.
- Подход: Ощути, категоризируй, реагируй (Sense - Categorize - Respond)
- Примеры: работа официанта, строителя по чертежу
- В разработке: настройка линтера по документации, добавление поля в CRUD-форму
- Сложные (Complicated) задачи
- Скрытые, но познаваемые причинно-следственные связи. Требуется экспертный анализ, чтобы найти решение.
- Подход: Ощути, проанализируй, реагируй (Sense - Analyze - Respond)
- Примеры: строительство дома, медицинское лечение, научные лаборатории, инженерные расчёты
- В разработке: оптимизация SQL-запросов, проектирование API, миграция базы данных
- Запутанные (Complex) задачи
- Причинно-следственные связи обнаруживаются только ретроспективно. Нельзя предсказать результат заранее, нужно экспериментировать.
- Подход: Попробуй, ощути, реагируй (Probe - Sense - Respond)
- Примеры: стартапы, инновационные проекты, разработка новых продуктов
- В разработке: выбор архитектуры нового сервиса, внедрение ML-модели, поиск product-market fit
- Хаотичные (Chaotic) задачи
- Отсутствие явных причинно-следственных связей. Нет времени на анализ, нужно действовать немедленно, чтобы стабилизировать ситуацию.
- Подход: Действуй, ощути, реагируй (Act - Sense - Respond)
- Примеры: сбой в продакшене, кризис безопасности, стихийные бедствия
- В разработке: даунтайм критического сервиса, утечка данных, zero-day уязвимость
- Неопределённость (Confusion / Disorder)
- Неясность принадлежности к категории. Нужно определить, в какой области ты находишься прямо сейчас.
- Подход: Сначала определи область
- Это самая опасная зона - люди склонны применять привычные подходы, не разобравшись в контексте
Применение модели
Данная модель позволяет определить, подходит ли Agile к данному проекту. Для различных проектов мы можем применять различные методы менеджмента команды:
- Запутанные (Complex) проекты требуют наличия гипотез и их проверки, что предоставляет нам Scrum внутри Agile
- Сложные (Complicated) проекты на зрелых стадиях не требуют сложных решений и проверки гипотез, им достаточно будет следить за задачами через Kanban
- Системы мотивации: OKR для запутанных, KPI для сложных проектов
- В простых проектах можно накладывать задачи по системе Waterfall, а в более сложных раскидывать задачи по PMI, Prince2 и PMBoK
Проекты могут менять свою область
- Проекты могут менять категории в зависимости от изменения причинно-следственных связей
- Пример: стартап переходит от запутанной к сложной области
Динамика между областями
Области Cynefin не статичны. Проекты, команды и ситуации перемещаются между ними - иногда сознательно, иногда неожиданно. Понимание этих переходов критически важно для управления.
Типичные переходы
Complex к Complicated. По мере накопления опыта и выявления устойчивых паттернов проект или его часть переходит из запутанной в сложную область. Команда начинает понимать причинно-следственные связи, появляются воспроизводимые практики. Это естественный и желаемый путь развития продукта.
Clear к Chaotic (обвал). Самый опасный переход в модели. Когда команда слишком долго находится в очевидной области, возникает самоуспокоенность. Процессы окостеневают, люди перестают задавать вопросы. Любое нестандартное событие обрушивает систему в хаос, потому что никто не готов к нему. Сноуден называет это “complacent drift” - дрейф самоуспокоенности.
Граница между Clear и Chaotic
Это единственная граница в модели, изображённая как обрыв, а не плавный переход. Падение из очевидной области в хаотичную происходит внезапно и болезненно. Классический пример в IT - монолит, который годами работал “нормально”, а потом резко перестал справляться с нагрузкой.
Chaotic к Complex или Clear. Из хаоса нужно выбраться как можно быстрее. Первые действия стабилизируют ситуацию, после чего можно перейти в запутанную область для экспериментов или в очевидную, если решение найдено.
Complicated к Complex. Происходит при изменении контекста - новый рынок, новая технология, смена требований. Экспертное знание перестаёт работать, нужно снова экспериментировать.
Осознанное управление переходами
Хороший руководитель намеренно перемещает задачи между областями:
- Запускает safe-to-fail эксперименты в запутанной области, чтобы быстрее перевести задачу в сложную
- Создаёт документацию и стандарты, чтобы перевести сложные задачи в очевидные
- Периодически “встряхивает” очевидные процессы, чтобы не допустить обвала в хаос
Cynefin для тимлида
Как определить текущую область
Задайте себе три вопроса:
- Знаем ли мы, что нужно делать? Если да и решение очевидно всем - вы в Clear
- Можем ли мы найти эксперта, который знает решение? Если да - вы в Complicated
- Нужно ли нам экспериментировать, чтобы понять, что работает? Если да - вы в Complex
Если ситуация требует немедленных действий без анализа - вы в Chaotic. Если вы не можете ответить ни на один вопрос - вы в Disorder и нужно сначала разобраться с контекстом.
Быстрый индикатор
Если на планировании спринта команда уверенно оценивает задачи - скорее всего, вы в Clear или Complicated. Если оценки расходятся в разы и никто не может объяснить, почему - вы в Complex.
Распространённые ошибки
Лечить Complex как Complicated. Самая частая ошибка. Руководитель нанимает дорогого консультанта или ищет “правильную” архитектуру для задачи, где правильного ответа пока не существует. Вместо этого нужны дешёвые эксперименты.
Требовать детальный план в Complex. Подробный план на три месяца для инновационного проекта - пустая трата времени. В запутанной области планируйте короткими итерациями с возможностью пересмотра направления.
Применять Agile к Clear. Не каждая задача требует итеративного подхода. Если нужно настроить CI/CD по задокументированной инструкции, просто сделайте это. Scrum-церемонии здесь создают лишний overhead.
Игнорировать Disorder. Когда непонятно, в какой вы области, люди по умолчанию используют свой привычный подход. Менеджеры строят планы, инженеры начинают кодить, аналитики рисуют диаграммы. Все делают привычное, но не то, что нужно. Первый шаг - остановиться и определить контекст.
Застревать в Chaotic. Героический режим работы 24/7 может быть оправдан при инциденте, но если команда живёт в нём неделями - это симптом системных проблем, а не временный кризис.
Принятие решений по областям
-
Clear
-
делегируйте
-
убедиться
-
Complicated - привлекайте экспертов и давайте им время на анализ. Ваша роль - найти нужного эксперта и обеспечить ресурсы
-
Complex - создавайте безопасную среду для экспериментов. Ваша роль - ставить ограничения на стоимость экспериментов и поддерживать команду при неудачах
-
Chaotic - принимайте решения быстро и единолично. Ваша роль - стабилизировать ситуацию, потом разбираться
Коммуникация контекста команде
Прозрачность о текущей области помогает команде понять, почему вы принимаете те или иные решения. Полезные формулировки:
- “Мы пока в Complex - давайте не строить финальную архитектуру, а проверим три гипотезы за спринт”
- “Это Complicated-задача - нам нужна экспертиза в Kubernetes, давайте найдём человека, который это уже делал”
- “Сейчас Chaotic - я принимаю решение единолично, обсудим на ретро”
Используйте терминологию Cynefin на планировании и ретроспективах. Со временем команда начнёт самостоятельно определять область и выбирать подходящий способ работы.
Связь с Agile-практиками
| Область | Подходящие практики | Стиль лидерства | Тип планирования |
|---|---|---|---|
| Clear | Waterfall, чеклисты, стандартные процедуры, автоматизация | Делегирование. Лидер задаёт стандарты и контролирует соответствие | Детальный план с фиксированными сроками, диаграмма Ганта |
| Complicated | Kanban, экспертные ревью, RFC-процесс, Architecture Decision Records | Фасилитация. Лидер собирает экспертов и помогает выработать решение | Milestone-планирование, оценка экспертами, буферы на анализ |
| Complex | Scrum, Design Sprint, Lean Startup, A/B-тестирование, safe-to-fail эксперименты | Создание условий. Лидер формирует безопасную среду и задаёт границы экспериментов | Короткие спринты 1-2 недели, OKR вместо фиксированного скоупа |
| Chaotic | Incident Response, War Room, Command & Control, жёсткий таймбокс | Директивный. Лидер принимает решения единолично и даёт чёткие указания | Нет планирования - немедленные действия, ретроспектива после стабилизации |
| Disorder | Разделение задачи на части и определение области для каждой | Исследовательский. Лидер задаёт вопросы и помогает команде определить контекст | Пауза для анализа, затем планирование по определённой области |
Один проект - несколько областей
Крупный проект почти всегда содержит задачи из разных областей. Backend с понятными CRUD-операциями может быть в Complicated, а ML-компонент того же проекта - в Complex. Используйте разные подходы для разных частей, не пытайтесь уместить всё в один фреймворк.
Заключение
Модель Кеневин - ключевой инструмент для понимания и управления различными типами задач в Agile-практиках, позволяющий выбрать наиболее эффективный подход к решению задач и управлению проектами. Главная ценность модели не в классификации, а в осознанном выборе стратегии действий на основе контекста.