Приоритизация бэклога. Максимальный гайд

Привет, читатели!

Кому из нас не знакома ситуация, когда «горит» вообще всё и сразу? Кажется, что каждая задача кричит: «Сделай меня первой!» И вот тут‑то и возникает ступор: за что хвататься, с чего начать? Методик приоритизации существует великое множество — от простой и понятной матрицы Эйзенхауэра до запутанных фреймворков вроде WSJF. Но как во всем этом разобраться и не утонуть в бесконечных таблицах и формулах?

Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT‑отделом 8. Я работаю в компании Софтонит. В этой статье я постараюсь простым языком рассказать о самых популярных подходах к приоритизации задач. Мы разберем их плюсы и минусы, посмотрим на реальные примеры и, надеюсь, вы найдете тот инструмент, который будет вам полезным и поможет навести порядок в бэклоге, а также сделать процесс приоритизации четким и понятным.

О чем статья

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

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

• Описания методик приоритизации с примерами

• Главное — система: почему выбор методики не так важен

• Если вы хотите разработать свою уникальную методику

• ChatGPT / Gemini / Claude помоги в приоритизации!

• Как мы реализовали возможность приоритизации задач в своем продукте для ИТ‑шников.

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

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

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

Матрица «Value vs Effort»

Метод матрица «Value vs Effort» представляет собой инструмент приоритизации задач, позволяющий визуально оценить соотношение между ценностью (value) и сложностью (effort), необходимыми для реализации каждой задачи.

Матрица состоит из двух осей:

Value (ценность): Оценка ценности задачи с точки зрения бизнеса. Она измеряется по следующим показателям:

• Привлечение (Acquisition) — это задача поможет привлечь новых клиентов

• Активация (Activation) — как скоро пользователи ощутят ценность новой функции

• Охват (Reach) — скольких клиентов охватит новая функция

• Доход (Revenue) — как эта функция поможет продукту зарабатывать

• Удержание (Retention) — поможет ли эта функция удерживать или возвращать клиентов в продукт

• Виральность (Virality) — пользователи станут рекомендовать продукт коллегам

Effort (сложность): Объем ресурсов, необходимых для выполнения задачи. Обычно оценивается в человеко‑часах или относительных величинах.

Пример

Допустим, ваша команда рассматривает три проекта:

1. Разработка нового интерфейса задания (V=8, E=6).

2. Оптимизация регистрации задания (V=5, E=3).

3. Улучшение шаблонов уведомлений (V=3, E=3).

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

Плюсы

• Простота визуализации и понимания приоритетов.

• Помогает быстро выявить высокоэффективные задачи.

• Позволяет команде согласовывать приоритеты.

Минусы

• Субъективность оценки значений критериев.

• Сложность точного измерения некоторых показателей (например, виральности).

• Может потребоваться дополнительное обсуждение для определения объективных метрик ценности и затрат.

ICE (Impact, Confidence, Easy)

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

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

ICE = Impact × Confidence × Easy

Каждый критерий оценивается по шкале от 1 до 10, где 10 — максимальная значимость.

• Impact (Влияние)

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

• Confidence (Уверенность)

Показывает, насколько команда уверена в своих оценках Impact и Ease. Это «проверка на реализм».

• Ease (Простота реализации)

Учитывает время, ресурсы и сложность выполнения задачи.

Важно! Умножение (а не сложение) усиливает дисбаланс между критериями: если один из них близок к нулю, общий балл резко падает. Это помогает «отсеивать» заведомо слабые идеи.

Пример

Команда выбирает между двумя функциями для своего решения:

Функция A:

• Влияние = 8 ( Добавление данной фичи повысит удовлетворение клиентов);

• Уверенность = 7 ( По данным опроса: 58% пользователей жаловались на отсутствие данного функционала);

• Простота реализации = 6 ( Необходимо дополнить API и переписать часть кода).

ICE = 8 × 7 × 6 = 336.

Функция B:

• Влияние = 9 ( Внедрение данного функционала увеличит количество продлений подписок и привлечет новых клиентов);

• Уверенность = 5 ( По данной функции нет данных, так как она новая, но использование подобного кейса у конкурентов дал +16% к росту интереса);

• Простота реализации = 8 ( Функционал уже разработан, осталось его только внедрить).

ICE = 9 × 5 × 8 = 360.

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

Плюсы

• Простота — не требует сложных расчетов.

• Скорость — оценка занимает минуты.

• Гибкость — критерии можно адаптировать под контекст.

• Наглядность — легко объяснить команде.

Минусы

• Субъективность — оценки зависят от личного мнения.

• Игнорирование ресурсов — не учитывает бюджет, время, риски.

• Риск искажений — если один критерий близок к нулю, весь балл обнулится.

• Нет весов — все критерии считаются равнозначными, что не всегда верно.

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

RICE (Reach, Impact, Confidence, Effort)

RICE — это усовершенствованная модель приоритизации, разработанная для оценки идей и проектов. Она расширяет метод ICE, добавляя критерий охвата аудитории (Reach) и заменяя «простоту реализации» на усилия (Effort), что делает ее более подходящей для решений с массовой аудиторией.

Метод RICE рассчитывается по формуле:

RICE = (Reach × Impact × Confidence) / Effort

Каждый критерий оценивается по своей шкале:

• Reach (Охват)

Что оценивает: Сколько пользователей/клиентов затронет задача за определенный период (например, месяц).

Шкала: Числовое значение (не проценты!).

• Impact (Влияние)

Что оценивает: Как задача повлияет на ключевую метрику (доход, конверсия, удержание).

Шкала: 1–3 (3 — максимальное влияние).

• Confidence (Уверенность)

Что оценивает: Уверенность команды в оценках Reach и Impact.

Шкала: 50% (низкая), 80% (средняя), 100% (высокая).

• Effort (Усилия)

Что оценивает: Трудозатраты в человеко‑днях или человеко‑месяцах.

Шкала: Числовое значение (чем больше число, тем выше усилия).

Важно! Effort стоит в знаменателе: чем больше усилий требует задача, тем ниже её приоритет.

Пример

Команда выбирает, какую фичу разработать в следующем квартале.

Вариант A: Внедрение согласования в личном кабинете.

• Охват = 15 000 пользователей/месяц (используют личный кабинет).

• Влияние = 2 (улучшит удовлетворенность, но не напрямую влияет на доход).

• Уверенность = 80% (есть данные, что 30% обращений связаны с отсутствием согласования).

• Усилия = 15 человеко‑дней.

RICE = (15 000 × 2 × 0.8) / 15 = 1,600.

Вариант B: Расширение функционала для линии поддержки.

• Охват = 8 000 пользователей/месяц (те, кто написал обращения).

• Влияние = 3 (сократит нагрузку на поддержку).

• Уверенность = 50% (функционал не проверен, но аналоги у конкурентов работают).

• Усилия = 25 человеко‑дней.

RICE = (8 000 × 3 × 0.5) / 25 = 480.

Итог: Приоритет отдается варианту A, несмотря на меньшее Влияние, за счет большего Охвата и меньших Усилий.

Плюсы

• Учет масштаба — Reach добавляет объективности.

• Баланс усилий и результата — Effort предотвращает выбор «дорогих» задач с низкой отдачей.

• Гибкость — можно адаптировать шкалы под бизнес‑метрики.

• Прозрачность — четкая связь между оценками и приоритетом.

Минусы

• Сложность расчетов — требует сбора данных по охвату и усилиям.

• Субъективность Impact — шкала 1–3 может быть интерпретирована по‑разному.

• Риск переоценки Reach — если аудитория сегментирована, цифры могут вводить в заблуждение.

• Не учитывает риски — например, технические или рыночные.

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

MoSCoW

MoSCoW — метод приоритизации задач, основанный на категоризации требований по четырем группам: Must have, Should have, Could have, Won't have. Название — сокращение от первых букв категорий. Метод популярен в Agile, управлении проектами и разработке ПО, где важно четко разделять «обязательное» и «желательное».

Метод MoSCoW делится на категории:

• Must have (Должно быть)

Что: Критически важные функции, без которых продукт неработоспособен или не соответствует целям.

Доля в релизе: 15–20% (иначе релиз становится слишком объемным).

• Should have (Стоит иметь)

Что: Важные, но не обязательные функции. Их отсутствие не блокирует продукт, но снижает ценность.

Когда реализовывать: Второй этап или ближайшие спринты.

• Could have (Можно иметь)

Что: Желательные улучшения, которые повышают удобство, но не критичны.

Особенность: Реализуются, если остаются ресурсы.

• Won't have (Не будет в этом релизе)

Что: Функции, которые откладываются на будущее (но не обязательно навсегда).

Важно: Не путать с «Never have» — это не отказ, а отсрочка.

Пример

Команда разрабатывает мобильное приложение Service Desk.

Приоритизация требований:

Must have:

• Список задач с подробной информацией.

• Синхронизация с основным решением.

Should have:

• Личный кабинет.

• Оповещения на электронную почту.

Could have:

• Гибкая настройка интерфейса.

• Дополнительные документы (наряд на работы и др.)

Won't have:

• Социальная сеть для пользователей.

• AI‑помощник.

Итог:

В первый релиз войдут только Must have. Should have и Could have будут доработаны позже, а социальная сеть и AI‑помощник отложены.

Плюсы

• Простота — не требует сложных расчетов.

• Прозрачность — все участники понимают, что войдет в релиз.

• Гибкость — легко пересматривать категории при изменении условий.

• Фокус на MVP — помогает избежать «распыления» на второстепенные задачи.

Минусы

• Субъективность — категории зависят от мнения команды или заказчика.

• Риск перегрузки Must have — если их слишком много, релиз становится нереалистичным.

• Нет количественной оценки — сложно сравнивать задачи внутри одной категории.

• Игнорирование зависимостей — не учитывает, что некоторые Should have могут быть критичны для Could have.

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

Кано

Модель Кано — метод анализа удовлетворенности пользователей продуктом путем классификации характеристик товара или услуги на несколько категорий в зависимости от степени влияния на восприятие клиента. Разработана японским профессором Нориаки Кано в конце XX века. Основная цель модели — определить приоритетность развития продуктов, выявляя характеристики, способные существенно повысить лояльность клиентов.

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

Категории функций модели Кано

• Обязательные («Must‑be») — Характеристики, воспринимаемые потребителями как само собой разумеющиеся. Их отсутствие вызывает недовольство, однако высокое качество таких характеристик редко приносит дополнительные бонусы лояльности.

• Ожидаемые («One‑dimensional») — Эти характеристики не являются абсолютно необходимыми, но они увеличивают удовольствие покупателя от продукта или услуги. Чем лучше реализована такая характеристика, тем больше довольства испытывает клиент.

• Привлекающие («Attractive») — Дополнительные свойства продукта, повышающие привлекательность и формирующие положительное впечатление у потребителя даже при относительно низком уровне исполнения.

• Нейтральные («Indifferent») — Такие характеристики практически не влияют на удовлетворение или неудовлетворенность пользователей.

• Антиконформные («Reverse features») — Функции в этой категории активно не удовлетворяют пользователей и должны быть полностью исключены из продукта. Они могут заставить пользователей разочароваться в продукте.

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

Описание характеристики

1) Насколько вам понравится наличие такой характеристики?

• Мне нравится, что это будет

• Я ожидаю, что это будет

• Я отношусь нейтрально

• Я могу терпеть, что это будет

• Мне не нравится, что это будет

2) Как вы отнесетесь к тому, что эта характеристика будет отсутствовать?

• Мне нравится, что этого не будет

• Я ожидаю, что этого не будет

• Я отношусь нейтрально

• Я могу терпеть, что этого не будет

• Мне не нравится, что это не будет

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

Пример

Допустим, компания разрабатывает программное обеспечение для управления IT активами предприятия.

Планируется разработка трех характеристик:

• Характеристика № 1: Автоматический мониторинг и обновление данных о программном обеспечении на компьютерах пользователей.

• Характеристика № 2: Поддержка мобильных устройств

• Характеристика № 3: Возможность интеграции с облачными хранилищами

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

Интерпретация результатов опроса:

Предположим, полученные данные показывают следующую картину.

Характеристика № 1: большинство респондентов выбрали варианты «Я ожидаю, что это будет» и «Мне не нравится, что этого не будет». Значит, данная характеристика относится к обязательным свойствам продукта («must be»).

Характеристика № 2: респонденты указали, что им нравится наличие мобильного приложения, но отсутствие такой возможности воспринимается спокойно. Следовательно, этот пункт считается привлекательным («attractive»), так как он добавляет дополнительную ценность.

Характеристика № 3: большинство опрошенных ответили нейтрально, показывая, что наличие или отсутствие этой функции не имеет большого значения для большинства пользователей. Такой признак относят к нейтральному типу («indifferent»).

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

Плюсы

• Позволяет точно выявить потребности пользователей.

• Уменьшает риски разработки ненужных функций.

• Помогает оптимизировать бюджет проекта.

• Повышает конкурентоспособность продукта на рынке.

• Способствует формированию устойчивого спроса.

Минусы

• Требует значительных ресурсов на проведение исследований.

• Результаты зависят от точности проведения опроса.

• Может оказаться сложной для интерпретации результатов.

• Имеет ограничения в долгосрочном прогнозировании потребностей пользователей — привлекательные функции со временем становятся обязательными.

Story Mapping

Story Mapping (картирование пользовательских историй) — метод визуализации продукта, который помогает командам структурировать задачи на основе пользовательского пути (user journey). Используется для фокусировки на ценности продукта и планирования релизов. В отличие от численных методов (ICE, RICE), Story Mapping фокусируется на логике взаимодействия пользователя с продуктом, что упрощает выделение MVP и распределение функций по этапам разработки.

Ключевые элементы

• Горизонтальная ось

Отображает этапы взаимодействия пользователя в хронологическом порядке (например: «Поиск товара» → «Оплата» → «Доставка»).

• Вертикальная ось

Определяет приоритет задач внутри каждого этапа:

• Верхние слои — критически важные функции для MVP.

• Нижние слои — улучшения или дополнительные возможности.

• User Activities (Активности)

Крупные шаги в пути пользователя (например, «Регистрация»).

• User Stories (Истории)

Конкретные задачи внутри активностей (например, «Вход через соцсети»).

• Releases (Релизы)

Границы между этапами разработки (что войдет в MVP, релиз 2.0 и т. д.).

Пример

Разработка приложения для заказа такси.

User Journey (Активности):

• Вызов такси

• Оплата

User Stories (Истории):

• Поиск машины:

  • MVP: Выбор пункта назначения, выбор типа авто;

  • Релиз 2: Сохранение адресов;

  • Релиз 3: Предварительный заказ

• Отслеживание поездки:

  • MVP: Карта с водителем, время прибытия;

  • Релиз 2: Уведомления о приближении;

  • Релиз 3: Интеграция с умными часами

• Оплата:

  • MVP: Карта, наличные;

  • Релиз 2: Распределение платежа;

  • Релиз 3: Кэшбэк

• Оценка поездки:

• MVP: 5-звездочная шкала;

• Релиз 2: Комментарии;

• Релиз 3: Бонусы за поездку

Итог:

В MVP войдут базовые функции заказа и оплаты.

Дополнительные возможности распределены между будущими релизами.

Плюсы

• Визуализация продукта — вся информация на одной карте.

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

• Гибкость — легко менять приоритеты и добавлять новые идеи.

• Понятность для нетехнических участников — минимум терминов.

Минусы

• Субъективность — приоритеты зависят от мнения команды.

• Сложность для масштабных продуктов — карта становится слишком большой.

• Нет количественных метрик — нельзя точно сравнить задачи.

• Требует времени — необходимо проводить воркшопы.

Story Mapping — инструмент для создания «живой» картины продукта. Он идеален для старта, но для детальной приоритизации стоит комбинировать его с методами вроде RICE или MoSCoW.

Buy a Feature

«Buy a Feature» — игровой метод приоритизации функций продукта, направленный на выявление наиболее ценных для пользователей возможностей. Участники (клиенты, стейкхолдеры или команда) получают виртуальный бюджет, который тратят на «покупку» предложенных функций.

Цель:

• Определить, какие функции пользователи считают критически важными.

• Снизить субъективность в принятии решений.

• Учесть мнение целевой аудитории на ранних этапах разработки.

Из чего состоит метод:

• Участники: Группа (5–10 человек) с разными ролями (клиенты, разработчики, менеджеры).

• Фичи: Список функций продукта с описанием и стоимостью (определяется заранее на основе сложности реализации, ресурсов).

• Бюджет: Виртуальные деньги, выдаваемые каждому участнику. Объем бюджета зависит от выбранного сценария:

  • Вариант № 1 — общего бюджета хватает только на несколько фич, бюджет каждого меньше самой дорогой (нужно всем вместе участникам купить фичу один раз).

  • Вариант № 2 — индивидуального бюджета хватает на любую фичу, но не на все (при анализе учитывается количество покупок фич).

• Правила:

  • Можно объединяться для покупки дорогих фич.

  • Фича считается «купленной», если набрана её полная стоимость.

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

• Анализ итоговых решений: После завершения мероприятия команда изучает приобретённые функции и выявляет наиболее востребованные изменения.

Контекст: Компания разрабатывает программный продукт «Управление IT‑отделом» для корпоративных клиентов.

Участники:

• Технический директор

• 1С‑разработчик

• Веб‑разработчик

• Финансовый аналитик

• Менеджер по продажам

Бюджет: Каждый участник получает по 30 монет.

Фичи и их стоимость:

• Автоматическое обнаружение устройств в сети — (60 монет)

• Аналитика расходов на IT‑инфраструктуру — (40 монет)

• Интеграция с Jira — (80 монет)

• Управление лицензиями ПО — (30 монет)

Процесс:

1. Технический директор и разработчики объединяют бюджеты (30 + 30 + 30 = 100 монет), чтобы купить Автоматическое обнаружение устройств в сети (80 монет), 20 монет он и веб‑разработчик тратят на Интеграция с Jira.

2. 1С‑разработчик оставшиеся 10 монет тратит на Управление лицензиями ПО.

3. Финансовый отдел вкладывает 30 монет в Аналитику расходов, дополняя свой бюджет 10 монетами от менеджера по продажам.

4. Менеджера по продажам оставшиеся 20 монет тратит на Управление лицензиями ПО.

Интеграция с Jira остается недофинансированной (собрано 20 монет из 80).

№	Фичи	Цена	Участники					Куплено
			Технический директор	1С-разработчик	Веб-разработчик	Финансовый аналитик	Менеджер по продажам
1	Автоматическое обнаружение устройств в сети	60	20	20	20			✔️
2	Аналитика расходов на IT-инфраструктуру	40				30	10	✔️
3	Интеграция с Jira	80	10		10			❌
4	Управление лицензиями ПО	30		10			20	✔️
Итого		210	30	30	30	30	30

Итог по приоритетам:

• «Автоматическое обнаружение устройств» (куплена, участвовало 3 человека).

• «Аналитика расходов» (куплена, участвовало 2 человека).

• «Управление лицензиями» (куплена, участвовало 2 человека).

• Решено отложить «Интеграция с Jira» до следующего спринта.

Плюсы

• Ориентация на клиента — решения базируются на их потребностях.

• Простота — не требует сложных расчетов.

• Наглядность — легко выявить приоритеты через матрицу (важность vs удовлетворенность).

• Гибкость — можно адаптировать шкалы и источники данных.

Минусы

• Зависимость от качества данных — нужны точные опросы или исследования.

• Субъективность — оценки важности могут различаться у разных сегментов аудитории.

• Игнорирование ресурсов — не учитывает стоимость или сложность реализации.

• Риск перекоса — задачи с высокой важностью и низкой удовлетворенностью могут быть слишком очевидными, что упускает скрытые возможности.

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

WSJF (Weighted Shortest Job First)

Модель WSJF (Weighted Shortest Job First) — используется для приоритизации задач в проекте. Она основана на принципе «Сначала выполняем быстрые и дорогие задачи». Этот метод позволяет определить наиболее важные задачи, которые приносят максимальную пользу за минимальное время.

Основные цели применения WSJF включают:

• Определение приоритетов задач

• Быструю поставку полезных функций

Элементы формулы:

• Cost of Delay: Стоимость задержки выполнения задачи, которая включает:

  • Business Value: Бизнес‑ценность задачи

  • Time Criticality: Степень срочности задачи

  • Risk Reduction: Уровень снижения риска

• Job Size: Размер задачи, определяемый временем и усилиями, необходимыми для её выполнения. Обычно измеряется в человеко‑часах или сторипоинтах.

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

Рассмотрим три задачи и проведем расчет WSJF для каждой из них.

Задача 1: Оптимизация системы мониторинга сети

• Business Value: Улучшение производительности и надежности сети приведет к повышению эффективности работы сотрудников. Балл: 8.

• Time Criticality: Задержка внедрения ухудшит работу всей компании. Балл: 7.

• Risk Reduction: Снижение риска сбоев и потери данных. Балл: 6.

Предположим, разработчики оценили объем работ в среднем в 5 дней.

• Job Size: 5 дней

Priority = (8+7+6)/5 = 4,20

Задача 2: Добавление модуля резервного копирования

• Business Value: Возможность быстрого восстановления данных после сбоя. Балл: 7.

• Time Criticality: Необходимо оперативно обеспечить защиту данных, иначе возможны серьезные последствия. Балл: 8.

• Risk Reduction: Резервное копирование значительно снизит вероятность потерь. Балл: 9.

Объем работ оценивается примерно в 7 дней.

Job Size: 7 дней

Priority = (7+8+9)/7 ≈ 3,43

Задача 3: Интеграция API для автоматизации процессов

• Business Value: Автоматизация повысит эффективность и уменьшит рутинные операции. Балл: 6.

• Time Criticality: Нет жесткой зависимости от сроков внедрения. Балл: 4.

• Risk Reduction: Небольшое влияние на риски. Балл: 3.

Работа занимает около 3 дней.

Job Size: 3 дня

Priority = (6+4+3)/3 ≈ 4,33

Итоговые результаты:

Интеграция API для автоматизации процессов ≈ 4,33

Оптимизация системы мониторинга сети = 4,20

Добавление модуля резервного копирования ≈ 3,49

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

Плюсы

• Простота и понятность критериев оценки

• Универсальность применения в различных проектах

• Повышение удовлетворенности клиентов благодаря выполнению высокоприоритетных задач

Минусы

• Субъективность оценки, особенно при недостатке данных

• Временные затраты на проведение оценки

• Риск отложения крупных задач, если они не были должным образом декомпозированы

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

Главное - система: почему выбор методики не так важен

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

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

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

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

Если я хочу разработать СВОЮ уникальную / идеальную методику

Иметь свой взгляд и собственную методику абсолютно нормальное желание.

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

Мы решили пойти этим путем и поэкспериментировать.

Поставка задачи. У нас есть:

• Руководитель по развитию нашего ПО (я) — Product Owner.

• Сложность задачи (ее понимает руководитель разработки).

• Оценка первой линии на сколько эта задача нужна и часто по ней есть вопросы.

• Число голосов, которые отдают пользователи нашего ПО за развитие фишек / пожеланий (получаем с сайта где клиенты могут проголосовать за фичу).

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

ChatGPT / Gemini / Claude помоги!

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

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

Ты team lead и в твоем отделе постоянно появляются и скапливаются задачи. Надо понять в каком приоритете приступать к выполнению задач. У тебя есть показатели:

• Value — бизнес‑ценность ценность задачи (заполняется Product Owner). Число от 1 до 1000

• Effort — сложность выполнения задачи (заполняется программистами). Число от 1 до 1000

• MoSCoW — оценка целесообразности выполнения задачи (заполняется техподдержкой). Имеет четыре числовых значения: 2 — задача должна быть сделана в любом случае, 1.66 — задача с не самыми важными требованиями, 1.33 — желательные требования, 1 — требования, которые можно проигнорировать.

• Voiting — число голосов пользователей продукта, которые проголосовали за выполнение этого задание.

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

Теперь пояснения по показателям, которые используем в промпте.

• Value проставляю я и могу влиять на то когда возьмут задачу в работу. Причем мой вес очень большой.

• MoSCoW заполняет первая линия. Первая линия чуть‑чуть влияет, но не сильно. Она причесывает оформление задачи, она вылавливает дубли если надо и объединяет задачи. Это как первичный фильтр.

• Voiting (голоса клиентов за фичи / доработки) — это уже наши клиенты и их голоса, которые влияют на вес. Кто‑то может возразить, что «как же так, Value считай всем рулит, а по идее должны сильно влиять голоса клиентов». Все так. Но возникают проблемы с тем, что клиенты не знают, например, о новых фичах и не видят в них смысла, пока не попробуют и вдруг окажется, что эта фича очень даже ничего. Оценка не сильно увеличивается, но после 10 отданных за фичу голосов происходит ее значительный буст.

• Effort (сложность) тоже должен быть. Эту оценку у нас проставляет руководитель разработки. Если есть две не особо важных задачи, но одна легкая, а другая сложная, то, очевидно, что нужно начинать с легкой.

Мне предлагались совершенно разные формулы в процессе.

Вариант 1.

Не самое удачное начало и я попросил чтобы Voiting рос линейно и влиял на общую оценку когда количество проголосовавших переваливает за 10.

Вариант 2

Уже лучше, но нам нужна формула, а не куча условий ЕСЛИ ... ИНАЧЕ ...

Попросил как-то учесть это и получил итоговую формулу.

Вариант 3. Итоговая формула на которой я остановился и ее обоснование:

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

У вас могут быть совершенно другие показатели. Ну или те, что вам важны. Это могут быть: прибыль компании, максимизация бонусов в IT ^_^, признак того, что задача пришла от главного босса и она автоматически увеличивается на +100 500 и т. п. Причем показатели могут быть в разных градациях.

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

Сейчас AI‑шечка шагнула так далеко, что возможно будет проще скормить ей свою методику, примеры как оценивать те или иные показатели и не делать ничего вручную. А нейросеть сама посчитает формулу целиком и сама вычислит итоговую оценку.

Как мы реализовали возможность приоритизаций задач в продукте для ИТ-шников

Покажем, как можно реализовать подобную систему приоритизации на примере нашего решения Управление IT‑отделом 8.

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

На примере Value (бизнес-ценности) добавим реквизит в объект:

А теперь добавим итоговый реквизит скоринга — формулу:

Видим, что объект имеет свою формулу и ссылается на другие реквизиты.

Теперь открывая объект мы будем видеть добавленные реквизиты-оценки и можем их менять. При этом реквизит Priority при изменении других реквизитов пересчитываться автоматически:

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

На скриншоте панель с проектами скрыта, видим задачи одного проекта, а задачи отсортированы по Priority. Сразу видно, что надо делать и в какой последовательности.

Вот таким образом мы добавили в программу приоритезацию. Получилось достаточно удобно.

Вместо заключения

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

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

Теперь давайте обсудим.

• Какие методики из перечисленных вы уже применяли в своей практике?

• С какими сложностями сталкивались при внедрении системы приоритизации?

• Какие лайфхаки или собственные подходы вы используете для определения приоритетов?

Буду рад вашим вопросам и опыту в комментариях! Вместе мы сможем сделать процесс приоритизации более эффективным и понятным.