Product Owner: как развивать карьеру и какие книги необходимо прочитать уже сейчас?

Что нужно владельцу продукта, чтобы исправить ошибки, повысить компетентность и развиваться профессионально? Какую литературу должен проработать каждый Product Owner?

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

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

Вопросы, которые нам часто задают начинающие РОs, примерно такие:

Василий: “Кажется, меня ненавидят все. Разработчики меня не воспринимают. Руководители постоянно предъявляют претензии. Сегодня им давай одно, завтра другое. Команда напряжена. Кто во всем виноват? Я. Что делаю не так?”

Дэн: “У нас не было ни продукт-оунера, ни финансов, чтобы его нанять. Так я стал владельцем продукта. Чувствую, что много на себя взял. Что делать?”

Надя: “Работаю продукт-оунером недавно. Сертификации пока не имею, но хочу развиваться в этой сфере. Что посоветуете почитать?”

Чтобы ответить на эти и подобные проблемы, рассмотрим три вопроса:

1. Проблемы начинающих.
2. Три направления работы владельца продукта.
3. Два начальных уровня Product Owner: Analyst и Proxy.

I. Проблемы начинающих

Обратим внимание на три типичные проблемы начинающих:

1. Критика продукт-оунеров.
2. Непоследовательность.
3. Перегрузка.

1. Критика продукт-оунеров.

Дело в том, что людям свойственно искать идеалы и верить в них. Недаром говорят, “Чтобы не разочаровываться — не очаровывайся”. Руководители и команда представляют себе идеал, а когда владелец продукта ему не соответствует, обвиняют его во всех смертных грехах.

Конечно, легендарные личности, изменившие мир, существуют. Например, многие считают идеальным продукт-оунером Джейн Мэннинг (Jane Manning). За два года она создала продукт Google Adwords, имея в команде только десять сотрудников.

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

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

С тех пор каждый топ-менеджер удивляется, почему их продукт-оунер — не Джейн Мэннинг.
Хотя критика владельцев продукта часто имеет почву. Например, в случае, когда продукт-оунер не совсем понимает три главных направления своей работы (см. далее) и автономности в пределах скрам-системы, из-за чего действует непоследовательно.

2. Непоследовательность

Большинство проблем возникает из-за непоследовательности владельца продукта.

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

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

3. Перегрузка

Непоследовательность начинающего ведет к его перегрузке.

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

Поэтому как навести порядок в работе владельца продукта? Чем на самом деле он должен заниматься?

II. Три направления работы владельца продукта

Владелец продукта отвечает за три направления работы:

1. Постоянное взаимодействие с командой

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

Экспертное мнение:

“Типичная ошибка начинающих — тонуть в деталях. Не зная, как правильно формулировать требования, владельцы продукта начинают прописывать их слишком подробно. Указывают технические подробности, спецификации, чрезмерно детализируют. Этого делать не стоит.

Аджайл-подход предполагает описание ПРОБЛЕМЫ, которую нужно решить, а традиционный — готовое РЕШЕНИЕ. Разница между подходами кардинальная.

От такой “классики” нужно отучиться. Ведь решений может быть несколько, и это уже дело команды — предоставить разные варианты.

Решением должно быть конкретное предложение того, что действительно можно реализовать в ограниченный временем период”.

— Вячеслав Москаленко,
сертифицированный тренер Scrum, соучредитель Agile.Live

2. Взаимодействие со стейкхолдерами

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

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

3. Связь с пользователями

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

Вот почему роль продукт-оунера не такая простая, какой кажется на первый взгляд.

Итак, что стоить предпринять владельцам продукта, чтобы развиваться профессионально?

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

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

Прежде чем что-то читать, необходимо понимать “Шкалу профессионального развития” и свое место на ней. Поняв это, вы выиграете время, сфокусировав внимание именно на тех аспектах, которые вам нужны на данном этапе, к тому же, сразу примените знания на практике.

Ведь каждый уровень предусматривает соответствующую литературу. Рассмотрим два таких уровня и рекомендации для каждого из них.

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

Итак, первое, что должен выяснить продукт-оунер, это свой настоящий уровень на шкале профессиональной компетентности Product Owner:

Обратим внимание на первые две ступеньки: Analyst и Proxy.

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

1. УРОВЕНЬ ANALYST

Что должен уметь владелец продукта на этом уровне:

• анализировать;
• приоритизировать.

Умение анализировать

1. Владелец продукта должен уметь анализировать информацию и передавать ее в понятной форме разработчикам. Иными словами, отвечать на вопрос: “Что хочет от команды босс?” При том понимать бюджетные, технологические и другие возможности компании.

2. Формулировать проблему.

Владелец продукта должен уметь формулировать проблему.

Почему постановка проблемы — “проблема”? Потому что обычно руководители приходят к разработчикам со слишком абстрактными, общими, не до конца понятными идеями.

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

Рассмотрим реальный пример:

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

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

Поэтому менеджер поставил задачу: “Найдите какое-то решение”.

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

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

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

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

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

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

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

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

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

→ Что читать?

Для уровня Analyst мы рекомендуем книгу Майка Кона “Пользовательские истории: гибкая разработка программного обеспечения” (User Stories Applied for Agile Software Development. Mike Cohn. Foreword by Kent Beck).

Владелец продукта должен быть мастером формулировки “пользовательских историй” (User Story). Каждая User Story не должна превышать длительность одной итерации (2 недели). В это время команда должна реализовывать 4-5 таких пользовательских историй.

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

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

Пример типичной пользовательской истории: “Как постоянный фасилитатор онлайн-сессий я хочу иметь возможность проводить голосования за ту или иную идею с помощью интерактивных карточек небольшой командой из 3-4 человек — для того, чтобы не тратить время на дополнительные инструменты”.

Умение приоритизировать

Помимо анализа, владелец продукта отвечает за Product Backlog — “артефакт”, в котором хранят и приоритезируют все User Story (как один из методов описания задачи или проблемы, которую нужно решать; проблема должна быть лаконичной, понятной и реалистичной для выполнения за одну итерацию).

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

→ Что читать?

Для формирования навыка приоритезации, рекомендуем для прочтения книгу “Профессиональный владелец продукта. Использование скрам в качестве конкурентного преимущества”, авторы Дон Макгреал и Ральф Джочем (The Professional Product Owner. Leveraging Scrum As A Competitive Advantage. Don McGreal, Ralph Jocham. Foreword by Ken Schwaber).

Сформировав эти два навыка анализа и приоритезации, можем говорить о следующем уровне, Proxy.

2. УРОВЕНЬ PROXY

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

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

Это предполагает следующее:

• Владелец продукта уровня Proxy имеет навыки планирования (Agile Estimating and Planning);
• Наделен автономностью в пределах Agile и Scrum.
• Однако автономность предполагает компетентность, осведомленность в “механике”. Владелец продукта хорошо понимает, что такое storypoints и как их использовать для прогнозирования.
• Выход за пределы узкого круга команды. Владелец продукта коммуницирует с конечными потребителями.
• Тайм-менеджмент. Владелец продукта владеет техниками управления временем.
• Умение делегировать задачи в рамках культуры Scrum, привлекать скрам-мастера, команду.
• Понимает распределение ролей и подробности скрам-подхода.
• Взаимодействует со скрам-мастером, который может дать ценный совет касательно того или иного вопроса.
• Хорошо владеет аналитическими навыками предыдущего уровня — умеет конкретизировать задачи, отсеять лишнее вследствие диалога с разными сторонами, достигает консенсуса.

→ Что читать?

Советуем прочитать книги:

• Майк Кон. “Agile. Оценка и планирование проектов” (англ. оригинал: Agile Estimating and Planning. Mike Cohn).
• Гунтер Вергэен. “Скрам. Мудрый путеводитель по скраму” (Scrum. A Smart Travel Companion. A Pocket Guide. Gunter Verheyen).
• Джефф Паттон. “Пользовательские истории. Искусство гибкой разработки ПО” (англ. орининал: User Story Mapping: Discover the Whole Story, Build the Right. Discover the whole story, build the right product. Jeff Patton, with Peter Economy. Forewords by Martin Fowler, Alan Cooper, and Marty Cagan).

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

Итоги

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

Таким образом, в начале профессионального пути владелец продукта должен обратить внимание на следующее:

1. Чтобы иметь успех, не обязательно быть гуру. Достаточно начинать с простых, но понятных обязанностей в пределах Скрам.
2. Самый первый навык — умение анализировать информацию по разработке продукта, из разных источников.
3. Умение формулировать проблему, четко ставить задачи, понятно описывать пользовательские истории.
4. Продукт-оунер умеет определять приоритеты и сосредотачиваться на главном.
5. Владелец продукта понимает свою автономность, а потому обеспечивает последовательность в работе и защиту команды от вмешательств извне.
6. Product Owner активно коммуницирует — выясняет необходимые сведения, отвечает на вопросы, разъясняет.
7. Во взаимодействии с различными участниками разработки владелец продукта находит оптимальные решения для бизнеса, учитывает возможности бюджета, команды, технологий.

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

Освоив первые два уровня компетентности Product Owner, Analyst и Proxy, владелец продукта станет профессионалом, который делает все для того, чтобы помочь команде, защитить ее, обеспечить ее всем необходимым для плодотворной реализации задачи. Таких будут уважать как разработчики, так и представители бизнеса. За такими успех.

ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE

Ближайшие сертификационные тренинги Agile.Live: Professional Scrum Product Owner (PSPO), Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live