Как использовать модель WSJF для приоритизации бэклога

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

Статья предназначена для тех, кто знаком с Agile-методологией и управлением проектами. В материале будет много терминов, которые мы не будем разбирать подробно, — иначе получится еще 10 статей в одной.

Что такое WSJF и зачем он бизнесу

WSJF (Weighted Shortest Job First) — это модель приоритизации задач, которую разработал создатель и владелец фреймворка SAFe. Она помогает понять, какие задачи нужно решать в первую очередь, а какие можно отложить.

WSJF — не самостоятельная методика, а часть фреймворка SAFe (Scaled Agile Framework). Он помогает крупным компаниям работать по Agile не на уровне одной команды, а на уровне всей организации — от топ-менеджеров до отдельных разработчиков.

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

Мы рассмотрим модель на примере SAFe — как самого популярного и документированного фреймворка, в котором WSJF используется «по умолчанию».

Что дает WSJF топ-менеджменту и бизнесу

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

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

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

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

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

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

Где и на каких уровнях применяется WSJF

В SAFe решения принимаются на разных уровнях.

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

• Strategic Themes — долгосрочные цели бизнеса, которые в SAFe формулируются через OKR (Objectives and Key Results). Например: «выход на международный рынок в 2026». 
• Epics — крупные бизнес-инициативы, которые длятся дольше одного PI — обычно от 8 до 12 недель. Примеры: «интеграция новой платежной системы», «вывод на новый рынок».
• Features — функциональные блоки, которые можно реализовать в рамках одного Program Increment — обычно это от 8 до 12 недель. Например: «внедрение авторизации через Госуслуги» или «автоматизация CRM-сценариев».
• User Stories — небольшие задачи, которые команда делает за две недели. Примеры: «починить фильтр», «переработать верстку карточки», «добавить чекбокс».

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

Когда WSJF не принесет ожидаемого эффекта

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

Решение принимает один человек. Например, директор сам говорит, что делать в первую очередь, а команда просто выполняет. В такой ситуации попытка посчитать WSJF превратится в формальность. Инициативы будут двигаться по личному убеждению одного человека. 

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

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

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

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

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

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

Как рассчитать WSJF

Модель WSJF основана на простой формуле:

WSJF = Cost of Delay / Job Size

Сначала участники WSJF-сессии определяют, что потеряет бизнес, если отложить задачу — Cost of Delay. Затем решают, сколько усилий нужно, чтобы эту задачу выполнить — Job Size. Инициативы с наибольшим отношением ценности к затратам получают приоритет.

Как посчитать Cost of Delay

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

Чтобы не путаться в абсолютных числах, для оценки используют модифицированный ряд Фибоначчи: 1, 2, 3, 5, 8, 13, 20, 40, 100… Это последовательность цифр, где каждое следующее значение в ряду равно сумме двух предыдущих, но после 13 ряд отклоняется от классической последовательности. Оценку каждой задаче ставят коллегиально: участники приоритизации вместе решают, какая самая простая — ей ставят единицу. Дальше идут к более сложным и оценивают их относительно единицы.

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

CoD складывается из трех параметров.

CoD = Business Value + Time Criticality + Risk Reduction and/or Opportunity Enablement

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

Time Criticality. Это срочность. В эту часть входят дедлайны, сезонные пики, риски упустить окно возможностей.

Risk Reduction and/or Opportunity Enablement. Показывает, снижает ли задача какие-то важные риски, например, технологические или регуляторные. Либо, наоборот, открывает возможности: выйти в новую нишу, протестировать рынок или ускорить запуск другого проекта. 

Разберемся на простом примере и без цифр Фибоначчи. Интернет-магазин одежды перед началом осеннего сезона выбирает между тремя задачами и так оценивает их по параметрам:

Business Value:

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

Time Criticality:

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

Risk Reduction / Opportunity Enablement

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

Как посчитать Job Size

Job Size — это относительная оценка усилий, которые потребуются для выполнения задачи. Участники WSJF-сессий не считают человеко-часы — вместо этого сравнивают задачи между собой по четырем параметрам: 

• объем (volume) — сколько работы нужно сделать;
• сложность (complexity) — насколько задача трудоемкая;
• знания (knowledge) — насколько понятна задача;
• неопределенность (uncertainty) — сколько неизвестного в задаче.

Обычно за эталон берут самую быструю или понятную задачу и присваивают ей единицу. Все остальные оцениваются относительно нее. Нельзя использовать дробные значения или ноль — WSJF тогда просто «сломается», потому что нельзя делить на ноль, а дробные оценки быстро ведут к псевдоточности и спорам.

Как проводить WSJF-сессии

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

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

• Product Manager — управляет бэклогом на уровне ART, приоритизирует фичи с учётом бизнес-ценности, согласует требования с несколькими командами.
• Business Owner — несет ответственность за ROI и стратегические приоритеты, согласует ценность инициатив с целями бизнеса, участвует в принятии решений при приоритизации.
• System Architect — обеспечивает архитектурную целостность решения, оценивает технические риски, участвует в формировании реалистичных оценок.
• Product Owner — управляет бэклогом команды, обеспечивает детализацию задач, синхронизирует приоритеты с Product Manager.
• Фасилитатор, обычно RTE — помогает провести сессию, фиксирует договорённости, обеспечивает равноправное участие всех заинтересованных сторон.

Вот как пошагово провести WSJF-сесиию:

1. Подготовьте список задач. Выносите только то, что уже имеет описание, бизнес-контекст и технические вводные. Если задача сырая — лучше ее отложить.
2. Назначьте фасилитатора RTE или кого-то из опытных скрам-мастеров. Он не оценивает, а помогает группе идти по шагам, фиксирует оценки для таблицы WSJF и не дает планированию затянуться из-за споров и разногласий.
3. Оценивайте каждый параметр в отдельности. Сначала — Cost of Delay: Business Value, Time Criticality и Risk Reduction and/or Opportunity Enablement. Потом — Job Size.
4. Начинайте оценку с единицы. Возьмите самую понятную задачу и присвойте ей 1. Все остальные оценивайте относительно нее.
5. Рассчитайте WSJF. Получится числовое значение для каждой задачи.
6. Постройте итоговый рейтинг. Он покажет, что запускать в первую очередь.
7. Обсудите результат. Если порядок кажется нелогичным, подумайте, почему именно. Можно проанализировать параметры, но точно не стоит их корректировать в угоду «логичности» приоритетов.

Какие ошибки бывают в применении WSJF

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

Оценивают задачи по-разному каждый раз. Если на сессиях оценки начинаются с потолка, результат не получится сопоставить. Модель работает только при относительной оценке: сначала нужно найти самую «легкую» задачу и дать ей балл 1, а потом сравнить с ней все остальное. Без этого WSJF теряет точку отсчета.

Ставят ноль или дробные значения. Ноль в WSJF недопустим: деление на ноль обнулит всю формулу, а при оценке параметров CoD он нивелирует вклад этого параметра в приоритет. Дробные значения тоже не работают — они создают ложную точность и быстро сбивают фокус. Поэтому используют только целые числа по шкале Фибоначчи (1, 2, 3, 5, 8, 13…).

Применяют WSJF к микрозадачам. Формула не предназначена для User Story или багов из спринта. У мелких задач нет отдельной бизнес-ценности — она появляется только в составе фичи. Попытка приоритизировать такие задачи перегружает процесс и не дает полезного результата.

Искажают оценки ради приоритета. Иногда участники завышают ценность или срочность задачи, чтобы она поднялась в списке. Бывает, задачу, которая по масштабу должна быть оценена, например, в 2 балла, оценивают в 5 или 8, хотя разница с эталонной задачей в реальности невелика. Или дробят крупную фичу на части, чтобы «выиграть» по формуле. Это подмена сути: модель превращается в игру, а не инструмент принятия решений.

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

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

Что в итоге

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

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

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