Приоритизация бэклога

Есть предположение, что в моей статье могут быть непонятные наборы букв, поэтому сразу объясню некоторые термины.

• RUN – это текучка,

• CHANGE – это развитие, новое.

• OKR – это целеполагание на уровне от стратегий до команд, направленных на создание новой ценности.

Идеальный Backlog по Scrum Guide

Если обратиться к Scrum Guide, там сказано, что backlog – это:

• Упорядоченный список известных требованиий к продукту,

• Единственный источник требований любых необходимых изменений в продукте,

• Владелец Продукта является ответственным за Backlog продукта, включая его содержимое, доступность и упорядоченность.

Положа руку на удобную вам часть тела, скажите: у вас в компании так?

Признаки идеального бэклога:

• Очередь ценных задач для поставки на рынок.

• Прозрачность для команды и заинтересованных лиц.

• Упорядоченность по ценности, зависимостям, рискам.

• Если владелец продукта уйдет в отпуск или заболеет, не возникнет так называемый bus factor – команда всегда знает, что делать.

• Является драйвером любых обсуждений.

За свою жизнь я еще не встречал ни одной компании, где это действительно так. Чего из этого обычно не хватает в командах? На самом деле – всего.

Реальность бэклогов в компаниях

Каждая компания уникальна по-своему. Где-то приоритизация строится по принципу «кто громче кричит, тот и прав».

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

Если backlog упорядочен:

1. Все всегда знают, что происходит. Можно даже построить Gantt-диаграмму, которая будет соответствовать действительности.

2. Быстрее происходят релизы и обновления, быстрее выкатывается новый функционал.

3. Команда не работает в стол – она делает только важные и нужные для бизнеса задачи, все остальное отсекается.

4. Как следствие, снижаются риски. Разработка и delivery – самый дорогой этап в цепочке создания ценности. И если этот этап загружен действительно важной и ценной работой, то на выходе мы получаем максимальную отдачу.

Если этого нет:

1. Обычно применяется подход «кто громче кричит».

2. Много работы в стол, частые переключения и смена приоритетов.

3. Низкая или нулевая ценность того, что делает команда.

4. Частые конфликты между командой и заказчиками. В какой-то момент это приводит к «бойцовскому клубу» между бизнесом и IT: бизнес считает, что айтишники ничего не делают в срок, а IT – что бизнес сам не знает, чего хочет.

Пример с кухней и метод приоритизации по MoSCoW

Я расскажу про несколько простых, «бытовых» методов приоритизации, которые можно использовать хоть завтра. Забегая вперед, стоит сказать, что лучшая приоритизация – кастомная, собранная под конкретную команду и заказчика. Как ее сделать – тема отдельного разговора.

Для примеров буду использовать кухню. Все мы хотя бы раз меняли у себя дома кухню – либо планировали, либо действительно это делали. Поэтому пример с кухней показался мне наглядным и понятным. Представим: у меня есть определенная сумма денег и список хотелок в голове.

Первый способ приоритизации – MoSCoW.

У нас есть несколько критериев:

• Must – то, что необходимо сделать в любом случае,

• Should – не самые важные требования, но они тоже должны быть выполнены,

• Could – желательные требования, которые можно сделать, если останется время и будут ресурсы,

• Would – хотелки, которые можно проигнорировать или перенести без вреда для продукта.

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

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

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

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

Таким образом, я расписал свои приоритеты и хотелки. У каждого они будут свои – например, в моей картине мира холодильник стоит за пределами кухни, поэтому его в этом списке нет.

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

Минусы: метод не объективен, не учитывает риски и техническую сложность реализации. Тем не менее, для заказчика это лучше, чем полное отсутствие приоритизации. Для команды – тоже.

Метод приоритизации ICE

Следующий тип приоритизации – ICE.

Здесь все достаточно просто: мы перемножаем три показателя – влияние (Impact), уверенность (Confidence) и простоту реализации (Ease).

Тот же пример с кухней, те же критерии. У нас есть шкала, где каждому элементу присваиваются оценки по трем столбцам:

• Impact (Влияние) – это оценка того, насколько сильно идея повлияет на бизнес.

• Confidence (Уверенность) – это оценка вашей уверенности, насколько идея повлияет на продукт и как просто ее будет реализовывать.

• Ease (Простота) – это оценка, насколько легко или сложно реализовать идею.

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

По сути, это субъективная, но быстрая оценка – «на глаз», по принципу «палец-потолок». Но это все равно лучше, чем отсутствие каких-либо критериев.

Плюсы метода: простейший алгоритм и высокая скорость принятия решений.

Минусы: субъективность и относительность результатов.

Метод приоритизации RICE

Следующий метод приоритизации – RICE.

Хотя он похож на ICE и отличается всего одной буквой, здесь появляется дополнительный показатель – охват (Reach), а сама формула немного меняется.

Теперь у нас есть четыре параметра:

• охват (Reach) – количество пользователей, которых затронет изменение,

• влияние (Impact) – насколько сильно идея повлияет на продукт или бизнес (оценка от 0,25 до 3: 0,25, 0,5, 0,75, 1, 2 или 3),

• уверенность (Confidence) – от 10 до 100%, отражает, насколько мы уверены в оценках и готовы «лечь костьми» за идею,

• трудозатраты (Effort) – оцениваются в часах.

Формула выглядит так:

RICE = (Reach ? Impact ? Confidence) / Effort

Здесь уже появляются количественные, более объективные показатели – например, реальное количество пользователей и оценка трудозатрат в часах.

Плюсы метода: наличие количественных метрик и снижение уровня субъективности.

Минусы: легко переоценить идею, особенно если кажется, что охват велик. В таком случае автоматически «поползет» вверх и уверенность в оценке.

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

Метод Cost of Delay / WSJF

Следующий метод приоритизации – Cost of Delay, часто используемый вместе с WSJF (Weighted Shortest Job First). Этот подход удобен тем, что его можно автоматизировать во многих трекерах – например, в Jira, Kaiten или Asana.

Как это выглядит на практике? В команду поступает идея. Она не двигается дальше стадии Discovery до тех пор, пока заказчик не определит ее ценность – то есть не укажет, сколько конкретно в деньгах планируется получить от реализации этой идеи. После этого идея уточняется: проводится техническая проработка, затем на груминге или PBR команда декомпозирует ее на задачи, оценивает трудозатраты и формирует общую оценку.

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

При оценке рекомендуется использовать ряд Фибоначчи – ряд, где каждое следующее число является суммой двух предыдущих (1, 2, 3, 5, 8, 13 и т.д.). Если оценка превышает, допустим, 8 или 13, это сигнал, что растет неопределенность: нужно декомпозировать фичу на более мелкие составляющие, не теряя при этом бизнес-ценности.

Такой способ оценки часто применяют уже перед постановкой задач в разработку – он идет последним этапом перед очередью. Однако сам по себе он недостаточен. Если используется WSJF, всегда нужен дополнительный метод приоритизации «на входе».

Например, заказчик приходит с предложением «добавить снег на сайте к Новому году». Звучит эффектно, но не несет бизнес-ценности. Продукт-менеджеру нужен инструмент, чтобы аргументированно сказать: «Нет, потому что это не принесет денег».

В этом отношении полезна книга «Пять способов сказать нет стейкхолдеру» – в ней подробно разбирается, как корректно отказывать заказчикам.

Плюсы метода WSJF:

• Единовременная приоритизация всего бэклога,

• Эффективная шкала оценки,

• Важные и актуальные критерии.

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

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

Та же логика применима и к команде: обещали две недели, сделали за три месяца. Это не упрек и не попытка наказать, а способ итеративно корректировать интуитивные ожидания и приближать их к реальности.

User Story Mapping

Эта техника заслуживает отдельной статьи, но кратко – суть в следующем.

Берем проект, например, ту же кухню. В голове формируем представление о продукте и делим его на основные составляющие – своего рода скелет, без которого новая кухня не может существовать. Это каркас, техника, элементы удобства и что-то для эстетики и феншуя.

Разделение можно делать по-разному: по CJM (клиентскому пути), по этапам или вехам проекта. Главное – понимать, через какие стадии проходит продукт или проект.

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

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

Плюсы метода:

• Помогает быстро и эффективно понять, что должно входить в MVP,

• Фокусируется на пользовательском опыте,

• Это совместная работа. В формировании историй участвует вся команда.

Минусы:

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

Приоритизация багов

Приоритизация багов обычно строится на двух критериях – критичность и срочность.

• Критичность – это комплексная оценка, включающая степень влияния ошибки: блокирует ли она работу системы, затрагивает ли широкую аудиторию, влияет ли на ключевые бизнес-процессы,

• Срочность – это показатель того, насколько «нужно вчера».

Если объединить эти два параметра, получится простая, но понятная формула приоритизации: Приоритет = Критичность ? Срочность. Такой подход позволяет быстро оценить, какие баги нужно устранять в первую очередь. Разумеется, лучшая приоритизация всегда кастомная – настроенная под конкретную компанию, продукт и команду.

Критичность можно образно описать как «объем проблемы», а срочность – как «насколько горит».

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

Сначала возникает сопротивление: «Я ведь все знаю, 25 лет в этом бизнесе». Но после этой первой волны отторжения наступает момент переосмысления. Появляется мысль: «Ладно, послушаю, даже если ерунду скажут». И постепенно это приводит к осознанию: «Надо же, они оказались правы».

Этот процесс не быстрый – человек не робот, невозможно щелкнуть пальцами, чтобы мышление изменилось мгновенно.

Работа с данными и построение модели приоритизации

Есть одна универсальная истина: данных всегда мало. Но при этом их всегда достаточно, чтобы формулировать гипотезы.

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

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

Попросите их объяснить, по каким критериям они принимают решения. Пусть при вас оценят 10, 15, 30 задач – это поможет понять логику. Если не получается, значит, «брали не за те грудки». Иногда помогают такие методы мотивации, как паяльник и утюг. В какой-то момент человек все равно начинает делиться.

В любом случае важно найти тех людей, через которых проходят решения по задачам. Если они начинают защищаться, можно сказать им примерно так: «Ты отличный артиллерист, но кто-то ведь должен подносить тебе снаряды. Давай я возьму это на себя хотя бы на время».

Когда человек немного расслабится, он начнет делиться – пусть частями – полезной информацией.

– Почему ты эту задачу поставил?

– Потому что у нее важный заказчик.

– А эту?

– Потому что верю в нее.

– А на основании чего веришь? Опыт, интуиция, похожие кейсы?

Через такие задушевные разговоры можно собрать довольно много данных. Да, их всегда будет недостаточно, но это нормально.

Смотрите на процессы как Шерлок Холмс через увеличительное стекло – ищите то, чего лично вам не хватает. Если, как у аналитика или продакта, у вас остается ощущение неудовлетворенности процессом, значит, где-то в модели приоритизации есть пробел.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.