Автор статьи
Продукт и проект в IT — это две разные сущности, которые часто путают. Ведь и над тем, и над другим могут трудиться разработчики, дизайнеры и прочие диджитал-специалисты.
А еще в последнее время стало модно привязывать слово «продуктовый» к чему ни попадя. Скажем, можно встретить такие словосочетания, как «продуктовый дизайнер», «продуктовая разработка» и так далее. А остальные тогда, что, — проектные?
Давайте же расставим все точки над i. Объясним, в чем разница между проектом и продуктом, а также поведаем о различиях в работе над тем и другим.
Что такое продукт, а что — проект в IT
Начнем с примера. Допустим, на рынке появилась какая-нибудь новая программа для компьютера: например, таск-менеджер. Эта программа — продукт, рассчитанный на потребителей. А вот процесс, при котором создали первую версию этого продукта, будет называться проектом. Давайте закрепим.
Продукт — результат умственного или физического труда, созданный для того, чтобы удовлетворять потребность аудитории и приносить прибыль своему владельцу. Продукт будет существовать, пока не закончится его жизненный цикл из-за какого-нибудь отрицательного события. Скажем, сначала все ездили на каретах, но потом появились более технологичные автомобили, отчего кареты перестали быть востребованными среди масс.
Проект — это активность, направленная на достижение цели, с запланированными началом и концом. Целью проекта может быть разработка того же таск-менеджера. Кроме сроков, у проектов ограничен бюджет. Также у проекта будут свои требования, которые нужно выполнить для его успешного завершения.
В общем, проект и продукт — это вообще разные вещи. Сравнивать их, как сравнивать теплое с мягким. Тогда почему их сравнивают, что у них общего?
А вот что. И над проектом, и над продуктом может кто-то работать: например, команда IT-специалистов. Только проектные работы имеют начало и конец, а работы над продуктом ведутся постоянно, вплоть до конца его жизненного цикла, который может и не наступить. Скажем, у того же таск-менеджера могут выходить регулярные обновления, которые будут следствием работ над продуктом.
И еще раз напомним, что работа над продуктом может включать в себя отдельные проекты. Например, редизайн таск-менеджера можно считать самостоятельным проектом в рамках работ над продуктом. Спринты в Scrum тоже можно считать отдельными проектами — об этом даже написано в официальном скрам-гайде. Если что, Scrum — это фреймворк для управления процессом разработки у продуктовых команд, некий свод правил для эффективной работы.
А теперь давайте более подробно разберем различия между проектом и продуктом с точки зрения рабочего подхода.
Отличия в работе над продуктом и проектом
Клиент
Проект создается, чтобы достичь конкретную цель заказчика, руководителя или лично вас. Требования к выполнению проекта будут зависеть от цели.
Продукт разрабатывается, чтобы удовлетворять потребности сразу множества людей — его потребителей. Продукт может создаваться для определенного сегмента рынка или для нескольких сегментов сразу.
Жизненный цикл
Проект всегда имеет ограниченные временные рамки.
Для продукта заранее не продумывают дату завершения. Когда создается продукт, его владелец желает, чтобы он приносил прибыль как можно дольше. Но когда близится конец жизненного цикла продукта, заказчик может начать работу над созданием нового, более актуального продукта.
Структура
Проектные работы заранее декомпозируются на отдельные задачи. В процессе они могут меняться, но цель и ее способы достижения в общем остаются примерно теми же. В худшем случае, проект могут свернуть, если он перестанет быть актуальным.
Ход работы над продуктом может постоянно корректироваться, исходя из требований рынка и прочих внешних обстоятельств. Например, в одной соцсети появились истории. Владельцы другой соцсети могут поставить себе цель — добавить такую же функцию к себе, чтобы не утратить конкурентоспособность и не потерять прибыль.
Команда
Для каждого проекта собирается своя команда. После его завершения специалисты собираются в другие команды, чтобы работать над другими проектами. Все просто — задачи расписаны, исполнители найдены, начинаем действовать.
Для работы над продуктом собирают кросс-функциональные продуктовые команды. Хорошо, если состав команды долго не меняется — участники команды напитываются экспертизой в работе над продуктом и все дольше работают вместе. За счет чего эффективность их работы постепенно растет.
Читайте также: «Как в разы поднять конверсию сайтов и приложений»
Менеджер
Менеджер проекта и менеджер продукта имеют те же отличия.
Первый отслеживает, как успешно двигается проект в бюджетных и временных рамках, а также насколько успешно выполняются требования заказчика.
Менеджер продукта работает иначе — он следит за достижением KPI по ключевым метрикам продукта. Для этого он берет в работу наиболее подходящие для этого задачи и занимается краткосрочным планированием их выполнения. Например, продуктовая команда, которая работает по фреймворку Scrum, собирает задачи в спринты — мини-проекты, которые чаще всего длятся от 2 до 4 недель.
А теперь к самому таинственному — разберем разницу в проектном и продуктовом подходе.
Что такое «проектный» и «продуктовый» проекты
Прилагательное «продуктовый» относится к сфере разработки и управления продуктами в IT. Оно описывает подходы, методы и практики, которые используются для создания и развития цифровых продуктов, например, мобильные приложения, веб-сайты и программное обеспечение.
При внедрении «продуктового» подхода основной фокус всегда стоит на потребностях конечного потребителя. Бизнес старается предложить продукт, который будет подходить его ЦА по качеству, стоимости, возможностям, престижности и другим параметрам, которые задают ценность продукта. Ну и разумеется, бизнес зарабатывает на продаже продукта.
«Продуктовый» подход в бизнесе обычно используют для постоянного развития и улучшения товаров и услуг, повышения качества и уровня удовлетворенности покупателей.
«Проектный» подход означает, что планируется временная деятельность для создания определенного продукта или его модернизация с учетом ограничений бюджета и сроков. При «проектном» подходе всегда установлены конкретные цели, даты, риски, возможные ресурсы и качество результата.
Читайте также: «Как продавать товары через коммерческий блог»
На что ориентироваться, чтобы добиться эффективности
В IT каждый проект и продукт уникальны, поэтому для каждого из них будут свои конкретные KPI в зависимости от их особенностей. Если же говорить глобально, то можно указать несколько общих KPI, которые есть в каждом проекте и отдельно — в каждом продукте.
Для проекта главное — соблюсти договоренности. Это значит не выходить за рамки оговоренного срока и стоимости, а также выполнить установленные требования. Нужно установить цель проекта — например, разработать таск-менеджер, и двигаться к цели в рамках того бюджета, который был выделен.
Для продукта главная цель — выйти на окупаемость. Также нужно продумать, как в дальнейшем будет масштабироваться и развиваться продукт. Чтобы оцифровать это развитие, в работе над продуктом также используют специальные метрики.
Например, у всех продуктов есть своя ключевая метрика, которую еще называют «метрикой Полярной звезды» или North Star Metric. С ее помощью можно добиться максимального потенциала роста компании и, исходя из нее, разработать четкую стратегию для развития.
В качестве North Star Metric используют что, что отражает основную ценность продукта для пользователей. Например, для соцсетей это количество активных пользователей в месяц, а для сервиса типа Яндекс Музыки — время, которое пользователи тратят на прослушивание. Ведь понятно, что если у продукта растут пользователи или им пользуются часто, продукт ценен для своей аудитории.
О самых важных метриках, которые позволяют оценить прибыльность и ценность продукта мы рассказали в статье «10 самых важных метрик продукта». Читайте и мотайте на ус.
Но есть и метрики, которые позволяют оценить эффективность продуктовой команды. Например:
- Velocity (скорость). Это метрика, которую используют во фреймворке Scrum. С ней измеряют, сколько задач и пользовательских историй удалось завершить за спринт. Так проще оценить, насколько эффективно работает команда.
- Throughput (пропускная способность). Метрика из Канбан Метода, альтернатива Velocity. Зная пропускную способность, можно понять, сколько задач выполняет команда за определенный период времени: например, месяц. С ней также можно оценить скорость продуктовой команды.
- Lead Time (время выполнения). Эту метрику тоже используют в Канбан Методе. Здесь замеряется время от взятия задачи в работу до ее сдачи заказчику, с учетом всех простоев и пауз. Этот показатель помогает понять, как быстро команда выполняет запрос заказчика. С его помощью можно спрогнозировать крайние сроки выполнения задач, чтобы не бояться вылететь за дедлайны и в дальнейшем работать над оптимизацией времени выполнения.
Как организовать структуру работы
С проектом чаще всего выстраивают иерархическую структуру работ. Об этом мы рассказывали в другой статье. Если кратко — проект разбивают на этапы и «едят слона по кусочкам». Команда разделяет большие задачи на маленькие, для каждой устанавливают исполнителя и сроки, отслеживают продуктивность. Все движется по плану с четкими и жесткими дедлайнами под контролем руководства.
Для продукта такой подход не применяется, так как в работе над ним нужна гибкость. Это одно из ключевых конкурентных преимуществ, жизненно необходимых для продукта и бизнеса в целом.
Работа над продуктом начинается с малого: сначала генерируются разные идеи, пока среди них не находится та, что обладает наибольшей потенциальной ценностью для пользователя. После на ее основе создается минимально жизнеспособный продукт, в который вкладывают минимальное количество ресурсов, чтобы не потерять много при проверке идеи «в бою». Если у продукта появляются пользователи, его и дальше продолжают улучшать и масштабировать, чтобы больше зарабатывать и давать больше ценности пользователям.
Кстати: несмотря на то, что ход работы над продуктом может меняться на лету, для отдельных задач в работе над ним тоже устанавливаются крайние сроки. Тут тоже есть дедлайны и тут тоже нельзя их факапить.
Кто и за что будет отвечать
При работе над проектом команда несет ответственность за успешное выполнение проекта, а заказчик — за результат, ведь все требования исходят от него. Бывает, что руководитель проекта становится партнером для заказчика: они вместе решают, каким будет результат. Но окончательное решение всегда за тем, кто дает бюджет на работу и выставляет требования.
При работе над продуктом ответственность распределяется между командой и заказчиком. Команда со своей экспертизой отвечает за качественное развитие продукта. А заказчик задает нужный вектор, определяя ключевую метрику продукта и занимаясь упорядочиванием беклога — эдакого задачника, из которого в приоритет ставятся те работы, что должны выгоднее всего добавить ценность продукту здесь и сейчас
Читайте также: «Как региональному бизнесу генерировать лидов в VK Рекламе»
Главные мысли
- Продукт — результат труда для удовлетворения потребности аудитории и увеличения прибыли своего владельца. Продукт будет существовать, пока не закончится его жизненный цикл — появится что-то новое и более удобное.
- Проект — это активность, направленная на достижение цели, у которой есть начало и конец. У проектов ограничены сроки, бюджет, а еще у проекта есть установленные требования к его выполнению от заказчика.
- Слово «продуктовый» чаще всего используют некорректно, не зная определение слова «продукт», а также разницу между продуктом и проектом. В IT говорить о продуктовом подходе – это когда команда использует гибкий подход к разработке. То есть, работает не по строгому ТЗ, а меняет план действий, адаптируясь под внешние условия. Отсюда же возникает термин «продуктовая команда» — так называют команды, которые непрерывно работают над улучшением продукта.
В заключение: подписывайтесь на телеграм-канал Awake Journal 🔥 Так вы не пропустите анонсы наших новых статей про маркетинг, управление, дизайн, нейросети и прочее, прочее, прочее в мире диджитала и айти 🙌
на журнал
