Что такое продукт?


Продукт – это что-то (материальное либо нет), созданное через процесс и создающее ценность на рынке.

Если вы работаете в Scrum-команде, то бесспорно знаете, что у вас должен быть бэклог продукта и Владенец продукта. Но что на самом деле представляет из себя продукт?

Для некоторых команд этот вопрос весьма неоднозначный. Без понимания, что является продуктом, организация не может должным образом сформировать команды и определить Владельцев продуктов. И если для каждого продукта свой бэклог, мы просто обязаны идентифицировать продукты до того, как приступим к разработке.

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

Что называют “Продуктом” авиакомпании?

Несколько лет назад я работал с авиаперевозчиком, когда возник вопрос определения продукта. Некоторые сотрудники компании утверждали, что авиакомпания делает только одно: перемещает людей из одного места в другое. Следовательно, они утверждали, что, несмотря на то, что в компании работает более 40 000 сотрудников, продукт должен быть только один.

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

Были ли эти системы Продуктами?

Определение продукта и примеры

Я определяю продукт как что-то (материальное либо нет), созданное через процесс и создающее ценность на рынке.

Из этого следует, что стул – это продукт. Microsoft Office – продукт. Консультационные услуги Agile также продукт. И картина, нарисованная художником тоже продукт. Продукт может быть чем-то физическим (стул), цифровым (Microsoft Office, электронная книга или стриминговое видео) или услугой (консультации по внедрению Agile).

Даже простая идея может быть продуктом (запатентованный алгоритм или секрет получения большего количества свайпов вправо в Tinder).

Каждый из них создается процессом, одним или несколькими действиями. Кто-то фрезерует и собирает стул. Microsoft Office был разработан кодом и тестированием. Процесс создания продукта не обязательно должен быть формальным или определенным. Создатели иногда даже не подозревают об этом процессе. Но какая-либо форма деятельности обязательна.

Продукт можно определить рекурсивно

Продукт может существовать внутри другого продукта. Возьмём к примеру ручку со сменным стержнем. Ручка – это продукт и картриджи внутри ручки тоже.

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

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

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

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

Продукт на примере авиакомпании

Итак, если продукты создаются с помощью определенного процесса и создают ценность, являются ли программные компоненты продуктами?

Чтобы ответить на этот вопрос, рассмотрим предыдущий пример с авиакомпанией. Каким образом знание того, что продукт создается через процесс и несёт ценность, может помочь авиакомпании в идентификации своих продуктов?

Окей, транспортировка людей из пункта А в пункт B – это продукт. Эта деятельность представляет ценность для рынка людей, которые с радостью платят за возможность прилететь в определенное место.

А как насчет системы мониторинга и планирования технического обслуживания самолетов? Я утверждаю, что это тоже продукт.

Он создается процессом, а также создаёт ценность на рынке. Но на каком рынке?

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

То же самое можно сказать и о веб-сайте авиакомпании, который позволяет пассажирам бронировать билеты на самолет. И для этого есть свой рынок.

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

Продукт на примере программных компонентов

Руководствуясь вышесказанным, рассмотрим программный компонент. Если одна команда разрабатывает программное обеспечение, используемое другими командами, можно ли считать это продуктом? Возьмём к примеру команду, которая создаёт виджет календаря. Да, календарь несёт ценность для других команд, им пользуются. Тогда я назову компонент, созданный для нескольких команд, продуктом.

Однако, здесь я бы чётко обозначил границу: если виджет календаря (или любой другой компонент) создаётся для одной команды, то он продуктом не является. Конечно, технически может существовать рынок с одним покупателем (или пользователем). Например картина, которая продаётся только одному человеку.

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

Избегайте субоптимизации продуктов

По словам профессора экономики Университета Сан-Хосе Тайера Уоткинса, субоптимизация «относится к практике сосредоточения внимания только на одном компоненте целого, и улучшение только этого компонента… игнорируя влияние на другие».

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

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

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

Поэтому для меня Word, Excel, PowerPoint и т. д. самостоятельные продукты, у каждого из которых свой product owner и бэклог. Например, проверка орфографии Word – продукт, создающий ценность. Другим командам уже не нужно писать свою собственную проверку орфографии с нуля.

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

Ещё один способ сократить нерациональное мышление при работе с несколькими продуктами – назначить главного владельца продукта.

Это стратегическая роль, ответственная за видение всех подпродуктов. Например, в продукте Office главный владелец продукта будет следить за тем, как каждый отдельный продукт влияет на Office в целом.

Основано на статье Майка Кона What is the Product?