Project to Product: как менеджеру проектов работать в продуктовой среде

Люди задают много вопросов на эту тему. А стоит ли учиться на менеджера проектов, если везде Agile? А может, стоит переучиться на «продакта», есть я уже «проджект»? А если я менеджер продуктов, может, стоит научиться управлять проектами и командой разработки? То есть, управление проектами противопоставляется управлению продуктами — как нечто несовместимое или взаимоисключающее.

Сегодня я хочу поглубже копнуть эту тему: можно ли сочетать оба этих процесса и обе профессии – проджект-менеджера и продакт-менеджера. Также эта тема может быть полезна, если в вашей организации стоит вопрос о переучивании менеджеров проектов в менеджеров продуктов, как более современную и популярную профессию.

Термины

Product Management (Управление продуктом)

Если мы посмотрим на стандарт про жизненный цикл ПО — а именно, ГОСТ Р ИСО/МЭК 12207-2010, который основан на международном ISO/IEC 12207:2008, — то увидим следующее:

“продукт (product): Результат процесса”.

Получается, что управление продуктом — это процесс. Давайте дополню, что сам процесс может включать планирование, создание и запуск продуктов, а также дальнейшую его поддержку в плане улучшения и развития — нечто такое, что не заканчивается.

Теперь надо детальнее разобраться с термином «продукт», т.к. термин из ГОСТ ни о чем конкретном не говорит. Тут надо оговориться, что в данной статье я рассуждаю только про цифровые продукты. Многое может быть применимо и для физических продуктов, но цифровые продукты обладают как минимум одним значимым отличием – почти нулевые расходы на копирование.

Поэтому смотрим в тот же стандарт на термин:

“программный продукт (software product):

Совокупность компьютерных программ, процедур и, возможно, связанных с ними документации и данных”.

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

Давайте опять взглянем на стандарт:

“выпуск (release):

Конкретная версия элемента конфигурации, которая становится доступной для специфической цели (например, выпуск теста)”.

Тут уже интереснее, лучше подходит к нашей ситуации. Если совместить эти определения, получается, что каждый выпуск программного продукта — это есть ни что иное, как отдельный продукт.

Далее давайте рассмотрим, что такое проектное управление.

Project Management (Управление проектами)

Если мы обратимся к тому же стандарту, то увидим следующее:

“проект (project):

Попытка действий с определенными начальными и конечными сроками, предпринимаемая для создания продукта или услуги в соответствии с заданными ресурсами и требованиями”.

Получается, что управление проектами — это процесс по запуску и сопровождению проектов, в рамках которых нужно достигать отдельных, уникальных целей и результатов (продуктов).

Я считаю определение из ГОСТа не достаточным, и для меня, проект — это временно́е предприятие, направленное на создание уникального продукта, услуги или результата, согласно PMBOK. То есть, у нас есть начало и завершение проекта, объем работы и требования, а также ограничения по ресурсам.

Теперь предлагаю погрузиться более детально в различия.

Различия продуктового и проектного управления

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

Соответственно, при управлении проектами нам надо следить за ограничениями, присущими проектам – сроки, бюджет, объем работы и т.п. Также важно налаживать коммуникацию, собирать информацию и статусы выполнения проектов и задач, синхронизацию работ разных людей и команд.

При управлении продуктом нам надо следить за параметрами, присущими продуктам – востребованностью, экономикой, удержанием клиентов и т.д. То есть, нам важно делать продаваемые продукты и зарабатывать деньги.

Вот вкратце и вся разница.

Получается, что продукт нельзя создать без проекта? Я считаю, что да, нельзя. Многие могут тут не согласится, но если детально посмотреть, на тот же Скрам, то мы увидим, что спринты — это те же проекты. Фичи — это те же проекты и т.д.

Мы немного посмотрели на различия проектного управления и продуктового. Теперь давайте рассмотрим, с чего начинается любая организация.

Трехмерная модель организаций

Если мы посмотрим на модель организации по методу Пульса, то увидим, что любая организация развивается как минимум в 3 направлениях:

• Цели
• Технологии
• Процессы и правила

Может показаться странным, что я рассматриваю метод управления проектным бизнесом в рамках рассуждений про управление продуктом. А где Agile, Scrum, CustDev, Lean и т.п.? Дело в том, что за несколько лет внедрения метода Пульса в продуктовой компании, у меня появилось понимание того, как должна быть организована проектная работа в продуктовой компании. Да, да, проектная работа при разработке продукта по современным подходам.

Давайте начнем немного издалека и разберем каждую вершину трехмерной модели организации.

Цели

Что кроется за данным направлением? Тут должен быть ответ на вопрос, ЧТО мы делаем и куда бежим. То есть стратегия. Интересно, а продуктовые менеджеры должны работать тут?

Технологии

Вопрос к технологиям должен быть построен через КАК мы делаем то, ЧТО нужно делать в рамках нашей цели.

Процессы и правила

И, наконец, третье измерение нужно, как и всегда, для того, чтобы подружить предыдущие два – правила «программируют» организацию. Тут тоже должен быть должен быть на вопрос КАК, но не КАК с точки зрения технологий, а «КАК нам всем вместе организовать работу так, чтобы сделать то, ЧТО надо и КАК требуется по технологиям».

И вроде бы очевидно, если брать такую простую модель и применять для продуктовых компаний и команд, то получается, что менеджер продукта работает на вершине «Цели», команда разработки работает на вершине «Технологии», а менеджеры проектов — на вершине «Процессы и правила». Но так ли это?

Я много исследовал тему проектного и продуктового подходов в рамках улучшения метода с его автором Алексеем Васильевым. В итоге у меня родилось несколько интересных открытий. В данной статье мы рассмотрим лишь некоторые, остальные планирую рассмотреть в следующих статьях.

• Давайте посмотрим на треугольник еще раз повнимательнее. Возьмем, например, вершину с целями. Как ставить цели? Как приоритизировать цели? Как отслеживать их выполнение? Мы помним, что на вопрос КАК отвечает вершина технологий, но тут то речь про цели, а не разработку ПО. Получается, что на вершине целей тоже есть технологии?

• Или рассмотрим вершину технологий – ЧТО нужно сделать, чтобы достичь целей? И КАК внедрить то, ЧТО нужно для достижения целей? Получается рекурсия какая-то. В технологиях есть цели, в целях есть технологии. И тоже самое в процессах и правилах.

Может наша модель не верна, и нельзя организацию описать через простую геометрическую фигуру? И да, и нет. Со временем мы заметили и сделали несколько открытий. Дело в том, что треугольник — это лишь отправная точка. Мы нашли в нем рекурсию.

Рекурсия трехмерной модели организаций

Если продолжить размышления и ответы на вопросы КАК и ЧТО, то получается, что в каждой вершине есть свои цели, свои технологии и процессы с правилами. То есть, для формирования целей, на соответствующей вершине, нам нужны технологии для этого. Это как раз и есть современный Product Management. Но он не отвечает на вопрос ЗАЧЕМ? Он только частично закрывает вопрос, КАК организовать процесс.

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

Вот простой пример. Технологией веб-сайта могут быть HTML, CSS, JavaScript, React и т.п. А технологией для разработки могут быть инструменты вроде IDE для программистов, Figma для дизайнеров или дизайн-систем, для синхронизации работы дизайнеров и разработчиков. Или вот еще пример: парное программирование — это технология написания кода.

Открытия, который мы нашли, исходя из рекурсивной модели

Проекты есть везде, и даже в современных продуктовых подходах и разработке согласно Agile

При формировании стратегии развития продукта в продуктовой компании есть такое направление, как проектная деятельность. С её помощью проектные менеджеры могут помогать менеджерам продукта организовывать свою работу. То есть, я утверждаю, что в управлении продуктами есть проекты. Не важно, проводите ли вы скоринг бэклога, работаете ли с гипотезами, проводите ли проблемные интервью или считаете ли юнит-экономику.

И если мы придерживаемся Agile-подходов и самостоятельности команд, то проектное управление должно быть как навык. Именно поэтому, в Scrum есть такая роль, как Scrum Master, а не руководитель проекта. Но при этом в некоторых случаях, лучше, чтобы большим количеством одновременно запущенных проектов занимались профессиональные проектные менеджеры.

Качество как баланс трех вершин

Отдельным открытием было то, что нигде в трехмерной модели организации не упоминается качество и поддержка. Например, если взять классические шаги разработки ПО Уинстона Ройса (Winston Walker Royce) и его статью 1970 года, то мы увидим процесс разработки ПО. Да, в них не учтены предшествующие этапы, которые сейчас как раз принято называть Product Management, но при этом есть шаги по сбору требований и анализу. Если условно принять, что это можно считать анализом рынка и сбора требований от пользователей, то мы получим почти текущую картину мира.

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

Вот этого направления и нет в треугольнике «Метод пульса». Где же поддержка в модели треугольника? И за что отвечает эта поддержка? На второй вопрос ответить проще, т.к. поддержка обеспечивает качество. И получается, что качество найти проще – это же баланс всех трех направлений! Из этого выходит четвертое направление. С одной стороны – это баланс всех трех направлений, а с другой – это еще одно направление, которым должны заниматься все участники.

Если совместить оба открытия, то получается, что баланс должен быть в каждой вершине треугольника в рекурсии. И это одна из проблем, которые я вижу при использовании современных продуктовых подходов и отрицании необходимости управления проектами – нарушение баланса трех направлений: стратегии, технологий и процессов.

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

Из интересного, если посмотреть на PMI и их свод знаний (PMBOK), то мы увидим, что в последних версиях они начинают включать в свод подходы и принципы гибкой разработки (Agile), и даже гибридные подходы. А вот Agile никак не учитывает управление проектами в своих подходах.

Вместо итогов

Данную тему я уже исследую несколько лет и сформировал свое представление:

Есть 2 варианта для людей с профессией руководителя проектов:

• Переучиваться в менеджера продукта;
• Найти себя, как руководитель проектов в продуктовой компании.

И 2 варианта для продакт-менеджеров:

• Обучиться дополнительно навыкам проектного управления;
• Найти себе в команду менеджера проекта, чтобы самим заниматься только продуктом.

Лично мне больше нравится идея современных гибридных подходов, в которых мы совмещаем продуктовый и проектный менеджмент. На данный момент я в процессе формирования такого подхода. И если статья будет полезна (прошу вас оценить статью ниже!), я напишу на эту тему еще ряд статей, приближаясь к гибридному управлению.

А если вы хотите погрузиться глубже в эту тему и наработать практику, приходите ко мне на тренинг “Project to Product. Краткий курс перехода” для проектных менеджеров. Там мы на примерах и ваших кейсах детально сравним разные современные подходы по разработке цифровых продуктов.

Желаю всем продаваемых продуктов и проектов без срывов сроков!