Многие проблемы кажутся неподъёмными только потому, что их пытаются решать одним большим комком. А потом удивляются, почему ничего не проясняется даже после десятков часов обсуждений. Здесь и появляется принцип MECE. Два простых требования к тому, как именно делить проблему: части не должны пересекаться и вместе должны покрывать всё без остатка.
Mutually Exclusive — значит, ни один элемент не попадает сразу в две категории. Если человек классифицирует причины оттока клиентов как «плохой сервис» и «высокие цены», то почти любой случай легко попадёт в обе корзины. Пересечение неизбежно, а значит анализ будет дублироваться и путаться.
Collectively Exhaustive — все возможные варианты должны быть учтены. Если разделить продажи только на «офлайн» и «онлайн», то забытыми окажутся маркетплейсы, партнёрские продажи, опт, бартер, тестовые отгрузки. Пропущенная категория почти гарантированно окажется той самой, где прячется главная причина.
Зачем вообще так строго себя ограничивать? Потому что мозг любит сокращения. Когда структура не MECE, человек либо бесконечно возвращается к одним и тем же пунктам, либо пропускает целые пласты реальности. В итоге решение либо запаздывает, либо бьёт мимо.
Самый практичный способ пользоваться принципом — строить дерево вопросов. Начинается всё с главного: «Что именно происходит и почему?». Дальше первый уровень должен отвечать на вопрос «по каким основным направлениям это может происходить?». И здесь уже нужна жёсткая проверка.
Допустим, задача — понять, почему проект постоянно срывает сроки. Один из худших вариантов первого уровня:
- задержки из-за программистов
- задержки из-за дизайна
- задержки из-за заказчика
На первый взгляд логично. На деле — почти классическое НЕ-MECE. Программисты и дизайн пересекаются (один и тот же человек может быть и там, и там), а заказчик может вызывать задержки по десятку разных причин, часть из которых дублирует первые две категории.
Гораздо чище выглядит так:
- проблема на нашей стороне (ресурсы / процессы / навыки / мотивация)
- проблема на стороне заказчика (изменение ТЗ / несогласование / задержка оплаты / недоступность для обратной связи)
- внешние непредвиденные факторы (форс-мажор, регуляторные изменения, ключевой подрядчик обанкротился)
Эти три блока почти не пересекаются и вместе закрывают 95–98 % реальных ситуаций.
На следующем уровне каждый блок снова делится. Например, «проблема на нашей стороне» →
- не хватает людей
- люди есть, но компетенций не хватает
- компетенции есть, но процессы тормозят
- процессы нормальные, но мотивация / коммуникация разрушены
И так до уровня, где вопрос уже можно проверить фактами за день-два: «Сколько задач в среднем закрывает мидл-разработчик за спринт по сравнению с планом за последние три месяца?».
Готовые MECE-каркасы сильно ускоряют работу. Самые надёжные из них:
- доход = количество клиентов × средний чек × частота покупок
- прибыль = доход − постоянные затраты − переменные затраты
- время выполнения = время активной работы + время ожидания
- проблема клиента = функциональность + удобство + скорость + цена + поддержка
Когда структура выстроена правильно, исчезает ощущение, что «всё связано со всем». Появляется последовательность: отвечаешь на нижние вопросы → поднимаешься выше → видишь, где именно основная дыра.
Главное заблуждение — думать, что MECE нужен только консультантам из больших фирм. На практике это просто самый быстрый способ перестать топтаться на месте. Разбил правильно — сразу понятно, где копать. Разбил криво — будешь месяцами «анализировать», а по факту бегать по кругу.
В итоге принцип не про красивые схемы на слайдах. Он про то, чтобы мозг не тратил энергию на путаницу, а сразу направлял её туда, где можно найти реальный рычаг. И чем чаще человек заставляет себя проверять «а это точно MECE?», тем быстрее приходят ясные решения.
ПОНРАВИЛСЯ ПОСТ? Ставь палец вверх и подписывайся!
Телеграмм: https://t.me/techitpm
ВК: https://vk.com/bitpm