Как стать гуру в определении приоритетов?

Десятки методов, как выбрать один?

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

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

«Смысл не в том, чтобы приоритизировать то, что в вашем плане, а в том, чтобы спланировать ваши приоритеты». Стефан Кови

С чего начинается качественная приоритизация?

Даже без методов и технологий можно освоить базовые рекомендации по планированию:

• Начните с главного - определите ценности. Даже на интуитивном уровне можно понять, какая задача принесет больше пользы, а какая нет.
• Составляйте списки. Это займет несколько минут за утренним кофе, зато поможет организовать целый день. Выгружайте мысли из головы на бумагу.
• Будьте гибкими. Стоит всегда быть готовыми к смене приоритетов по независящим от вас факторам.
• Не забывайте о менее приоритетных задачах. Однажды они могут стать приоритетными.
• Ставьте реальные цели. В этом помогают специальные методологии, например, установка SMART-целей. По ней, любая качественная цель должна быть: Specific – конкретная, Measurable - измеримая, Achievable – достижимая, Relevant/ realistic – актуальная и реальная, Time-bound – ограничена во времени.

Это может выглядеть так (на примере целей, поставленных для оптимизации блога):

Specific/ Конкретная цель

Неверно: Хотелось, бы чтоб статьи блога репостили в соцсетях.

Верно: Все продуктовые статьи блога должна быть расшарены в Facebook и Twitter.

Measurable/ Измеримая цель

Неверно: На следующей неделе мы добавим в блог некоторые плагины.

Верно: На следующей неделе мы добавим 3 крутых плагина в админку блога: а, б, с.

Achievable/ Достижимая цель

Неверно: В следующем месяце мы увеличим процент открытия статей на 20%, через 2 месяца –на 40%.

Верно: В следующем месяце процент открытия статей увеличится на 3-4% по сравнению с предыдущим.

Relevant/ realistic/ Реальная цель

Неверно: Через 2 месяца наш блог станет самым популярным в отрасли.

Верно: Через 2 месяца число подписчиков блога увеличится на 5%.

Time bound/ Цель отслеживаемая, с временными рамками

Неверно: Нужно увеличить число лонг-ридов в следующем квартале.

Верно: К 1 марта число лонг-ридов в блоге должно составлять 5-6 в месяц.

Когда я работал над этим материалом, в Quora мне написал Trevor Andrews, автор книги «Мифы Тайм Менеджмента». Преподаватель университета из Британии с более чем 10-летним опытом работы и исследований поделился интересными мыслями, касательно приоритизации:

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

В процессе написания своей книги, я пришел к нескольким интересным выводам, связанным с определением приоритетов:

• Формальный подход к определению приоритетов, составление списка и распределение задач, типа a, b, c и т. д., требует больше вашего драгоценного времени в управлении им и обеспечивает стресс.
• Люди с ленивым укладом только делают то, что нужно сделать, не «распыляясь» на постороннее и часто более эффективны в делах, чем люди, которые проактивны и трудолюбивы».

Такие выводы имеют место быть. Но все популярные методологии и техники были разработаны на основе детальных исследований и много раз доказывали свою эффективность. Обратимся к ним.

Модель Кано

Свою разработку японский исследователь Noriaki Kano опубликовал в 1984 году в статье, где было много идей для определения удовлетворенности клиентов функциями продукта. Эти идеи обычно называют моделью Кано или «Теорией привлекательного качества».

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

Теория основана на следующих предпосылках:

1. Удовлетворенность клиентов функциями продукта зависит от уровня предоставляемой функциональности (насколько хорошо они реализованы).
2. Функции могут подразделяться на категории, в зависимости от того, как клиенты реагируют на предоставленный уровень функциональности.
3. Вы можете определить, как клиенты относятся к какой-либо функции через анкетирование.

Кано выделяет 3 основные составляющие профиля качества:

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

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

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

Метод приоритизации MoSCoW

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

Название методологии - акроним, где каждая согласная буква определяет категорию приоритета:

M – Must - требования, которые имеют решающее значение и должны быть первоочередно применимы к продукту. Если даже одно из них не учтено, релиз считается невыполненным.

S – Should - требования важны, но не имеют решающего значения для релиза. Такие требования не сильно чувствительны к времени.

C - Could - желательные, но необязательные для релиза требования. Обычно это малозатратные усовершенствования для продукта.

W - Would - считаются наименее критичными или могут вовсе не соответствовать стратегии продукта. Они могут быть легко проигнорированы и быть пересмотрены для будущих релизов.

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

Методология Story Mapping

Метод отображения истории был впервые описан в статье Джеффа Паттона в начале 2000х, в ней он рассказал про свой опыт.

Основная идея Story Mapping заключается в том, что бэклога в продукте недостаточно для организации и расставления приоритетов в работе. Необходима более развернутая структура.

В общих чертах, метод Story Mapping организован следующим образом:

Есть горизонтальная ось, представляющая последовательность использования. Истории пользователей (или задачи) размещаются вдоль этой оси в последовательности, в которой они выполняются пользователем.

Есть вертикальная ось, которая означает критичность. Задачи располагаются по вертикали относительно того, насколько они важны (сверху вниз). Одинаково важные задачи можно сохранять на одной высоте.

Группы связанных историй пользователей могут быть сгруппированы как «Действия/ активности»:

• Создайте вертикальную линию для разделения групп задач от других.
• Например, действием может быть «управление почтой», при этом «отправить электронное письмо на один или несколько адресов» является пользовательской задачей.
• Действия располагаются над вертикальной осью и не имеют какой-либо последовательности. Они просто есть и не могут быть приоритетными или нет.

У этого метода структурирования бэклога много преимуществ, но самые главные для приоритезации следующие:

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

Игровая технология "Быстрая лодка"

Этот игровой метод фокусируется на обратном аспекте приоритизации - определении наименее приоритетных функций продукта.

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

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

Происходит это так:

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

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

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

Так игровой метод визуализации рассматривает групповой подход и предполагает возможность «делиться своими жалобами».

Методология KJ

Метод Jiro Kawakita часто используют в project/ product менеджменте в качестве группового процесса для установления приоритетов. Он быстро помогает прийти к объективному групповому согласию из ряда субъективных данных.

Основное внимание в концепции уделяется заинтересованным сторонам в рамках одной организации.

Это 8-ступенчатый процесс для групп любого размера, рассчитанный на промежуток времени около часа. Сперва следует обеспечить следующие требования:

• Много стикеров нескольких цветов.
• Комнату с просторной стеной.
• Наличие управляющего процессом/ ведущего.
• Флип-чарт или доску для результатов приоритезации.

Если все соблюдено, можно начинать поэтапно:

1. Определение фокусного вопроса. Фокусный вопрос стимулирует результаты. У каждого сеанса будет свой собственный фокусный вопрос (например, «кто наши пользователи?», «какие цели у пользователей, когда они скачивают приложение?» и т. д.)
2. Организация Группы. Люди в группе должны быть из разных структур компании, чтобы получить более разнообразные перспективы.
3. Выгрузка мнений/ данных на стикеры по одному пункту на каждом. Каждому участнику группы предлагается провести мозговой штурм по разным направлениям.
4. Размещение стикеров на стенке. Каждый участник располагает их в рандомном порядке. Они могут смотреть на стикеры других участников и, при необходимости, добавлять новые.
5. Группировка похожих тематик. Когда все добавили свои стикеры на стену, группа начинает группировать похожие темы в другой части комнаты.
6. Присвоение имени. Каждому участнику предлагается присвоить имя каждой группе, используя стикеры другого цвета.
7. Голосование за наиболее важные группы Участникам предлагается использовать свою точку зрения, чтобы выбрать, какие группы, по их мнению, наиболее важны для ответа на фокусный вопрос.
8. Оценка наиболее важных групп. Это последний и самый важный шаг. Все индивидуальные стикеры помещаются на доске и располагаются по количеству голосов. Участники могут объединять подобные группы, что добавляет их голоса и поднимает их рейтинг. Когда три-четыре группы уже четко "отрываются" по рейтингу, активность может быть закончена.

Метод определения приоритетов Feature Buckets

Технология определения приоритетов, которую предложил Адам Нэш также очень популярна и проста.

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

Концепции функций нужно разместить в одном из четырех ведер(воображаемых или реальных):

• Metrics Мovers ("Двигатели" показателей) - функции, которые значительно изменят целевые показатели бизнеса и продукта. Должны быть конкретные цели и стратегии решения инвестировать в продукт или функцию (здесь можно применять такие показатели, как ААРРР (Pirate Metrics).
• Customer Requests (Запросы клиентов) - это функции, которые были запрошены непосредственно клиентами. Они обычно являются дополнительными улучшениями, но их всегда важно учитывать, как любую важную обратную связь, связанную с использованием продукта.
• Delight (Функции удовольствия) - функции, которые создаются внутри компании на основе понимания дизайна или технологии. Работа над неожиданными функциями важна для удивления клиентов и достижения отдельного положения на рынке.
• Strategic (Стратегические) - функции, которые включены по стратегическим причинам, связанным с будущими целями (например, экспериментирование и сбор данных).

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

Инструменты для определения приоритетов

Для больших и маленьких продуктовых команд придуманы инструменты и сервисы, которые облегчают планирование и помогают приоритезировать задачи быстро и просто. Один из них - Backlog Priority Chart, который предлагает полноценная платформа для product менеджеров Hygger.io.

Ни одна ваша идея не потеряется на этом графике, а удобная система оценки Value & Efforts и 4 квадранты помогут систематизировать их с помощью критериев:

• Quick Wins – для идей первоочередного порядка.
• Big Bets – для идей с высоким приоритетом, но которые могут быть выполнены после Quick Wins.
• Maybes – идеи с меньшей ценностью и срочностью, их можно отложить.
• Time sinks – о таких идеях лучше вовсе забыть.

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

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