Как определить приоритет для задач? 5 методов

Для эффективного планирования спринтов и списка задач важно грамотно расставлять приоритеты у задач. Это позволит выполнять работу эффективнее и не срывать поставленные сроки. Опираться можно на что угодно: на свои пожелания, возможности команды, указания руководства или внешние обстоятельства. Но если спросить у руководителей разных отделов, чья задача приоритетнее, каждый проголосует за свою. Есть множество методов объективной оценки приоритетов задач. Рассмотрим некоторые из них.

«Влияние — уверенность — простота» (ICE Scoring)

Создатели метода «Влияние — уверенность — простота» (ICE) выделяют 3 фактора:

• Влияние (Impact) — какое влияние окажет на пользователя. Например, как задача повлияет на конверсию в оплату или сколько денег принесет бизнесу.

3 一 огромное влияние;

2 一 высокое влияние;

1 一 среднее влияние;

0,5 一 слабое влияние.

• **Уверенность (**Confidence) — в вашей оценке охвата, влияния и трудозатрат. Оценивается то, насколько мы уверены в оценке предыдущих факторов. Как много входных данных, на которых вы основывались?

100% 一 высокая достоверность;
80% 一 средняя достоверность;
50% 一 низкая достоверность.

При подсчете учитывается не процент, а доля. То есть 100% = 1.

• Трудозатраты (Effort) — сколько времени и усилий требуется для выполнения задачи. Чем проще выполнить ее, тем выше будет оценка. Можно ориентироваться на время или сложность выполнения.

Итоговая оценка тоже будет считаться следующим образом:

Чем выше оценка, тем задача приоритетнее. С помощью этого метода можно выбирать гипотезы, которые команда будет тестировать в первую очередь.

«Влияние — уверенность — трудоёмкость + охват» (RICE Score)

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

• Охват (Reach) — сколько пользователей затронет эта задача/идея. Например, количество регистраций в месяц.

Чтобы получить оценку по RICE, необходимо провести вычисления:

Задача с большей оценкой RICE — наиболее приоритетная.

Московский метод (MoSCoW)

При использовании этого метода нужно соотнести задачи к одному из четырех критериев:

• Надо (Must-Do) — задачи, которые нужно выполнить обязательно. Без них продукт не может существовать.
• Следует (Should-Do) — важные задачи, но не критические. Могут не иметь решающего веса при выборе продукта, но при этом важны к исполнению.
• Можно было бы (Could-Do) — задачи, желательные для релиза.
• Необязательно (Won’t-Do) — наименее критичные задачи, можно отложить до следующего релиза.

Приоритеты расставляются сверху вниз — от M к W. То есть, сначала выполняем задачи из категории «Надо» (Must-Do), а в последнюю очередь 一 из категории «Не обязательно» (Won’t-Do).

Техника структурной карты требований (Story Maping)

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

• Горизонтальная ось 一 шаги клиента.
• Вертикальная ось 一 критичность задач.

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

Стоимость задержки (Cost of Delay и WSJF)

WSJF (Самое простое и самое ценное прежде всего) 一 система оценки, при которой вы получаете список задач, где на первом месте — самая простая в реализации, но и самая ценная с точки зрения бизнеса.

Для начала нам необходимо рассчитать показатель Cost of Delay (Стоимость задержки). Он позволяет определить, как задержки в релизе какой-либо функции влияют на деньги. А так же помогает оценить список задач в деньгах. Формула следующая:

• Бизнес-ценность **(**User-bussiness value) — насколько задача принесет пользу для бизнеса или клиента.
• **Временная критичность (**Time criticality) — насколько нам важно сделать эту задачу сейчас или мы можем подождать. Например, конкурент делает что-то похожее и нам нужно опередить его.
• **Фактор риска (**Risk Reduction) — насколько эта фича уменьшает риск или открывает новые возможности.
• **Сложность работы (**Job size) — насколько технически сложно реализовать эту инициативу.

Оценку выполняют с помощью чисел Фибоначчи, как в итерационной модели.

Группу оценивающих следует разделить на 2: бизнес и ИТ. Каждая группа самостоятельно оценивает задачи с помощью покера планирования на физической доске.

Оценка производится по колонкам, а не инициативам. Например, сначала все инициативы оцениваются по бизнес-ценности, а затем по временной критичности.

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

Расчет производится по следующей формуле:

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