Если вы работаете в Scrum команде, то несомненно знаете, что должен быть бэклог продукта и владелец продукта.
Но что же такое продукт?
Для некоторых команд это может быть довольно фундаментальный вопрос. В конце концов, организация не может определить нужных владельцев продуктов, команды и роли, не зная сначала, каковы ее продукты. И если для одного продукта существует один бэклог продукта, нам необходимо знать, что представляют собой наши продукты, прежде чем создавать бэклог для каждого из них.
В большинстве случаев, определение продуктов компании может показаться достаточной простой задачей. Например, производители часов могут предположить, что любой предмет, который они продают, может являться их продуктом. Однако, это может быть сильным упрощением реальных вещей, и некоторым компаниям очень сложно определить свои продукты.
Что является продуктом авиакомпании?
Взять к примеру авиакомпанию. Некоторые сотрудники компании утверждают, что авиакомпания осуществляет только одну вещь (или услугу): перемещает людей из одной точки в другую. Эти же сотрудники утверждают, что несмотря на то, что в компании может работать более 40 тыс. человек, у компании только один продукт.
Другие сотрудники утверждают, что у авиакомпании множество продуктов. Например, веб-сайт с информацией о пассажирах, с помощью которого можно делать бронирование, регистрацию на рейс или проверять статус рейса. Также существует система мониторинга и планирования технического обслуживания самолётов. И есть ещё одна система, позволяющая членам экипажа выбрать рейс, на котором они хотели бы поработать согласно своего стажа.
Всё ли перечисленное — продукты?
Определение продукта и примеры
Майк Кон определяет продукт как что-то (физическое или нет) созданное в процессе и предоставляющее ценность рынку.
Исходя из этого определения, стул будет продуктом, Microsoft Office тоже, услуги по Agile консультированию тоже продукт, картина тоже будет продуктом.
Таким образом, продуктом может быть что-то физическое (например, стул) или что-то цифровое (например, Microsoft Office, электронная книга, телевещание), также продуктом может быть услуга (например, Agile консультирование).
Продуктом может быть даже идея (например, запатентованный алгоритм).
Каждый из этих видов продуктов создаётся в процессе или, говоря проще, посредством одного или нескольких действий. Кто-то изготавливает и собирает стулья. Для Microsoft Office был создан дизайн, написан и протестирован код. Процесс, который создаёт продукт не обязательно формальный и определённый. Некоторые создатели могут даже и не знать о существовании процесса. Однако некоторая форма деятельности входит в создание каждого продукта.
Продукты могут быть определены рекурсивно
Продукт может существовать с другим продуктом. Например, у пишущей ручки есть стержень с чернилами. Ручка — продукт, однако и стержень с чернилами — продукт.
Такие подпродукты могут быть и у стула. Например, компания изготавливающая и продающая стулья может закупать ножки для стула у другой компании. В таком случае, ножки для стула тоже будут продуктом.
Продукты могут быть определены рекурсивно. Лесозаготовительная компания срубает деревья для изготовления древесины, древесина — это самостоятельный продукт. Затем, мебельная фабрика изготавливает из данного дерева ножки для стула, а другая компания использует данные ножки для изготовления стульев собственного дизайна. Таким образом продукты могут существовать внутри других продуктов.
Продукты приносят ценность рынку
Когда мы выделяем подпродукты внутри большого продукта, нам следует быть внимательными, так как каждый подпродукт должен приносить ценность рынку. Это не говорит о том, что что-то должно быть куплено, чтобы стать продуктом, однако, чтобы стать продуктом это что-то должно удовлетворять потребность и желание.
Это применимо и к ножкам для стула и к сменному стержню для ручки. При определении продуктов — и, следовательно, владельцев продуктов и бэклогов продуктов в Scrum — крайне важно чтобы они приносили ценность рынку.
Применим определение продукта к примеру с авиакомпанией
Итак, если продукты создаются в процессе и приносят ценность рынку, является ли программные компоненты продуктами?
Для того, чтобы ответить на этот вопрос возьмем авиакомпанию из предыдущего примера. Как понять, что понятие продукт — это что-то созданное в процессе и предоставляющее ценность рынку — поможет авиакомпании определиться со своими продуктами?
Прежде всего, легко заметить, что перемещение людей из одной точки в другую — это продукт. Эта деятельность приносит ценность рынку и люди охотно платят за возможность перелёта в другую точку.
А что насчет системы мониторинга и планирования технического обслуживания самолётов? И это тоже продукт.
Она создана в процессе и также приносит ценность рынку. Какому рынку?
Конечно же, можно сказать, что пассажиры получают ценность, что летают в технически исправных самолётах. Однако, на самом деле сотрудники авиакомпании получают ценность от данной системы, так как им не надо делать данную работу вручную, она для них компьютеризована.
Тоже самое может быть сказано и о сайте авиакомпании, который позволяет пассажирам бронировать авиабилеты. Для сайта существует рынок.
Подводя итог, можно сказать, что у авиакомпании один большой продукт — и множество подпродуктов. Всё, что можно представить как приносящее ценность рынку является продуктом.
Применение определения продукта к программным компонентам
Держа в голове вышесказанное, перейдём к программным компонентам. Если одна команда создаёт программу, которой пользуются другие команды, можем ли мы сказать, что программа — продукт?
Для примера рассмотрим команду, которая создаёт календарь. Календарь приносит ценность рынку — другим командам, которые будут его использовать. В таком случае, компонента, которая создаётся для нескольких команд, — продукт.
Однако, здесь стоит провести грань для компонентов, которые используются только одной командой. Конечно, технически может существовать рынок для одного клиента, например, картина продаётся одному человеку. Когда же речь идёт о гибкой разработке продукта, может оказаться опасным думать о чём то как о продукте, когда это используется только одним человеком или группой. Такое может привести к такому, что, например, могут начать думать, что код — это продукт, который предоставляется рынку тестировщиков. И это не просто путь назад к последовательной разработке, это также форма субоптимизации.
Избегание субоптимизирующих продуктов
Согласно профессору Таер Воткинсу из государственного университета экономики Сан Хосе (San Jose State University Economics) субоптимизация «относится к практике сосредоточения внимания на одном компоненте из всех и внесении изменений для улучшения только в один компонент... игнорируя эффект изменений на другие компоненты»
Хотя компании хотят определить все свои продукты, чтобы лучше управлять работой, они не хотят сужать свой фокус до уровня, когда они не смогут увидеть целое из-за фокусировки на отдельных частях. Такие компании стремятся определить каждый продукт настолько широко насколько это возможно.
Как было сказано ранее в примере с авиакомпанией, бывает, что продукт настолько велик, что обслуживает несколько рынков, и лучше выделить в нём несколько продуктов, которые обслуживают свои рынки.
Например, довольно легко представить Microsoft Office как один продукт, однако, он является набором нескольких продуктов и каждый продукт предоставляет различные функции и обслуживает разные (но частично совпадающие) рынки.
Word, Excel, PowerPoint и тд. — это отдельные продукты. У каждого из них свой владелец продукта и свой продуктовый бэклог.
С таким большим продуктом как Office, легко представить, что есть и продукты, которые представляют собой общую функциональность для Word, Excel и PowerPoint. Если говорить о проверке грамматики, то да, выделение компоненты как отдельного продукта имеет смысл. Функциональность по проверке грамматики ценна для рынка (другим команда нет необходимости создавать свою отдельную такую же компоненту с нуля).
Тем не менее, функции Excel {=СУММА; =СРЗНАЧ и прочее} нельзя выделять как продукт, так как эта функциональность уникальна для Excel, таким образом функциональность служит только одному клиенту. Слишком рискованно для данной функции выделять отдельного от Excel владельца продукта и отдельный продуктовый бэклог.
В дополнение к тому, что следует избегать продуктов для одного клиента, еще одним способом снижения неоптимального мышления при работе с несколькими продуктами является назначение главного владельца продукта (chief product owner).
Главный владелец продукта (chief product owner) — это стратегическая роль, он отвечает за формирование видения по всем подпродуктам. Например, для продукта Office главный владелец продукта (chief product owner) будет следить за тем, как каждый отдельный продукт влияет на весь пакет.
P.S.
Правильное определение продуктов компании позволяет избежать проблем со структурой команды, управлением бэклога продукта и людьми не на своих местах.
Текст адаптирован с оригинальной статьи:
https://www.mountaingoatsoftware.com/blog/what-is-a-product