У продуктовой команды почти всегда больше задач, чем она способна выполнить одновременно.
Новые функции конкурируют с техническим долгом. Запросы клиентов — с внутренними улучшениями. Бизнес хочет ускорить одну инициативу, поддержка приносит другую, разработка просит время на архитектурные изменения, а в backlog уже лежат десятки идей, которые когда-то тоже казались важными.
В такой ситуации задача Product Owner — не просто составить список.
Нужно определить:
что команда должна делать раньше, а что сознательно будет сделано позже.
Именно это и есть практический смысл приоритизации.
Но хороший процесс не заканчивается на выставлении баллов RICE или раскладывании карточек по матрице. После выбора приоритетов остаётся второй, не менее важный вопрос:
как превратить этот порядок в реалистичный план разработки с учётом ограниченной команды?
Разберём оба уровня.
Что такое приоритизация задач на практике
Приоритизация — это способ сравнить несколько возможных направлений работы и определить их относительный порядок.
Ключевое слово здесь — относительный.
Фраза «эта задача важная» почти ничего не означает, если остальные задачи тоже важные.
Полезный приоритет отвечает на вопрос:
Если мы не можем сделать A и B одновременно, что должно получить ресурс первым?
Поэтому приоритизация всегда связана с ограничениями.
Если бы команда могла выполнять все идеи одновременно и без ограничений по людям, времени и бюджету, приоритеты были бы не нужны.
Но в реальной продуктовой разработке ограничения есть всегда.
Почему «срочно» и «важно» быстро перестают работать
Самая простая система выглядит так:
- высокий приоритет;
- средний;
- низкий.
Для небольшой очереди этого может хватить.
Проблема возникает, когда большинство задач получают статус «высокий».
Например:
- новый платёжный сценарий — высокий;
- критичный запрос крупного клиента — высокий;
- обязательная интеграция — высокий;
- переработка onboarding — высокий;
- технический долг перед масштабированием — тоже высокий.
В итоге приоритет перестаёт выполнять свою функцию.
Когда всё важное, реальный порядок определяется уже не системой, а тем, кто громче попросил, у кого ближе встреча с руководством или какая проблема возникла последней.
Поэтому хорошая приоритизация должна заставлять принимать решение.
Не «важно ли это?», а:
«важнее ли это следующей инициативы?»
Сначала определите уровень приоритизации
В продуктовой разработке можно приоритизировать разные сущности:
- идеи;
- гипотезы;
- фичи;
- задачи;
- инициативы;
- проекты;
- технический долг;
- запросы клиентов.
Если смешать всё в одну очередь, сравнение быстро становится бессмысленным.
Например, небольшая задача интерфейса может получить высокий балл RICE и оказаться выше крупной инициативы по запуску нового продукта. Формально расчёт верный, но сравниваются разные масштабы.
Поэтому полезно разделять уровни.
Уровень 1. Продуктовые инициативы
Крупные изменения, проекты и направления развития.
Именно здесь Product Owner отвечает на вопрос:
что продуктовая команда должна продвигать в первую очередь?
Уровень 2. Задачи внутри инициативы
Когда инициатива уже выбрана, внутри неё можно определять порядок конкретных работ.
Эти два уровня связаны, но не обязаны использовать одну и ту же модель приоритизации.
Какие критерии стоит учитывать
Универсальной формулы не существует.
Но большинство продуктовых решений так или иначе опираются на несколько типов факторов.
Ценность
Какой результат даст задача?
Это может быть:
- рост выручки;
- повышение конверсии;
- удержание пользователей;
- снижение издержек;
- уменьшение количества обращений;
- выполнение обязательства перед клиентом;
- снижение операционного риска.
Ценность лучше формулировать конкретно.
«Это полезная функция» — слабый критерий.
«Она должна снизить долю ручной обработки заявок» — гораздо лучше.
Охват
Сколько пользователей, клиентов или процессов затронет изменение?
Функция может быть очень полезной, но только для небольшой аудитории.
Другая — давать умеренный эффект, зато для большинства пользователей.
Уверенность
Насколько команда уверена в ожидаемом эффекте?
Есть большая разница между:
пользователи регулярно просят эту функцию,
и:
нам кажется, что эта идея должна понравиться.
Уверенность помогает не ставить на один уровень проверенные данные и предположения.
Стоимость или усилия
Сколько ресурсов требует реализация?
Одинаковый эффект при недельной и трёхмесячной разработке — это разные решения.
Риск
Что произойдёт, если работу не сделать?
Для части технических, юридических или инфраструктурных задач именно риск может быть главным фактором.
Стратегическое соответствие
Поддерживает ли инициатива выбранное направление продукта?
Иногда привлекательная возможность не должна попадать наверх просто потому, что она отвлекает команду от основной стратегии.
RICE: когда нужно сравнить продуктовые инициативы
RICE — одна из самых известных моделей приоритизации.
Обычно она учитывает четыре фактора:
- Reach — охват;
- Impact — влияние;
- Confidence — уверенность;
- Effort — усилия.
В упрощённом виде логика такая:
больше охват × больше влияние × выше уверенность / меньше усилий = выше приоритет.
RICE удобен, когда нужно сравнить несколько продуктовых инициатив в более или менее одинаковом контексте.
Например:
| Инициатива | Охват | Влияние | Уверенность | Усилия |
|---|---|---|---|---|
| Новый onboarding | высокий | высокий | средняя | большие |
| Быстрое восстановление пароля | высокий | средний | высокая | небольшие |
| Расширенная аналитика | низкий | высокий | средняя | средние |
Такой подход заставляет команду обсуждать не абстрактную привлекательность идеи, а конкретные основания.
Но RICE не выдаёт объективную истину.
Если входные оценки субъективны, итоговый балл тоже остаётся моделью, а не фактом.
ICE: проще, но грубее
ICE обычно строится вокруг трёх факторов:
- Impact — влияние;
- Confidence — уверенность;
- Ease — простота реализации.
Он подходит, когда нужно быстро сравнить идеи и не хочется строить более тяжёлую модель.
Например, на раннем этапе продукта ICE может быть удобнее RICE, потому что точного охвата ещё нет.
Недостаток очевиден: система чувствительна к субъективным оценкам.
Если один участник ставит влиянию 9 из 10, а другой 6 из 10, математическая точность итогового числа ничего не гарантирует.
Поэтому ICE полезнее воспринимать как способ структурировать обсуждение, а не как автоматический механизм принятия решений.
MoSCoW: хорошо для границ, хуже для строгой очереди
MoSCoW делит требования на четыре категории:
- Must have;
- Should have;
- Could have;
- Won't have now.
Подход полезен, когда нужно определить обязательный состав релиза, проекта или версии.
Например:
Must have — без этого релиз не выполняет основную задачу.
Should have — важно, но можно временно обойтись без этого.
Could have — полезно при наличии времени.
Won't have now — осознанно не делаем в текущем периоде.
Проблема начинается, если Product Owner пытается использовать MoSCoW для строгого порядка из десятков задач.
Десять элементов категории Must всё равно нужно как-то упорядочить между собой.
Поэтому MoSCoW хорошо отвечает на вопрос «что войдёт в объём?», но слабее отвечает на вопрос «что делаем первым?».
Value/Effort: простой способ начать
Один из самых практичных вариантов — матрица «ценность / усилия».
Задачи условно попадают в четыре зоны:
Высокая ценность, небольшие усилия
Очевидные кандидаты на раннюю реализацию.
Высокая ценность, большие усилия
Стратегические инициативы, которые стоит планировать осознанно.
Низкая ценность, небольшие усилия
Можно делать при наличии свободной мощности, но они не должны вытеснять более важную работу.
Низкая ценность, большие усилия
Главные кандидаты на отказ или существенную переработку.
Сила подхода — в простоте.
Он хорошо подходит для первичного разбора backlog, когда сложная балльная система пока не нужна.
Когда формулы начинают мешать
Метод приоритизации становится вредным, если команда начинает защищать рассчитанный балл вместо обсуждения реального решения.
Например:
У этой задачи RICE 742, поэтому она обязана быть первой.
Но в реальности может существовать ограничение, которого нет в формуле:
- юридический срок;
- обязательство перед ключевым клиентом;
- зависимость от внешнего поставщика;
- необходимость сначала выполнить техническую работу;
- риск безопасности;
- отсутствие нужного специалиста.
Поэтому любой рассчитанный приоритет должен оставаться инструментом поддержки решения, а не заменой решения.
Product Owner всё равно отвечает за итоговую последовательность.
Полезнее иметь один порядок, чем десять одинаковых «высоких» приоритетов
После оценки инициатив полезно получить не просто категории, а относительный порядок.
Например:
- Переработка оплаты.
- Новый onboarding.
- Интеграция с партнёром.
- Расширение отчётности.
- Административная панель.
Это не означает, что №5 не важен.
Это означает:
если возникнет конфликт за один ресурс, сначала его получит работа с более высоким приоритетом.
Такой порядок гораздо полезнее для планирования, чем пять карточек с красной меткой High.
Приоритет не равен порядку фактического старта
Здесь появляется важный нюанс.
Проект №1 может иметь максимальный приоритет, но не иметь возможности начаться сегодня.
Например:
- аналитика ещё не завершена;
- нужен специалист, занятый текущей работой;
- внешний подрядчик не предоставил данные;
- этап зависит от другой инициативы.
В это же время проект №2 может иметь свободный независимый этап.
Поэтому хороший план не должен интерпретировать приоритет как команду:
остановить всё и немедленно начать самый важный проект.
Правильнее:
при конфликте за ограниченный ресурс более важная инициатива получает преимущество, если её этап действительно готов к началу.
Это различие критично для реального календарного планирования.
Приоритизация бэклога и планирование — разные процессы
Допустим, Product Owner получил идеальный backlog:
- Функция A.
- Функция B.
- Функция C.
- Функция D.
Что теперь?
Если все задачи выполняет один универсальный разработчик и между ними нет зависимостей, порядок backlog почти совпадёт с планом.
Но реальные продуктовые команды устроены сложнее.
Функции требуют разных специализаций.
Этапы зависят друг от друга.
Специалисты уже заняты.
Некоторые работы можно выполнять параллельно.
Возникают отпуска и внеплановые задачи.
Поэтому после приоритизации начинается новый процесс:
планирование.
Нужно понять, как приоритетный порядок будет реализован при существующих ограничениях.
Как перейти от приоритета к реальному плану
Полезно пройти пять шагов.
Шаг 1. Зафиксируйте относительный порядок инициатив
Должно быть понятно, какая работа выигрывает при конфликте за ресурс.
Шаг 2. Разложите инициативы на этапы
Для каждого крупного направления определите работы, которые можно оценить и назначить специалистам.
Шаг 3. Укажите ресурсы и зависимости
Кто нужен для каждого этапа?
Что должно завершиться до его старта?
Шаг 4. Учтите текущую загрузку
Команда не начинает квартал с чистого листа.
Люди уже выполняют задачи.
Поэтому новый высокий приоритет не означает автоматическую доступность нужного специалиста сегодня.
Шаг 5. Постройте календарную последовательность
Только здесь становится видно:
- когда начнётся инициатива;
- какие работы пойдут параллельно;
- где появляется ожидание ресурса;
- когда получится результат.
Это уже не приоритизированный список, а план.
Что делать со срочными задачами
Срочная работа неизбежна.
Проблема не в том, что приоритеты иногда меняются.
Проблема возникает, когда изменение происходит без оценки последствий.
Предположим, новая задача становится №1.
Дальше Product Owner должен увидеть:
- какой специалист понадобится;
- какую текущую или будущую работу она вытеснит;
- какие даты изменятся;
- какие обязательства окажутся под риском.
Только после этого можно принять осознанное решение.
Иначе приоритетизация превращается в бесконечную перестановку верхней карточки, а сроки всех остальных инициатив «почему-то» постоянно уезжают.
Приоритет должен иметь историю
Есть ещё одна полезная практика — фиксировать не только текущий приоритет, но и значимые изменения.
Например:
1 сентября Проект A — №1, проект B — №2.
15 сентября После нового обязательства перед клиентом проект B поднят на №1.
Через месяц такой контекст помогает объяснить, почему первоначальный прогноз больше не актуален.
Без истории команда легко приходит к спору:
Почему опять не уложились?
Хотя фактически план мог несколько раз осознанно меняться.
Как понять, что ваша система приоритизации работает
Есть несколько простых признаков.
Команда может назвать верхние инициативы без спора
Если каждый участник считает главным что-то своё, приоритеты существуют только на бумаге.
При конфликте за ресурс понятно, кто получает его первым
Не требуется каждый раз собирать отдельное совещание.
Низкоприоритетные задачи действительно ждут
Это звучит очевидно, но часто именно здесь система ломается: формально задача низкая, но всё равно выполняется раньше, потому что её проще начать.
Изменение приоритета приводит к пересмотру плана
Если порядок изменился, а прогноз по срокам остался прежним, система, вероятно, не учитывает реальные ограничения.
Можно объяснить, почему работа находится именно на этом месте
Не обязательно иметь сложную формулу.
Но решение должно быть воспроизводимым и понятным.
Где здесь KORDO
KORDO не заменяет RICE, ICE, MoSCoW или продуктовую экспертизу. Следующий уровень процесса разобран в материалах про приоритизацию бэклога и планирование продуктовой разработки.
Решение о том, что важнее, остаётся за Product Owner и командой.
KORDO нужен на следующем шаге.
Когда относительный приоритет инициатив уже определён, его можно связать с этапами, специалистами, зависимостями и текущей загрузкой команды.
Тогда приоритет перестаёт быть просто меткой и начинает влиять на реальную последовательность работ.
Если более важная инициатива должна получить общий дефицитный ресурс раньше, последствия для остальных сроков можно увидеть в отдельном сценарии перепланирования. Опубликованный План при этом меняется только после явного подтверждения и публикации новой версии.
Так появляется ответ не только на вопрос:
Что для нас сейчас важнее?
но и на следующий:
Когда команда действительно сможет это сделать и что из-за этого сдвинется?
Главное
Приоритизация задач нужна не ради красивой таблицы баллов.
Её цель — помочь команде принимать ограниченные решения.
RICE, ICE, MoSCoW, Value/Effort и другие методы полезны, если они делают выбор прозрачнее. Но ни один из них не отменяет продуктового контекста и ответственности Product Owner.
Практически процесс выглядит так:
ценность → сравнение → относительный приоритет → ресурсы → последовательность → календарный план.
Первые три шага отвечают на вопрос «что важнее?».
Следующие три — на вопрос «что команда реально сможет сделать раньше?».
И только вместе они превращают приоритизацию из списка намерений в управляемый процесс продуктовой разработки.