В условиях высокой конкуренции важно концентрироваться на самом приоритетном. Конкуренты постоянно выпускают новые фичи. Их так много, что просто не хватает времени на их изучение. Клиенты в развитии продукта также играют важнейшую роль, предлагая улучшения, конструктивную критику и свежие советы. В общем, идеи растут «как снежный ком».
В любом продукте, скорее всего, хотят внедрять те функции, которые поднимут на новый уровень доходы, увеличат возвраты (retention) или виральность (virality).
Здорово, если вы уже внедрили какой-либо количественный фреймфорк, например, Pirate Metrics (AARRR). Он помогает сконцентрироваться на самых важных этапах вашей воронки продаж, а именно на AARRR (acquisition, activation, retention, referral, revenue).
Однако вернемся к большому скоплению идей и инициатив.
Итак, проблема следующая — у вас скопилось много идей из разных источников: из Intercom, Zendesk, Satismeter, из личных бесед с клиентами, от сотрудников. Вам становится все сложнее выбирать идеи для очередного спринта. Причем, цена ошибки очень высока: вы рискуете сделать такую фичу, которая будет невостребованная аудиторией и не принесет ожидаемых бенефитов. Например, она не увеличит конверсию в регистрацию или ARPD.
Backlog постоянно растет и управлять им становится все сложнее — менеджер продукта тратит много времени на его аудит, во время которого он просматривает идеи, расставляет приоритеты, выбрасывает то, что перестало быть актуальным. Каждый раз нужно мониторить все идеи. Самое время “перелопатить” известные техники приоритизации и найти свое решение.
Мы в Hygger.io предлагаем системное решение этой проблемы выбора. Решение состоит из трех основных блоков:
Как правило, Backlog — это обычный список. В Hygger бэклог — это двухмерная Kanban доска. Более того, пользователя предлагаются Labels (тэги) и Swimlanes. Этого более чем достаточно, чтобы структурировать ваш бэклог любого размера.
Например, колонками на этой Kanban доске могут быть этапы работы над идеями:
Это лишь пример процесса. Возможно, в вашей компании есть отдел проектирования и идею сначала надо спроектировать, написать ТЗ и лишь потом отправлять в разработку. Вы можете самостоятельно “подогнать” структуру доски под ваш процесс разработки.
Вместо процесса вы можете сделать в колонках релизы, чтобы распределить идеи. Кстати, Hygger умеет считать Capacity для колонок — чтобы вы могли равномерно распределять задачи по релизам.
С помощью Swimlanes вы можете разделить идеи. Например, так:
Лейблы можно использовать для чего угодно, например, для того, чтобы отметить идеи конкретных клиентов. Или идеи конкретных сотрудников. Или отметить особо важные идеи. Или отметить Сandies — мелкие фичи, которые делают продукт “вкуснее” для пользователей. Эти Сandies усилий практически не требуют, на скорость работы не влияют. Но замчая их, пользователи чувствуют заботу о них и больше доверяют.
Идеи упорядочены по полочкам, теперь можно приступать к их оценке. Оценка поможет вам в будущем сделать правильный выбор.
Оценить все идеи удобно с помощью двух критериев: Value или Impact и Effort.
Говоря абстрактным языком, Value — этот вклад, который идея или фича может дать в ваш продукт. Для корректной оценки вам нужно сначала понять, что вы хотите улучшать с помощью этой фичи.
Допустим, что вы внедрили Pirate Metrics (AARRR), тогда ваши цели могут быть такими:
В Hygger для оценки используются числа Фиббоначи и Planning poker (или Scrum Poker). Пользователям доступен набор карточек с такими значениями: ?, 0, ?, 1, 2, 3, 5, 8, 13, 20, 40.
Процесс оценки идей по Value в компании такой:
Efforts, как правило, оценивает человек, который имеет технические компетенции — это может быть менеджер проекта или менеджер продукта с опытом работы программистом. Оценка делается грубая, без привлечения программистов. На данном этапе привлекать программистов еще рано, потому что не все идеи дойдут до разработки. И есть опасность потратить время впустую.
Когда вы оценили все идеи, вы можете переходить к этапу выбора идей. Не обязательно делать это сразу после окончания оценки — иногда лучше взять паузу и дать идеям отлежаться. Вы можете получить новые данные, например, из внешней среды, которые могут повлиять на оценку Value или Efforts.
У нас в компании процесс пересмотра идей является постоянным и фоновым. Но мы это делаем на графике, а не на Kanban доске, потому что на графике самые важные идеи четко отделены от всякой ненужной мелочи. Вы можете пересматривать идеи от самых важных до ненужных, если вам позволяет время. Главное то, что важные идеи вы пересматриваете вначале, и на них у вас всегда найдется 5 минут.
Те идеи, которые вы оценили, вы можете увидеть на графике.
На графике есть две шкалы — Value и Efforts, а также 4 квадранта:
График удобен тем, что позволяет оценивать идеи друг относительно друга. Во время оценочной сессии идеи оцениваются, как правило, независимо друг от друга. Но когда мы начинаем сравнивать идеи, которые оценены одинаково, друг с другом, явно какая-то идея будет более полезной или менее трудозатратной. Исходя из этого, мы можем скорректировать оценки идеи, их Values или Efforts.
Итак, вы оценили идеи, отобрали с помощью графика самые полезные идеи, и теперь вы можете отправлять их в разработку — на Kanban доску или на Спринт-доску.
Подводя итог, кратко выделим главное:
А как у вас обстоят дела с приоритезацией? Ждем ваших комментариев и отзывов.
В любом продукте, скорее всего, хотят внедрять те функции, которые поднимут на новый уровень доходы, увеличат возвраты (retention) или виральность (virality).
Здорово, если вы уже внедрили какой-либо количественный фреймфорк, например, Pirate Metrics (AARRR). Он помогает сконцентрироваться на самых важных этапах вашей воронки продаж, а именно на AARRR (acquisition, activation, retention, referral, revenue).
Однако вернемся к большому скоплению идей и инициатив.
Определяем проблему
Итак, проблема следующая — у вас скопилось много идей из разных источников: из Intercom, Zendesk, Satismeter, из личных бесед с клиентами, от сотрудников. Вам становится все сложнее выбирать идеи для очередного спринта. Причем, цена ошибки очень высока: вы рискуете сделать такую фичу, которая будет невостребованная аудиторией и не принесет ожидаемых бенефитов. Например, она не увеличит конверсию в регистрацию или ARPD.
Backlog постоянно растет и управлять им становится все сложнее — менеджер продукта тратит много времени на его аудит, во время которого он просматривает идеи, расставляет приоритеты, выбрасывает то, что перестало быть актуальным. Каждый раз нужно мониторить все идеи. Самое время “перелопатить” известные техники приоритизации и найти свое решение.
Находим решение
Мы в Hygger.io предлагаем системное решение этой проблемы выбора. Решение состоит из трех основных блоков:
- Структурирование бэклога с помощью Kanban доски, тегов и Swimlanes.
- Оценка всех идей по двум критериям — Value и Effort.
- Выбор самых важных идей с помощью визуального инструмента Backlog Priority Chart.
Структурирование бэклога
Как правило, Backlog — это обычный список. В Hygger бэклог — это двухмерная Kanban доска. Более того, пользователя предлагаются Labels (тэги) и Swimlanes. Этого более чем достаточно, чтобы структурировать ваш бэклог любого размера.
Например, колонками на этой Kanban доске могут быть этапы работы над идеями:
- Collect Ideas — здесь вы собираете все идеи. Достаточного одного предложения или ключевого слова.
- Review Ideas — далее вы изучаете идеи, проясняете и детализируюте. Детально описывать каждую идею на старте не нужно, потому что не факт, что идея будет выбрана и пойдет в разработку.
- Score Ideas — на этом этапе вы оцениваете идеи (об этом чуть позже).
- Approval — здесь идею проверяет Scrum Master или менеджер проекта — достаточно ли подробно она описана, чтобы ее можно было отдавать в разработку.
- Developing — идея отправилась в разработку.
- Done — идея реализована и функция «залита» на продакшн.
Это лишь пример процесса. Возможно, в вашей компании есть отдел проектирования и идею сначала надо спроектировать, написать ТЗ и лишь потом отправлять в разработку. Вы можете самостоятельно “подогнать” структуру доски под ваш процесс разработки.
Вместо процесса вы можете сделать в колонках релизы, чтобы распределить идеи. Кстати, Hygger умеет считать Capacity для колонок — чтобы вы могли равномерно распределять задачи по релизам.
С помощью Swimlanes вы можете разделить идеи. Например, так:
- по компонентам системы (backend, frontend, API, mobile apps, и т.д.)
- по высокоуровневым сферам жизнедеятельности продукта (usability, new features, marketing, technical debts, и т.д..)
- по Pirate Metrics (acquisition, activation, retention, referral, revenue).
Лейблы можно использовать для чего угодно, например, для того, чтобы отметить идеи конкретных клиентов. Или идеи конкретных сотрудников. Или отметить особо важные идеи. Или отметить Сandies — мелкие фичи, которые делают продукт “вкуснее” для пользователей. Эти Сandies усилий практически не требуют, на скорость работы не влияют. Но замчая их, пользователи чувствуют заботу о них и больше доверяют.
Идеи упорядочены по полочкам, теперь можно приступать к их оценке. Оценка поможет вам в будущем сделать правильный выбор.
Оценка идей по Value и Effort
Оценить все идеи удобно с помощью двух критериев: Value или Impact и Effort.
Говоря абстрактным языком, Value — этот вклад, который идея или фича может дать в ваш продукт. Для корректной оценки вам нужно сначала понять, что вы хотите улучшать с помощью этой фичи.
Допустим, что вы внедрили Pirate Metrics (AARRR), тогда ваши цели могут быть такими:
- вы хотите поднять конверсию в регистрации (acquisition).
- вы хотите увеличить число пользователей, которые должны словить “aha” момент и стать лояльными пользователями вашего продукта (activation).
- вы хотите, чтобы ваши пользователи чаще приходили к вам и использовали какую-то фичу (retention).
- вы хотите увеличить число высылаемых приглашений (referral).
- вы хотите увеличить средний чек (revenue).
В Hygger для оценки используются числа Фиббоначи и Planning poker (или Scrum Poker). Пользователям доступен набор карточек с такими значениями: ?, 0, ?, 1, 2, 3, 5, 8, 13, 20, 40.
Процесс оценки идей по Value в компании такой:
- ведущий берет новую идею из очереди.
- далее команда вслух обсуждает эту идею, чтобы все понимали ее одинаково.
- далее каждый участник кладет оценку вверх рубашкой.
- ведущий вскрывает все карты и идет обсуждение оценок.
- участники, которые поставили максимальную и минимальную оценку поясняют, почему они поставили такую оценку.
- далее идет процесс обсуждения до тех пор, пока команда не придет к консенсусу. Часто мы используем таймер, чтобы повысить качество обсуждения.
Efforts, как правило, оценивает человек, который имеет технические компетенции — это может быть менеджер проекта или менеджер продукта с опытом работы программистом. Оценка делается грубая, без привлечения программистов. На данном этапе привлекать программистов еще рано, потому что не все идеи дойдут до разработки. И есть опасность потратить время впустую.
Когда вы оценили все идеи, вы можете переходить к этапу выбора идей. Не обязательно делать это сразу после окончания оценки — иногда лучше взять паузу и дать идеям отлежаться. Вы можете получить новые данные, например, из внешней среды, которые могут повлиять на оценку Value или Efforts.
У нас в компании процесс пересмотра идей является постоянным и фоновым. Но мы это делаем на графике, а не на Kanban доске, потому что на графике самые важные идеи четко отделены от всякой ненужной мелочи. Вы можете пересматривать идеи от самых важных до ненужных, если вам позволяет время. Главное то, что важные идеи вы пересматриваете вначале, и на них у вас всегда найдется 5 минут.
Выбор идей с помощью визуального инструмента Backlog Priority Chart
Те идеи, которые вы оценили, вы можете увидеть на графике.
На графике есть две шкалы — Value и Efforts, а также 4 квадранта:
- Quick Wins – идеи с высоким Value и низким Efforts. Это очень полезные фичи, которые легко сделать. Эти задачи лучше делать в первую очередь. Быстро сделали — быстро получили результат.
- Big Bets – идеи с высоким Value и Efforts. Задачи, которые настолько полезные, насколько и сложные/длительные в реализации. Эти задачи можно делать во вторую очередь. Делать их придется дольше чем Quick Wins, но зато польза от них будет такая же большая.
- Maybes – идеи с низким Value и Efforts. Задачи, которые не дают особой пользы, но их можно легко сделать. Такие идеи лучше отложить в долгий ящик.
- Time Sinks – идеи с низкой полезностью, но с высокими трудозатратами. О таких идеях лучше вообще забыть.
График удобен тем, что позволяет оценивать идеи друг относительно друга. Во время оценочной сессии идеи оцениваются, как правило, независимо друг от друга. Но когда мы начинаем сравнивать идеи, которые оценены одинаково, друг с другом, явно какая-то идея будет более полезной или менее трудозатратной. Исходя из этого, мы можем скорректировать оценки идеи, их Values или Efforts.
Итак, вы оценили идеи, отобрали с помощью графика самые полезные идеи, и теперь вы можете отправлять их в разработку — на Kanban доску или на Спринт-доску.
Заключение
Подводя итог, кратко выделим главное:
- В структурировании бэклога двумерные Kanban доски значительно облегчают жизнь. С помощью Swimlanes удобно разделять идеи по разным параметрам, после чего можно приступать к оценке идей.
- В Hygger оценить идей можно с помощью критериев Value и Effort.
- Инструмент Backlog Priority Chart завершает процесс выбора идей, визуализируя их на удобном графике с двумя шкалы и четырьмя квадрантами приоритезации.
А как у вас обстоят дела с приоритезацией? Ждем ваших комментариев и отзывов.
strongholda
C точки зрения бизнеса приоритеты мы расставляем так:
Влияние на стороны:
1. На Клиента (какие выгоды продукт принесет Клиенту).
2. На бизнес (значимость для бизнеса).
3. На общество (значимость для экосистемы).
Влияние на результат:
1. Прибыльность (принесет ли прибыль?).
2. Стратегическая важность (Политически или социально Стратегически важный или нет?).
3. Эффективность (Улучшит ли эффективность деятельности).
Зачастую львиная доля проектов является улучшением эффективности.
А стратегически важных проектов может быть немного.
Бизнесу интересна в первую очередь прибыльность.
Исполнителям важна эффективность.
Договориться со всеми сторонами о приоритетах и убедить их — задача ПМа.
Pavel_Ku Автор
Спасибо, что поделились опытом.