[Управление проектами] Приоритизация фичей
Автор
Сообщение
news_bot ®
Стаж: 6 лет 3 месяца
Сообщений: 27286
Мы как продукт менеджеры, генерируем неисчисляемое количество идей. Каким-то образом у себя в голове их приоритизируем. Голова лопается, мы не знаем, что делать с этими идеями. В вашем “листе идей” какой-то ад творится… Особенно это знакомо людям которые только начинают свой путь в бизнесе, или же только начинают свой путь продуктами.
Эта статья поможет быстро (на пальцах) откинуть из сотни фичей большую часть. И оставить только те, которые действительно принесут бизнесу пользу.
Для начала рассмотрим переменную таблицу методов приоритизаций:
Исходя из данной таблицы, можно сделать вывод.
По горизонтали есть внутренние методы приоритизации, которые решаются в рамках компании — команды.
Если же принимают участие пользователи, то соответственно это внешние.
По вертикали, то сколько данных есть для принятия решений.
Качественные когда вы делаете глубинные интервью от десятков респондентов. И количественные, когда имеется много разных аналитических данных.
Внешние методы применяются:
Когда продукт только вышел в свет, и мы пока не понимаем глубинных потребностей потребителя.
Когда внутри компании есть ключевые подразделения которые принимают решения (аналитика, маркетинг, сейлзы, стейкхолдеры).
Внутренние методы применяются:
Когда есть история какая функциональность меняет метрики, можно сделать приоритизация внутри команды.
Уточнение результатов полученных из внешних методов;
Мы рассмотрели основные различия внутренних и внешних методов.
Далее мы рассмотрим такие методы приоритизации как быстрая (на пальцах) и медленная.
Быстрая позволяет откинуть наиболее не ценные функции, а медленная помогает выбрать из оставшихся самые лучшие.
Быстрые методы
Метод Reach/Frequency
Reach — охват аудитории. Сколько людей готовы воспользоваться фичей.
Frequency — частота использования фичи.
В идеале нам нужен верхний правый угол. Те кто все время пользуется и вся аудитория.
Метод Poker planning
Идея взята из Agile методологий. (Оценка производится внутри команды.)
Оценка пользы фичи
Команде ставится условие: 1 палец — фича не очень, 2 пальца — фича норм, 3 пальца — фича просто бомба.
Вы произносите фичу и на счет “раз, два, три”, члены команды поднимают пальцы. Считаете средний балл. (Можете приглашать внешних людей из других проектов).
Оценка затрат
Собираем разработчиков, говорим про функционал и так же ставим условие: 1 палец — быстро сделают. 2 пальца — разработка будет не сложной. 3 пальца — разработка будет очень сложной и долгой.
Далее мы делим пользу на затраты и получаем приблизительную оценку функциональности.
Фича 4 имеет самый высокий процент, значит точно будет вверху таблицы приоритизаций. Фича 2 имеет самый низкий процент — мы точно выкидываем из нашего бэклога.
Медленные методы
RICE
Разработан компанией intercom.
Это такой метод приоритезации идей и фич продукта, который включает 4 фактора, которые менеджер продукта использует для оценки и приоритизации фич:
Reach — охват аудитории. Не забываем, что охват именно тех людей, которые увидят эту фичу.
Impact — влияние фичи на пользователя. Его радость, бусты, эмоции от данной фичи. (0.25 — очень плохо, 0.5 — плохо, 1 — средне, 2 — хорошо, 3 — отлично)
*** Некоторые считают что impact — это именно влияние фичи на компанию. То есть какое количество метрик мы подымем при помощи этой фичи.
Confidence — Уверенность в гипотезе. Довольно важный параметр, показывающий на сколько вы считаете хороша ли гипотеза, т.к мы не всегда придумываем супер-топ идеи. ( Высокая = 100%, средняя = 80%, слабая = 50% и ниже)
Effort — Сложность разработки. Обычно указывается в месяцах. (пол месяца 0.5)
Приоритизация по ROI
Изначально Вам нужно сделать иерархию метрик. Если Ваш продукт не Amazon и не google, более чем достаточно будет сделать древовидную систему. Что из чего происходит. Например Life time Value напрямую зависит от Retention. Отлично! Этого будет достаточно для интернет магазина. Далее по аналогии в зависимости от масштабов продукта, можно использовать аналитические данные и делать формулы.
Очень удобно когда есть идея, знать на какую метрику она повлияет. И понимать на каком уровне дерева находится. И чем будет придуманная фича ближе к главной метрике, тем профитнее она. Чем дальше, соответственно шансов почти нет, что она повлияет на главную метрику.
Пример приоритизаций из иерархии метрик
С командой мы расставляем “вес” фичи, на сколько кто в нее верит. + ставится на те которые выбирает большинство. На них можно делать основной акцент на ближайшие пол года.
Пример приоритизации по ROI
У нас есть количество пользователей за год. Мы делаем прогноз, что воспользуются продуктом 70%, а приобретут продукт 50% от пользователей.
Я прикидываю, что внедрение фичи принесет компании 4% от прибыли.
Зная сколько у нас прибыль от одной оплаты, не сложными расчетыми мы получаем сумму которую наша фича принесет за год дополнительно.
Далее мы идем к разработчикам и понимаем сколько будет длиться разработку. Переводим все в челвоека часы и получаем стоимость разработки.
Имея эти данные мы можем посчитать ROI ((доходы — расходы) / расходы * 100%) фичи.
Таким образом, мы можем посчитать все фичи из бэклога и приоритизировать его.
*** Так же можно сделать более детальную проработку таблицы с Реальными % конверсии, пессимистичными и оптимистичными.
Плюсы:
Ты получаешь оценку в деньгах. Люди любят деньги.
Люди верят числам.
Минусы:
Не учитываются абсолютные значения
Многое зависит от личных скилов продакт менеджера.
Мелкие фичи не понятно как считать.
Нюансы:
Считать прибыль, а не выручку.
Типичные ошибки Product manager’ов
1. Оценивать в одиночку.
Всегда просите, чтобы ваши расчеты кто нибудь проверил. Свежий взгляд всегда хорошо;
2. Не учитывают влияние одной части на другие части продукта.
Очень важно думать как вся экосистема работает, чтобы не проседали другие части продукта;
3. Повестись на хейтеров.
Всегда есть хейтеры которые пользуются продуктом, но всегда чем то не довольны. Главное не путать между обычными хейтерами и людьми которые хотят помочь продукту. Делать исследования глубже;
4. Количественная оценка не всегда лучше, чем качественная.
Если продукт новый, или не большой, лучше всего общаться со своей аудиторий и понимать ее глубинные потребности.
5. Закопаться в мелочах. Смотрите на продукт сверху!
Итог
Подводя итог могу сказать, что та система приоритизации, которая работает в Яндексе, вряд ли будет работать, если вы захотите ее применить для стартапа, в котором работает четыре человека.
Компании разные, у них разные цели, разные задачи, разное позиционирование и положение на рынке — кто-то еле сводит концы с концами и важно заработать денег буквально завтра, иначе стартапу конец, а кому-то деньги уже не так важны в сравнении с положением на рынке или репутацией, у кого-то есть деньги на масштабирование и главной задачей является привлечение новых пользователей, а кто-то не может масштабироваться из-за ограничений инфраструктуры и хочет сократить круг пользователей, но зарабатывать больше денег с существующих. В общем, не все так просто.
Спасибо за уделенное время.
===========
Источник:
habr.com
===========
Похожие новости:
- [Экология, Энергия и элементы питания, Будущее здесь, Управление проектами] Солнечный портфель компании TOTAL
- [Локализация продуктов, Управление продуктом, Управление проектами] 15 советов: Локализация сервисов под разные страны
- [Управление разработкой, Управление проектами, Agile, Управление продуктом] Как гибкие методы разработки помогают создавать стратегию для бизнеса
- [Управление проектами, Управление персоналом, Карьера в IT-индустрии] Осмысленность работы и эффективность
- [IT-компании, IT-стандарты, Управление продуктом, Управление проектами] Методологический скачок: от таблиц-портянок к понятному каталогу услуг в ITSM-системе
- [Управление проектами, Удалённая работа, Программирование, Лайфхаки для гиков] Один день удаленного тимлида на бэкенде
- [Управление проектами, Учебный процесс в IT, Управление персоналом, Карьера в IT-индустрии] Без эйчаров, интервью и спешки: как нанимают системных администраторов в Southbridge
- [API, Управление проектами, Управление продажами, Управление персоналом] Как я сделал бота, который контролирует моих сотрудников, следит за моими тренировками, весом и чтением книг
- [Управление разработкой, Управление проектами, Управление продуктом, Управление персоналом] Два «вечных» подхода к управлению собственным бизнесом
- [CRM-системы, Управление проектами] Как работает администратор зубоврачебной клиники — и как должен
Теги для поиска: #_upravlenie_proektami (Управление проектами), #_backlog, #_product_management, #_upravlenie_proektami (
Управление проектами
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 17-Май 17:04
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 3 месяца |
|
|
Мы как продукт менеджеры, генерируем неисчисляемое количество идей. Каким-то образом у себя в голове их приоритизируем. Голова лопается, мы не знаем, что делать с этими идеями. В вашем “листе идей” какой-то ад творится… Особенно это знакомо людям которые только начинают свой путь в бизнесе, или же только начинают свой путь продуктами. Эта статья поможет быстро (на пальцах) откинуть из сотни фичей большую часть. И оставить только те, которые действительно принесут бизнесу пользу. Для начала рассмотрим переменную таблицу методов приоритизаций:  Исходя из данной таблицы, можно сделать вывод. По горизонтали есть внутренние методы приоритизации, которые решаются в рамках компании — команды. Если же принимают участие пользователи, то соответственно это внешние. По вертикали, то сколько данных есть для принятия решений. Качественные когда вы делаете глубинные интервью от десятков респондентов. И количественные, когда имеется много разных аналитических данных. Внешние методы применяются: Когда продукт только вышел в свет, и мы пока не понимаем глубинных потребностей потребителя. Когда внутри компании есть ключевые подразделения которые принимают решения (аналитика, маркетинг, сейлзы, стейкхолдеры). Внутренние методы применяются: Когда есть история какая функциональность меняет метрики, можно сделать приоритизация внутри команды. Уточнение результатов полученных из внешних методов; Мы рассмотрели основные различия внутренних и внешних методов. Далее мы рассмотрим такие методы приоритизации как быстрая (на пальцах) и медленная. Быстрая позволяет откинуть наиболее не ценные функции, а медленная помогает выбрать из оставшихся самые лучшие. Быстрые методы Метод Reach/Frequency Reach — охват аудитории. Сколько людей готовы воспользоваться фичей. Frequency — частота использования фичи.  В идеале нам нужен верхний правый угол. Те кто все время пользуется и вся аудитория. Метод Poker planning Идея взята из Agile методологий. (Оценка производится внутри команды.) Оценка пользы фичи Команде ставится условие: 1 палец — фича не очень, 2 пальца — фича норм, 3 пальца — фича просто бомба. Вы произносите фичу и на счет “раз, два, три”, члены команды поднимают пальцы. Считаете средний балл. (Можете приглашать внешних людей из других проектов). Оценка затрат Собираем разработчиков, говорим про функционал и так же ставим условие: 1 палец — быстро сделают. 2 пальца — разработка будет не сложной. 3 пальца — разработка будет очень сложной и долгой. Далее мы делим пользу на затраты и получаем приблизительную оценку функциональности.  Фича 4 имеет самый высокий процент, значит точно будет вверху таблицы приоритизаций. Фича 2 имеет самый низкий процент — мы точно выкидываем из нашего бэклога. Медленные методы RICE Разработан компанией intercom. Это такой метод приоритезации идей и фич продукта, который включает 4 фактора, которые менеджер продукта использует для оценки и приоритизации фич:  Reach — охват аудитории. Не забываем, что охват именно тех людей, которые увидят эту фичу. Impact — влияние фичи на пользователя. Его радость, бусты, эмоции от данной фичи. (0.25 — очень плохо, 0.5 — плохо, 1 — средне, 2 — хорошо, 3 — отлично) *** Некоторые считают что impact — это именно влияние фичи на компанию. То есть какое количество метрик мы подымем при помощи этой фичи. Confidence — Уверенность в гипотезе. Довольно важный параметр, показывающий на сколько вы считаете хороша ли гипотеза, т.к мы не всегда придумываем супер-топ идеи. ( Высокая = 100%, средняя = 80%, слабая = 50% и ниже) Effort — Сложность разработки. Обычно указывается в месяцах. (пол месяца 0.5) Приоритизация по ROI Изначально Вам нужно сделать иерархию метрик. Если Ваш продукт не Amazon и не google, более чем достаточно будет сделать древовидную систему. Что из чего происходит. Например Life time Value напрямую зависит от Retention. Отлично! Этого будет достаточно для интернет магазина. Далее по аналогии в зависимости от масштабов продукта, можно использовать аналитические данные и делать формулы.  Очень удобно когда есть идея, знать на какую метрику она повлияет. И понимать на каком уровне дерева находится. И чем будет придуманная фича ближе к главной метрике, тем профитнее она. Чем дальше, соответственно шансов почти нет, что она повлияет на главную метрику. Пример приоритизаций из иерархии метрик  С командой мы расставляем “вес” фичи, на сколько кто в нее верит. + ставится на те которые выбирает большинство. На них можно делать основной акцент на ближайшие пол года. Пример приоритизации по ROI  У нас есть количество пользователей за год. Мы делаем прогноз, что воспользуются продуктом 70%, а приобретут продукт 50% от пользователей. Я прикидываю, что внедрение фичи принесет компании 4% от прибыли. Зная сколько у нас прибыль от одной оплаты, не сложными расчетыми мы получаем сумму которую наша фича принесет за год дополнительно. Далее мы идем к разработчикам и понимаем сколько будет длиться разработку. Переводим все в челвоека часы и получаем стоимость разработки. Имея эти данные мы можем посчитать ROI ((доходы — расходы) / расходы * 100%) фичи. Таким образом, мы можем посчитать все фичи из бэклога и приоритизировать его. *** Так же можно сделать более детальную проработку таблицы с Реальными % конверсии, пессимистичными и оптимистичными. Плюсы: Ты получаешь оценку в деньгах. Люди любят деньги. Люди верят числам. Минусы: Не учитываются абсолютные значения Многое зависит от личных скилов продакт менеджера. Мелкие фичи не понятно как считать. Нюансы: Считать прибыль, а не выручку. Типичные ошибки Product manager’ов 1. Оценивать в одиночку. Всегда просите, чтобы ваши расчеты кто нибудь проверил. Свежий взгляд всегда хорошо; 2. Не учитывают влияние одной части на другие части продукта. Очень важно думать как вся экосистема работает, чтобы не проседали другие части продукта; 3. Повестись на хейтеров. Всегда есть хейтеры которые пользуются продуктом, но всегда чем то не довольны. Главное не путать между обычными хейтерами и людьми которые хотят помочь продукту. Делать исследования глубже; 4. Количественная оценка не всегда лучше, чем качественная. Если продукт новый, или не большой, лучше всего общаться со своей аудиторий и понимать ее глубинные потребности. 5. Закопаться в мелочах. Смотрите на продукт сверху! Итог Подводя итог могу сказать, что та система приоритизации, которая работает в Яндексе, вряд ли будет работать, если вы захотите ее применить для стартапа, в котором работает четыре человека. Компании разные, у них разные цели, разные задачи, разное позиционирование и положение на рынке — кто-то еле сводит концы с концами и важно заработать денег буквально завтра, иначе стартапу конец, а кому-то деньги уже не так важны в сравнении с положением на рынке или репутацией, у кого-то есть деньги на масштабирование и главной задачей является привлечение новых пользователей, а кто-то не может масштабироваться из-за ограничений инфраструктуры и хочет сократить круг пользователей, но зарабатывать больше денег с существующих. В общем, не все так просто. Спасибо за уделенное время. =========== Источник: habr.com =========== Похожие новости:
Управление проектами ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 17-Май 17:04
Часовой пояс: UTC + 5