Po это кто в бизнесе

3630 просмотров

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

Об участниках
Project manager (PM) — менеджер проекта
Задачи менеджеров проекта

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

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

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

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

Product manager (PdM) — менеджер продукта
Задачи менеджеров продукта

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

ПРЕДПРИНИМАТЕЛЬСТВО ЭТО #бизнес #мышление #психология #деньги #предприниматель

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

3. Менеджеры продукта выполняют в среднем на 2 типа задач больше, чем проектные менеджеры.

4. Что нравится менеджерам продукта: возможность принимать участие в продукте с растущей аудиторией, рост метрик и команды, ответственность за продукт, разнообразие задач, предметная область, развитие, комфортная нагрузка, начальник.

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

Product owner (PO) — владелец продукта
Задачи владельцев продукта

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

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

  • product owner “вырастает” из product manager, при этом продуктовые задачи от него не уходят, а проектные добавляются;
  • недостаточное понимание роли владельца продукта в компании, нет распределения обязанностей между членами команды;
  • небольшая компания или проект — один человек справляется со всеми обязанностями в рамках команды;
  • владельцем продукта называют руководителя, а в командах в его подчинении присутствуют выделенные менеджеры продуктов и менеджеры проектов.

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

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

Пример, как уйти от ЦЕНОВОЙ КОНКУРЕНЦИИ и получить ЭКСКЛЮЗИВ в товарном бизнесе? Развитие бизнеса.

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

6. Что не нравится владельцам продукта: отсутствие большого количества hard skills: не используем ни python, ни sql, не проводим custdev, не составляем cjm, описание задач и контроль постановки задач, навязывание необоснованных задач, смешение методологий и микроменеджмент, не хватает рук.

Источник: vc.ru

Product owner в банке – кто это и что он умеет

Product owner в банке – кто это и что он умеет

2017-11-21 в 9:35, admin , рубрики: agile, product owner, Альфа-Банк, Блог компании «Альфа-Банк», управление персоналом, Управление продуктом, управление разработкой

Продакт оунер. Владелец продукта. Продуктолог. PO.

Product owner в банке – кто это и что он умеет - 1

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

О том, кто такой продакт в понимании Альфа-Банка, что это за человек, что он умеет делать и как относится к своей команде, нам рассказал VDavydov Владимир Давыдов, руководитель по развитию цифровых каналов и продуктов Блока “Массовый бизнес”

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

Во всем.

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

Вот кто такой продакт и какими компетенциями он должен обладать:

Читайте также:  Производство кружек как бизнес

Product owner в банке – кто это и что он умеет - 2

(кликабельно)

Качества продакта

Профессиональные навыки и умения product owner’a тесно связаны с циклом создания продукта.

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

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

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

— Формирование и проверка гипотезы. Логичным итогом какого-либо исследования является набор продуктовых гипотез. А что надо делать с гипотезами? Правильно – проверять. Быстро, с пониманием критериев успеха.

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

— Работа с командой. Создание продукта. Мы тут все agile-евангелисты и выбрали для себя фреймворк скрама как, на наш взгляд, самую эффективную методологию, позволяющую быстро доставлять ценность до потребителей. Поэтому у нас достаточно стандартный набор артефактов — dsm, pbr, sprint planing, demo, retro…

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

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

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

Например, для ТОП-менеджеров ожидания будут про конкретный Value для бизнеса – скажите об этом Value и рассказывайте на постоянной основе о прогрессе.

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

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

Ответственность продакта

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

Сейчас мы пропагандируем именно такой подход — это очередной виток эволюции. Мы прошли довольно большой путь в формировании продуктового института (Альфа-Банк первым в России начал применять гибкие методологии разработки Agile, прим. редакции).

Цифра VS Банк

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

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

Читайте также:  Захват бизнеса это в истории

Цели

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

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

Это вопрос ответственности.

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

Если клиент не нашел какую-то кнопку (или она неудобно расположена) — это проблема дизайнера, его зона ответственности.

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

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

Черный список качеств

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

— Отношение к своей команде как к рабочей силе, как к ресурсу

Продакты в Альфа-Банке — люди, формирующие каждый свою команду спецназа. Команду людей, где каждый готов прикрыть друг друга. Это именно команда, а не шестеренки в механизме.

— Не видит разницы между лидером и руководителем

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

— Не разделяет рабочую культуру

Это важно. Мы стараемся подбирать людей так, чтобы уровень рабочей культуры у них был примерно один. Чтобы им было комфортно работать друг с другом. Если тебе дискомфортно работать с коллегами, общаться с ними и вообще приходить в офис — работать будет, прямо скажем, сложно.

— Отсутствие логического мышления

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

Если это не про него, значит, он не очень понимает, что делает, зачем и как — это тупик.

Продакты в Альфе

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

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

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

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

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

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

На сегодняшний день у меня около десятка продактов, у каждого из них — по паре команд.

Но завтра таких человек может стать 20. Мы большой банк, у нас много продуктов и мы всегда смотрим в будущее. Вакансии PO открыты и сейчас, если вам близки наши подходы и вы хотите попробовать себя в роли продакта – дерзайте.

Читайте также:  Какие виды бизнеса плана

Источник: www.pvsm.ru

Product Owner: что должен уметь?

Product Owner: что должен уметь?

Product Owner (далее PO) – это необходимая роль в команде гибкой разработки digital-продукта. Гибкий подход (Agile) принципиально отличается от традиционного (waterfall). Здесь главная оценка – работающий продукт, промежуточный результат, а устные договоренности и потребности заказчика важнее, чем техническое задание.

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

И ВСЕ-ТАКИ ЧТО ЖЕ НУЖНО УМЕТЬ?

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

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

Чтобы проектная команда придерживалась установленного видения, РО составляет дорожную карту продукта (roadmap) – краткосрочный или долгосрочный план выполнения, изменения и развития проекта.

Составлять и управлять бэклогом продукта

Бэклог – это список фич и задач для разработчиков, который может меняться в зависимости от потребностей проекта. Изменять бэклог может как РО, так и разработчик.

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

Описание работы фич также лежит на РО.

Создавать визуальные прототипы

Умение быстро создать приблизительный интерфейс приложения, сайта или веб-сервиса – еще один навык, необходимый для PO. Он должен смоделировать поведение пользователя и создать прототип в соответствии с ним. Для этого необходимы знания и опыт User Experience/User Interface (UX/UI).

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

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

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

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

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

Разрабатывать модель монетизации

РО должен сделать так, чтобы продукт приносил доход. Необходимо уметь просчитывать юнит-экономику (заработок бизнеса с потока пользователей), чтобы продукт не приносил убытков, анализировать и улучшать LTV (LifeTime Value) – прибыль от одного пользователя за все время сотрудничества, а также общий Revenue (доход).

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

Эффективно общаться с заказчиком и командой разработки

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

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

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

Рейтинг
( Пока оценок нет )
Загрузка ...
Бизнес для женщин