WSJF или как мы сэкономили недели на принятии решений

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

Всем привет, это снова Никита Кармаз и мы снова говорим о бизнесе и построении рабочих процессов. Сегодня речь пойдёт о приоритезации, а точнее о том, как её построить. Я не стану рассказывать о каких-то сложных методологиях, громоздких процессах, психологии и многом другом, о чём рассказывал раньше. К аспекту приоритезации мы подойдём прагматически, я бы даже сказал математически.

Я расскажу о конкретной формуле и о том, как эта формула помогла интернет-магазину, с которым я работал на протяжении трёх лет, сэкономить сотни часов на принятии решений и определении порядка работ.

Немного о проблеме. Интернет-магазин столкнулся с ситуацией, когда появлялась идея о добавлении нового функционала, но реализация этой идеи на практике сильно тормозила. “Всегда есть задачи, которые нужно решать в течение Scrum-итерации” или “Специалисты не могут сразу переключиться на работу с новым функционалом”, а очень часто “Это вообще к нам не относится. Работа пока есть, а на расширение нет ни времени, ни денег”. Любое обсуждение и попытки “пожертвовать” чем-либо в угоду перспективы наталкивались на несогласие, волокиту и желание перетянуть одеяло на себя.

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

Процитируем классику: “Мы никогда так не ошибались в своей жизни”.

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

Для начала разберём, что такое приоритезация. Начнём с простого определения.

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

Тут всё очевидно: Благодаря приоритезации компании избегают распыления сил команды, ускоряют процесс разработки нового функционала и определяют чёткий порядок выполнения работ.

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

• RICE (Reach — охват, Impact — влияние, Confidence — достоверность, Effort — усилия) — формула, которая основывается на количестве затронутых пользователей (Reach), возможном влиянии на пользователей (Impact), общей оценке первых двух факторов (Confidence) и трудозатратах (Effort) на реализацию задачи.

• ICE (Impact — влияние, Confidence — уверенность, Ease — легкость реализации) — формула, которая опирается на факторы влияния на пользователей (Impact), уверенности в масштабе этого влияния (Confidence) и простоте внедрения инициативы (Ease).

• Value vs Effort — формула позволяет ответить на два ключевых вопроса: какую пользу принесёт реализация данной задачи (Value) и сколько сил будет затрачено для её выполнения (Effort). Сравнение двух показателей позволит понять, насколько важной является задача.

Все они являются наиболее популярными и наиболее эффективными, но лично для нас они дополнительно были объединены одним серьёзным недостатком.

Все эти формулы нацелены на процессы, лежащие за пределами самой компании. Охват и влияние на аудиторию, возможная польза от реализации задачи — всё это факторы , которые трудно прогнозировать и которыми трудно управлять. Все прогнозы о возможной прибыли и преимуществах являются субъективными, хоть и основываются на конкретных данных.

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

С этой позиции наш выбор пал на WSJF.

Принцип работы формулы лежит в самом названии. WSJF означает Weighted Shortest Job First, т.е. самые важные и простые задачи первостепенны. Это система оценки, результатом которой является приоритезированный список задач, где первая — самая простая в реализации, но при этом и самая ценная с точки зрения бизнеса.

WSJF работает по следующей формуле:

Теперь разберём числитель и знаменатель, а также систему рассчёта.

Cost of Delay — ключевой показатель, который представляет из себя сумму следующих факторов: Ценность для бизнеса (Business Value); Временная критичность (Time Criticality) и Фактор риска (Risk Reduction).

• Business Value ­ – критерий, оценивающий степень полезности задачи/фичи для бизнеса;
• Time Criticality – важно сделать задачу быстро или её выполнение может подождать?
• Risk Reduction – оценивая этот параметр фактически нужно ответить на вопрос – «от каких рисков мы сможем себя уберечь?».

Оценка всех трёх факторов и является основой для последующей приоритезации. Но как она происходит?

Здесь в дело вступает ряд Фибоначчи. Это числовая последовательность, в которой первыми показателями являются 0 и 1, а последующие числа есть сумма двух предыдущих чисел (0, 1, 1, 2, 3, 5, 8, …). Главный плюс, из-за которого используется именно эта последовательность, в том, что она не линейна, то есть, сложнее давать одинаковую оценку всем задачам, а разница приоритетов демонстрируется куда сильнее.

Далее составляем таблицу, где горизонтальной линией представлены три указанных фактора Cost of Delay и параметр Job Size (как долго будет решаться задача, её объёмы и силы, которые нужно затратить), а вертикальной — все задачи, которые нужно реализовать. Все члены рабочей команды или отдела присваивают свои числа каждой из задач (1 — минимальный уровень важности, 21 — максимальный). Важно, чтобы оценка проводилась всеми специалистами в пределах одного столбца. В итоге имеем следующую таблицу (данные взяты для примера, у нас было гораздо больше задач):

В конце суммируются баллы по трём факторам, и результат делится на число параметра Job Size. Задача с наибольшим баллом считается приоритетной. Стоит помнить, что параметр Job Size предполагает градацию от большего числа к меньшему.

Всё выглядит довольно логично, но мы, например, сразу же столкнулись с человеческим фактором. Некоторые специалисты были не согласны с оценкой, поскольку считали своё направление и работу наиболее важной (или наоборот). Но я сразу объяснил, что с числами невозможно спорить, после чего мы провели углубленное изучение задачи для понимания контекста и масштабов, а все возражения тут же отпали.

То, что приоритезация играет колоссальную роль в построении рабочих процессов, это факт, с которым трудно спорить, хотя я часто встречал мнения о том, что она нужна лишь тогда, когда одна команда работает над несколькими проектами одновременно или когда менеджеры не могут решить, кому сколько ресурсов нужно дать. Но даже если и так, то неужели это уменьшает значимость приоритезации? Лично для меня, ни в коем случае.

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

Тем не менее, выбирать модель приоритезации стоит исходя именно из сложности бэклога и целей вашего менеджмента. Я вообще посоветовал бы использовать несколько методов подряд, либо некую комбинацию, чтобы найти вариант идеально подходящий именно вам (хотя понимаю, что такое количество времени и ресурсов просто для пробы – это нечто на уровне фантастики).

А на сегодня всё. Желаю всем удачных проектов и постоянного профессионального развития. До новых встреч.