Дисклеймер

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

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

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

Преамбула

У некоторых могут сразу возникнуть вопрос — "В чем разница между Продакт Менеджером и Продакт Овнером?"

Что ж, давайте именно с этого и начнем.

Разница между Продакт Менеджером и Продакт Овнером

Если коротко, в нескольких пунктах, то примерно так:

1. Фокус и обязанности:

   • Продакт Овнер больше ориентирован на операционное управление продуктом в контексте разработки и взаимодействия с командой. Его главная задача — управление бэклогом, приоритизация задач, создание и описание user stories, участие в скрам-церемониях, работа с критериями готовности (DoR) и завершенности (DoD). Продакт Овнер чаще всего сосредоточен на краткосрочных целях и тесно взаимодействует с разработчиками.

   • Продакт Менеджер занимается более стратегическими вопросами: он отвечает за видение продукта, его развитие на рынке, стратегию, взаимодействие с клиентами и стейкхолдерами. Продакт Менеджер также анализирует рынок, конкурентов и потребности пользователей для того, чтобы разрабатывать долгосрочные планы продукта и определять его уникальное предложение. Его задачи более глобальны и включают в себя формирование бизнес-целей и управление жизненным циклом продукта.

2. Ответственность перед командой:

   • Продакт Овнер непосредственно работает с командой разработки, обеспечивая её всем необходимым для эффективной работы. Он описывает требования, управляет бэклогом и регулярно участвует в планировании, грумингах и ретроспективах (СКРАМ церемонии).

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

3. Приоритеты:

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

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

4. Ключевая метрика успеха:

   • Продакт Овнер чаще всего измеряет свой успех через успешную и своевременную реализацию инкрементов продукта.

   • Продакт Менеджер ориентируется на показатели рынка: рост прибыли, доля на рынке, уровень удовлетворённости клиентов и другие бизнес-метрики.

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

Как я понимаю роль Продакт Овнера

Когда я говорю о роли Продакт Овнера, в первую очередь я имею в виду СКРАМ-роль, но с некоторыми дополнениями. 

В моем представлении, Продакт Овнер — это ключевое звено между продуктовой командой и департаментом разработки. Основным outcome продуктовой команды является является BRD (Business Requirement Document), который выступает отправной точкой для работы Продакт Овнера. Этот документ детализирует бизнес-требования к продукту, новым фичам или улучшениям продукта, которые нужно реализовать. Задача Продакт Овнера — "перевести" эти требования на технический язык (или функциональный, если хотите) и на основе этого сформировать бэклог продукта, которым уже он и будет управлять.

Hard Skills Продакт Овнера

Я предлагаю подсветить все зоны ответственности и задачи Продакт Овнера отдельно, чтоб нам было, где "подсмотреть" вдруг что.

Hard Skills согласно СКРАМ роли

1. Управление и приоритизация бэклога продукта;

2. Описание и детализация пользовательских историй (User Stories);

3. Определение и описание критериев готовности (Definition of Ready) и завершенности (Definition of Done);

4. Взаимодействие с заинтересованными сторонами (стейкхолдерами) для сбора бизнес-требований;

5. Участие в планировании спринтов и их приоритизация;

6. Проведение груминг-сессий для улучшения и уточнения требований;

7. Подготовка и проведение демо продуктов по завершению спринтов;

8. Постоянная связь с командой разработки для решения вопросов и уточнения деталей;

9. Обеспечение качества и своевременности выполнения задач;

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

11. Участие в ретроспективах для улучшения процессов разработки;

12. Следование за развитием продукта на всех этапах от идеи до релиза;

13. Оценка и контроль инкрементов продукта для достижения бизнес-целей;

14. Решение проблем и устранение препятствий, мешающих команде разработки выполнять задачи;

Hard Skills с учетом моих дополнительных требований

Для меня важно, чтобы Продакт Овнер умел переводить бизнес-требования на технический язык. Для этого необходим опыт работы с документами, такими как BRD и WBS. Кроме того, ключевой задачей Продакт Овнера является повышение эффективности и точности оценок команды разработки. Поэтому навыки работы с инструментами, такими как BurnUp, BurnDown и Velocity Charts, также имеют большое значение.

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

Логично предположить, что, поскольку Продакт Овнер тесно взаимодействует с командой разработки, ему необходимо разбираться в процессах разработки на базовом уровне. Важен опыт работы с такими инструментами, как Postman, SQL, Git. Также критично понимание базовой технической терминологии (кстати я ее описал ранее в трех статьях, ссылки прикреплю ниже) и навыки работы с основными инструментами. Например, использование консоли браузера, знание DOM-модели, HTML и CSS для оперативной проверки фронта после завершения спринта. Опыт работы с API через Postman и понимание JSON также будут большим преимуществом.

Базовую терминологию я описал ранее в трех статьях:

1. От API до CI/CD: Базовые термины в IT, которые желательно знать

2. От Gantt до WBS: Ключевые термины в Проджект-Менеджменте

3. От A/B до OKR: Ключевые термины в Продакт-Менеджменте

А вот тут писал статью о том, что такое WBS и как ее составлять:

1. Элитные страдания с Work Breakdown Structure (WBS)

Итого, давай набросаем список "дополнительных" обязанностей и зон ответственности:

1. Умение составлять и читать BRD, WBS;

2. Умение работать с Postman, Git, SQL;

3. Базовое понимание HTML, CSS;

4. Умение работать с консолью браузера;

5. Умение работать с API через Postman / JSON;

6. Оптимизация производительности команды разработки;

7. Применение Velocity Chart, BurnUp / BurnDown Charts;

8. Скилл мануального тестирования фронта (не факт что пригодится, то мало-ли);

9. Скилл манулаьного тестирования бека (не факт что пригодится, то мало-ли);

10. Умение работать с Figma, Miro, Mural, Draw.io:

    1. Создание блок-схем;

    2. Создание вайрфреймов ;

    3. Использование и навигация по дизайну и UI-Kit продукта в фигме;

Ну и логично, что знание английского должно быть минимум на уровне Upper Intermediate (C1). 

Составляем Тестовое Задание

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

Но времена изменились. Сейчас конкуренция за место значительно выросла, и за позицию приходится чуть ли не драться на топорах до первой крови. В такой ситуации тестовое задание — отличный инструмент. Это позволит отсечь менее подготовленных кандидатов, и выявить лучших из лучших. Так что мощное ТЗ звучит как неплохой план, да?

Уже чувствую как кандидаты начинают ненавидеть эту статью :)

Что добавить в ТЗ, а что оставить на этап собеседования

В целом тут простой и логичный ответ. Давайте разделим все скиллы на 3 категории. Например такие:

1. Скиллы, которые можно проверить на практике

   1. Скиллы, требующие длительной практики и навыка

   2. Скиллы, которым можно обучиться за короткий промежуток времени

2. Скиллы, которые трудно проверить на практике

   1. Скиллы, требующие длительной практики и навыка

   2. Скиллы, которым можно обучиться за короткий промежуток времени

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

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

Скоуп ТЗ

Можно комбинировать задачи из практической и теоретической частей, ведь полный список может занять слишком много времени у кандидата, даже в текущих условиях рынка. Лично я считаю, что 4-5 часов на выполнение тестового задания в современных реалиях — это вполне адекватно. Если позиция привлекательная и ты рассчитываешь зарабатывать 5-7 тысяч долларов в месяц, то потратить даже целый день, чтобы продемонстрировать свои навыки, не должно быть проблемой. В конце концов, я сужу по своему опыту в найме кандидатов и в работе на подобных позициях.

Поехали:

1. Создайте мокап в Miro или Figma для любого продукта с рынка (продукт на выбор кандидата).

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

2. Опишите User Stories, которые соответствуют продукту на представленном мокапе;

3. Сформулируйте DOR, DOD и Acceptance Criteria для этих User Stories;

4. Создайте WBS (Work Breakdown Structure), который будет описывать структуру выбранного продукта;

5. Разработайте календарь Release Plan, включающий команды Design, Development, Product и QA. Укажите даты релизов для каждой команды и отобразите их взаимосвязь между собой;

6. Предложите пример roadmap для новой фичи, начиная от идеи и заканчивая релизом. Какие ключевые этапы вы включите в этот процесс?

7. Ответить на вопросы:

   1. Как вы определяете, что BRD готов к декомпозиции и переводу в User Stories?

   2. Предоставьте список API, с которыми вам доводилось работать ранее;

   3. На основе описания вакансии, в каких областях и инициативах вы чувствуете себя наиболее опытным, компетентным и уверенным?

   4. Как вы работаете с техническим долгом? В какой момент вы принимаете решение о том, чтобы приоритизировать задачи, связанные с техническим долгом?

   5. Какие метрики, помимо Velocity и BurnDown, вы используете для оценки эффективности команды и качества продукта?

   6. На основе каких критериев вы приоритизируете бэклог продукта?

   7. Какие шаги вы предпринимаете для повышения точности оценки задач командой разработки?

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

   9. Как вы оцениваете и минимизируете риски в проекте? Приведите пример управления рисками из вашего опыта.

Софт Скиллы

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

Вот ключевые софт скиллы, которые важны для Продакт Овнера:

1. Коммуникация

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

2. Навыки приоритизации

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

3. Управление временем

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

4. Эмпатия и эмоциональный интеллект

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

5. Решение проблем и критическое мышление

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

6. Переговорные навыки

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

7. Гибкость и адаптивность

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

8. Внимание к деталям

Продакт Овнер должен быть скрупулезным в своей работе, особенно когда дело касается документации, описания требований (WBS, user stories, DOR. DOD, ACs) и контроля за выполнением задач. Важно не упускать мелочи, которые могут повлиять на качество продукта.

9. Ответственность и лидерство

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

Структура Описания Вакансии

Я обычно придерживаюсь примерно такой структуры

1. Title

2. Overall Summary

3. Areas Of Responsibilities

4. Skills

5. Test Task (Может идти отдельно)

Overall Summary

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

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

Areas Of Responsibilities

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

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

Skills

Сухой список скиллов, которые важны. Можно просто списком.

Test Task

В целом уже обсудили выше. 

Готовый пример

Overall Summary

When we refer to the role of a Product Owner, please don’t think of it as a typical Scrum role. Review the list of responsibilities below, and once you join our team, you can choose a title that best suits you :)

We are looking for a Product Owner with a minimum of 3 years of experience in the responsibilities and tools listed below.

Experience working in a product company, and not just outsourcing, is a plus, as the processes, goals, and requirements in these environments differ significantly.

It’s also a plus if you’re familiar with creating and managing BRDs (Business Requirements Documents), WBS (Work Breakdown Structure), as well as DOD (Definition of Done), DOR (Definition of Ready), and AC (Acceptance Criteria).

A high level of English proficiency (at least C1) is required, as you will frequently communicate with international teams.

Formally, you will be part of the Product Team and report to the Head of Product, but you will regularly collaborate with the IT team.

At present, we have several products already in production, and a few others in active development. You will initially be working on the products that are live (feel free to check our website for more details).

In our view, the Product Owner serves as a vital link between the product and development teams. You will receive detailed business requirements from the product team, and your role will be to: create and manage the product backlog based on requirements from all product managers, describe user stories, add DOR, DOD, and AC to tickets, facilitate grooming sessions, participate in planning meetings, conduct demos for the Product Team, and ensure the timely delivery of features while maintaining the quality of the product backlog, tickets, and features in production. (This is not an exhaustive list of responsibilities, but a high-level overview).

Areas of Responsibility

• Manage the Jira Dev board:

  • Ensure that each ticket is described according to the guidelines;

  • Custom fields are properly filled in;

  • Priorities are clearly set;

  • Each ticket is estimated;

  • Each ticket is associated with an Epic;

  • Regularly track Burndown/Burnup charts and IT team velocity;

• Provide regular Release Notes and Release Plan reports (export from Jira);

• Create, manage, and maintain directories with release reports, release notes, etc.;

• Work with BRDs, WBS, and other requirements provided by Product Managers to create, manage, and describe user stories and epics;

• Lead grooming sessions with the IT team;

• Facilitate planning sessions with the IT team;

• Conduct demo sessions for Product Managers;

• Gather missing information and ask clarifying questions to Product Managers and other stakeholders;

• Ensure the quality of released products and features by checking functionality before the demo and after the QA team's review;

• Assist the IT team in following processes defined by the CTO and Operational Product Managers;

• Create and describe Epics, User Stories, and Bugs according to the templates, standards, and processes;

• Ensure that each user story (if applicable) includes DOR, DOD, and AC.

Required Skills

• English proficiency at least at C1 level;

• Ability to set and manage DOD, DOR, and AC;

• Experience in creating and describing Epics, User Stories, and Bugs;

• Proficiency with BurnUp and BurnDown charts;

• Ability to create wireframes in Figma or Miro;

• Experience creating WBS and BRDs independently;

• Expertise in facilitating grooming and planning meetings;

• Ability to decompose BRDs into Epics and User Stories;

• Presentation skills to showcase product features to stakeholders;

• Experience in performing manual testing to ensure that QA and IT teams haven’t overlooked any issues;

• Be prepared for monthly KPIs, which will be set by your direct manager;

• Proficiency in SQL, Postman, and GIT.

Test Task

Prepare a mockup in Figma or Miro of any feature from any marketplace, crypto exchange, or other valuable product of your choice. Please attach the following for the feature:

• User Stories;

• DOR;

• AC.

Additionally, please answer the following questions:

• How do you determine when a BRD is ready for grooming, decomposition into user stories, and final estimation?

• How would you facilitate the grooming ceremony? What are the expected inputs and outcomes?

• Provide a list of APIs you’ve worked with in the past (include at least a few examples).

• Based on the job description, in which areas and initiatives do you feel the most experienced, knowledgeable, and confident?

• Provide an example of your favorite product(s) on the market (it could be a marketplace, bank, smartphone, etc.) and explain why.

Скачать PDF можно тут: клац

Заключение

Найти хорошего Product Owner — это найти человека, который одновременно разбирается в бизнесе и технологии, а также умеет эффективно управлять процессами разработки. Такой специалист должен обладать несколькими ключевыми навыками. Во-первых, это способность грамотно приоритизировать задачи и управлять бэклогом, что помогает команде достигать целей без лишних задержек. Во-вторых, важен опыт работы с документами, такими как BRD и WBS, и использование метрик вроде Burndown и Burnup для отслеживания прогресса команды.

Мои соц сети.

Telegram Channel: https://t.me/mr_ponder