Методы приоритизации задач: как не промахнуться мимо результата

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

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

Какой метод приоритизации выбрать

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

Что такое приоритизация задач

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

Связь между приоритизацией и продуктивностью команды очевидна: когда сотрудники знают, на чем сфокусироваться в первую очередь, они работают слаженнее и результативнее. В то же время пренебрежение приоритизацией часто приводит к «синдрому белки в колесе», когда команда много работает, но не достигает значимых результатов. Поэтому навык расставлять приоритеты — одно из важнейших умений менеджера и команды в целом.

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

Какую роль играет в управлении разработкой

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

1. Управление бэклогом разработки 

При создании сложных B2B-решений, например, ERP-системы, бэклог может содержать сотни задач. Приоритизация помогает выделить те 20% функциональности, которые принесут 80% ценности. Так, например, разработка модуля финансовой отчетности может оказаться важнее, чем улучшение интерфейса панели администратора.

2. Распределение ресурсов и планирование спринтов

Когда ресурсы и сроки проекта ограничены, приоритизация помогает оптимально распределять время разработчиков — она помогает команде брать в работу самые важные задачи. Так проект быстрее приносит пользу, а важная функциональность появляется раньше. Если что-то пойдет не по плану, четкие приоритеты помогут команде быстро решить, на чем сосредоточиться в первую очередь.

3. Принятие стратегических решений

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

4. Баланс краткосрочных и долгосрочных целей

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

5. Коммуникация с заказчиками и инвесторами

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

Модели приоритизации задач 

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

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

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

Модель RICE

Модель RICE — это метод приоритизации задач, который помогает командам принимать обоснованные решения о том, какие проекты или фичи разрабатывать в первую очередь. Название модели — аббревиатура, состоящая из первых букв четырех основных факторов:

1. Reach (охват) — оценивает, сколько пользователей или клиентов затронет предлагаемое изменение за определенный период. Например, если новая функциональность повлияет на 1000 пользователей в квартал, значение Reach будет 1000.
2. Impact (влияние) — определяет, насколько сильно изменение повлияет на каждого пользователя. Обычно используется шкала от 0,25 (минимальное влияние) до 3 (максимальное влияние).
3. Confidence (уверенность) — отражает степень уверенности команды в своих оценках. Выражается в процентах: 100% — полная уверенность, 50% — низкая уверенность.
4. Effort (усилия) — оценка времени, необходимого для реализации проекта, обычно выражается в человеко-месяцах.

Для расчета приоритета по модели RICE используется формула:

RICE score = (Reach * Impact * Confidence) / Effort
 

Проекты с более высоким баллом RICE считаются более приоритетными.

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

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

Модель ICE

Модель ICE — простой и быстрый метод приоритизации задач, созданный Шоном Эллисом, известным по введению термина Growth Hacking. Название модели — аббревиатура трех факторов:

1. Impact (влияние) — насколько сильно задача повлияет на ключевые показатели продукта или бизнеса.
2. Confidence (уверенность) — насколько команда уверена в своих оценках влияния и легкости реализации.
3. Ease (легкость) — насколько просто реализовать задачу с учетом имеющихся ресурсов.

Каждый фактор оценивают по шкале от 1 до 10. Затем значения перемножают, получая итоговый балл ICE. Задачи с наивысшим баллом считаются приоритетными.

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

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

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

Модель WSJF

Модель WSJF (Weighted Shortest Job First) — это метод приоритизации задач, разработанный в рамках Agile и Lean подходов. WSJF помогает командам определить, какие задачи следует выполнять в первую очередь, основываясь на их ценности для бизнеса и времени выполнения.

Основная идея WSJF заключается в том, чтобы максимизировать ценность работы в единицу времени. Модель учитывает два фактора:

1. Cost of Delay (CoD) — стоимость задержки. Это сумма трех компонентов:

• ценность для бизнеса;
• срочность или критичность задачи;
• снижение рисков или возможности.

2. Job Size — объем работы или время, необходимое для ее выполнения.

Формула WSJF выглядит так: WSJF = CoD / Job Size
 

Чем выше значение WSJF, тем выше приоритет задачи.

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

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

User Story Mapping

Основные элементы User Story Mapping:

• Пользовательские истории — краткие описания функций с точки зрения пользователя.
• Каркас (Backbone) — последовательность основных шагов, которые пользователь выполняет при взаимодействии с продуктом.
• Задачи — детальные действия, необходимые для реализации каждого шага каркаса.
• Приоритеты — расположение задач по вертикали в зависимости от их важности.

Процесс создания карты:

1. Определите основные шаги пользователя и создайте каркас.
2. Добавьте детальные задачи под каждый шаг каркаса.
3. Приоритизируйте задачи, располагая их вертикально: наиболее важные — сверху.
4. Разделите карту на релизы или MVP горизонтальными линиями.

Среди преимуществ метода визуализация полного пути пользователя, которая помогает сфокусироваться на создании ценности. Также с помощью User Story Mapping легко определить черты MVP, что особенно полезно при разработке сложных продуктов или при работе с большим количеством требований.

MoSCoW

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

• Must have (обязательно): критически важные задачи, без которых проект не может считаться успешным.
• Should have (следует сделать): важные, но не критичные задачи, которые добавляют значительную ценность проекту.
• Could have (можно сделать): желательные, но не обязательные задачи, которые улучшают проект, но их отсутствие не влияет на основную функциональность.
• Won't have (не будет сделано): задачи, которые намеренно исключаются из текущего объема работ.

Применение MoSCoW позволяет быстро определить самые важные элементы проекта, эффективно распределить ресурсы и сфокусироваться на создании MVP. Однако у метода есть и ограничения: субъективность при распределении задач по категориям, отсутствие четких критериев для оценки важности задач и риск переоценить количество Must have задач

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

Opportunity Scoring

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

Чтобы применить Opportunity Scoring:

1. опишите фичи или возможные результаты использования продукта;
2. проведите опрос пользователей, попросив их оценить каждую фичу по двум критериям: важность (насколько это важно для пользователя) и удовлетворенность (насколько пользователь доволен текущей реализацией);
3. используйте формулу для расчета оценки возможности: 

Оценка = Важность + (Важность - Удовлетворенность)
 

4. проанализируйте результат — функциональность с высокой важностью и низкой удовлетворенностью считаются самыми перспективными для улучшения.

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

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

Buy-a-Feature

Buy-a-Feature — это интерактивный метод приоритизации задач, который помогает продуктовым командам определить наиболее ценную для пользователей функциональность. Суть метода заключается в имитации процесса покупки фичей продукта участниками.

Как работает Buy-a-Feature:

1. составьте список возможных улучшений продукта;
2. назначьте каждой фиче «цену»‎, основываясь на сложности реализации или затратах ресурсов;
3. соберите группу участников (пользователей или стейкхолдеров);
4. выдайте каждому участнику определенное количество «денег»‎;
5. предложите участникам «купить»‎ фичи, которые они считают наиболее важными;
6. наблюдайте за процессом и обсуждайте решения участников.

Метод очень наглядно демонстрирует ограниченность ресурсов и стимулирует участников к обсуждению и совместному принятию решений. С помощью Buy-a-feature можно выявить неочевидные приоритеты пользователей, а также создать нестандартную атмосферу для обсуждения продукта.

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

Cost of Delay

Cost of Delay (CoD) — это метод приоритизации задач, который помогает командам оценить экономическую ценность своевременного завершения проекта. Суть метода заключается в количественной оценке потерь от задержки реализации функциональности или проекта.

Чтобы рассчитать Cost of Delay:

1. оцените потенциальную прибыль от проекта за единицу времени (например, за месяц);
2. определите время, необходимое для завершения проекта;
3. разделите ожидаемую прибыль на время реализации.

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

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

Cost of Delay особенно полезен при управлении портфелем проектов и принятии решений о запуске новых продуктов, он помогает командам сосредоточиться на проектах, которые принесут наибольшую экономическую выгоду в кратчайшие сроки.

Матрица Эйзенхауэра

Матрица Эйзенхауэра делит задачи по двум признакам — важности и срочности — на четыре группы:

1. Важно и срочно — делать сразу: инцидент на проде, сдача релиза заказчику.
2. Важно, но не срочно — запланировать: архитектурные улучшения, обучение команды, техдолг.
3. Срочно, но не важно — делегировать: типовые запросы, часть встреч.
4. Не важно и не срочно — убрать из списка.

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

Модель Кано

Модель Кано предложил японский исследователь Нориаки Кано в 1984 году. Она делит функции продукта по тому, как они влияют на удовлетворённость пользователей:

• Обязательные — их наличие воспринимается как должное, а отсутствие вызывает недовольство. Например, уведомление о смене статуса заявки.
• Одномерные — чем лучше реализованы, тем выше удовлетворённость. Например, скорость загрузки.
• Привлекательные — их не ждут, но они радуют. Например, ИИ-подсказка решения по инциденту.
• Безразличные — не влияют на оценку продукта.
• Обратные — часть пользователей воспринимает их негативно.

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

Value vs Effort

Value vs Effort — матрица «ценность — усилия». Каждую задачу оценивают по пользе для бизнеса и трудозатратам и раскладывают по четырём квадрантам:

• Быстрые победы (высокая ценность, мало усилий) — делать в первую очередь.
• Крупные проекты (высокая ценность, много усилий) — планировать и делить на этапы.
• Мелкие доработки (низкая ценность, мало усилий) — брать, когда есть свободное время.
• Невыгодные задачи (низкая ценность, много усилий) — отказаться.

Метод удобен для первого разбора большого бэклога на встрече с командой. Для точной расстановки внутри квадрантов его дополняют RICE или WSJF.

Резюме

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

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