— Руководители проектов круче! 

— Нет, продакт оунеры круче! 

«Эксперт отличается от всезнайки тем, что не утверждает, что лучше, что хуже, а относится к стандартам, методологиям и фреймворкам, как к коробке с инструментами».

Мне, как руководителю проектного офиса, приходилось сталкиваться с тем, что продакт- и проджект-менеджеры:

  • путаются в базовых терминах, таких как «проект» и «продукт»,

  • не понимают, в чем отличия руководителя проектов и продакт оунера, 

  • не видят разницы в проектных и продуктовых практиках, жизненных циклах и т.п. 

Поэтому я решил разобрать всё по полочкам и собрать в одном месте всю необходимую информацию. Итак, начнём с простого: постараемся разобраться, что такое «проект», а что такое «продукт». Для этого обратимся к определениям, приведенных в фреймворках, стандартах и руководствах.

Проект — это…

PMBOK ver.7 - 2021
Временное предприятие, направленное на создание уникального продукта, услуги или результата. Временный характер проектов определяет существование начала и конца работы проекта или её фазы. Проекты могут существовать самостоятельно или в составе программы или портфеля.

Prince 2 - 2017
Временное предприятие, созданная с целью поставки одного или нескольких бизнес-продуктов в соответствии с согласованным бизнес кейсом.

P2M - 2017
Предприятие по созданию ценности, основана на миссии проекта, которая выполняется в заданные или согласованные сроки, с учетом ограничений, включая ресурсы и внешние обстоятельства.

IAPM – 2022
Предприятие, которое характеризуется общей уникальностью условий, таких как цели, время, бюджет, люди и другие ограничения.

IPMA ver,4 - 2015
Уникальное, временное, междисциплинарное и организационное стремление реализовать согласованные результаты в рамках заранее определенных требований и ограничений.

ГОСТ Р 54869-2011
Комплекс взаимосвязанных мероприятий, направленный на создание уникального продукта или услуги в условиях временных и ресурсных ограничений.

ISO/IEC 2382:2015 Information Technology vocabulary
Предприятие с заранее определенными целями, масштабом и длительностью. 

ISO/IEC/IEEE 26514:2022 Systems and software engineering 
Усилия с определенными начальными и конечными критериями, предпринятые для создания продукта и услуги в соответствии с определёнными ресурсами и требованиями.

DIN 69901:2009
Это одноразовая, не повторяющаяся деятельность или совокупность действий, в результате которых за определенное время достигаются четко поставленные цели.

По классике прошлись, ну а что в «Agile»?

Scrum guide 2020
Каждый Sprint можно считать коротким проектом.

Стоит отменить, что данное утверждение справедливо только в контексте спринта.

Kanban - 2021
Определение проекта отсутствует. Так как Руководство называется Kanban for Scrum Teams. Можно сделать вывод, что определение проекта должно совпадать с определением в Scrum guide. 

LeSS – 2022
В LeSS отсутствует определение проекта. Несмотря на то, что LeSS — это масштабированная версия однокомандного Scrum, но это не одно и тоже (определение проекта из Scrum не применимо).

LeSS is not Scrum

SAFe ver.5 -2022
Надеюсь, мою статью прочтут разработчики SAFe 5 и не будут писать откровенную чушь. Я бы очень хотел посмотреть на компанию в IT, которая для реализации проекта всегда выделяет команду. А проекты реализуются обязательно по waterfall — в общем рука-лицо.

Проект по мнению SAFe:

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

Получается, что перед началом проекта мы должны подумать: 

  • Что получим в результате проекта? 

  • Сколько проект займет времени? 

  • Сколько будет стоить? 

  • Кто его будет реализовывать — сами или аутсорс? 

Сначала думаем, считаем, оцениваем, только потом реализуем по ПЛАНУ с постоянной детализацией и уточнением. 

! Пожалуйста, не ходите в Википедию за определением проекта — там неверный перевод и устаревшая информация.

Продукт — это…

PMBOK ver.7 - 2021
Произведённый артефакт, который можно выразить количественно, и который может являться как конечным объектом, так и компонентом.

Prince2 - 2017
Входы или выходы, материальные или нематериальные, которые можно описать заранее, создать и протестировать. PRINCE2 предлагает два типа продуктов: управленческие (базовые планы, записи и отчеты) и специальные (создаются для целей управления проектом) продукты.

P2M - 2017
Чёткое определение отсутствует, но по контексту руководства P2M можно сделать вывод, что под продуктом подразумевается физический продукт (можно потрогать и пересчитать).
Это является спецификой японского стандарта – стандарт ориентирован для применения на промышленных предприятиях. 

IAPM – 2022
Чёткое определение отсутствует. Под процессом разработки продукта подразумеваются регулярные повторяющиеся действия.

IPMA ver.4 - 2015
Четкое определение отсутствует, по контексту можно сказать, что под продуктом подразумевается результат проекта.

ISO/IEC 2382:2015 Information Technology vocabulary - 2015
Четкое определение отсутствует, под продуктом подразумевается компьютерная программа, процедура или сопутствующие данные для пользователей.

ISO/IEC/IEEE 26514:2022 Systems and software engineering 
Аналогично c ISO/IEC 2382:2015.

Scrum guide 2020
Это средство поставки ценности. У него есть четкие границы, известные заинтересованные лица, четко определенные пользователи или клиенты. Продукт может быть услугой, физическим продуктом или чем-то более абстрактным.

Kanban - 2021
Определение совпадает с Scrum guide.

LeSS - 2022
Четкое определение продукта в LeSS отсутствует, но приводятся некоторые соображения

Чаще всего определение «продукта» в LeSS не совпадает с определением исходного «продукта», а это требует изменения мышления и, в конечном счете, приводит к изменениям в организации.

Выдержка из фреймворка

Определение «продукта» необходимо уточнять потому, что это влияет на:

  • масштаб бэклога продукта;

  • кто будет владельцем продукта;

  • масштаб продукта (в количестве команд) и соответственно на выбор фреймворка — LeSS или LeSS Huge.

Обычно мы различаем:

  • «идеальное» определение «продукта», которое позволяет нам ответить на расширяющие вопросы.

  • «практическое» определение «продукта», которое является подмножеством предыдущего определения и с которого мы можем начать и постепенно улучшаться.

Обычным способом формирования определения «продукта» является расширение его границ, с помощью ответов на расширяющие вопросы, а затем «приземление» данного определения до «практического».

SAFe ver.5 -2022
Удивительно, но факт — определение продукта отсутствует. Так как команды в этом фреймворке используют ScrumXP и Kanban, можно сделать вывод, что определение продукта совпадает с приведенным в Scrum guide.

Примеры продукта по мнению SAFe

Приметы продукта:

  • продукт может являться результатом проекта;

  • продукт может быть конечным объектом, компонентом или услугой;

  • у продукта четко определены границы, пользователи/клиенты;

  • под процессом разработки продукта подразумеваются регулярные повторяющиеся действия;

  • средство поставки ценности.

Сравнение понятий

Давайте взглянем, что получилось.

Проект 

Продукт

— Проект обязательно ограничен во времени. Сроки реализации определяются на этапе планирования. Тут стоит добавить, что сроки могут уточняться в процессе реализации проекта.

— Проект состоит из совокупности уникальных действий. Уникальные в данном контексте означает – не повторяющиеся. 

— В результате реализации проекта должен получиться продукт или услуга. 

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

— Это средство поставки ценности.

— Проект характеризуется общей уникальностью условий.

— У продукта четко определены границы, пользователи/клиенты.




— Под процессом разработки продукта подразумевается — регулярные повторяющиеся действия.


— Продукт может являться результатом проекта. 

— Продукт может быть конечным объектом, компонентом или услугой.


— Средство поставки ценности.

P.S. Все формулировки брал из последних редакций первоисточников, все пруфы доступны по соответствующим ссылкам.

А что с практической стороны?

У проекта и продукта есть кое-что общее:

— и проект, и продукт имеют ограничения;

— оба являются средствами поставки ценности пользователю/клиенту.

И есть одно значимое отличие: проект, в отличии от продукта, характеризуется уникальностью действий (не повторяющихся) и условий его реализации. 

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

Михаил Белов

методолог «Ростелеком-Солар», преподаватель.

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

Проект и продукт неразрывны, однако надо очень четко осознавать,  где и когда нам эффективнее использовать разные подходы. Проекты — это про создание продукта (MVP, новые мажорные релизы, смена платформы), когда есть четко выраженные ограничения ряда факторов. Не всегда проект привязан к конкретной дате, но он ограничен во времени с точки зрения задач компании. Продуктовые подходы — это хорошо и замечательно, но это чуть меньшая предсказуемость, пусть и в заданных рамках. Тут отсутствует явное временное ограничение, однако есть конкретные показатели, на основании которых временное ограничение может резко наступить. Все, что выше приведено как примеры продуктовых подходов, декларирует то, что существует в проектных подходах уже десятилетия, однако у многих в голове Project неразрывно связан с Waterfall, что очень сильно огорчает.

Лидия Муравьева

директор продукта в Ozon fresh

Продукт — это результат деятельности. Его можно создать, улучшить, видоизменить. Он может быть бессрочным и оцениваться определенными метриками успеха. Проект — деятельность, ограниченная во времени, имеющая бинарную метрику оценки: сделали или нет. Т.е. проект — это инструмент, а продукт — объект, к которому проекты могут быть применимы.

Вывод

В этой статье я постарался дать разносторонние и полные определения «проекта» и «продукта», провел линию между этими понятиями, чтобы больше их не смешивали или смешивали гораздо реже :) 

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

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

Мы завели соцсети с новостями и анонсами Tech-команды. Если хотите узнать, что под капотом высоконагруженного e-commerce, следите за нами там, где вам удобнее всего: TelegramVK.

Комментарии (14)


  1. PastorGL
    26.05.2022 17:33
    +6

    Слишком много букв.


    У продукта есть единственное характеристическое свойство, которое называется «отчуждаемость». Если что-то может быть передано с концами кому-то другому — это продукт. Если нет, то это не продукт. Собственно, конец дискуссии.


    1. allter
      27.05.2022 10:36
      +2

      Можно себе представить платформенный продукт, который сложно или нельзя отчуждить - например из-за используемых NDA компонентов. Но его при этом можно продать - т.е. дать доку на сервис, физические изделия и т.д

      Т.е. разделение простое:

      Продукт - это набор фич, ценных для пользователя

      Проект - набор согласованных бизнес-процессов (направленный на добавление или убирание фич, либо не связанный с ними)


      1. PastorGL
        27.05.2022 16:04

        Если платформа неотчуждаема, то это сервис. А если экземпляр платформы можно поднять независимо, то она может быть продуктом.


        Для примера возьмём микрософтовскую экосистему office.com+hotmail+live services — оторвать от azure её нельзя, то есть, это сервис. Но sharepoint, на основе которого он построен, это уже продукт, который можно держать и на своём железе. И в данном случае номерной релиз sharepoint — это некоторый срез облачных rolling релизов со стабилизирующими патчами.


        Что важно в контексте темы, поддержкой этих двух веток одной и той же платформы занимаются разные команды, — сервисная и продуктовая, — жизненный цикл-то отличается.


        1. allter
          28.05.2022 15:14

          В вашем примере office.com и hotmail - это один сервис? Нет. Это два разных продукта (хотя, конечно, какая-то взаимосвязанность там есть). Точнее, это - Product Service System (PSS), как это называется по научному, или PaaS, как не совсем правильно, но всё же в целом верно (т.к. P там - это скорее Platform, что несколько большее, чем продукт).

          Или например, часто бывает так, что сервис есть (обычно бесплатный). Но нет ни доки на него, ни SLA. И когда, например, добавить ещё одного пользователя в нём - жуткий квест. Продуктом такой сервис сложно назвать. Скорее, это какой-то "витамин" для тех, кто им по какой-то причине вынужден пользоваться.


          1. PastorGL
            28.05.2022 18:07

            Вы в какие-то частности закапываетесь. Понимаю, в деревьях больше интересных подробностей, чем смотреть на лес целиком.


            Повторю ещё раз, без примеров и аналогий: продукт отчуждаем. Жизненный цикл продукта подразумевает пункт «отгрузка», когда он передаётся кому-то отличному от производителя.


            А копаться в частностях можно до бесконечности.


            1. allter
              28.05.2022 18:33

              И отгрузка, и приёмка есть и у сервисных продуктов.

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

              Вот gitlab (CE/EE) - это сервис или продукт? С одной стороны это конкретный код, который доступен в рамках сервиса gitlab.com (совместно с другим кодом, который неотчуждаем). С другой стороны, это набор фич, который вы можете применять на своём собственном железе.

              Согласен про непродуктивность споров о терминологии, но в эти частности закопались вы, утверждая что среди неотчуждаемых сервисов не может быть продуктов. :) По такой логике даже коробочная винда - это не продукт. Ведь при её "покупке" вам не дают ИАП или хотя бы лицензии делать с ней всё, что лично вы хотите - а дают лишь коробочку, CD и немного макулатуры. А для OEM инсталляций винды - и того меньше (и не давали бы вовсе, если бы M$ не приучила пользователей к красивым наклейкам).


  1. DikSoft
    26.05.2022 18:26
    +3

    Продукт — это миф, созданный ушлыми продаванами. Цель: сразу продать Заказчику и Проект без обязательств по срокам завершения, и поддержку без чётких критериев по срокам выполнения и по функциональному содержанию.

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

    Тех, кто на это повёлся, уже много. Мало кто после «развода» будет признавать свою глупость. Поэтому двусмысленно звучащее слово Продукт потихоньку используется всё чаще.

    Вокруг продуктового подхода сформировался целый набор ритуалов, единственная цель которых максимально замаскировать всю его шарлатанскую сущность. И более того, есть даже целый класс «специалистов по ритуалам»…

    Если вы что-то поддерживаете и дорабатываете, то не надо делать вид, что вы занимаетесь Продуктом. Будьте честнее. Есть нормальное название для таких процессов.

    Результат работы может быть реально полезен Заказчику, что не отменяет того, что за Разработку и Эксплуатацию (поддержку) он мог заплатить меньше и менее пафосно.


    1. WizardryIB
      27.05.2022 11:04
      +1

      Отлично сформулировано! Заберу...


  1. uzverkms
    26.05.2022 22:33
    +2

    Что же это за проджекты, которые путают проект и продукт? Наверное какие-то очень неопытные, которым ещё мало попили крови, бросая на разработку продуктов вместо продакт-менеджеров? А я такое в живую видел :)

    Вместо тысячи слов можно было бы обойтись несколькими вариантами визуализации (на вкус).

    Продакт-менеджер делает (не обязательно с помощью проектов) правильный продукт. А проджект-менеджер делает продукт (не всегда правильный :) ) правильным путём. В одной картинке пара абзацев: проект как средство создания продукта. Проект как средство реализации этапа (этопов) жизненного цикла продукта.

    Вот другой вариант визуализации той же мысли (из PMBoK 7)

    И совсем не соглашусь с вынесением в сравнение этих сущностей следующего тезиса:

    — Проект состоит из совокупности уникальных, т.е. неповторяющихся действий.

    Ничего подобного. Проект можно делать с использованием стандартных процессов/действия организации. Например, путём их уникального (или кроссфункционального) сочетания достигая уникального результата. Или задействуя их на отдельных этапах проектов. Кроме того, есть куча проектов с инкрементной или итеративной моделью поставки ценности - там некоторые действия повторяются регулярно. Даже в "традиционных" больших проектах со Stage-Gate подходом все равно происходят схожие активности по планированию-ревью-принятию решений.


  1. WizardryIB
    27.05.2022 10:50
    +2

    Мои пять копеек...

    "В результате реализации проекта должен получиться продукт или услуга." - Может получиться рабочий процесс. По результатам предпроекта могут получить критерии, состав и количество ресурсов, а также сроки окончания для последующего проекта...


  1. normal
    27.05.2022 20:58

    короч, режиссёр фильма -- это продакт, а продюсер -- проджект?))


    1. uzverkms
      27.05.2022 21:58

      продюсер - спонсор/куратор/продакт проекта

      режиссер - проджект


      1. normal
        28.05.2022 01:54

        если покрутить эту аналогию, про фильмы, я так рассуждаю -

        режисеру важнее всего результат (продукт), он хочет вечный запредельный шедевр создать, чего-бы это не стоило.

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

        и конечно граница размытая, и вполне один человек может это все совместить (аки Спилберг или Кемерон).


        1. uzverkms
          28.05.2022 02:42

          Инди-кино для того и придумано, чтобы режиссёр воплощал свою идею не смотря на всяких умников продюсеров.

          Но в обычном массовом коммерческом кино всё нередко происходит иначе. Из свежих примеров достаточно вспомнить новость про уволившегося режиссера следующего фильма Форсаж. Уверен, что фильм тем не менее будет снят и выпущен.

          Если же глянуть статью про кинопродюсеров в вики, то там есть пример продюсера Дэвида Селзника: "хрестоматийный пример — деятельность Д. Селзника на проекте «Унесённые ветром», где в процессе создания одного фильма сменилось четыре режиссёра".