Будьте ВИСИ или MECE-principe

Техника МЕСЕ лежит в основе всей работы над проектами в McKinsey. Это одна из лучших практик для бизнес анализа и постановки задач. Особенно сложных проектов.

МЕСЕ — это аббревиатура от «взаимно исключающие, совместно исчерпывающие» (Mutually Exclusive, Collectively Exhaustive). Техника МЕСЕ лежит в основе всей работы над проектами в McKinsey.

Ключевые преимущества MECE:

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

Она вкладывается в голову каждого нового сотрудника с момента его прихода в компанию.

Все документы, включая внутренние записки, презентации, почту или голосовые сообщения, должны быть составлены в виде МЕСЕ. Не говоря уже о аналитических документах по проекту.

Спросите любого выпускника школы McKinsey о том, что ему больше всего запомнилось о процессе работы над решением проблем, и он ответит вам: МЕСЕ, МЕСЕ, МЕСЕ.

МЕСЕ структурирует ваше мышление

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

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

Взгляните еще раз. Все ли аспекты следуют один за другим (именно один за другим)? При этом подумали ли вы обо всех аспектах? Если и это так, значит, ваши пункты совместно исчерпывающие.

Пример подхода

Предположим, ваша команда работает над проектом для знаменитой американской производственной компании «Американские Скрепки». Проблема, с которой вы столкнулись, — «Нам необходимо продавать больше наших скрепок». Ваша команда может начать с составления следующего списка для решения этой проблемы:

Изменение способа продаж в розницу
Улучшение системы маркетинга продукции
Снижение стоимости единицы продукции

Несмотря на то, что этот список выглядит достаточно общим, это нормально. Мы продолжим разговор о дальнейшей детализации в следующей секции. Важно, что этот список составлен в технике MECE.
Предположим, вы добавите еще один пункт — «Перестройка процесса производства». Как этот пункт соотносится с тремя уже написанными? Действительно, это важный аспект, но он не может находиться бок о бок с предыдущими тремя пунктами. Он должен быть размещен под пунктом «Снижение стоимости изделий», вместе с подпунктом «Поддержка дистрибьюторской системы» и еще одним — «Улучшение учетной политики». Почему так? Потому что все эти три пункта призваны снизить стоимость изделий. Размещение одного из них (или всех) в ряду первых приведет к повторениям. Список перестанет быть взаимно исключающим. Повторения укажут на отсутствие стройности в мыслях составившего этот список и введут в заблуждение читателей.
Когда ваш список готов и все пункты в нем разделены и ясны, вы должны проверить, присутствуют ли в нем все аспекты, относящиеся к проблеме. Вернитесь назад к пункту «Перестройка процесса производства», который вы поместили под пунктом «Снижение стоимости изделий». Здесь кто-то из членов вашей команды может сказать: «Мы должны подумать об улучшении качества нашей продукции с помощью улучшения производственного процесса».
Он прав. Значит ли это, что вы должны переструктурировать уже имеющийся у вас список? Нет, но вы должны включить это замечание в свой список под пунктом «Снижение стоимости изделий», сделав его отдельным подпунктом «Изменение процесса производства для улучшения качества продукции». Итак, теперь ваш список выглядит так:

1. Изменение способа продажи в розницу
2. Улучшение системы маркетинга нашей продукции
2.1. изменение процесса производства для улучшения качества продукции
3. Снижение стоимости единицы продукции
3.1. перестройка процесса производства для снижения затрат на единицу продукции

Предположим, у вашей команды возникло еще несколько интересных идей, которые не подходят ни под один из уже существующих пунктов. Что тогда? Вы можете игнорировать их, но это не поможет вашему клиенту решить его проблему. Вы можете дописать эти пункты в основной список, но тогда их будет слишком много. Обычно списки, которые презентует McKinsey, состоят не менее чем из двух, но и не более чем из пяти основных пунктов (конечно, три — лучший вариант).

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

Примеры из практики команды разработки PHP

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

На практике возможности визуализации очень ограничены и потому все эти пирамидки превращаясь в простой текст, принимают форму обычного документа, с заголовками и самое главное — Table of contents.

Пример хорошей аналитики в команде PHP как RFC Namespaces in bundled PHP extensions тут.

Вместо слова RFC вы можете использовать слово ТЗ, или Спецификация или Бизнес анализ задачи — то как назвать документ не очень важно.

Важно то что идеи в этом документы должны быть структурированы и иметь ToC.

Например ребята из PHP собрали хороший шаблон документа: https://wiki.php.net/rfc/template

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

Состав разделов документа может отличаться от задачи к задаче, но почти всегда есть такие заголовки как введение, предложения, мотивация, порядок шагов или дорожная карта и т. д.

Итоговый документ анализа проекта может быть как коротким, так и длинным: