1. Позиция владельца продукта 2. Знакомство с позициями владельца продукта

Неправильно понятая позиция владельца продукта

Ответственность владельца продукта часто неправильно понимается, что приводит к интересным внедрениям Scrum и владения продуктом в частности.

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

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

1. Клерк

Клерк также называется администратором, секретарем, официантом, обслуживающим персоналом или принимающим заказы.

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

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

• У клерков, как правило, бесконечный (или, по крайней мере, обширный) список невыполненных работ по продукту, в первую очередь потому, что они редко, если вообще когда-либо, говорят "нет" заинтересованным сторонам. Когда заинтересованная сторона выдвигает идею, запрашивает новую функцию или говорит им, что делать, клерки обычно отвечают: “Конечно, позвольте мне добавить это в список невыполненных работ”.
• Клерки, как правило, имеют внутреннюю направленность. Внутренние заинтересованные стороны говорят им, что делать и что строить. Клерки (часто) не взаимодействуют с внешними заинтересованными сторонами, редко - с внешними пользователями и (почти) никогда - с реальными, платящими клиентами, которые покупают продукт. Они редко общаются (или им разрешается общаться) с внешними влиятельными лицами или заинтересованными сторонами в управлении, такими как юридические органы и/или регулирующие органы.
• Клерки выступают в качестве посредника (почтового голубя) между разработчиками и заинтересованными сторонами. Им нужно часто переводить людей в режим ожидания, чтобы получить больше информации от других. Они не могут принимать никаких решений, потому что им нужны согласования и разрешение, прежде чем действовать. Такая реактивная позиция, требующая разрешения, часто демотивирует всех. Владельцам продуктов-клерков трудно сказать "нет", потому что они стараются угодить всем. Они склонны к микроуправлению, распределяя задачи между членами команды, управляя с помощью электронных таблиц, используя людей, снижая оценки усилий разработчиками, максимизируя результат и являясь координатором команды.

2. Писатель

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

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

Разработчики в Scrum-командах отказываются от выполнения, когда работа не соответствует определению готовности (DoR - Definition of Ready). Они подталкивают владельца продукта к подготовке компонентов к спринту в соответствии с DoR. DoR - это практика (не обязательная в Scrum), которую иногда используют авторы историй и Scrum-команды.

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

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

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

Следующие закономерности связаны с неправильно понятой позицией писателя:

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

3. Менеджер проекта

Менеджера проекта также называют максимизатором скорости, максимизатором использования ресурсов, администратором списка пожеланий, помощником руководства и репортером о ходе работы.

Менеджеры проектов, как правило, озабочены повседневным прогрессом разработчиков. Они редко, если вообще когда-либо пропускают Daily Scrum, даже если только для того, чтобы спросить отдельных членов команды, что они сделали, что собираются делать и не мешает ли им что-нибудь. Они измеряют успех команды в виде увеличения скорости и, как правило, “отчитываются” о моментах истории, графиках выгорания и скорости перед заинтересованными сторонами во время обзора спринта.

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

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

Следующие закономерности связаны с неправильно понятой позицией менеджера проекта:

• Менеджеры проектов привыкли управлять проектами, а не продуктами. Проекты имеют четкое начало и конец, являются временными и выполняются временной командой/организацией. Роль менеджера проекта предназначена для получения результатов, которые затем передаются в линейную организацию для дальнейшего внедрения и фактической реализации ожидаемых результатов. Однако быть владельцем продукта - это не временное занятие! Владельцы продукта "внутри" в долгосрочной перспективе (а не только для получения некоторых результатов) и несут (или должны нести) ответственность за общую стоимость владения, прибыль и убытки от продукта.
• Менеджеры проектов, как правило, озабочены повседневным прогрессом разработчиков. Теперь, просто чтобы внести ясность, не обязательно плохо знать, что происходит с разработчиками. Однако работа владельца продукта не заключается в том, чтобы управлять прогрессом, которого добиваются разработчики. Ваша задача состоит в том, чтобы максимизировать ценность, предоставляемую разработчиками, убедившись, что (потенциально) наиболее ценная (или наиболее рискованная) работа выполнена в первую очередь.
• Когда спринт приносит больше story points, чем было получено в предыдущем спринте, руководители проектов обычно приходят в восторг.
• Менеджеры проектов часто привыкли отчитываться о (традиционных) показателях прогресса, таких как объем, время и бюджет, а также о результатах, процентах прогресса, рисках, контрольных точках и отклонениях от первоначального плана. Хотя для владельцев продуктов не является плохой практикой следить за бюджетом и потенциальными рисками, способ борьбы с ними в рамках Scrum совершенно иной.
• Менеджеры проектов привыкли получать проекты/задания с четким объемом, сроками и бюджетом. Они также привыкли обращаться к руководящему комитету за разрешением или одобрением, чтобы направлять свои действия и решения. Владельцы продукта не отчитываются перед руководящим комитетом. Они не выходят на улицу за новыми проектами и заданиями. Они создают видение продукта и стратегию и начинают максимизировать его ценность. Владельцы продукта подотчетны и несут ответственность за результаты.
• Другие связанные с этим виды поведения менеджеров проектов - микроменеджмент, управление показателями, установление крайних сроков, распределение задач между членами команды, управление с помощью электронных таблиц, использование людей, сокращение оценок усилий разработчиками, максимизация результатов и роль координатора команды.

4. Специалист по предметной области (SME)

Специалист по предметной области (SME) также называется старшим пользователем, ключевым пользователем, менеджером процессов, экспертом в предметной области или бизнес-экспертом.

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

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

Следующие закономерности связаны с неправильно понятой позицией SME:

• SME могут определять работу с высокой степенью детализации. Они, как следует из этого термина, являются экспертами в своем бизнесе, предметной области или технической области, и некоторые из них без колебаний делятся своими знаниями со всеми остальными. Следовательно, одна из ловушек НЕКОТОРЫХ владельцев продуктов заключается в том, что они могут часами рассказывать о своей области знаний. Нередки случаи, когда встречи занимают гораздо больше времени, чем ожидалось, и что, несмотря на продолжительные выступления SME, никто не понимает целей, над достижением которых они работают.
• Другие SME, напротив, часто делают комментарии типа “Вам не обязательно это знать” или “Я дам вам знать о следующих шагах, когда мы доберемся до них”. Информация, которой они располагают, может быть ценной, но они тщательно оберегают ее — иногда намеренно, иногда неосознанно. Знания - это сила, и некоторые SME воспринимают свои знания как гарантию занятости. Таким образом, не обязательно выступают за обмен знаниями; вместо этого они с ложечки сообщают разработчикам крошечные фрагменты общей картины, постоянно участвуя в процессе разработки.
• Еще одно рискованное поведение, которое часто демонстрируют SME, - это быть одновременно владельцами продуктов и разработчиками. Например, владелец продукта SME может одновременно выполнять функции архитектора программного обеспечения / предприятия, бизнес-разработчика или, возможно, эксперта по работе с клиентами. Наличие нескольких рабочих мест и ролей в команде сопряжено с риском. Будучи старшим или экспертом в команде, часто обнаруживаешь подводный камень, заключающийся в том, чтобы вмешаться и сделать это самостоятельно. Нет ничего необычного в том, что старший разработчик или архитектор перестроил кодовую базу за одну ночь или что владелец маркетингового продукта переработал весь план маркетинговой кампании за выходные.
• Другие связанные с этим модели поведения - быть архитектором, техническим экспертом (по разработке), менеджером тестирования, старшим (техническим) сотрудником в команде, который принимает решения по всем деталям, дизайнером UX, микроменеджером, распределяющим задачи между членами команды и снижающим оценку усилий разработчиками.

5. Охранник (гейткипер)

Охранник также упоминается как защитник, страж, щит, врата или единая точка контакта.

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

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

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

• Гейткипер отлично справляется с тем, чтобы держать заинтересованных лиц подальше от разработчиков и блокировать все коммуникации. Соглашение, заключенное между Гейткипером и разработчиками, заключается в том, что все вопросы задаются и на них даются ответы через Гейткипера, который при необходимости проконсультируется с заинтересованными сторонами. Разработчики не задают вопросов непосредственно пользователям или заинтересованным сторонам, не говоря уже о заказчиках.
• Другой типичный шаблон гейткипера заключается в том, что все идеи, пожелания, требования и результаты работы должны быть доведены непосредственно до владельца продукта. Таким образом, Гейткиперы гарантируют, что даже самый незначительный запрос заинтересованных сторон не дойдет до разработчиков без ведома Гейткипера.
• Гейткиперы также блокируют обратную связь от заинтересованных сторон к разработчикам. Они склонны рассматривать 2-4-часовые обзоры спринта как пустую трату времени разработчиков - времени, которое можно было бы лучше потратить на написание кода. Поэтому они проводят обзоры Sprint самостоятельно; собирают отзывы заинтересованных сторон, пользователей и заказчиков; затем делятся этими отзывами с разработчиками.
• Гейткиперы настаивают на подписании всех требований и конечных результатов, которые разрабатывают разработчики.

6. Менеджер

Менеджера также называют руководителем команды, тимлидом, техническим руководителем, владельцем продукта и Scrum-мастером, а также лицом, ответственным за управление персоналом.

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

Менеджер - это настоящий человек, ориентированный на развитие людей. Еще одной целью менеджера является оценка эффективности работы отдельных членов команды.

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

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

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

Предпочтительные позиции владельца продукта

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

1. Визионер

Визионера также называют вдохновителем, нарушителем статус-кво, мечтателем или обладателем творческого продукта.

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

Видение не всегда должно быть таким, как “через 10 лет отправим человека на Марс”. Некоторые видения масштабны, другие малы — и не каждое видение обязательно приводит к успеху.

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

2. Соавтор (коллаборатор)

Также называют командным игроком и работником команды.

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

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

3. Представитель заказчика

Представитель клиента также упоминается как адвокат клиента, голос клиента, представитель пользователя, адвокат пользователя или голос пользователя.

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

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

4. Принимающий решение ("решатели")

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

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

Что делают хорошие "Решатели"? Что ж, они слушают!

Великие "Решатели", заботятся о том, чтобы другая сторона чувствовала себя услышанной и понятой.

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

• (а) отрицаете ли вы его озабоченность: “Этого не происходит”
• (б) сводите ее к минимуму: “Это не проблема”
• (в) довершаете: “По сравнению с тем, что мне пришлось сделать,...”
• (d) прервать их на середине их сообщения....

5. Экспериментатор

Сэр Исаак Ньютон, Луи Пастер, Мария Кюри, Альберт Эйнштейн и Никола Тесла - вот некоторые из величайших ученых всех времен. Если бы не такие люди, как Никола Тесла, то, возможно, вы не смогли бы прочитать эту книгу, и, возможно, мы бы вообще ее не написали. Эти и другие ученые, новаторы и экспериментаторы являются движущей силой инноваций.

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

6. Инфлюенсер (оказывающий влияние)

Человека, оказывающего влияние, также называют политиком.

К числу самых известных и влиятельных лидеров всех времен относятся такие люди, как Мохандас К. Ганди, Нельсон Мандела, Мартин Лютер Кинг-младший и Авраам Линкольн. Эти джентльмены входят во все десятку лучших политиков, влиятельных лиц, меняющих мир и так далее.

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