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

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

WSJF расшифровывается как Weighted Shortest Job First. В простом виде показатель равен стоимости задержки, делённой на размер работы. Чем выше результат, тем раньше имеет смысл рассмотреть задачу. Метод предпочитает работу, где каждый условный день усилий снимает большую потерю от ожидания. Это не правило «всегда делать самое маленькое»: крупная задача тоже выйдет наверх, если цена её откладывания высока.

Стоимость задержки, или Cost of Delay, — оценка того, что организация теряет, пока результат не готов. Её не всегда удаётся выразить рублями. Команда может использовать относительную шкалу, но должна одинаково понимать её для всех сравниваемых задач. Размер работы, Job Size, тоже можно оценивать относительно. Делить баллы одной команды на человеко-дни другой без общей калибровки нельзя.

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

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

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

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

Для каждой части выберите относительный балл и коротко запишите основание. «Бизнес-ценность — 8, потому что 40% заказов сейчас обрываются на оплате» полезнее, чем просто «8». Чувствительность ко времени требует вопроса: что случится, если отложить на один месяц? Если ответ «почти ничего», срочность должна быть низкой, даже когда инициатор очень громко просит задачу.

Job Size отражает объём усилий, который понадобится для результата. Команда может использовать условные баллы, рабочие дни или другой единый масштаб. В относительной оценке часто берут последовательность 1, 2, 3, 5, 8, 13: промежутки растут вместе с неопределённостью. Балл 13 не означает «сделать срочно»; он показывает, что работа существенно крупнее балла 5.

Полезно обсудить оценки совместно с исполнителями. Один разработчик видит код, тестировщик — объём проверок, дизайнер — состояние макетов. Если оценки расходятся, попросите участников объяснить предположения: какие зависимости, возвраты и внешние согласования они учитывают? Метод покера планирования помогает сначала показать независимые оценки, а затем выяснить причину разброса.

Аналогия с уже выполненной задачей часто надёжнее абстрактного балла. Если новая интеграция похожа на прошлую, сравните число интерфейсов, проверок и неизвестных. Размеры «футболок» XS–XL пригодятся для первого грубого прохода, но перед расчётом WSJF их нужно согласованно перевести в числовую шкалу. Не превращайте условные баллы в обещанные календарные дни без отдельного плана доступности команды. О том, как уменьшать крупные единицы работы, читай в материале о размере задачи в Канбане.

Пусть магазин выбирает между тремя задачами. Быстрая оплата получает 8 баллов пользы, 5 — срочности и 3 — риска или возможностей: стоимость задержки равна 16. Размер работы — 4 балла, поэтому WSJF равен 4. Уведомление о наличии получает 5 + 3 + 2 = 10 при размере 2; WSJF равен 5. Новый раздел каталога получает 8 + 2 + 2 = 12 при размере 8; WSJF равен 1,5.

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

Проверяйте арифметику. Если стоимость задержки равна 28, а размер — 4, WSJF равен 7, а не 6,2. Ошибка в одной строке способна поменять порядок всего бэклога. Удобно хранить три составляющие числителя, размер, частное и дату оценки в отдельной таблице или полях задачи, чтобы любой участник мог восстановить решение.

Слабая сторона — субъективность входных оценок. Модель легко «накрутить», завысив пользу или занизив размер желанной задачи. Записывайте доказательства, ставьте оценки совместно и возвращайтесь к факту после выполнения. Ещё одна опасность — бесконечно откладывать крупные стратегические проекты. Если большой результат обязателен, разделите его на ценные части или зафиксируйте отдельную ёмкость под долгую работу.

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

Чтобы начать, выберите пять-семь крупных кандидатов, договоритесь о шкалах и проведите совместную оценку. Сохраните аргументы и через цикл сравните ожидаемую пользу с фактической. Если расчёт регулярно расходится с результатом, уточните шкалу, а не усложняйте формулу. Хороший приоритет — тот, который помогает доставить ценность раньше и остаётся понятным команде.