Часто управленец пытается решать задачу неподходящим способом. Человек по фамилии Сноуден (не тот, другой) придумал модель Cynefin, по-нашему — Кеневин. Валлийское слово, примерно переводится как «среда обитания».<\/p>\n
Модель помогает менеджеру определить, в какой среде он работает, и выбрать подходящий метод принятия решений. Выделяют пять сред, или доменов: очевидный<\/b>, осложненный<\/b>, сложный<\/b>, хаотичный<\/b>, беспорядочный<\/b>.<\/p>\nОчевидный домен<\/h2>\n
Задачи простые, причина и следствие очевидны, решение лежит на поверхности. Такие задачи можно закрыть по инструкции: выявить проблему, сопоставить с известными решениями, применить типовые подходы.
\nСменить перегоревшую лампочку, добавить памяти перегруженному серверу, отправить стандартный договор клиенту в ответ на запрос — это задачи из очевидного домена.
\nПросто возьми инструкцию и фигачь по ней.<\/p>\n
Есть проблема, и решение неочевидно, но поддается анализу. Нужны эксперты, они разберутся в данных, выберут подходящий вариант. Здесь может быть несколько решений, но все они логичны и объяснимы.
\nНапример, оптимизировать налоги, написать код сортировки массива, выявить неисправность оборудования, создать архитектуру айтишной системы.
\nПодключи экспертов и получи решение.<\/p>\n
Правильного ответа нет, его можно найти только через пробы и анализ, даже эксперты не знают точного решения. Придется экспериментировать, выявлять закономерности и на их основе выстраивать стратегию.
\nПримеры: вывод продукта на рынок, запуск рекламной кампании в новой нише.
\nПроверяй гипотезы и получи решение.<\/p>\n
Ситуация нестабильна и критична, на анализ нет времени. Нужно быстро действовать и локализовать проблему.
\nПримеры: пожар в серверной, упало приложение в проде, ключевой клиент внезапно ушел к конкуренту.
\nНемедленно исправляй, разберешься потом.<\/p>\n
Это когда вообще непонятно, в каком ты домене. Команда тупит, клиенты недовольны, начальство что-то требует.
\nОпредели, в каком ты домене, потом действуй.<\/p>\n
Зачем нужна модель Кеневин? Чтобы определить тип задачи и выбрать верный способ управления. Бессмысленно решать задачи, требующие проверки гипотез с помощью «наилучших отраслевых практик». Не сработает, даже если позвать сто экспертов.<\/p>\n
Давайте теперь разберемся, как применяют модель. Вот менеджер Марианна. Ее команда готовится выкатить обновление приложения для курьеров. За пару дней до релиза кто-то замечает: карты загружаются медленнее обычного.<\/p>\n
Вроде проблема простая: не хватает мощности серверов. Это легко проверить, надо посмотреть загрузку. Ой, да! Сервер не справляется. Решение очевидно: добавляют ресурсы, карты снова работают быстро.<\/p>\n
Через час проблема возвращается. Значит, дело не только в мощности. Осложненная ситуация: требуется анализ. Марианна подключает разрабов, те смотрят логи. А-а-а, изменился алгоритм загрузки карт, сервер перегружен ненужными запросами. Решение найдено, разрабы правят код.<\/p>\n
Все хорошо? Не-а. Теперь у части пользователей приложение вообще не запускается. Разрабы не понимают, в чем дело, аналитики тоже. Это уже сложная ситуация, причин может быть много. Нужно выдвигать гипотезы, тестировать. У Марианны глаза цвета спелой клубники. Тут команда выясняет, что проблема в несовпадении версий чего-то там. Разрабатывают патч, все в порядке.<\/p>\n
Релиз в проде и... хаос! Продукт массово вылетает у пользователей, поддержка погребена под трехметровым слоем жалоб. В панике команда пытается исправить обновление, но все только ухудшается. Это хаотичная зона, действовать надо быстро. Марианна приказывает отключить проблемные функции, команда стабилизируют систему. Все начинают разбираться, что пошло не так. И вдруг... Ладно, оставим Марианну за этим занятием.<\/p>\n
Важно не только решать проблемы, но и понимать, с чем именно ты имеешь дело. Простому — инструкция. Осложненному — эксперт. Сложному — эксперимент. Хаосу — быстрые действия.<\/p>\n", "date_published": "2025-02-28T13:20:05+05:00", "date_modified": "2025-02-28T13:20:28+05:00", "tags": [ "pm", "проектирование" ], "_date_published_rfc2822": "Fri, 28 Feb 2025 13:20:05 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "226", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "118", "url": "https:\/\/timsa.ru\/all\/menedzher-proektov-vs-menedzher-produktov\/", "title": "Ликбез: менеджер проектов vs менеджер продуктов", "content_html": "
Люди из непродуктовых компаний часто спрашивают, чем отличаются менеджер проектов (Project Manager) и менеджер продуктов (Product Manager). <\/p>\n
Представьте: вы зашли в ресторан. Ресторан хороший, вы лично знаете хозяина и уверены, что все готовится из свежайших продуктов, по лучшим рецепта и с соблюдением всех гигиенических норм. Вы знаете, что блюда приготовлены правильно.
\nЗадумчиво листаете меню и вдруг понимаете, что просто хочется сладенького. Вы покидаете ресторан, покупаете себе мороженое в ближайшем киоске и радуетесь солнечной погоде.<\/p>\n
Несмотря на то, что в ресторане блюда приготовлены правильно, вам сейчас они не подошли. Для вас это неправильные блюда. А мороженое — подходящее, правильное.<\/p>\n
Разница между менеджером продукта и менеджером проекта примерно такая же, как между понятиями «сделать правильный продукт» и «сделать продукт правильно». <\/p>\n
Когда создается что-то новое — компьютерная игра, гоночный автомобиль, онлайн-сервис выдачи кредитов, смартфон, — то открывается проект. Собирается проектная команда и назначается менеджер проекта. Он будет отвечать за то, что в результате проекта получится продукт с согласованными заранее свойствами.
\nМашина сможет разгоняться до 1500 км\/ч, смартфон будет со встроенным счетчиком Гейгера, а для получения кредита не понадобится никаких документов вообще. Менеджер проекта будет отвечать за то, что этот продукт появится на рынке 1 января 2030 года, а перерасход бюджета не будет значительным. ) <\/p>\n
Менеджер проекта отвечает за то, что продукт будет создан правильно.<\/p>\n
Но рынок может не принять этот продукт. Машине негде будет разгоняться до такой скорости, счетчик Гейгера будет тиканьем раздражать владельца смартфона, а банк разорится, выдавая кредиты без документов. Тогда окажется, что силы, время и деньги на проект потрачены зря. Но к менеджеру проекта никаких претензий. Он сделал то, что от него ждали — успешно завершил проект по созданию продукта с заданными свойствами.<\/p>\n
Зато есть претензии к тому, кто отвечал за востребованность продукта рынком — менеджеру продукта. Именно он должен управлять свойствами продукта, чтобы продукт был успешен, а пользователи довольны.<\/p>\n
Менеджер продукта отвечает за то, что будет создан правильный продукт.<\/p>\n
Но менеджер продукта не отвечает за то, что продукт сделан правильно. Если вдруг у машины на презентации арабскому шейху (кто такую еще купит-то?) отвалится бампер, то все претензии к менеджеру проекта. Если к смартфону вместо счетчика Гейгера прикрутили фен, то вопросы к менеджеру проекта. <\/p>\n
Еще раз: менеджер проекта делает продукт правильно, а менеджер продукта делает правильный продукт.<\/p>\n
Важно: менеджер проекта и менеджер продукта — это роли. Часто их совмещает один человек. Это разумно для больших продуктов, которые делает несколько продуктовых команд, как в Авито. Или для маленьких продуктов с одной командой — как в стартапах, для экономии.<\/p>\n
Совмещать роли не обязательно — эти два типа менеджеров спокойно существуют в одном продукте, их зоны ответственности разделены. Менеджер продукта при этом — заказчик для менеджера проекта и его команды. <\/p>\n
Кто из них круче? Менеджер продукта много знает про юнит-экономику, метрики, умеет принимать сложные решения на основе данных и тюнинговать продукт, получая выдающиеся коммерческие результаты.)
\nМенеджер проекта умеет работать с людьми, ставить цели и достигать их в заданные сроки и бюджет, с нужным качеством.
\nОба круты.<\/p>\n