Разбираемся с экспертом
В бэклоге всегда больше задач, чем ресурсов. Команды не успевают делать все одновременно: кто-то продвигает новые фичи, кто-то требует срочных правок, кто-то настаивает на техническом долге. WSJF — модель, которая помогает продукту или бизнесу понять, какие инициативы действительно стоит запускать в первую очередь. В статье разбираем, как работает модель приоритизации, зачем она бизнесу и как ее посчитать.
Статья предназначена для тех, кто знаком с Agile-методологией и управлением проектами. В материале будет много терминов, которые мы не будем разбирать подробно, — иначе получится еще 10 статей в одной.
WSJF (Weighted Shortest Job First) — это модель приоритизации задач. Она помогает понять, как задачи нужно решать в первую очередь, а какие можно отложить.
WSJF — не самостоятельная методика, а часть подхода к управлению потоком задач в масштабных Agile-фреймворках. Один из таких — SAFe (Scaled Agile Framework). Он помогает крупным компаниям работать по Agile не на уровне одной команды, а на уровне всей организации — от топ-менеджеров до отдельных разработчиков.
Модель WSJF встроена в SAFe как способ приоритизации крупных инициатив: чем больше потенциальная ценность и чем быстрее можно ее получить, тем выше приоритет. При этом WSJF не ограничен только SAFe: его можно применять в любом процессе, где задачи большие, ресурсов не хватает, а решений принимают много.
Мы рассмотрим модель на примере SAFe — как самого популярного и документированного фреймворка, в котором WSJF используется «по умолчанию».
WSJF — это инструмент для принятия решений, когда все сделать нельзя, а выбирать приходится между важным и еще более важным. Модель помогает командам продукта и топ-менеджерам синхронизироваться. Вот какие преимущества она дает.
Прозрачность приоритизации. Решения больше не зависят от влияния или уровня тревожности отдельных сотрудников. Все участники используют одну и ту же модель и одни и те же параметры. Это делает процесс приоритизации предсказуемым и понятным: даже если в топе оказалась не задача сотрудника, он понимает, почему.
Фокус на ценности. WSJF поднимает задачи, которые в текущем контексте приносят наибольшую бизнес-ценность. Это могут быть доработки под срочного клиента, фичи для ускорения продаж или автоматизация, снижающая ручные затраты.
Снижение потерь. В модели для каждой задачи считают бизнес-ценность и стоимость промедления. Так топ-менеджмент видит, какие инициативы в случае отсрочки принесут меньше потерь — и может правильно расставить приоритеты.
Согласованность между отделами. Маркетинг, продукт, IT, архитектура, бизнес — все участвуют в оценке и договариваются, что важнее. Это снижает конфликты, особенно в масштабных продуктах, где работают десятки команд.
Оптимизация ресурсов. Когда их мало, WSJF помогает понять: на какие две из десяти инициатив стоит потратить силы прямо сейчас. Это особенно полезно в кризис, при смене стратегии или запуске нового направления.
Тренер и консультант по Kanban методу и SAFe, основатель компании Pragmatic
WSJF работает не потому, что это точная математика, а потому что это язык, на котором можно договориться. Ты не просто говоришь «моя задача важная», а объясняешь, почему именно сейчас она важнее других.
В SAFe решения принимаются на четырех уровнях.
Чтобы применять WSJF, важно различать уровни задач, с которыми работают команды. У каждой свой масштаб и горизонт планирования.
Тренер и консультант по Kanban методу и SAFe, основатель компании Pragmatic
На уровне Strategic Themes не применяют WSJF, так как в планировании обсуждают не задачи, а ориентиры. Оценивать User Story по WSJF тоже бессмысленно, потому что у них нет отдельной бизнес-ценности. Они — часть фичи, и ценность появляется только в целом. Если одна история выпадет из плана — все остальное тоже теряет смысл.
К тому же User Story слишком много — приоритизация каждой отдельной истории перегрузит процесс. Проще оставить этот шаг команде, которая и так использует свои методы оценки — например, Story Points.
WSJF — полезный инструмент, но не универсальный. Есть ситуации, в которых применение этой модели либо не имеет смысла, либо создает лишнюю нагрузку. Ниже разберем основные случаи, когда WSJF стоит отложить.
Решение принимает один человек. Если приоритеты определяются напрямую руководителем — модель не нужна. Например, директор сам говорит, что делать в первую очередь, а команда просто выполняет.
В такой ситуации попытка посчитать WSJF превратится в формальность. Инициативы будут двигаться по личному убеждению одного человека. Это не плохо — просто WSJF в таких условиях бесполезен.
Продукт только начинает развиваться. На старте проекта нет смысла приоритизировать десятки инициатив — сначала нужно сделать скелет: создать базовую архитектуру, собрать первую версию и убедиться, что продукт вообще работает.
WSJF полезен, когда у вас уже есть выбор и когда задачи конкурируют за внимание. А в начале, как правило, делать нужно все и сразу. Например, флоу регистрации, базовую аналитику, отправку писем и поддержку API.
У бизнеса хаос-менеджмент. Если задачи ставятся через чат, приоритеты меняются каждый день, а планы никуда не записываются — WSJF не поможет. Модель требует хотя бы базовой устойчивости: бэклог, регулярных встреч и договоренностей.
Если этого нет, любая приоритизация будет нарушена при первом же кризисе. А значит, и расчеты потеряют смысл.
Слишком много мелких задач. Модель становится громоздкой, если вы пытаетесь применять ее к каждой кнопке или техническому долгу. Чтобы оценить параметры расчетов, нужна контекстная информация, а у микрозадач ее просто нет. В результате команда тратит больше времени на обсуждение, чем на выполнение.
Модель WSJF основана на простой формуле:
WSJF = Cost of Delay / Job Size
Сначала команда определяет, что потеряет бизнес, если отложить задачу — Cost of Delay. Затем решает, сколько усилий нужно, чтобы эту задачу выполнить — Job Size. Инициативы с наибольшим отношением ценности к затратам получают приоритет.
Cost of Delay (CoD) — это сумма потерь, которые компания понесет, если не возьмется за задачу прямо сейчас. Это не одна цифра, а три составляющих, каждая из которых оценивается совместно.
Чтобы не путаться в абсолютных числах, оценки проводят в относительных баллах — обычно используют ряд Фибоначчи: 1, 2, 3, 5, 8, 13… Это последовательность цифр, где каждое следующее значение в ряду равно сумме двух предыдущих. Оценку каждой задаче ставят коллегиально: участники планирования вместе решают, какая самая простая — ей ставят единицу. Дальше идут к более сложным и задают им значение из ряда Фибоначчи.
Так проще сравнивать задачи между собой: чем выше балл, тем больше потери от отсрочки.
CoD складывается из трех параметров.
CoD = Business Value + Time Criticality + Risk Reduction
Business Value. Это ценность для бизнеса или клиента: может быть, задача напрямую увеличит выручку, ускорит продажи или улучшит опыт пользователей.
Time Criticality. Это срочность. В эту часть входят дедлайны, сезонные пики, риски упустить окно возможностей.
Risk Reduction. Показывает, снижает ли задача какие-то важные риски, например, технологические или регуляторные. Либо, наоборот, открывает возможности: выйти в новую нишу, протестировать рынок или ускорить запуск другого проекта.
Разберемся на простом примере и без цифр Фибоначчи. Интернет-магазин одежды перед началом осеннего сезона выбирает между тремя задачами:
В итоге получится такой приоритет: сначала исправляем ошибку в приложении (высокий риск потери клиентов), затем запускаем новую доставку (критично для сезона), и только потом добавляем «Избранное».
Тренер и консультант по Kanban методу и SAFe, основатель компании Pragmatic
У оценки CoD есть нюанс — мы складываем совершенно разные категории: деньги, срочность, риски. В реальной жизни это не одно и то же, но модель заставляет договориться и принять общее решение. Это не точная наука, а способ понять, где больше боли и пользы одновременно.
Job Size — это относительная оценка усилий, которые потребуются для выполнения задачи. Команда не считает человеко-часы — вместо этого сравнивает задачи между собой: что проще, а что сложнее.
Обычно за эталон берут самую быструю или понятную задачу и присваивают ей 1 балл. Все остальные оцениваются относительно нее. Нельзя использовать дробные значения или ноль — WSJF тогда просто «сломается», потому что нельзя делить на ноль, а дробные оценки быстро ведут к псевдоточности и спорам.
Тренер и консультант по Kanban методу и SAFe, основатель компании Pragmatic
Важно помнить: Job Size — это не Story Points. По сути, это не про сложность, а про «стоимость» задачи в ресурсах команды: сколько времени, согласований, работы потребуется, чтобы закрыть фичу или эпик. В эту оценку могут входить любые усилия — не только разработка, но и дизайн, тестирование, легал, валидации на стороне клиента.
Например, если нужно просто подключить готовый API, который уже используют другие команды — Job Size может быть 1. А если задача требует R&D, согласований с партнерами и обучения пользователей — она может получить 8 или 13, даже если сама по себе выглядит небольшой.
Главное — не угадать точную длительность, а сравнить задачи между собой и понять, какие потребуют больше вложений, а какие — меньше. Чем выше Job Size, тем «дороже» задача в ресурсах.
На WSJF-сессии участники вместе решают, какие задачи действительно стоит делать сейчас. Это помогает избежать лишней работы и снижает конфликты между отделами.
Чтобы оценки были осмысленными, в сессии участвуют представители всех заинтересованных сторон:
Тренер и консультант по Kanban методу и SAFe, основатель компании Pragmatic
WSJF — это не про формулу. Самое ценное — это обсуждение, которое возникает вокруг нее. Если вы просто вбили баллы в таблицу и выдали приоритет — это не WSJF. Людям нужно самим пройти через оценку, иначе не будет доверия к решению.
На сессии обязательно должны быть все, кто влияет на результат: продукт, чтобы понимать бизнес-ценность, архитекторы, чтобы реалистично оценивать усилия, заказчики, чтобы обозначить срочность. И фасилитатор, который не дает разговору развалиться в спор за баллы.
Бывало, приходят без архитекторов — и в Job Size начинается фантазия. Без бизнеса — и ценность становится условной. А если все это еще и с готовыми цифрами — смысл теряется совсем. WSJF работает, только если обсуждение честное и коллективное.
Вот как пошагово провести WSJF-сесиию:
Тренер и консультант по Kanban методу и SAFe, основатель компании Pragmatic
WSJF-сессии проводят не постоянно, а по мере необходимости. Для фич это обычно происходит перед PI Planning или перед выходом новых релизов. Эпики пересматривают реже — например, раз в месяц или в рамках портфельного ревью. Если запускается новый продукт, к WSJF-сессии имеет смысл вернуться после появления первого рабочего прототипа — когда уже есть задачи, которые конкурируют за внимание.
Постоянно пересчитывать приоритеты не нужно, но если появляются новые данные, меняются сроки или условия на рынке — стоит собрать участников и пересмотреть оценки.
Модель WSJF кажется простой — формула одна, параметры известны. Но на практике ее легко использовать неправильно. Вот с какими ошибками чаще всего сталкиваются команды.
Оценивают задачи по-разному каждый раз. Если на сессиях оценки начинаются с потолка, результат не получится сопоставить. Модель работает только при относительной оценке: сначала нужно найти самую «легкую» задачу и дать ей балл 1, а потом сравнить с ней все остальное. Без этого WSJF теряет точку отсчета.
Ставят ноль или дробные значения. Ноль в WSJF недопустим: деление на ноль обнулит всю формулу. Дробные значения тоже не работают — они создают ложную точность и быстро сбивают фокус. Поэтому используют только целые числа по шкале Фибоначчи (1, 2, 3, 5, 8, 13…).
Применяют WSJF к микрозадачам. Формула не предназначена для User Story или багов из спринта. У мелких задач нет отдельной бизнес-ценности — она появляется только в составе фичи. Попытка приоритизировать такие задачи перегружает процесс и не дает полезного результата.
Искажают оценки ради приоритета. Иногда участники завышают ценность или срочность задачи, чтобы она поднялась в списке. Или дробят крупную фичу на части, чтобы «выиграть» по формуле. Это подмена сути: модель превращается в игру, а не инструмент принятия решений.
Нет общей договоренности. Если участники не обсуждают, что значит «большая ценность» или «высокая срочность», каждый оценивает по-своему. В результате формула теряет смысл.
Не пересматривают оценки. Даже точные оценки устаревают, если меняется контекст: появляются новые ограничения, уходит клиент или сдвигается рынок. WSJF-сессии не должны быть раз в жизни — при изменениях приоритеты нужно пересматривать.
WSJF — это не универсальная формула, а способ договориться. Он помогает бизнесу, продукту и командам совместно расставить приоритеты и сфокусироваться на задачах, которые приносят максимум ценности при минимальных усилиях.
Модель особенно полезна, когда много конкурирующих инициатив, а ресурсов на все не хватает. Но работает она только при честном обсуждении, общих правилах и регулярных пересмотрах.
Если использовать WSJF формально — ради таблицы или галочки — он не даст эффекта. А если внедрять как инструмент диалога и принятия решений, он помогает командам двигаться синхронно и быстрее достигать результата.
Читайте только в Конверте
Unisender — платформа автоматизации маркетинга. Удобные конструкторы, 100+ шаблонов и интеграций, гибкие тарифы. До 1500 писем бесплатно.
Искренние письма о работе и жизни, эксклюзивные кейсы и интервью с экспертами диджитала.
Проверяйте почту — письмо придет в течение 5 минут (обычно мгновенно)
