Владелец продукта (Product owner) - это связующе звено между всему участниками проекта как со стороны заказчика так и исполнителя.
Зона ответственности Product owner
В классическом определении владелец продукта отвечает за максимизацию ценности продукта, получаемого в результате работы scrum-команды. В течении проекта усилия команды и затраты, которые несет команда, трансформируются в некую ценность для заказчика. Таким образом, усилия владельца продукта направлены на то, чтобы принести максимальную пользу за каждый спринт работы команды. Поскольку для заказчика важна ценность и платит он именно за это, а команда генерирует затраты, то финансовый результат проекта хорошо характеризует эффективность работы владельца продукта.
Основные задачи Product owner
1. Участвовать в pre-sale. Важно подключиться к проекту на этапе pre-sale, поскольку здесь обозначаются основные архитектурные решения, фиксируются ограничения и закладывается бюджет сверху. Здесь владелец продукта, обладая экспертными знаниями предметной области, должен предложить максимально эффективные решения на запросы заказчика. Это касается выбора конфигураций, описания интеграций с другими системами, технологии запуска системы и других вопросов. Хорошей практикой является фиксация основных аспектов в форме устава проекта.
2. Управлять ожиданиями. На старте и на протяжении всего проекта очень важно вовремя формировать нужные ожидания у заказчика. Например, если какой-то функционал оговаривался и включен в рамки проекта, но по каким-то причинам его доставка задерживается или вовсе невозможна, то заказчик должен быть проинформирован как можно скорее. Для управления ожиданиями стейкхолдеров, на этапе подготовки к проекту необходимо составить реестр ключевых лиц, в котором зафиксировать их влияние и ожидаемые результаты от проекта.
3. Управлять приоритетами. Владелец продукта понимает, какие пользовательские истории требуется доставить раньше, какие могут подождать или вообще оставить на "после запуска". Задача владельца продукта в том, чтобы управлять этими приоритетами, договариваться об этом со стейкходлерами и формировать единое видение развития продукта.
4. Выдерживать рамки проекта. Очень часто в ходе проекта возникают новые пользовательские истории и стейкхолдеры. Задача владельца продукта здесь - соблюдать баланс между возможностями команды и объёмом работы для достижения цели проекта. Например, если в ходе проекта возникают истории, которые добавили в ограничения и делать не планировали, но выяснилось, что они блокируют запуск, то такие истории надо брать в работу. При этом нужно договориться о том, чтобы какие-то другие истории были вынесены на "после запуска". Все новые пожелания, не блокирующие запуск, должны быть отложены на потом. Все изменения обязательно должны находить отражение в дорожной карте проекта, которая составляется владельцем продукта в рамках нулевого принта и актуализируется по ходу проекта.
Чек-лист подготовки Product owner к проекту представлен ниже.
Важно отметить, что владелец продукта (Product owner) и руководитель проекта (Project Manager) не тождественные понятия. Ключевое отличие заключается в подходе к определению успешность проекта. С позиции руководителя проекта успешным можно считать проект, выполненный в полном объеме, за установленные сроки и бюджет, но это не всегда будет обозначать, что проект имеет ценность для бизнеса. Цель же владельца продукта - выстроить поток создания ценности внедряемого продукта через призму ценности бизнеса для конечного потребителя, с учетом бюджета и сроков проекта.
Скачать чек-лист можно по ссылке.
Поддержите нас лайками, если материал статьи оказался полезным для вас. Все новости и материалы в нашем телеграмм-канале https://t.me/bit_erp.