Приоритизация WSJF: как выбирать задачи, которые приносят максимум ценности
WSJF (Weighted Shortest Job First - "взвешенное сначала самое короткое") - это способ выстроить задачи так, чтобы команда сначала делала то, что дает наибольшую отдачу за наименьшее время. Метод позволяет сравнивать разнородные задачи не "по ощущениям", а через понятную формулу: какую ценность мы теряем, откладывая работу, и сколько усилий нужно, чтобы эту ценность получить.
Метод появился внутри SAFe (Scaled Agile Framework) как инструмент для управления большими портфелями задач в IT, но со временем вышел далеко за рамки разработки: его используют в продукт-менеджменте, маркетинге, логистике, операционном управлении и даже в работе внутренних служб компаний.
Базовая идея WSJF
Логика проста:
сначала делаем те задачи, от задержки которых мы теряем больше всего, и которые при этом можно реализовать относительно быстро.
Это похоже на работу очереди: если нужно обслужить нескольких клиентов, и один из них занимает 1 минуту, а другой - 10, выгодно сначала пропустить того, кто "быстрый". Так общее время ожидания для всех сократится.
В продуктовом управлении ситуация аналогична. У вас есть бэклог: новые фичи, улучшения, исправления багов, техдолг, эксперименты. Каждая задача:
- приносит определенную выгоду продукту или бизнесу;
- требует определенного времени и ресурсов.
WSJF помогает упорядочить этот хаос и получить список задач, отсортированных по "выгодности" их немедленного выполнения.
---
Формула WSJF
Общий вид формулы:
WSJF = Cost of Delay / Job Duration
Где:
- Cost of Delay (CoD) - стоимость задержки, упущенная выгода от того, что задача не сделана прямо сейчас;
- Job Duration - длительность выполнения задачи (сколько времени и ресурсов потратит команда).
Чем выше CoD и чем меньше Job Duration, тем выше приоритет по WSJF.
Из чего состоит Cost of Delay
Cost of Delay - не одно число, а сумма трех компонент:
1. User-Business Value (ценность для пользователя и бизнеса)
Оцениваем, насколько задача важна для клиентов и компании:
- решает ли она заметную проблему;
- улучшает ли ключевые метрики (доход, конверсию, удержание, NPS);
- задевает ли большой сегмент аудитории.
Высокий балл получает задача, которая:
- закрывает острую боль многих пользователей;
- напрямую влияет на выручку или ключевые продуктовые KPI.
2. Time Criticality (критичность по времени)
Отвечает на вопросы:
- Насколько важно сделать это сейчас?
- Есть ли жесткие сроки (сезонные акции, изменения законодательства, договоренности с партнерами)?
- Упадет ли ценность задачи, если ее отложить?
Например:
- фича к крупной маркетинговой кампании имеет высокую критичность по времени;
- доработки для следующего года могут иметь низкую.
3. Risk Reduction / Opportunity Enablement (снижение рисков / открытие возможностей)
Показывает, помогает ли задача:
- уменьшить вероятность крупных проблем (безопасность, стабильность, репутационные риски);
- подготовить базу для важных будущих фич, рынков или каналов монетизации.
Это могут быть:
- рефакторинг, уменьшающий вероятность фатальных багов;
- создание инфраструктуры для экспериментирования;
- интеграции, которые потом позволят запустить новые продукты.
Итоговая формула CoD:
CoD = User-Business Value + Time Criticality + Risk Reduction/Opportunity Enablement
Как оценивают значения
Чаще всего используют модифицированную шкалу Фибоначчи:
1, 2, 3, 5, 8, 13, 20
Причины:
- команды не тратят время на излишнюю точность (разницы между 7 и 8 в реальности нет);
- каждый следующий шаг заметно больше предыдущего - легче сравнивать по порядку, а не по "точным" цифрам;
- оценки носят сравнительный характер: важно, что задача А важнее задачи Б, а не то, что у А "ровно 7,4 балла".
---
Job Duration: как оценивать длительность задач
В знаменателе формулы - Job Duration. Это не календарный срок, а объем усилий команды:
- оцениваем не "неделя в календаре", а "неделя полной загрузки одного или нескольких специалистов";
- также используем ту же шкалу Фибоначчи: 1, 2, 3, 5, 8, 13, 20.
Важно:
- одна неделя работы одного разработчика - это одна оценка;
- одна неделя работы трех человек - более высокая оценка, потому что задействовано больше ресурсов.
Дальнейшая развернутая формула выглядит так:
WSJF = (User Value + Time Criticality + Risk/Opportunity) / Job Duration
Задачи с наибольшим значением WSJF - кандидаты в верх бэклога.
---
Пример 1: интернет-магазин электроники
Представим, что вы управляете онлайн-магазином электроники.
Ситуация:
- команда разработки маленькая;
- накопилось множество задач от маркетинга, поддержки и руководства;
- цель на ближайшие три месяца - максимизировать прибыль.
В бэклоге, например, лежат:
- добавление оплаты через новый способ (например, быстрые платежи);
- редизайн главной страницы;
- улучшение блока "сравнение товаров";
- исправление критичного бага в оформлении заказа;
- настройка сценариев для брошенных корзин.
Применяем WSJF: для каждой задачи оцениваем:
- User-Business Value;
- Time Criticality;
- Risk Reduction / Opportunity Enablement;
- Job Duration.
Дальше считаем WSJF и заносим данные в таблицу.
После подсчетов может получиться картина:
- исправление критичного бага - высокий CoD и относительно небольшая длительность → WSJF, например, 53.0;
- сценарии для брошенных корзин - тоже заметный вклад в выручку, средняя длительность → WSJF около 8.7;
- подключение нового способа оплаты - ощутимый плюс, но влияние чуть ниже, чем у корзин → WSJF около 5.2;
- редизайн главной страницы и улучшение сравнения товаров - задачам можно назначить низкий CoD при высокой продолжительности → WSJF около 1.1.
Результат:
сначала исправляем критичный баг, затем занимаемся брошенными корзинами, потом новым способом оплаты. Эстетически приятные, но слабо влияющие на прибыль задачи логично отложить.
Чтобы перенести результаты в таск-трекер, практично:
- добавлять WSJF-оценку в квадратных скобках к названию задачи;
- выравнивать значения по длине (например, `[053.0]`, `[008.7]`);
- сортировать по убыванию - так самый выгодный набор задач окажется наверху.
---
Пример 2: мобильное приложение для бегунов
Допустим, вы развиваете приложение для любителей бега. Уже реализованы:
- отслеживание тренировок;
- базовая статистика;
- история пробежек.
Продукт работает, но пользователи хотят больше:
- социальные функции (друзья, лента активности);
- планы тренировок;
- интеграции с часами;
- система достижений и челленджей;
- платная подписка с расширенными возможностями.
Цель - повысить удержание пользователей, чтобы люди возвращались в приложение и регулярно пользовались им.
Для каждой задачи команда дает оценки по WSJF, фокусируясь на метриках retention и вовлеченности. Например:
- геймификация (ачивки, челленджи) - высокая ценность для удержания, средняя длительность;
- интеграция с популярными часами - большая ценность для определенного сегмента, но высокая сложность;
- простые социальные функции (добавить друзей, лайки) - средняя длительность, заметное влияние на вовлеченность;
- запуск платной подписки - высокая бизнес-ценность, но часть функционала, на который будет завязана подписка, еще не сделана → снижается текущий CoD.
После подсчетов становится видно, что:
- некоторые "громкие" задачи (например, сложная интеграция) по эмоциям кажутся важными, но их WSJF ниже;
- простая геймификация или небольшой социальный функционал могут дать больший вклад в удержание за меньшие усилия.
Так формируется реалистичный план развития продукта: сначала - быстрые, но ценные улучшения, затем - более тяжелые инициативы.
---
Важные нюансы применения WSJF
1. Зависимости между задачами
Формула WSJF не учитывает зависимости.
Может быть ситуация:
- задача А имеет низкий WSJF;
- задача Б - высокий WSJF;
- но Б невозможно сделать, не завершив А.
Если смотреть только на цифры, А уйдет в конец очереди, и вы никогда не доберетесь до Б. Поэтому:
- всегда стройте карту зависимостей;
- помечайте задачи, являющиеся "блокерами" для других;
- корректируйте план: иногда задачу с меньшим WSJF приходится делать раньше, чтобы разблокировать крупную ценность.
2. Регулярный пересмотр оценок
Контекст меняется:
- выходит конкурент с новой фичей - растет Time Criticality;
- появляются новые каналы трафика и гипотезы монетизации - меняется User-Business Value;
- команда находит более простое техническое решение - падает Job Duration.
Поэтому:
- не относитесь к оценкам WSJF как к высеченным в камне;
- обновляйте их перед каждым спринтом или итерацией;
- обсуждайте, что изменилось во внешней и внутренней среде.
3. CoD - это упущенная выгода, а не прямой убыток
Стоимость задержки - это не только потери, но и незаработанные деньги:
- если вы откладываете запуск платной подписки, вы не теряете текущие деньги, но и не зарабатываете потенциальные;
- откладывая улучшение онбординга, вы продолжаете "терять" часть новых пользователей, которые могли бы остаться.
WSJF помогает увидеть не только "где горит", но и где лежат возможности, которые вы не используете из‑за постоянного откладывания.
4. Коллективные оценки важнее мнения одного эксперта
Чтобы избежать перекоса:
- собирайте оценки от нескольких ролей: продукта, разработки, маркетинга, поддержки, аналитики;
- обсуждайте расхождения в баллах - именно в дискуссиях часто вскрываются скрытые риски и возможности;
- фиксируйте договоренности, чтобы к ним можно было вернуться при пересмотре приоритетов.
---
Как внедрить WSJF в команду: пошаговый подход
1. Определите цель периода
WSJF всегда привязывается к конкретной цели: рост выручки, удержания, NPS, снижение издержек. Без этого сложно оценивать User-Business Value.
2. Сформируйте список задач
Соберите все инициативы в один бэклог: фичи, улучшения, баги, техдолг, эксперименты.
3. Опишите каждую задачу простыми словами
Кратко сформулируйте:
- какую проблему она решает;
- кого затрагивает;
- к каким метрикам относится.
4. Проведите сессию оценки
- используйте шкалу Фибоначчи;
- для каждого пункта (Value, Time Criticality, Risk/Opportunity, Duration) договоритесь о единых принципах;
- можно проводить оценку в формате покер-планирования, а затем обсуждать различия.
5. Посчитайте WSJF и отсортируйте бэклог
- внесите все данные в таблицу;
- вычислите CoD и затем WSJF для каждой задачи;
- отсортируйте по убыванию WSJF и получите обновленный приоритетный список.
6. Проверьте результат через здравый смысл
- учитывайте зависимости;
- убедитесь, что короткие и полезные задачи не потерялись среди "гигантов";
- проверьте, что стратегия (цель периода) действительно поддерживается верхними задачами.
---
Типичные ошибки при использовании WSJF
1. Слишком детальная точность
Попытки выставить оценки вроде "7,5" или спорить между "8" и "9" уводят в сторону. WSJF - про относительные величины, а не про математическую точность.
2. Игнорирование работы без прямого влияния на выручку
Обслуживание техдолга, улучшение стабильности, безопасность часто недооцениваются. Важные технические задачи нужно честно оценивать по компоненту Risk Reduction.
3. Приравнивание WSJF к единственному источнику правды
Цифры помогают, но не заменяют здравый смысл и стратегическое видение. Важные инициативы с долгосрочным эффектом иногда останутся "ниже" по WSJF, но все равно должны быть в планах.
4. Смешение разных горизонтов планирования
Не стоит в одну таблицу сваливать:
- мелкие задачи на несколько дней;
- масштабные проекты на несколько месяцев.
Лучше разделять уровни: сначала - крупные инициативы, а внутри каждой из них - приоритизация мелких задач.
---
Когда WSJF особенно полезен
- Ограниченные ресурсы
Небольшая команда, много запросов - нужно объяснить, почему делаем одни задачи, а другие откладываем.
- Межфункциональные конфликты
Маркетинг, продажи, поддержка и техкоманда тянут одеяло в разные стороны. WSJF помогает перевести спор из "кто громче кричит" в структурное сравнение ценности и затрат.
- Запуск нового продукта или крупного релиза
Когда идей больше, чем возможностей, метод помогает вычленить небольшой набор задач, который даст максимальный эффект.
- Переход от хаотичного к системному управлению бэклогом
Если до этого приоритизация строилась на интуиции или влиянии отдельных людей, WSJF становится прозрачной, понятной основой для планирования.
---
Как адаптировать WSJF под свою реальность
Метод гибкий и допускает адаптацию под специфику бизнеса:
- можно переопределить, что именно считать User-Business Value (например, в b2b - влияние на LTV ключевых клиентов, в b2c - на конверсию и удержание);
- можно добавить дополнительные критерии внутри компонентов CoD, чтобы делать оценки более осознанными;
- допустимо использовать укрупненные оценки (например, "низкий/средний/высокий", маппя их в значения Фибоначчи) для команд, которые только осваивают метод.
Главное - сохранить общий принцип: приоритет определяется не "красотой" идеи и не громкостью запроса, а соотношением ценности и длительности реализации.
---
WSJF помогает переводить приоритизацию из плоскости субъективных споров в последовательный процесс с понятной логикой. В результате команда:
- тратит меньше времени на споры о важности;
- быстрее получает измеримую ценность;
- прозрачнее объясняет стейкхолдерам, почему одни задачи попали в ближайший спринт, а другие - нет.
Используя WSJF регулярно и осознанно, вы постепенно выстраиваете культуру, в которой решения принимаются не по инерции и не по эмоциям, а опираясь на реальные эффекты для пользователей и бизнеса.
