Владелец Продукта

Роль владельца продукта в LeSS концептуально совпадает с ролью в Scrum с одной командой. Однако его фокус смещается в сторону сохранения видения и обеспечения максимальной отдачи от инвестиций в Продукт (ROI).

Масштабированный Владелец Продукта

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

При традиционной крупномасштабной продуктовой разработке есть группа (часто это продуктовые менеджеры), которая фокусируется наружу компании, и группа (обычно разработчики), которая фокусируется вовнутрь — и они никогда не смогут работать в одном направлении. В LeSS у одного владельца продукта есть достаточно времени, чтобы сосредоточиться на клиентах и их приоритетах, а также у него есть возможность потратить некоторое время, работая с командами разработчиков. Он действует как интегратор, объединяя команды и клиентов/пользователей вместе, чтобы команды стали более клиентоориентированными.

В отличии от других масштабируемых Scrum подходов, в LeSS возможно эффективно масштабировать роль Владельца Продукта в виде одного человека, потому что в этом случае мы имеем меньше ролей, должностей и меньше сложности.

Приоритизация и актуализация

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

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

Зачем делать акцент на прямом взаимодействии между командами и клиентами/пользователями? Причины следующие: (1) предотвращение потери информации, которая возникает при наличии нескольких передаточных звеньев, (2) содействие совместному созданию решений реальных проблем клиентов и (3) повышение мотивации и эмпатии за счет прямого взаимодействия разработчиков и клиентов.

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

Поиск Владельца Продукта с учетом типа вашей разработки

Шаг 1: Определите тип вашей разработки

Поиск правильного Владельца Продукта зависит от знания типа разработки, которую вы реализуете:

• Продуктовая разработка—Для внешних потребителей или рынка.
• Внутренняя (продукт) разработка—Для одного или нескольких пользователей внутри компании. Такая группа разработки обычно называется ИТ или Системная Разработка.
• Проектная разработка—Обычно для одного внешнего клиента. В таком типе разработки работа организована и контрактуется как проект, хотя это не обязательно означает контракт с фиксированным объемом работ / сроком / стоимостью по проекту. Компания-разработчик в таких случаях обычно является аутсорсером или системным интегратором. Клиент или клиентская компания включает в себя как заказчика, так и пользователей, которые не всегда находятся в одном подразделении.

Шаг 2: Найдите подходящего Владельца продукта

Продуктовая разработка—В этом случае в компании продуктовой инициативой будет заниматься либо (1) некоторое бизнес-направление (например, направление розничного банкинга), либо (2) подразделение продуктового менеджмента. Традиционный Продуктовый Менеджмент отвечает за анализ клиентов и конкурентов, формирование видения Продукта, выбор и приоритизацию крупных блоков функционала, формирование дорожной карты Продукта и другие мероприятия, не связанные с технической стороной Продукта. Эти структуры не управляют работой традиционного подразделения разработки.

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

Внутренняя (продукт) разработка—Хорошего владельца продукта для внутренней продуктовой разработки в LeSS можно найти (1) в подразделении, которое будет использовать систему, и при этом (2) он должен быть сильно вовлечен и иметь глубокий опыт в выполнении реальной работы, для которой будет использоваться система. Такие люди очень близки к реальным пользователям.

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

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

Следующий рисунок показывает, как выглядит Владелец продукта в различных типах организаций:

Во всех случаях хороший Владелец Продукта должен “испытывать страсть” к Продукту.

Когда невозможно сразу найти подходящего Владельца Продукта, вы можете быстро начать применение LeSS с временным Владельцем Продукта не со стороны бизнеса, который понимает, что происходит, и может механически выполнить эту роль. Пусть команды завершат несколько Спринтов под временным Владельцем Продукта, пока не будет разработана основа, и —это важно- команды разработчиков смогут доставлять действительно “готовый” инкремент (или что-то близкое к этому) каждый Спринт. Почему? Группы разработчиков с большей вероятностью обретут и вдохновят подходящего постоянного Владельца Продукта, если они смогут продемонстрировать новые возможности, которые принесут ощутимую пользу бизнесу. Очень важно, чтобы все понимали, что непостоянный Владелец Продукта - это временное решение. Мы часто используем термин “поддельный Владелец Продукта”, чтобы указать насколько нефункциональным может быть такое решение. Потому что временный не только не является лучшим владельцем продукта, но и может причинить ущерб, пытаясь заполнить роль, для которой он не подходит. Его необходимо заменить как можно скорее, чтобы избежать риска создания второсортного продукта.

Шаг 3: Дайте полномочия и ответственность реальному Владельцу Продукта

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

Пять видов взаимоотношений

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

• Владелец Продукта<–>Команды
  Команды помогают Владельцу Продукта создать наилучший Продукт для клиента. Они должны знать как двигаться дальше и действительно ли то, что они уже сделали, достигло цели. Владелец Продукта должен знать, что нужно командам и как он может им помочь.
• Владелец Продукта<–>Клиенты
  Владелец продукта и команды пытаются создать наилучший Продукт для клиента. Клиенты должны знать, когда они будут иметь функции, которые им необходимы, и, возможно, обоснование расстановки приоритетов. Будьте прозрачными для клиентов, за счет их максимального вовлечения. Владельцу Продукта необходимо изучать цели или проблемы совместно с клиентами (или выявлять то, что находится за пределами их видения), а также собирать информацию, которая поможет ему правильно расставить приоритеты.
• Команды<–>Клиенты
  Задача команд создать лучший Продукт для клиентов. Для этого они должны понимать контекст для создаваемого ими функционала и иметь знания в предметной области. В идеале команды создают решения напрямую вместе с клиентами путем глубокого, а не поверхностного понимания их целей и проблем. Команды должны удостовериться, что они полностью понимают требования, которые они проясняют совместно с клиентами.
• Владелец Продукта<–>Топ-менеджмент
  Высшее руководство за пределами продуктовой группы (портфельные менеджеры, руководители высшего звена и др.) должны рассматривать Владельца Продукта, как человека, который берет на себя и несет полную ответственность за успешность Продукта. Он отвечает за то, чтобы процесс и статус разработки был прозрачным, а также за реализацию поставленных более высоким руководством целей (возможно, неявных) для достижения желаемых результатов (например, ROI и доли рынка). Владелец Продукта при поддержке Скрам-мастеров привлекает помощь высшего руководства для улучшения организационной структуры.
  • Владелец Продукта<->Скрам-мастера
    Отношения, описанные выше, напрямую связаны с “владением Продуктом”, но есть и другая сторона. Это относится к знаниям и поведению Владельца Продукта. Скрам-мастерам необходимо знать проблемы, вопросы и препятствия Владельца Продукта, чтобы они могли ему помочь. Хороший Скрам-мастер всегда выслушает или “подставит плечо”. Скрам-мастера обучают и дают обратную связь, чтобы владельцы продукта могли адаптироваться.

Собрания LeSS

У людей, только начинающих знакомство с LeSS, часто возникает вопрос “Как один владелец продукта собирается управлять множеством встреч со всеми этими командами?”. К счастью, причина этого вопроса заключается в недопонимании. Владелец Продукта в LeSS посещает только общие для команд мероприятия, даже в ситуации когда есть несколько команд. Количеством членов команд на таких мероприятиях можно управлять. Если есть только две команды, участвовать в мероприятиях могут все участники команд. Но если команд много - на общих мероприятиях присутствуют только по два представителя от каждой команды.

Какие LeSS мероприятия посещает Владелец Продукта, и какова средняя длительность таких мероприятий в типичном двухнедельном Спринте?

• Первая часть планирования - 1 час.
• Общее уточнение Бэклога Продукта (PBR) - 4 часа
• Обзор Спринта - 2 часа.
• Общая ретроспектива - 1.5 часа.

Таким образом, общее время, затрачиваемое на LeSS события, составляет в среднем около восьми часов в двухнедельном Спринте.

Владелец Продукта не посещает командные мероприятия: Вторая часть планирования Спринта, Ежедневный Скрам, командные уточнения Бэклога Спринта, командные Ретроспективы.

Перевод статьи осуществлен Сергеем Господчиковым и Алексеем Ворониным