Анти-паттерны владельца продукта и способы решения

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

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

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

Вот несколько важных фактов о роли владельца продукта, о которых вы должны помнить:

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

В этой статье мы рассмотрим анти-паттерны владельца продукт. А так же разберем эти ситуации и как их исправить.

Много владельцев продуктов, один продукт

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

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

Вы также можете столкнуться с тем, что несколько владельцев продуктов «владеют» своей командой или областью продукта в пределах одного продукта. Владельцы сегментированных продуктов изолируются, делая то, что они хотят. И в результате нет единого представления о том, каким должен быть продукт. Это приведет к тому, что ваши пользователи получат продукт с несвязной архитектурой, обремененный техническими долгами.

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

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

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

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

Частично занятый владелец продукта

«Где владелец продукта?» Мы задавали этот вопрос много раз, работая со Scrum-командами. Команда разработчиков хочет продолжать работать, но им нужны ответы от владельца продукта. Это распространенный симптом наличия владельца продукта, который работает неполный рабочий день.

Так как же появляются владельцы продуктов с частичной занятостью? Когда роль владельца продукта впервые вводится в организации, большинство руководителей отделов и руководителей проектов воспринимают ее как всемогущую и угрожающую позицию. Термин «владелец продукта» подразумевает общее владение продуктом, но традиционно право собственности на продукт распределяется по различным ролям. Эта консолидация “права собственности”может вызвать чувство угрозы у некоторых руководителей. Они чувствовали себя комфортно и привыкли работать как в прошлом.

Мы часто видим эту первоначальную негативную реакцию на роль ВП в компаниях, где эта роль является новой. Набор навыков уникален и отличается от всего, что ранее существовало во многих организациях. Естественная склонность менеджмента состоит в том, чтобы сделать его работой частично занятой. Это легко сделать: вместо того, чтобы прорваться через бюрократические проволочки, вводя новую роль, руководство уменьшает управленческие обязанности у яркого руководителя и он становится PO с частичной занятостью.

Другой способ, которым может появиться владелец продукта, работающего неполный рабочий день, – это если человек из Scrum-команды обнаружит, что он или она фактически выполняет роль владельцем продукта. Это может произойти, когда руководство не называет явно владельца продукта. К сожалению, этот владелец продукта по умолчанию слишком занят, чтобы фактически выполнять большую часть работы, необходимой для ПО.

Владелец продукта, работающий неполный рабочий день, делает все возможное для Scrum-команды, но 10% времени, отведенного на эту роль, быстро падает до 5%. У этого человека все еще есть другая работа. Владелец продукта проводит обзоры спринта. Ретроспективы спринта для него не так важны, как встречи по бюджету, совещания с руководителями или тушение пожаров персонала. Посещать первые полчаса при планирования спринта – это все, что он может себе позволить.

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

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

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

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

• Оценка продуктов конкурентов.
• Оценка информации о клиентах.
• Создание дорожной карты.
• Управление бюджетом.
• Внедрение метрик на основе ценности.
• Сбор информации от заинтересованных сторон.

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

Исполняющий обязанности владельца продукта

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

Владелец продукта управляет бэклогом продукта. Это похоже на то, что должен делать бизнес-аналитик, верно? Конечно, это сопряжено с чуть большей ответственностью, но люди в организации могут испугаться термина «владелец продукта». Мы можем сделать управление бэклогом продукта единственной целью этого человека, а другие обязанности, такие как управление бюджетом, останутся на тех же людях. Если мы откажемся от контроля над бюджетом, то что тогда мы будем делать?

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

Руководитель бэклога продукта просто будет записывает требования, которые предоставляют заинтересованные стороны, и обеспечивает, чтобы группа выполнила именно то, что указано в списке. Существует даже вероятность того, что отдел кадров создаст роль с официальным названием «Владелец продукта». Обязанности, определенные в документе отдела кадров, могут выглядеть так же, как у прославленного бизнес-аналитика или руководитель продукта. Тем не менее, роль лишена ответственности. А значит успеха не будет.

Иногда проблема проста: организация или владелец продукта просто не понимает Scrum. Если это так, сейчас самое время объяснить все, что представляет собой роль владельца продукта. Сосредоточьтесь на четкой ответственности каждой роли в Scrum, почему крайне важно предоставлены все возможности и владение владельцу продукта. Это необходимо, чтобы максимизировать ценность того, над чем работает команда разработчиков.

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

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

Как вы можете видеть, исполняющий обязанности PO (product owner) может обречь продукт. Итак, что вы можете исправить этот анти-патерн? Узнайте фактического владельца продукта, задав простой вопрос: с кем нам нужно поговорить, чтобы получить больше денег для финансирования следующего спринта? Обычно вам не нужно больше денег, но полезно знать, кто принимает решение.

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

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

Главнокомандующий

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

Вот как это выглядит:

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

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

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

Теперь давайте посмотрим с другой стороны.

Быть владельцем продукта может означать быть одиноким. Это может быть причиной такого контролирующего поведения. Владельцы продуктов испытывают огромное давление на них: заинтересованные стороны возлагают большие надежды, команды разработчиков нуждаются в ясности и поддержке, а клиенты – требовательны. В сочетании с тем фактом, что это может быть новая роль для человека или компании, владелец продукта может чувствовать себя действительно напуганным. Как Scrum-мастер, вы должны сотрудничать с владельцем продукта, помогая ему создать набор инструментов, который ему нужен для успеха. И иногда, вы можете помочь, просто спросив владельца продукта: «Все в порядке?»

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

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

Scrum-мастер + Владелец продукта

Некоторые компании считают, что это нормально совмещать роль Scrum-мастера и владельца продукта. Люди в управлении могут сказать: «У нас нет места/бюджета для двух новых должностей, поэтому давайте объединим эти обязанности в одну роль». Они могут даже захотеть объединить другие должности в этой роли, такие как менеджер проекта, архитектор или даже разработчик.

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

Вот некоторые вещи, которые Scrum-мастера обычно обсуждают с членами команды разработчиков, заинтересованными сторонами и руководством:

• Команда разработчиков: поддержка Scrum и гарантирование, что команда оптимизирована для эмпирического управления процессом.
• Заинтересованные стороны: создание понимания о работе в сложной сфере и демонстрация того, насколько необходимо иметь эмпирический контроль процесса.
• Руководство: Совместная работа над организационными изменениями, необходимыми для успеха Scrum.

Напротив, вот те вещи, которые владельцы продукта должны обсуждать с теми же людьми:

• Команда разработчиков: видение и направление продукта и то, как владелец продукта перевел это видение и направление в бэклог продукта.
• Заинтересованные стороны: Сотрудничество и активное участие в продвижении продукта.
• Руководство: работа через процесс бюджетирования.

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

Чего не хватает в таблице, так это взаимодействия между Scrum-мастером и владельцем продукта друг с другом. Есть несколько важных взаимодействий для владельца продукта и Scrum-мастер. Владельцу продукта / Scrum-мастеру не к кому обратиться, когда им понадобится помощь, и в результате все это отразиться на продукте.

Scrum-Мастер служит владельцу продукта множеством способов. Вот несколько примеров:

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

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

Выполнив всю эту работу, владелец продукта не сможет выполнить задачи, ожидаемые от Scrum-мастера. Чтобы люди узнали об этой проблеме, попробуйте выполнить задание:

Подумайте о роли Scrum-мастера и продумайте каждую задачу, которую кто-то в этой роли может выполнить во время спринта и создайте заметку для каждой задачи. Как только вы исчерпаете свои мысли, сделайте перерыв. Когда вы вернетесь, перейдите к роли владельца продукта и сделайте то же самое со стикерами другого цвета, чтобы разграничить роли. Затем посмотрите на то, что вы написали и спросите:

• Есть ли сходство в работе?
• Есть ли конфликт интересов, вызванный выполнением обеих ролей?
• Может ли один человек выполнить все эти задачи?
• Что и / или кто может пострадать, если один человек станет совмещать роли?

Теперь пройдитесь по ценностям Scrum и спросите, действительно ли возможно сосредоточиться на обеих ролях и работе во время спринта. Можете ли вы по-настоящему посвятить себя выполнению этой работы на высоком уровне? Будете ли вы достаточно открыты со Scrum-командой, чтобы признать, как трудно совмещать? Проявите ли смелость признать, когда вы не знаете, что делать дальше? Достаточно ли у вас уважения к клиентам и заинтересованным сторонам, чтобы перестать выполнять обе роли, если доставка продукта страдает?

Если вы не можете честно ответить «да» на эти вопросы, то отстаивайте свою роль (или человека, выполняющего обе эти роли), чтобы он был разделен на две роли.

Отсутствие ясного видения

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

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

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

Каково видение продукта, над которым вы работаете сейчас? Видение должно циркулировать в вашей голове, как текст любимой песни. Без видения продукта и сопутствующего измеримого результата, каждому сложно дать отзыв о том, успешен ли продукт. Это может привести к тому, что владелец продукта часто меняет свое мнение о том, куда должен идти продукт или каково определение «ценности» для этого проекта. ВП может даже начать принимать заказы от заинтересованных сторон, пытаясь удовлетворить их любые требования, что, как мы уже обсуждали, не совсем так, как должен работать Scrum.

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

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

Учтите, что единственно лучший способ мотивировать команду разработчиков – это дать им понять, какое влияние их работа оказывает на мир. Если владелец продукта обеспечивает четкое видение продукта с результатами, измерениями и показателями, это влияние будет ясно видно команде и организации. Это может улучшить моральный дух и доказать, что финансовые вложения, которые организация сделала в продукт, были оправданы.

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

У вашей Scrum-команды нет видения продукта или им трудно понять, что это за продукт? Начните с поиска способа описать ваш продукт одним вдохновляющим словом.

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

Если бы мы выбрали одно слово в качестве объединяющего слогана для Scrum, то, что каждый мог бы оставить позади, как насчет слова эффективность?

Метод подачи одним словом описан в книге Даниэля Пинка «To Sell Is Human: The Surprising Truth About Moving Others». Это один из многих методов, которые вы можете предложить для совместной работы с владельцем вашего продукта. Также есть много других хороших, таких как Product Vision Board Романа Пихлера или Product Vision Box из книги Innovation Games: Creating Breakthrough Products Through Collaborative Play.

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