Что является проектом, а что продуктом? Как понять, когда проект перетекает в продукт и когда продукту нужен проект? К сожалению, границы этих понятий бывают неочевидны, вызывая путаницу в подходах, из-за которой страдают и проектные команды, и продуктовые.
Что можно назвать продуктом?
Определение продукта. Если ваша компания постоянно создает какую-либо ценность для своих клиентов (товар или услугу), это означает, что она производит определенный продукт. Неважно, что это: молочная тара, автомобиль, дизайн или консалтинг. Сегодня довольно часто о продуктах говорят не только в контексте рынка, но и подразумевая ценность, которую создают подразделения вашей компании друг для друга. Этот тренд берет начало с тех времен, когда компании переводили определенные функции на аутсорсинг, и специалисты, которые ранее воспринимались как коллеги, превращались в поставщиков продуктов.
Продукт – товар или услуга, которую можно предложить для рынка и которая будет удовлетворять потребности потребителей.
Развитие продукта. Мы говорили, что agile-философия подразумевает стремление постоянно улучшать продукт, то есть увеличивать его ценность для клиента. Главная идея продуктового подхода заключается в стабильном повышении качества. Это значит, что продукт как объект управления выделяется для того, чтобы вы могли лучше понимать требования рынка или внутренних потребителей. Чем больше требований вы удовлетворяете, тем качественнее продукт, тем больше его ценность для вашего клиента.
Экономика продукта. Продукт может быть рентабельным и нерентабельным, то есть производить его вам или выгодно, или нет. Поэтому когда вы выстраиваете стратегию компании, то делаете это относительно рынка. Допустим, планируете выводить на рынок новые продукты или повышать качество тех, что уже есть.
Продукт проекта – это совсем не тот продукт?
Иногда говорят, что в результате проекта создается продукт. Однако есть нюанс в том, как понимают продукт в проектном и продуктовом подходе.
Продуктовый подход видит продукт как ценность для клиента. Продукт может существовать очень долго, может уйти с рынка или реализоваться в новом качестве.
Проектный подход видит продукт как результат проекта. Такой продукт вы получаете по итогам ограниченной во времени проектной деятельности. Это может быть новая услуга или товар, разработанная методология, результат исследования, информационный материал и т. д.
Может ли продукт проекта как-то влиять на продукт как ценность для клиента? Да, может. Более того, если проследить за тем, как развиваются продукты в продуктовом подходе, то окажется, что драйверами их развития довольно часто являются как раз проекты.
Как с помощью проектов повысить качество продукта?
Представьте, что вы выделили новый продукт как объект управления, и у вас теперь должна появиться команда продукта, которая несет ответственность за постоянный рост качества, то есть за стабильное увеличение ценности для клиента. Продуктовая команда может разбить свою деятельность на определенные мероприятия. Например, выделить модернизацию продукта и начать управлять ею как проектом в обычной последовательности: от идеи до экономического обоснования, от экономического обоснования до появления проектной технической документации, от утверждения документации до появления того опытного образца… И для этого проекта будет, соответственно, формироваться уже проектная команда.
Таких проектов вокруг продукта может появляться достаточно много, например: маркетинговая кампания, автоматизация производства, разработка вариантов дизайна и т. д. Все эти проекты направлены на какое-то улучшение продукта. Их совокупность называется программой проектов. Для каждого проекта в программе надо создавать отдельную команду, договариваться с ней о целях, сроках, бюджетах и интеграции полученного результата в большой и протяженный во времени продукт.
Как команда продукта может помочь достичь результатов проекта?
Может ли случится так, что не проект улучшает продукт, а наоборот, продукт влияет на результат проекта? Да, такое возможно. Допустим, ваша команда разработчиков решила не просто продавать продукт, а внедрять его у клиентов. И проектами внедрения у вас занимаются проектные команды.
Представьте, что клиент говорит проектной команде: «Ваш продукт замечательный, но мне не хватает вот таких его качеств, чтобы подписать акт». В самом запущенном случае может вообще прозвучать: «Мне не хватает этих качеств, чтобы купить у вас этот продукт».
Тогда проектная команда может подойти к команде продукта и попросить ее реализовать запрашиваемые качества в продукте. У продуктовой команды, в свою очередь, должны быть отлажены механизмы, позволяющие оценить такое предложение:
«Да, это важное качество, и мы включаем его в план. Можете договариваться с клиентом»
«Мы понимаем, зачем это клиенту, но делать не будем, потому что это не имеет отношения к нашему продукту»
«Мы знаем, как можно решить задачу клиента с помощью нашего продукта без предложенных вами доработок»
Таковы могут быть решения сильной продуктовой команды, у которой отлажены процессы планирования ресурсов и которая хорошо понимает, что и зачем она реализует в своем продукте. И самое главное – когда эта команда понимает, откуда у клиента взялась потребность в этих качествах, она создает точку опоры для проектных команд, которым предстоит внедрять продукт.
Синергия двух подходов
Таким образом, в рамках повышения качества продукта могут появляться мероприятия, из которых выстраивается программы проектов. Так проекты усиливают продукт.
В то же время продуктовая команда может поддержать проекты, дав проектным командам базис для принятия решений и облегчая их коммуникацию с заказчиками. Так продукт усиливает проекты.
Поэтому если вы видите, что ваша продуктовая команда «наезжает» на проектные, потому что те чего-то не делают или, наоборот, делают, но не то, то возможно, проблема вовсе не в проектах, а в том, как продуктовая команда транслирует им свое понимание качества. С другой стороны, если проект не ведет к улучшению продукта и его результат не интегрируется в продукт, значит произошло рассогласование целей, и за это ответственность несет проектная команда.
