Владелец продукта — это сложная роль. Из-за того, что кандидатов на неё найти трудно, роль Product Owner'а часто видоизменяется в компаниях: получает необычные функции или исключает стандартные.
Сегодня мы поговорим о таком понимании Scrum, в котором владелец продукта — единственный, кто общается с заинтересованными сторонами (от клиентов до заказчиков) и транслирует это команде. В каких-то случаях это может совпадать с явлением «proxy product owner» (об этом мы рассказывали отдельно).
Итак, существуют scrum-команды, где вся связь с внешним миром держится на владельце продукта.
Например, команда придумала новую функцию. Она рассказывает это владельцу продукта, а тот должен связаться со стейкхолдерами. Второй вариант — в истории что-то непонятно, требуется мнение одной группы стейкхолдеров. Команда снова просит владельца продукта связаться с заинтересованными сторонами. Ещё звоночек — все задачи поставляет только владелец продукта, команда не участвует в их корректировке, придумывании новых функций и прочем. Бэклог проекта воспринимается не как собственность команды, а как список от владельца продукта.
Это частая ситуация, и хотя она не так губительна для разработки, с ней всё равно нужно бороться.
По традиции, обратимся к Scrum Guide:
Владелец Продукта несёт ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки.
На владельце продукта лежит управление бэклогом, он расставляет приоритеты, имеет право вносить и убирать PBI. Для этого Product Owner общается и с командой, и с заинтересованными сторонами. Но в Scrum Guide нигде не сказано, что только владелец продукта должен общаться со стейкхолдерами.
Такое понимание роли PO вредит разработке, потому что создаёт бутылочное горлышко: все вопросы должны проходить через владельца продукта, это нагружает его, задерживает процесс и лишает команду самостоятельности. Такой подход вредит и стейкхолдерам:
- если задачи или отзывы проходят через дополнительное звено, снижается отклик. Для некоторых вещей (например, претензий) иногда лучше пройти через третьи руки, но для прямых задач важно персональное общение с разработчиком;
- scrum-процесс бюрократизируется и теряет гибкость, команда рискует получить информацию по «сломанному телефону», тогда продукт не будет соответствовать потребностям;
- новые идеи не хочется внедрять, потому что их обсуждение нужно повторить три-четыре раза.
Scrum-команды должны работать в тесном контакте с клиентами и пользователями. Это делает возможным быстро и верно реализовать продукт. Роль PO — расставить приоритеты так, чтобы команда получала от стейкхолдеров ценную для цели спринта информацию, но при этом не перегружала себя случайными задачами.
Наладить взаимодействие между стейкхолдерами и командой без участие PO можно, но степень участия зависит от организации и задач. Наиболее важно это в компаниях, которые разрабатывают прикладные приложения, где функционал опирается на требования пользователей.
Если что-то можно сделать напрямую, сделайте.
Есть несколько приёмов:
- не игнорировать то, что на ревью спринта должны присутствовать стейкхолдеры, глубже работать над этим событием, активно использовать приёмы фасилитации,
- на планирование или груминг приглашать экспертов, которые пользуются продуктом, чтобы помочь определиться с ценностью новой фичи,
- организовать общий чат со scrum-командой и группой стейкхолдеров, где можно быстро проверить предположение или задать вопрос,
- привлекать команду к custdev-исследованиям, анализировать пользователей, совместно придумывать персоны (и подписать у каждого персонажа, с кем можно связать по задачам, связанным с ним),
- организовывать отдельные встречи со стейкхолдерами и командой.
Все меры направлены на то, чтобы scrum-команды были более гибкими, а PO не был загружен мелкими задачами, работая только как передатчик. Владелец продукта вовлекает стейкхолдеров в разговор, а команда не боится связываться с ними напрямую.
