Развитие управленческих практик не стоит на месте: появляются новые подходы, направления и даже профессии. Мы следим за современными темами и выбираем для вас самые интересные. Сегодня предлагаем познакомиться с основами управления продуктами (product management, продакт менеджмент). Прочитав статью, вы сможете объяснить любому человеку, чем занимается менеджер продукта, и узнаете, как найти правильную идею для нового продукта.
Если вы продакт менеджер, или подозреваете, что в скором времени можете взять на себя эту роль, скорее всего, вам придется объяснить, чем вы занимаетесь, людям, которые меньше вас разбираются в этой области:
- вашему дорогому другу, у которого страничка в Фейсбуке появилась только в середине 2016 года;
- вашему отцу-луддиту (противнику автоматизации и технологий – прим. пер) в старом кардигане, который так и не привык использовать электробритву;
- вашей энергичной бабуле, самое технологически продвинутое устройство которой – это радиоприемник.
Или, возможно, это будет ваш племянник, знакомый с технологиями с рождения, но не имеющий ни малейшего понятия, как разработаны бесчисленные приложения, которыми он пользуется каждый день.
Без длинных вступлений, вот описание продакт менеджмента для всех друзей, отцов, бабушек и племянников. Надеемся, что вам и вашим коллегам оно тоже пригодится.
Что такое продакт менеджмент?
В самых простых терминах…
Продакт менеджмент – это принятие решения, что создавать дальше.
Продукты создают, чтобы решать разные проблемы. Это утверждение в равной степени применимо как к физическим продуктам, например, скейтбордам, так и к цифровым, например, Фейсбуку. Эти проблемы не просто существуют в воздухе. Это реальные проблемы реальных людей. Для простоты, будем называть их потребностями пользователей.
Потребности пользователей включают функциональные (например, «мне необходимо попасть в класс вовремя») или эмоциональные (например, «я хочу чувствовать признание моих друзей»). Такой продукт, как скейтборд, может решить обе эти потребности, но это же может сделать Тесла. Оптимальное решение для потребности может различаться в зависимости от человека, времени и контекста ситуации.
В действительности потребности пользователя решают отдельные функции продукта. Колеса скейтборда позволяют ему перевозить своего владельца. Красивые, хотя и агрессивные очертания Теслы дают владельцу возможность самовыражения.
Цифровые продукты ничем не отличаются от физических. Бабушке нужно координировать встречи с внуками, поэтому она уступает технологиям и создает аккаунт на Gmail. Спустя 5 часов обучения она отправляет свое первое электронное письмо (конечно, полностью написанное капслоком). Интуитивный интерфейс помогает ей успешно отправить письмо. Встроенная адресная книга избавляет от необходимости помнить электронный адрес своего внука (c00ld00d1997@gmail.com). В это же время ее внуки испытывают эмоциональную потребность в признании своими сверстниками и могут делать это, создавая онлайн-личности на страницах, которые предназначены для этого.
Основное различие между физическими и цифровыми продуктами в том, что функции физического продукта должны быть определены до того, как продукт будет продан. Программное обеспечение, особенно веб-приложения и мобильные приложения, постоянно пополняются новыми возможностями и функционалом, для того, чтобы понравиться пользователям. В этом случае особенно справедливо сказать, что работа продакт менеджера – решить, какие возможности и функциональность добавлять следующим шагом.
Поэтому, когда в следующий раз вы будете объяснять племяннику, чем занимаетесь, вы можете сказать:
«Знаешь эту функцию в инстаграме, которая превращает твое лицо в собачью мордочку? Эта функция была добавлена только потому, что продакт менеджер решил, что это хорошая идея, и добился ее реализации потом и кровью силами команды людей (дизайнеров и разработчиков).»
Вы даже будете знать, что ответить племяннице, которая только что поступила в университет Беркли и усмехается:
«Ну а как продакт менеджеры решают, что это хорошая идея?»
Когда задают такой вопрос, можно сослаться на определение продакт менеджмента от Марти Кагана из книги «На крючке. Как создавать продукты-хиты»: продукт или отдельная его функция должны быть ценными, удобными в использовании и реализуемыми.
Что означает эта формула?
- Ценность – в том, что продукт решает чью-то задачу, удовлетворяет потребность.
- Удобство использования – потому что многие люди должны разобраться в том, как пользоваться продуктом, и не бросить попытки на середине пути; эти же люди должны продолжать пользоваться продуктом регулярно, не разочаровываясь в нем.
- Реализуемость – так как нельзя задействовать слишком много ресурсов (время, деньги, усилия, материалы), иначе компания обанкротится или уступит более бережливым конкурентам.
Подводя итоги, продакт менеджеры решают, что создавать следующим шагом, и делают они это, определяя, является ли идея ценной, удобной в использовании и реализуемой.
Источник
В этой статье, открывающей серию публикаций по продакт менеджменту, мы простым языком объяснили, чем занимается продакт менеджер: решает, над какими продуктами или отдельными функциями этих продуктов работать дальше. Это решение принимается на основании оценки перечня идей по трем параметрам: ценности, удобству использования и реализуемости.
Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:
Ваш канал
Как определить, что вашему проекту нужен Agile?
Сегодня
Всем привет!
Классическое проектное управление основано на последовательном выполнении этапов работ (именно поэтому так же используется выражение «водопадный» или «каскадный» подход) и передаче заказчику готового продукта в конце проекта. Система Agile предлагает выстроить работу в другом формате: короткими отрезками времени, например, в 2 недели, поставлять заказчику ограниченно работоспособный продукт, который уже имеет для него ценность, и быстро получать обратную связь для корректировки направления работы. Очевидно, что перед нами два принципиально разных подхода. Лучше ли Agile классического проектного управления и стоит ли для всех проектов теперь использовать Agile? Разобраться нам поможет модель Киневин.
Эту модель разработал Дейв Сноуден (Dave Snowden) – исследователь и консультант по управлению знаниями из Уэльса. Эта модель создавалась для принятия решений при помощи определения контекста проекта. Основная мысль модели в том, что, действуя в разных системах, мы должны вести себя по-разному.
Киневин выделяет 5 типов систем: Простые (Simple), Сложные (Complicated), Запутанные (Complex), Хаотические (Chaotic) и Беспорядочные (Disorder).
5 систем в модели Киневин
Простые системы (Simple)
В Простых системах взаимосвязи между элементами и причинно-следственные связи очевидны наблюдателю. В таких системах существуют «лучшие практики» достижения результата, будь то способ производства газосиликатных блоков, завязывания морских узлов или заваривания чая. Алгоритм действий в таких системах: «Ощути – Категоризируй – Реагируй». Примерами могут быть повторяющиеся и относительно простые проекты – установка базовой станции мобильной связи, укладка тротуара во дворе, проведение вебинара.
Сложные системы (Complicated)
В Сложных системах взаимосвязей больше, а их выявление требует знаний и дополнительного анализа. В этой области не существует одной единственной «лучшей практики», есть множество «хороших практик». Так, два дизайнера по одному ТЗ сделают разные макеты сайта, и будет сложно объективно определить, какой из них лучше. Продукт в таких системах понятен и поддается описанию в виде требований, есть понимание технологии его создания, содержание работ такого проекта поддается описанию и декомпозиции. Сложные системы – «место обитания» экспертов. В общем виде в Сложной области действовать нужно так: «Ощути – Анализируй – Реагируй». Примером проектов в этом домене могут быть создание медицинского центра, внедрение ERP-системы, реконструкция производственной линии.
Запутанные системы (Complex)
Примером Запутанной системы может служить биржа или транспортная система крупного мегаполиса: огромное количество взаимосвязей, одни и те же действия часто приводят к совершенно разным последствиям. В таких системах сложно полагаться как на историческую информацию, так и на отдельные наблюдаемые со стороны факты. В таком случае нам необходимо самим изобрести практики достижения результатов. Для этого мы действуем по алгоритму «Исследуй – Ощути – Реагируй». Мы выдвигаем гипотезу, проверяем ее, смотрим на результаты и вносим изменения в нашу картину мира. Мы повторяем этот процесс до тех пор, пока не достигнем необходимого результата или пока не станет понятно, что дальнейшая реализация проекта нецелесообразна. Кстати, несколько гипотез можно проверять одновременно. В качестве примера этого домена могут быть проекты разработки нового мобильного приложения, выход на новый зарубежный рынок или создание законопроекта в области искусственного интеллекта.
Хаотические системы (Chaotic)
Хаос – состояние крайней нестабильности. В таком состоянии нет возможности проведения предварительного анализа, построения гипотез или выяснения причинно-следственных связей. Примером может служить природная или техногенная катастрофа: пожар, веерное отключение электроэнергии или отказ в работе финансовой системы из-за хакерской атаки. К счастью, состояние Хаоса встречается редко и длится довольно недолго. Здесь мы действуем по алгоритму «Действуй – Ощути – Реагируй». Первый шаг в условиях Хаоса – это Действие. Цель Действия – уменьшение Хаоса. Затем необходимо ощутить результат этого действия и прореагировать с целью перевода системы из Хаотического состояния в Запутанное. На проверку гипотез просто нет времени, в Хаотических системах все происходит невероятно быстро.
Беспорядочные системы (Disorder)
И наконец, Беспорядок. Беспорядочные системы невозможно отнести к одной из вышеописанных категорий. Как правило, Беспорядочными считаются системы, которые состоят из нескольких подсистем, относящихся к разным категориям. Цель действий в этом домене – выявить эти самые подсистемы, отнести их к одной из категорий и действовать соответственно.
Алгоритмы действий в системах модели Киневин
Где сработает классический подход?
Но вернемся к проектному управлению. Классический или «водопадный» подход предполагает построение подробного плана проекта на весь период его жизненного цикла. Мы планируем сроки, стоимость, содержание и качество. А для этого необходимо знать причинно-следственные связи в цепочке работ проекта и взаимосвязи между участниками. По всем этим критериям классическое проектное управление наиболее подходит для работы в Сложных системах: при строительстве дорог, зданий, запуске производства промышленного оборудования.
В каких ситуациях нужен Agile?
К Запутанным системам относятся проекты с высокой долей неопределенности. Как правило, это проекты, связанные с инновациями. В них нет лучших или хороших практик. Зачастую даже нет четких требований к будущему продукту. Планировать в таких системах можно лишь на небольшой отрезок времени. И здесь на сцену выходит Agile. За ограниченный интервал времени мы проверяем гипотезы о том, каким должен быть продукт, создавая его ограниченный функционал. Разработчик получает возможность на основе обратной связи от пользователей и заказчиков сделать выводы для последующего улучшения продукта. Agile возник именно в таких условиях и здесь применение гибких подходов принесет наибольшую пользу.
Резюме
Для работы в домене Сложных систем гибкие практики избыточны: нет необходимости в проверке гипотез и изобретении практик там, где уже существуют хорошие практики и компетентные эксперты. Ложка хороша к обеду, а инструмент – для своей задачи. Agile не заменит проектное управление, они предназначены для разных ситуаций. Применяйте инструменты в тех ситуациях, для которых они созданы, и с большей вероятностью добьетесь успеха.
В следующей статье мы расскажем, что такое гибкое мышление и почему не стоит пытаться «внедрить» Agile.
О том, как выбрать правильный подход для решения ваших организационных задач, в чем особенности, преимущества и недостатки итеративно-инкрементального подхода, вы можете узнать на тренинге ICAgile Certified Professional
Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:
