Когда мы говорим о приоритизации какой-либо работы, у нас есть всего несколько путей.
FIFO first in, first out «первым пришёл — первым ушёл»
Первый путь, самый простой и в профессиональной среде называется FIFO (First In, First Out), что означает "первым вошел – первым вышел". Данный подход применяется очень часто в различных областях, например, живые очереди в поликлинике работают по такому принципу. Тот, кто первый встал в очередь, обслуживается в первую очередь.
Метод FIFO хорошо работает там, где задачи равнозначны. Каждый из участников очереди платит тем, что ждет своей очереди, и ожидание в очереди примерно одинаково для всех и зависит только от длины очереди.
А как по другому?
Но что делать, если ценность выполненной работы сильно отличается? Как бизнесу из всего списка задач понять, что более важное, а что может подождать? Как определить, что действительно самое важное?
Для этого существуют модели приоритизации, которые также называются скорингом.
Первый раз я применял скоринг на практике, когда создавал отдел продаж в одной из IT-компаний. В отделе продаж были потенциальные клиенты, и обработка каждого клиента занимала много времени. Очень важно было определить, какого клиента обрабатывать в первую очередь.
Позже у меня было много похожих задач, и сейчас, в роли Agile коуча, я обучаю команды и владельцев продукта приоритизировать свой бэклог.
Сегодня мы рассмотрим одну из множества техник приоритизации. Почему именно ее? Просто потому, что сегодня именно о ней я рассказывал на работе.
WSJF (Weighted Shortest Job First)
WSJF (Weighted Shortest Job First) переводится как "сначала самая ценная и короткая работа". Когда-то, когда вычислительные ресурсы были очень ограничены, этот метод использовался для приоритизации пакетных заданий. Этот принцип успешно перенесен в приоритизацию бэклогов в сфере IT.
Как рассчитывается приоритет по WSJF?
WSJF = Стоимость задержки / Сложность задачи
Стоимость задержки = Пользовательская или бизнес-ценность + Критичность по времени + Снижение рисков или новые возможности
Каждое из значений – это коэффициент, соответствующий ряду Фибоначчи (1, 3, 5, 8, 13, 21). Если мы говорим оценке бэклога в Scrum, то владелец продукта, совместно с командой, оценивает каждый из показателей на основе своего опыта. Если оценки различаются, то в формате диалога находится оптимальное значение, часто для этого используется покер-планирование, о котором я расскажу в следующих статьях.
- Сложность задачи - насколько элемент сложен в реализации, сколько времени и ресурсов это займет. Чем выше сложность, тем выше оценка. Сложность задачи оценивает команда разработки.
- Пользовательская или бизнес-ценность - насколько ценна для бизнеса или пользователя данная функциональность. Чем выше ценность, тем выше оценка. Данный показатель оценивает владелец продукта, основываясь на исследованиях о продукте или интервью с пользователями.
- Критичность по времени - насколько важно реализовать этот элемент сейчас? Что мы выиграем от быстрой реализации, и что мы потеряем, если реализация данного элемента отложится? Именно эти вопросы нужно задать, чтобы оценить данный показатель. Для примера, представьте, что вы и ваш конкурент хотите выпустить один и тот же функционал, которого еще нет на рынке. Критичность по времени в этом случае будет высокой, так как предположительно тот, кто выпустит функционал первым, соберет самую большую долю рынка этой услуги. Чем выше критичность, тем быстрее нужно это сделать, и тем выше оценка
- Снижение рисков или новые возможности - Данная доработка снижает риски наступления негативных событий? Данная доработка откроет нам новые возможности? Если хотя бы один из ответов на эти вопросы "да", то данный показатель скорее всего больше единицы. Чем выше снижение рисков или потенциал новых возможностей, тем выше оценка.
Проще всего это делать в Excel, где каждому показателю выделена одна колонка.
Важные правила расчета WSJF
Есть несколько важных правил для заполнения данных показателей:
- Заполнять нужно колонки последовательно; сначала заполняем, например, сложность задачи для всех задач, а затем заполняем для всех задач критичность по времени и так далее.
- Начинаем заполнять с минимального значения в колонке, проставив этому элементу единицу. Остальные элементы заполняются относительно самого маленького значения.
На основании расчетов получаем значение WSJF для каждого элемента. Чем выше данное значение, тем приоритетнее нужно выполнять данный элемент.
В заключение важно отметить, что как и любая модель WSJF, это всего лишь инструмент, который помогает понять, что более важное, а что менее важное. Решение о итоговом приоритете должен принимать человек, и в контексте Scrum это владелец продукта.
Если статья понравилась подписывайтесь на канал "Путь Agile" в телеграмм
