{"id":14268,"url":"\/distributions\/14268\/click?bit=1&hash=1e3309842e8b07895e75261917827295839cd5d4d57d48f0ca524f3f535a7946","title":"\u0420\u0430\u0437\u0440\u0435\u0448\u0430\u0442\u044c \u0441\u043e\u0442\u0440\u0443\u0434\u043d\u0438\u043a\u0430\u043c \u0438\u0433\u0440\u0430\u0442\u044c \u043d\u0430 \u0440\u0430\u0431\u043e\u0447\u0435\u043c \u043c\u0435\u0441\u0442\u0435 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f71e1caf-7964-5525-98be-104bb436cb54"}

Product Owner: 7 ключевых обязанностей

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

Пара вступительных слов

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

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

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

Итак, 7 основных обязанностей продакт оунера:

Определение видения продукта

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

Наличие продакт-оунера на проекте гарантирует заказчику, что agile-команда будет придерживаться того видения, которое установлено заказчиком. Для этого продакт-оунер составляет дорожную карту продукта (roadmap) – краткосрочный или долгосрочный план выполнения, изменения и развития проекта.

Управление бэклогом продукта

Еще одна обязанность продакт оунера – управлять бэклогом. Бэклог – это список задач для команды разработчиков, который может меняться в зависимости от потребностей проекта. Изменять бэклог может как продакт оунер, так и разработчик. Здесь обязанность продакт оунера состоит в том, чтобы составить список задач и определить их приоритетность выполнения в соответствии с бизнес-задачами заказчика.

Приоритезация потребностей продукта

Приоритезация потребностей – неотъемлемая часть agile-процесса. Она также зависит от бизнес-задач заказчика и сроков выпуска проекта. Например, если разрабатываемый продукт должен быть запущен в течение 6 месяцев, продакт оунер должен определить, какие главные функции должен включать его MVP (minimum viable product) – минимально жизнеспособный продукт, и, исходя из этого, решить, длительность каких итераций можно изменить. Приоритезация потребностей также зависит от бизнес-задач заказчика.

Контроль на всех этапах разработки

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

Выработка продуктовой стратегии совместно с заказчиком

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

Эффективная коммуникация с заказчиком и разработчиками

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

Оценка прогресса продукта

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

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

0
19 комментариев
Написать комментарий...
Вася Бездомный

Самое главное не написано, что PO это роль с фреймворке SCRUM и вне его существовать не может.

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

Ответить
Развернуть ветку
Alexandre Svergoun

Всё зависит от проекта. Для некоторых (очень редких) проектов каскад ещё может работать. Для большинства проектов Agile просто необходимость. За 10 лет работы, я заметил что проекты реализованные по Agile самые полезные для клиентов и оказали самое сильное влияние на продуктивность компании клиента.

Ответить
Развернуть ветку
Вася Бездомный

Я выше написал - Cynefin, там всё расписано что для чего. Можно и микроскопом гвозди забивать, но всё же лучше для этого молоток подобрать.

Ответить
Развернуть ветку
Nikita Tanygin

Agile работает только в вебе и только в сервисах, которые не критично сломать и быстро починить :)

Ответить
Развернуть ветку
Alexandre Svergoun

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

Ответить
Развернуть ветку
Nikita Tanygin

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

Ответить
Развернуть ветку
Alexandre Svergoun

Я вообще то Scrum Master.
Первый пункт манифеста и первая ценность :
1. Customer satisfaction by early and continuous delivery of valuable software
Это как раз о том что я сказал. В каскадной разработке, с клиентом общается аналитик до начала кодирования. А клиент юзает первый раз программу когда всё уже закодированно.
При Agile клиент видит первые скрины уже через пару недель, и может уже по юзать программу в тестовом режиме. И самое главное, может сразу дать полезный фидбак и сделать так что бы форму доделали так как ЕМУ надо. Что и приводит к Customer satisfaction.

Ответить
Развернуть ветку
Nikita Tanygin

Ну я тоже был скрам-мастер, и что? :) Это аргумент? У вас либо каша в голове, либо вы не очень четко выражаете свои мысли

В каскадной разработке, с клиентом общается аналитик до начала кодирования

А в Скраме общается PO, и что?

А клиент юзает первый раз программу когда всё уже закодированно.

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

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

еще раз, причем тут Agile? это может быть при любом нормально выстроенном процессе

Что и приводит к Customer satisfaction

к Customer satisfaction приводят прямые руки и нормальные процессы, а не bullshit бинго

Ответить
Развернуть ветку
Alexandre Svergoun

Похоже это у вас каша в голове про каскад.
В каскаде 7 фаз.
1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Воплощение
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка

каскадная модель подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.

То есть юзер получает готовую версию.

А вот здесь почитайте про Lean

Lean is a business methodology
Lean’s first applications outside of manufacturing appeared in software development, in a discipline known as Agile methodology. Conceptually, Agile software development is a Lean development methodology for optimizing the software development cycle

https://leankit.com/learn/lean/lean-methodology/

Ответить
Развернуть ветку
Alexandre Svergoun

Agile это гибкая. У нас на всех демо всегда были клиенты. И после каждой итерации они должны были потрать время на проверку и дать фидбак.

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

Непрерывная общение с заказчиком и поставка прототипов как раз таки называется Agile / Lean но не как не каскад.

Ответить
Развернуть ветку
Nikita Tanygin

Я не буду читать вашу ссылку после вашей же цитаты, в которой Agile называют методологией :)

То есть юзер получает готовую версию.

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

Ответить
Развернуть ветку
Ruslan Kopytov

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Ruslan Kopytov

Заказчиков может быть много. И их интересы могут конфликтовать.

Ответить
Развернуть ветку
Вячеслав Васильевич

Господа InfoShell, saas сервисы разрабатываете "под ключ"?

Ответить
Развернуть ветку
Dmitry Kotenko
Автор

Да, Вячеслав, разрабатываем. Напишите, пожалуйста, на почту [email protected] или сделайте запрос здесь: https://infoshell.ru

Ответить
Развернуть ветку
Dmitry Kotenko
Автор

Как мы можем связаться с вами?

Ответить
Развернуть ветку
Вячеслав Васильевич

Отписался на E-mail Кирилла.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Матин Таджиев

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

Ответить
Развернуть ветку
16 комментариев
Раскрывать всегда