Гибкая разработка: кто такой владелец продукта?

Введение: что делает владелец продукта?

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

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

С этого момента я буду использовать аббревиатуру PO для Product Owner.

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

Отказ от ответственности: описанная здесь роль Владельца Продукта не является прямой реализацией Владельца Продукта Scrum. Советы предназначены, но не исключительно для работ по оказанию услуг. У меня нет сертификата Scrum.

Начнем с некоторых определений. Большинство публикаций согласны со следующим утверждением о роли.

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

\~ scrum.org

Многогранный характер роли также широко признан.

Но для этого agile-владелец продукта берет на себя несколько ролей, включая бизнес-стратега, дизайнера продукта, рыночного аналитика, специалиста по связям с клиентами и менеджера проекта. Короче говоря, agile-владельцы продукта — неотъемлемая часть любой скрам-команды.

\~lucidchart

Разнообразие обязанностей обычно приводит к потере новых ЗП. Борьба за баланс интересов клиентов, менеджмента и команд разработчиков реальна. Они должны поставлять продукты в обычно сжатые сроки. При общении со всеми они должны оставаться настойчивыми, имея при этом ограниченные полномочия по принятию решений.

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

Кто является владельцем продукта?

Я провел несколько бесед с другими владельцами продукта и спросил: «Кто такой PO? Что она делает?». Было слишком много ответов, чтобы пытаться сделать из них связный блок текста.

• ответственный человек

• Контактное лицо

• руководитель группы

• бизнес-аналитик

• психолог

• тренер

• член команды разработчиков

• прокси

• разработчик / ученый

• с учетом перспективы пользователя

• Преобразовывает пожелания в действия

• максимизирует ценность

• сбор требований

• мученик

• не тестировщик - но определяет критерии тестирования

Это много.

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

С точки зрения компании, Владелец Продукта — это тот, кто ведет исполнение контракта. Она отвечает за отставание и следит за определением выполненного. В компании, которую я использую в качестве примера для статьи, в небольших проектах не менее 20% времени человека должно быть потрачено на роль, если он также поддерживает большую техническую нагрузку. В идеале один человек должен «владеть» одним продуктом.

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

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

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

Другие обязанности владельца продукта включают в себя:

• Управление рисками

• Преобразование историй в задачи

• Нести ответственность, когда она становится размытой

• Поддерживать менее X элементов невыполненной работы (100 было указано как хорошее число)

Владельцы продукта в жизненном цикле проекта

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

• Предпродажа

• Продажи

• Подбор команды

• Разработка проекта

• Служба поддержки

• Продажи

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

На каждом из этих этапов следует помнить истину, неоднократно повторявшуюся в интервью, которое я проводил:

** BACKLOG - это инструмент PO**

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

Стартовое совещание

Вот основные советы:

• отправить повестку перед встречей

• укажите цель встречи

• представить команду

• выйти за рамки

• организационные элементы: совещания по статусу, каналы связи, обмен результатами работы, управление задачами, доступ к ресурсам

• оставить место для своих идей для встречи

• предложить несколько дат

Планирование

Цель состоит в том, чтобы указать приращение ценности, которое будет разработано в следующем спринте.

• Напоминайте команде о ближайших и долгосрочных целях и приоритетах

• Разделите задачи на те, которые подходят для одного спринта

• Не вдаваться в подробности

• Все участники вовлечены

• TIMESLOT - соблюдайте его, производительность резко снижается через один час

Совещания по статусу

Под статусной встречей я подразумеваю встречу с клиентом.

• начните с легкой темы

• форма - не так важно

• нет необходимости каждый раз готовить идеальные слайды

• придерживаться фиксированной повестки дня

• отправить резюме

• вся команда не нужна

Советы по проведению общих встреч

• будь готов

• быть первым

• придерживаться определенных временных интервалов

• запрашивать любые дополнительные временные ограничения

• небольшая светская беседа — это нормально

• включать логотип клиента в материалы

• не просите неподготовленных людей о вещах, к которым, по вашему мнению, они не готовы, особенно при большой аудитории

• будь собой/человеком

Культурные различия

Имейте это в виду. В международной среде люди обычно обучены межкультурному общению или, по крайней мере, привыкли к нему, поэтому они будут подстраивать свое социальное поведение под вас. Но это должно работать в обе стороны. Если вы начинаете проект с клиентом из той культуры или региона, о которой вы мало знаете, почитайте немного.

Заключительные мысли: кто такой владелец продукта?

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

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

Фото на обложке от fauxels с Pexels