6 лучших фреймворков для приоритизации задач по Agile

Расписываем шесть методик для команды, которые помогут оценить важность и сложность задач в цифровых продуктах — и не только

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

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

Так происходит плюс-минус всегда. И без приоритизации работать не получится, потому что реализовать всё разом нельзя. Здесь команде (или командам) приходится синхронизироваться и учиться задавать правильные вопросы.

❌ «Это хорошая идея или плохая?»

✔️ «В какой последовательности нужно реализовать идеи, чтобы принести максимальную пользу клиентам и бизнесу?»

Тут пригодятся шесть методов определения приоритетов — они помогут нащупать правильные ответы на правильные вопросы.

👉🏻 Если ищите гибонький инструмент для работы по гибким методам, то вот ссылка на сервис WEEEK. У нас есть спринт-доски для Agile-работы, WIP-лимиты и другие штуки. И гибкая служба поддержки

Пробовать WEEEK

Фреймворк для расстановки приоритетов задач — от необходимых до ненужных. Хорошо работает в условиях ограниченных ресурсов. Идеально ложится на определение состава MVP.

Идеи и задачи распределяются по категориям:

Обязательно (M, Must Have) — идея, без которой продукт будет бесполезным
Должно быть (S, Should Have) — нужная идея, которая выполняется после обязательных задач

⬆️ Здоровый баланс для этих двух категорий — 50% всех идей

Может быть (Could Have) — идея, которую желательно включить. Остаётся на будущее, когда ключевые моменты доведены до ума
Могло бы быть (W, Would Have) — идеи из разряда хотелок, которые не играют принципиальной роли

👉 Как работает метод — писали тут и приоритизировали по фреймворку разные предметы от шариковой ручки до лендинга

быстро приступить к критичному и отказаться от «хотелок»
повысить прозрачность и общение — больно уж простая классификация приоритетов
управлять ожиданиями заинтересованных сторон
распределить ресурсы по категориям

Этот фреймворк поможет оценить задачу в числах. Расшифровывается так:

Impact — влияние задачи на проект
Confidence — уверенность, что реализация приведёт к положительному результату
Ease — простота исполнения

Три параметра каждой задачи оцениваются от 1 до 10. Например, влияние — 5, уверенность — 8, простота — 7. ICE считают по формуле:

Impact * Confidence * Ease = ICE

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

Похожий фреймворк для получения числовой оценки задачи. Расшифровка тоже почти совпадает:

Reach — охват
Impact — влияние задачи на проект
Confidence — уверенность, что реализация приведёт к положительному результату
Effort — усилие на выполнение

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

В отличие от ICE, в RICE обычно используют реальные цифры, а не примерную оценку.

Reach — охват аудитории. Оценивается на основе фактических данных — например, количестве посетителей сайта за неделю.

Impact — влияние на достижение цели. Шкала оценок:

3 – огромное воздействие
2 – сильное воздействие
1 – среднее воздействие
0,5 — низкое воздействие
0,25 — минимальное воздействие

Confidence — уверенность в успехе в процентах от 0% до 100%. 100% — высокая степень уверенности, 80% — средняя, 50% — низкая. Если показатель ниже 50, это повод отказаться от задачи в принципе.

Effort — усилия, которые уйдут на выполнение задачи. Измеряется во времени: часах, днях, неделях, месяцах. Например, чтобы два дизайнера работали три месяца, потребуется шесть человеко-месяцев (2 х 3 = 6).

Reach * Impact * Confidence / Effort = RICE

создаёт полную картину для определения приоритетов задач
основывает решения на данных, а не на интуиции
гарантирует, что команда не пропустит задачи, которые требуют минимум усилий

Оценивает время, объём и усилия на задачу с помощью карт. Классный инструмент для небольших команд.

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

Можно посмотреть наш ролик про метод планинг покера

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

У нас есть видео про Planning Poker — можно не читать, а посмотреть:

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

Показатель рассчитывается по формуле: CoD = упущенный доход или стоимость за единицу времени × продолжительность задержки.

Допустим, предполагаемая прибыль от продукта — 100 000 рублей в месяц, а его запуск задерживается на два месяца. Итого:

CoD = 100 000 рублей × 2 = 200 000 рублей.

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

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

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

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

Основные, обязательные (Must Have) — база, необходимая для конкурентоспособности. Это способность нашего приложения воспроизводить музыку
Одномерные, всегда важные (One-Dimensional) — или технические, производительные характеристики продукта. Это возможность находить и добавлять себе песни
Привлекательные (Attractive) — радуют пользователей, но если их нет, никто особо не заметит. Это, например, возможность расшифровывать текст песни
Нежелательные (Reverse) — те, что губят пользовательский опыт и снижают удовлетворённость. Долгая загрузка или внезапные обновления приложения
Неважные (Indifferent) — не вызывают никаких эмоций. Например, раздел с юридической документацией. Есть он и есть, пусть лежит

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

😎 Ещё у нас есть текст про 10 способов приоритизации дел и задач на проекте

🧘🏻‍♀️ Про разницу Agile и Scrum тоже есть, если вдруг надо

🎓 А ещё есть реальный кейс с применением разных методик в онлайн-школе NeoFamily

Автор: Таня Уржумцева

6 комментариев

Андрей Петушков

13 июня

Непонятно объяснение как применять модель Кано.

Ответить

WEEEK

Автор

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

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