В последние годы стало очень модно противопоставлять проектному подходу продуктовый. Мол, проекты — это когда зафиксированы результаты, сроки, бюджеты, и потому всё жёстко и неудобно, а продукты — это когда ничего на старте непонятно, но будем стараться создавать ценность по мере движения вперёд. Управление проектами теперь не в фаворе, управление продуктами — наоборот.
Однако многие, кто заменяет (у себя или у клиента) проектный менеджмент на продуктовый, не утруждают себя анализом границ применимости, а «приклеивают» управление продуктами и к месту, и не к месту.
Приведу примеры, связанный с информационными технологиями: предположим, у нас есть идея какой-то ИТ-системы, закрывающей очень существенную потребность определённой аудитории или устраняющей очень неприятную «боль», при этом аудитория является внешней по отношению к нашей организации и, как нам кажется, готовой платить за закрытие потребности и устранение боли. Мы до конца не понимаем, что за ИТ-система получится, как именно она будет закрывать и устранять, куда она будет развиваться, как её позиционировать, как монетизировать. На верхнем уровне идея нам ясна, а в реализации, понятное дело, будет миллион вопросов и миллиард вариантов. Пригодился бы в таком случае продуктовый подход, применённый к разработке ИТ-системы? Очень вероятно.
Теперь посмотрим на другую ИТ-систему: почти готовую, сторонней разработки, нами приобретённую и теперь кастомизируемую для автоматизации внутренних бизнес-процессов нашей компании. Да, здесь тоже есть разработка и развитие, и даже немножко неопределённости. Стоит ли в этом случае применять продуктовый подход? Совсем не очевидно, ведь продукта как такового у нас нет. Однако очень многие зачем-то пытаются играть в продуктовый менеджмент и в таких вот кейсах.
Попробуем разобраться, разумно ли это.
Сначала нам потребуется дать определение продуктовому подходу. Как это часто бывает (см. IT Service Management, Agile, DevOps, Kanban и проч.), найти годное, разумное и универсальное определение будет нелегко. Так уж повелось, что в области менеджмента используются концепции, которые мало кто пытается определить; вместо этого разные авторы и эксперты делают вид, что определения не нужны, либо что всем и так всё понятно, либо определяют через примеры (то есть: никак не определяют). Для целей настоящей заметки нам будет достаточно вот такого определения:
Продуктовый подход — это способ максимизации бизнес-результатов в условиях динамически появляющихся и меняющихся возможностей и, как правило, высокой неопределённости через определение продукта и организацию деятельности вокруг этого продукта.
При этом продуктовый подход помогает постоянно находить ответы на следующие вопросы:
Какую бизнес-модель использовать, как её изменять? Как монетизировать?
На какую целевую аудиторию направлять продукт? Как позиционировать и менять позиционирование продукта?
Какую функциональность нужно добавить или изменить? Какие свойства продукта нужно создать или изменить? Когда это лучше всего сделать?
Какую функциональность не нужно добавлять или изменять? Какие свойства не нужно создавать или изменять?
…
Из определения и списка вопросов следует, что продуктовый подход не является универсальным. Можно выделить следующие три основных критерия его применимости:
динамически появляющиеся и меняющиеся возможности;
активное и постоянное развитие;
(возможно) высокая неопределённость.
Вернёмся к двум примерам, которые я приводил в начале заметки. Для первой ИТ-системы (той, что направлена на внешних клиентов) перечисленные критерии полностью применимы. Для второй (которая направлена на внутренних клиентов) — скорее нет, чем да; возможно, сработает лишь один критерий из трёх, активное и постоянное развитие.
Продолжим рассуждения. Что происходит сразу же, как только какая-либо организация начинает «внедрять» продуктовый подход? Известно что: нужно что-то назвать продуктом и назначить владельца продукта (product owner). Снова вернёмся к нашим примерам. В первом из них выделение продукта пройдёт, скорее всего, просто и безболезненно — все, кому нужно, будут достаточно хорошо представлять себе что именно мы понимаем под данным продуктом. Равно как и назначение владельца продукта будет означать, что у данного персонажа появляются значимые в рамках организации ответственность и полномочия, зачастую сильно завязанные на P&L и личный финансовый доход.
А что произойдёт со вторым примером? Вполне возможно, что упражнение «давайте наши ИТ-системы поделим/сгруппируем в продукты» будет волюнтаристским, мало обоснованным, границы продуктов получатся нечёткими, плавающими. Назначенные владельцы продуктов не получат значимых полномочий, их мотивация будет слабо завязана на успешность продукта, а, значит, реализовать своё назначение и свою ответственность им будет не проще, чем тем же менеджерам проектов.
Далее, продуктовый подход предлагает множество очень интересных инструментов, или практик, например, CustDev, Customer Journey Map, дорожные карты продуктов, MVP, продуктовые метрики (MAU, DAU и прочий retention) и других. Для первого из наших примеров эти практики могут очень помочь в создании и развитии продукта. Для второго — скажем прямо, не совсем. CustDev для бухгалтерии — любопытное мероприятие, как и измерение retention для работников, к примеру, отдела логистики.
Итак, анализ ключевых составляющих продуктового подхода подводит нас к традиционному выводу: для каждой задачи нужно использовать свой инструмент. Если то, что вы хотите назвать продуктом, удовлетворяет трём основным критериям — добро пожаловать в дивный новый мир продуктового менеджмента. Если же нет — стоит поискать другие методы, способы, подходы.
Однако не всё так просто. У меня есть два соображения, почему продуктовый подход хорошо использовать даже тогда, когда критерии не очень выполняются.
Первое: некоторые элементы продуктового подхода будут полезны даже в тех случаях, когда у нас «не очень-то и продукты». Например:
концентрация на ценности, а не на функциональности;
чёткое определение границ и зависимостей, в том числе взаимных, отсюда — полшага до взаимных обязательств;
использование дорожных карт, даже если в первое время это фактически будут дорожные карты релизов функциональности, а не настоящие дорожные карты продуктов;
организация рабочего процесса (а то и потока создания ценности), а не процесса разработки ПО;
формирование продуктовых, а не проектных команд;
использование продуктовых метрик для принятия операционных и тактических решений, даже если вместо MAU/DAU мы сможем измерять, к примеру, только использование функциональности.
Скажу так: не видел, чтобы перечисленные элементы приносили вред, зато видел, как они приносят пользу, даже если настоящих, «взрослых» продуктов нет.
И второе: в большой организации (читай: Enterprise) от унификации подхода может быть больше пользы, чем вреда, если, конечно же, всё стараться делать с умом. Что я имею ввиду: несколько лет назад активно обсуждалась концепция бимодальных ИТ, или мультискоростных ИТ (название зависит от того, чьи материалы вы читаете, Gartner или Forrester). Предполагалось, что в одном и том же ИТ-департаменте часть систем могут развиваться и использоваться (change & run) на «высокой» скорости, а другая часть — на «низкой». Поэтому в одной части этого ИТ-департамента применяются одни методы и подходы к организации деятельности (например, продуктовый подход), а в другой части — другие (например, проектный подход).
Так вот, опыт показывает, что построение такого ИТ-департамента — довольно сложная задача, требующая высокой компетенции внутренних управленцев, равно как и опытных и недешёвых консультантов рядом. Потому — может быть экономически нецелесообразной. Проще, дешевле и лучше использовать единые, унифицированные подходы.
Итак, суммируем. Продуктовый подход можно, на мой взгляд, использовать даже в тех случаях, когда у нас нет классических продуктов. Такое использование, разумеется, требует осмысления, его не следует применять под копирку, по аналогии, или потому, что все вокруг так теперь делают.
