Владелец продукта в Scrum — единственная связь между командой и бизнесом?

Владелец продукта — это сложная роль. Из-за того, что кандидатов на неё найти трудно, роль Product Owner'а часто видоизменяется в компаниях: получает необычные функции или исключает стандартные.

Сегодня мы поговорим о таком понимании Scrum, в котором владелец продукта — единственный, кто общается с заинтересованными сторонами (от клиентов до заказчиков) и транслирует это команде. В каких-то случаях это может совпадать с явлением «proxy product owner» (об этом мы рассказывали отдельно).

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

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

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

По традиции, обратимся к Scrum Guide:

Владелец Продукта несёт ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки.

На владельце продукта лежит управление бэклогом, он расставляет приоритеты, имеет право вносить и убирать PBI. Для этого Product Owner общается и с командой, и с заинтересованными сторонами. Но в Scrum Guide нигде не сказано, что только владелец продукта должен общаться со стейкхолдерами.

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

  • если задачи или отзывы проходят через дополнительное звено, снижается отклик. Для некоторых вещей (например, претензий) иногда лучше пройти через третьи руки, но для прямых задач важно персональное общение с разработчиком;
  • scrum-процесс бюрократизируется и теряет гибкость, команда рискует получить информацию по «сломанному телефону», тогда продукт не будет соответствовать потребностям;
  • новые идеи не хочется внедрять, потому что их обсуждение нужно повторить три-четыре раза.

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

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

Если что-то можно сделать напрямую, сделайте.

Есть несколько приёмов:

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

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