Один из главных принципов, которому учат в консалтинге. При этом в большинстве источников авторство приписывается McKinsey и Барбаре Минто в частности.
В моём арсенале этот метод занимает видное место в ежедневных рутинах. Он помогает систематизировать любую предметную область — создать классификатор чего либо, разбить тикеты на стримы, систему на подсистемы, составить план презентации и т.д.
Я видел множество статей, пытающихся доходчиво объяснить, что это такое и как использовать. Но лучшее, пожалуй, описание встретил на днях в книге 1958 года Уемова Авенира Ивановича "Логические ошибки. Как они мешают правильно мыслить". Очень рекомендую к прочтению.
MECE-принцип можно описать как строгое соблюдение правил деления понятий , которые Уёмов подробно описывает на страницах 69–74.
Если перекладывать MECE на понятия и термины книги получится следующее:
MECE — это правильное логическое деление понятия, при котором:
— Объём членов деления в сумме равен объёму делимого понятия (Collectively Exhaustive).
— Члены деления не пересекаются между собой (Mutually Exclusive).
— Деление ведётся по одному основанию , без смешивания критериев.
— Деление не пропускает ступеней и охватывает всё множество.
Этим постом хочу рассказать не только про классный MECE, но и показать, как иногда можно присвоить авторство чего-то общедоступного, из разряда здравого смысла, просто грамотно упаковав в "фреймворк".😁
Почитать про MECE (рандомная подборка статей):
— MECE: Основы структурного мышления для решения сложных задач
— Наводим порядок в мыслях: структурируем идеи c помощью принципа МЕСЕ
— Принцип MECE в деловых презентациях
#thoughts #logic #mece
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤5👍1
Знакомая ситуация? Вы запустили новую фичу — и тут же пользователи начали жаловаться. Значит, фича плохая, верно?
Не обязательно))
Сегодня хочу поговорить об одной коварной логической ошибке, которая постоянно подводит даже опытных профессионалов:
корреляция ≠ причинно-следственная связь
Или проще: "после не значит вследствие".
❌ Плохой пример мышления:
"Мы внедрили новый инструмент → через неделю упали метрики → значит, инструмент виноват"
✅ Правильный подход:
"Мы внедрили новый инструмент → через неделю упали метрики. Что ещё изменилось? Какие ещё факторы могли повлиять?"
В работе мы часто сталкиваемся с этой ошибкой:
— Пример 1: После обновления UI количество отказов выросло. Команда сразу делает вывод, что новый дизайн плохой. Но возможно, в тот же день началась сезонная распродажа у конкурента.
— Пример 2: После перехода на новый фреймворк увеличилась скорость загрузки. Все рады, но на самом деле улучшение дал CDN, который подключили параллельно.
— Пример 3: После релиза новой функции выросла конверсия. Продакт рад, но на самом деле это сезонный всплеск спроса.
Как не попадаться в эту ловушку?
— Ищите альтернативные объяснения - когда видите связь между двумя событиями, задайте себе: "Что ещё могло повлиять?"
— Собирайте больше данных - одна метрика не даёт полной картины. Сравнивайте с контрольной группой, анализируйте временные ряды.
— Проводите A/B-тесты - если хотите точно знать причину, единственный надёжный способ — контролируемый эксперимент.
— Задавайте "глупые" вопросы - "А точно ли это связано?", "Может, мы что-то упускаем?", "Как это проверить?"
Помните: в нашем мире всё взаимосвязано. Просто потому что событие B произошло после события A, не значит, что A вызвало B. Иногда это просто совпадение, иногда третий фактор влияет на оба.
Следующий раз, когда в команде начнут искать "виновника" упавших метрик, предложите остановиться и посмотреть шире. Возможно, проблема совсем в другом месте.
#thoughts #analytics #logic
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤4👍3