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

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

Попробую обобщить накопленный мной опыт…

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

Идея 1: Заставьте бизнес определиться с Владельцем Продукта

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

Бывает, что команда внешняя по отношению к компании или просто IT-отдел не пользуется особой популярностью. Тогда требовать и ставить ультиматумы не получиться. Однажды, мои коллеги из другой команды рассказывали, что они просто сделали спринт на основе того, что им дали “представители бизнеса”, а во время демонстрации, видя их неудовольствие, они предложили “выход” путем определения одного представителя бизнеса, который скоординирует приоритеты, детали и т.п. Идея была принята на ура.
Так что ищите возможности “продать” необходимость единого Владельца Продукта 😉

Идея 2: Используйте Посредника

Как известно, многие конфликты интересов можно разрешить с использованием Посредников. В нашем случае мы говорим о необходимости единого Владельца Продукта. Таким образом Посредник может исполнять роль доверенного лица бизнеса и выступать единым контактным лицом по отношению к команде. Когда-то я даже видел термин Proxy Product Owner, т.е. Уполномоченный Владелец Продукта (ниже УВП). Такой человек может быть не самым главным экспертом в бизнесе и в тоже время обладать необходимыми знаниями полномочиями для принятия решения о приоритетах, планах на релиз, итерацию и выполнять остальные функции Владельца Продукта при активной помощи как команды, так и бизнеса.

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

• Слишком малое знание бизнеса – в этом случае УВП будет ходить к представителям бизнеса для принятия каждого сколь-нибудь важного решения. А учитывая занятость этих людей (они же не смогли сами выполнять роль ВП) – эта процедура будет долгой и задержка ответа может быть губительной для команды
• Слишком большое знание технологий – возможно роль УВП будет выполнять представитель IT департамента на стороне заказчика или другой изначально технический человек. В этом случае он скорее будет заинтересован в создании “архитектуры приложения”, чем в реальных нуждах пользователей. Возможно, даже приоритеты он будет назначать исходя из их технической важности/сложности вместо их значимости для бизнеса и пользователей.
• Слишком малая заинтересованность – бывает, что исполнять роль Посредника назначают какого-то промежуточного менеджера, который лично не заинтересован в бизнес аспектах продукта и в то же время не очень вовлечен в технические аспекты. Получается, что он просто “занимает эту должность”, потому что ему сказали большие дяди.
  Любой ВП (УВП) должен быть вовлечен в процесс разработки и мотивирован отдавать свои силы и время для достижения успеха этого проекта (продукта). Владелец Продукта – это тоже активный участник Scrum команды. Если он не считает себя таким, тогда сразу проявятся проблемы.

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

Идея 3: Сменный Владелец Продукта

Я думаю, эту идею можно использовать как компромисс между использованием представителя бизнеса и Посредником.

Если у вас есть несколько продуктов или подсистем, то наверняка есть разные менеджеры продукта или кто-то, кто больше всего заинтересован в одной из подсистем. Если релиз (3-5 итераций) сосредоточить на одном из продуктов, то ответственный за него сможет выполнять роль Владельца Продукта в течении всех итерации данного релиза. А после этого передаст полномочия другому Владельцу Продукта – другому менеджеру продукта.

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

Из явных минусов могу выделить следующее:

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

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

P.S.

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