Всем привет!

Всех с наступившим, надеюсь отлично провели новый год и готовы что то почитать интересное

Сегодня я расскажу вам про важный концепт из области управления проектам - матрица Cynefin (также это фреймворк)

Как ее только не произносят: киневин, синефин, цинефин и так далее, слово уэльское, разговорное, обычные правила английского тут бессильны, официально произносится как "kuh-NEV-in”, означает “место обитания или принадлежности” (habitat). Придумал матрицу профессор Дейв Сноуден, крутой старый чувак, у него очень интересные интервью на ютубе, советую посмотреть какое нибудь хотя бы одно.

Итак, матрица описывает 5 доменов, проект может находится в одном из них и, соответственно, фреймворк описывает разную последовательность действий, в зависимости от того, в каком домене находится проект

1) Очевидный (или Явный, или Простой) — Clear / Obvious

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

2) Сложный — Complicated

Здесь есть причинно-следственные связи, но они требуют анализа или экспертных знаний. Подход — хорошие практики, не единственно верные.

3) Сложнокомплексный (или Комплексный) — Complex

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

4) Хаотичный — Chaotic

Нет устойчивых причинно-следственных связей. Требуется немедленное вмешательство, чтобы стабилизировать ситуацию.

5) Неопределённый (или Беспорядочный) — *(Disorder)*

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

Как это использовать?

Пример 1: Клиент требует новый модуль в продукте
Ситуация: Клиент хочет новый отчёт по аналитике. Думает, что «это просто».

Разбор:
- Сначала кажется Очевидным — просто вывести данные.
- Но при анализе выясняется, что источники данных разрозненные, API нестабильны.
- Это уже Сложный домен — нужен аналитик + архитектор, чтобы проработать логику и интеграции.

Решение:
- Опиши возможные варианты отчёта.
- Проведи оценку усилий для каждого.
- Согласуй с клиентом, какой из вариантов покрывает ключевые цели.

Пример 2: Запуск нового финтех‑продукта на рынке MENA
Ситуация: Непонятна реакция пользователей. Регуляторные риски. Разная зрелость у стран.

Разбор:
- Это типично Комплексный домен: неизвестные переменные, нужна гибкость.

Решение:
- Запустить MVP в одной стране.
- Собрать данные о поведении пользователей.
- Постепенно расширяться, меняя фичи и UX под поведение реальных пользователей.

Пример 3: Уволился главный DevOps, все пайплайны лежат
Ситуация: Нет доступа к ключевым системам, прод упал.

Разбор:
- Это Хаос — надо действовать немедленно, не разбираясь в причинах.

Решение:
- Восстановить сервис любой ценой: откат, резерв, внешние ресурсы.
- Только после стабилизации — анализ, построение нового CI/CD.

Пример 4: Заказчик сам не знает, что хочет
Ситуация: Вроде «простой сайт», но требования постоянно плавают, фидбек противоречивый.

Разбор:
- Это Неопределённость (Disorder). Пока непонятно, с чем ты имеешь дело.

Решение:
- Разбей требования по частям.
- Где можно — применяй стандарты (Очевидное).
- Где нужна интеграция — оцени (Сложное).
- Где реакция пользователей важна — планируй A/B тесты (Комплексное).
- Если что-то резко ломается — переход в Хаос.