Каково происхождение термина «Владелец продукта» в Scrum?

Я всегда интерпретировал это как то, что Владелец Продукта (PO)... владеет продуктом . Он/она является заместителем представителя конечных потребителей, которые в будущем будут буквально владеть продуктом. Таким образом, его/ее обязанности чем-то похожи на обязанности клиента на месте в eXtreme Programming.

И хотя клиент всегда прав™, клиент не является вашим начальником. Ваш босс - это ваш босс. Гипотетически один человек может выполнять обе роли PO и менеджера, но лично я бы этого не советовал - это разные роли с разными обязанностями и целями. Так же, как клиент и босс.

Согласно Scrum Guide , PO отвечает за:

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

Там нет ничего даже о лидерстве-слуге, не говоря уже о «нормальном» лидерстве. Скрам-мастер — это лидер-слуга Скрам-команды. PO — это просто еще один член с другими обязанностями.

Их обязанность состоит в том, чтобы притворяться, будто они владеют продуктом.

TL;DR

Вам придется спросить Кена Швабера или Джеффа Сазерленда, откуда они придумали этот термин. Источник термина, по-видимому, не задокументирован публично, но, вероятно, он был введен где- то между 1995-2001 годами.

Неканоническая этимология

В 90-е годы многие люди изучали agile-практики и идеи. Scrum и XP — две фреймворка, разработанные в этот период, причем формальное определение XP , по- видимому, предшествовало определению Scrum на несколько лет.

Роль владельца продукта в Scrum тесно связана с ролью локального клиента в экстремальном программировании. Можно утверждать, что XP использует термины, которые относятся к членам команды разработчиков, в то время как Scrum использует термины, которые пытаются привлечь больше заинтересованных сторон. (Этот тип бизнес-ориентированной терминологии еще более очевиден в таких фреймворках, как SAFe.) Далее можно было бы утверждать, что локальный клиент — это роль, которая определяется в основном с внутренней точки зрения команды, тогда как Владелец продукта — это роль с делегированными полномочиями. ответственности с организационной точки зрения. Рассмотрим следующее исследование «собственности», чтобы понять, почему это может быть так.

В Scrum понятие «право собственности» проистекает из обязательства роли нести исключительную ответственность за максимизацию ценности разрабатываемого продукта. Руководство по Scrum , в частности, говорит:

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

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

Эта цепочка рассуждений обеспечивает прагматическое объяснение введения термина и дает некоторое объяснение его полезности по сравнению с другими родственными терминами. Однако только авторы фреймворка могут канонически объяснить, как был выбран этот термин для Scrum.

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

Вот мое, по общему признанию, неофициальное использование термина:

«Владелец продукта» представляет Всемогущего Клиента и часто является самым непосредственным связующим звеном команды с ними, обычно отчитываясь непосредственно перед ними. Эта роль очень конкретно сосредоточена на том , что продукт будет делать и для кого он в конечном итоге будет работать, а также на обеспечении того, чтобы все это действительно соответствовало бизнес-целям, для которых он был заказан, с точки зрения бизнес-подразделений, которые его заказали, и это будет правильно функционировать и интегрироваться в преобладающую деловую (!) среду. Таким образом, на собраниях команды владелец продукта является доверенным лицом для этих заинтересованных сторон.

Я считаю родственную роль « менеджера по продукту» несколько иной, потому что эта роль связана с тем, «как» выполняется работа. Итак, если продолжить эту аналогию до конца, роль «менеджера по продукту» состоит в том, чтобы сделать «владельцев продукта» счастливыми. Концептуально «менеджеры = практические занятия, владельцы = невмешательство» с точки зрения фактической повседневной деятельности по разработке.

И для меня очень выгодно иметь две роли, четко разделенные и четко формализованные: владелец смотрит на реальных владельцев... фактический бизнес-контекст, в котором будет работать готовый продукт... в то время как менеджер имеет свою глаза устремлены на процесс, который используется для его создания и изменения. Назовите это «управлением Янусом» — римский двуликий бог.

Я думаю, что эта распространенная ошибка происходит от слова «владелец». «Собственный» имеет два разных значения: 1. иметь, обладать; и 2. признать или признаться в этом. Владелец продукта — это не тот, кто владеет продуктом; скорее, это тот, кто признает или отрицает спецификации продукта в невыполненной работе.

Происхождение ... Некоторые методы были разработаны в компаниях-разработчиках программного обеспечения, а не для ИТ-групп (таких компаний, как Easel или Borland). Таким образом, Turbo Pascal был «продуктом», который они продавали — это не был бренд, Borland был брендом — таким образом, если вы возглавляете группу Turbo Pascal, вы «владеете» продуктом.

В маркетинге не было концепции владельца продукта, они были сосредоточены вокруг бренд-менеджера.

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

Предлагаю рассмотреть главные роли в agile-команде. Крайне важно понимать роль каждого целостно, чтобы все это имело смысл. Если команда зациклилась на конкретном термине «владелец», это может быть потому, что они ищут власти или контроля и не смотрят на все, что связано. Выделите все роли и обязанности и дайте им понять, где они хотят быть, основываясь на своих ценностях и навыках.

• Менеджер по продукту
• Владелец продукта
• Скрам-мастер
• Скрам-команда

Хотя каждая ситуация индивидуальна, ясное представление о ролях, мотивах и обязанностях позволит вам адаптировать команду к своему размеру и целям.

В Scaled Agile Framework есть несколько хороших материалов для выявления различий. https://www.scaledagileframework.com/product-owner/