О чем говорят приоритеты элементов бэклога
Портал №1 по управлению цифровыми
и информационными технологиями
Каждый ответственный сотрудник в вашей компании, вероятно, имеет собственное мнение о том, что является наибольшим приоритетом бизнеса. Но какой проект на самом деле должен быть приоритетным? К счастью, есть отличные методы, которые помогут определить приоритет задач в бэклоге продукта.
Менеджер по продукту: безумству храбрых поём мы песню
Взгляните на менеджера по продукту как на невоспетого героя, который должен «пасти котов» и подталкивать всех по каждой задаче, чтобы обеспечить соблюдение сроков, закрытие задач, развёртывание кода и выпуск продуктов. Речь идёт не только о том, чтобы все были сосредоточены и уложились в срок, но и об обеспечении достаточной гибкости и упорства в работе над задачами при достижении целей в ситуации, когда требования заказчиков и пользователей меняются. Любой хороший менеджер по продукту должен отлично знать свой продукт, но как он решает, на чем и когда сосредоточиться?
В этой статье рассматриваются различные методы приоритизации. Тут не преследуется цель продвижения какого-то конкретного фреймфорка, подхода или идеологии. Это обзор различных способов интерпретации и расстановки приоритетов в бэклоге продукта.
Что такое бэклог продукта?
Бэклог продукта – это список задач, необходимых для выполнения стратегических планов дорожной карты развития продукта. Бэклог предназначен для того, чтобы приземлить бизнес-идеи на практические задачи, включающие инструкции что и кому делать. В то время как дорожная карта развития продукта представляет собой общую картину, описывая высокоуровневые цели и стратегии, предназначенные для ЛПР, бэклог продукта – это список конкретных дел, составленный (возможно) для тех, кто выполняет основную часть работы: продуктовой команды и разработчиков.
Какие задачи содержатся в бэклоге продукта?
Задачи в продуктовом бэклоге различаются в зависимости от особенностей работы команды. Те, кто использует идеологию Скрам, могут обратиться к формату пользовательских историй (user story). При таком подходе задачи в бэклог продукта ставятся с точки зрения конечного пользователя. Например:
«Как (тип пользователей) я хочу (чего они хотят достичь), чтобы я мог (результат, которого они хотят достичь)»
Вне зависимости от выбранного способа описания, типичные задачи или истории обычно включают:
Важность приоритезации бэклога
Бэклог продукта должен представлять собой список всех связанных с продуктом задач, которые необходимо выполнить команде, с указанием исполнителей и сроков. Проблема в том, что список не является исчерпывающим. Он должен быть гибким и обязательно будет меняться в зависимости от обстоятельств. Например, быстрый выпуск продукта конкурентом может означать, что теперь нужно выпустить обновление продукта раньше, чем ожидалось, чтобы не утратить преимущества, а это означает, что всё остальное откладывается.
Даже такие события, как презентации на выставках (виртуальных или очных), могут означать, что команды меняют приоритет в сторону задач, необходимых для продаж и маркетинга, в надежде заполучить новых клиентов. Но возникает проблема, когда список задач продолжает пополняться, а менеджер по продукту изо всех сил пытается поддержать темп, необходимый для просмотра и организации всех задач по предпочтениям и приоритетам. Эффективный бэклог продукта должен быть хорошо структурирован, организован так, чтобы его можно было легко прочитать и понять, а также должен соответствовать актуальным стратегическим потребностям бизнеса.
5 вещей, которые никто не упоминает
Есть много людей, которые зарабатывают деньги на организации команд разработчиков и захотят продать вам свой «безотказный» метод. Ещё есть множество ресурсов, привязанных к службам, которые вы уже используете. Но хотелось бы отметить несколько важных моментов. Независимо от того, какие методы управления бэклогом продукта вы выберете, для того чтобы они заработали, необходимо пять вещей:
Методы приоритизации бэклога
1. Матрица «Влияние/усилия» (Impact Effort).
Задачи распределяются на матрице с двумя осями: уровень усилий и уровень влияния. Это легко проделать на собраниях с использованием доски и стикеров. Есть также специальные шаблоны в распространённых ресурсах Edraw, Miro и SketchBubble. Это упражнение хорошо проводить с участием членов продуктовой команды из разных подразделений, поскольку оно даёт возможность противопоставить разные приоритеты друг другу.
Дополнительно можно познакомиться с хорошим критичным анализом этого метода от Итамара Гилада.
2. Ранжирование по стеку
Повсеместно распространённый метод – это ранжирование по стеку. Составляется список элементов, которым требуется приоритезация, затем ранжируется от наиболее важных (верхняя часть стопки) к наименее важным (нижняя часть стопки). Получаем стек задач для обслуживания.
Преимуществ: номер один может быть только один. Этот метод гарантирует, что в поставке всегда максимальная ценность, и команда никогда не работает над малоценными задачами. Кроме того, им легко пользоваться. Недостатки: чаще всего приоритеты определяются субъективно, на основе интуиции, подкреплённой некоторой аналитикой.
3. Метод MoSCoW
Метод MoSCoW – альтернатива расстановке приоритетов в терминах «Важно/Нужно/Хочется» (High/Medium/Low).
Проблема с методом MoSCoW заключается в том, что он не помогает, если необходимо выбрать среди нескольких задач в списке обязательных. Кроме того, легко увидеть, что новые версии имеют приоритет над рефакторингом, если рефакторинг всегда делегируется категориям «могли бы сделать» или «можно обойтись».
4. Средневзвешенная кратчайшая работа выполняется первой
Принцип средневзвешенного кратчайшего задания (Weighted Shortest Job First, WSJF) используется в гибкой разработке программного обеспечения для определения приоритетов элементов работы на основе принципов бережливого производства. Определение достигается путём деления стоимости задержки (Cost of Delay) на время, необходимое для выполнения задачи.
Есть много разных математических способов вычислить это, но эмпирический способ – подумать о том, что потеряет компания в целом, если что-то не будет сделано или цель не будет достигнута. Это может означать финансовую и репутационную потерю, невозможность перепродать связанный продукт или узкие места, такие как задержка связанных релизов. Конечно, всегда будет определённый уровень субъективности, но, возможно, меньший, чем попытка определить, какая задача для пользователей является наиболее важной.
5. Приоритезация на основе данных
Возможно, вы поддерживаете коммуникации с отделом продаж, чтобы получить обратную связь через отзывы клиентов, или следите за настроениями пользователей в социальных сетях, чтобы понять, с какими проблемами они сталкиваются. Но есть ещё один инструмент, который помогает понять поведение клиентов, включая потоки пользователей и их болевые точки: данные. Использование прикладных инструментов для количественной оценки экономических последствий реализации задач может помочь при их приоритизации.
Хорошо, мы расставили приоритеты для нашего бэклога. Что теперь?
Автор Cate Lawrence
Источник
Техники скоринга и приоритизации бэклогов
Ну что, как там ваши планы на изоляцию? Зимние вещи убрали? Желанные киношки посмотрели? Пылящиеся книжки прочитали? А до полезностей, как всегда, нет времени. Да ладно, не оправдывайтесь — для тех, кто никак не выкроит часок для просмотра видео с нашего канала на Ютубе, мы сделали быстроусвояемую статью. Имейте совесть, всего-то 15 минут вместо 60:)
Ситуация
Когда есть есть бэклог, менеджеру нужно каким-то образом расставлять в нем приоритеты. Скрам говорит, что первыми должны идти самые важные с точки зрения бизнеса задачи. Но тут возникает две проблемы.
Первая — справедливый момент субъективизма: часто приоритеты выставляются так, как владельцу бизнеса взбредет. в голову. Но иногда владелец может сильно «галлюцинировать» и нести откровенную чушь, но при этом быть уверен, что все так и есть.
Вторая проблема: слишком много стейкхолдеров верхнего уровня со стороны бизнеса на больших проектах или в крупных компаниях. У каждого из них могут быть свои противоречивые требования. Если собрать, например, пять топов большой компании и попросить их приоритизировать свои требования, скорее всего, каждый будет утверждать, что его задачи имеют нулевой приоритет, и их нужно делать прямо сейчас.
Хорошие новости — есть несколько методик, которые помогают в этом случае:
Методы приоритизации задач
Как выглядит бэклог?
Бэклог — это таблица. В одной колонке — список чего-либо (какие-то хотелки), есть колонка с оценкой (estimate) и есть колонка с приоритетами. Приоритеты — это какие-то числа, как правило, большие. Большие для того, чтобы между приоритетами оставались «дырки», куда можно добавлять новые задачи (или чтобы легко менять приоритетность).
По классике приоритеты выставляются с точки зрения Business Value (ценности для бизнеса) — того, что для бизнеса нужно в первую очередь, оно и пойдет в работу на первом этапе. Но есть другие способы приоритизации, которые бывают удобнее — особенно, если у вас есть ворох разношерстных задач.
Story Mapping
Допустим, у вас есть очень много задач, они мелкие и вообще без приоритетов и привязки к каким-то группам. Что с ними делать? Разбейте их на Story Mapping. Как это работает:
Шаг 1. Строим последовательность того, как юзеры будут пользоваться вашим продуктом, и какие шаги они будут предпринимать. Простой пример:
Шаг 2. На стикеры выписываем, какие по каждому из этих процессов есть детали — чем ниже висит стикер у каждого этапа, тем ниже у него приоритет.
Результат: весь список задач разбит по шагам пути пользователя, плюс у каждой фичи есть приоритеты (чем ниже фича висит в листе, тем у неё ниже приоритет с точки зрения всего пути пользователя).
Где и как применять
Допустим, у вас действительно набралось очень-очень много задач. Тогда вы выписываете их все на стикеры и делаете Story Mapping. Лучше — в команде.
Другой вариант — у вас идёт брейншторм, вы придумываете, каким дальше будет ваш продукт и какие фичи брать в работу. У команды много идей, какие-то хотелки вам «насыпал» маркетинг — нужно понять, каким образом это всё вообще кластеризовать. Story Mapping особенно хорошо работает в такой ситуации.
Оговорка: этот метод применим именно с точки зрения продуктового менеджмента, когда есть много задач, непонятно, какие из них первыми брать в проработку. Грубо, когда мы только продумываем сам продукт и то, какой функционал он будет включать. Дальше это уже режется на кусочки, из которых можно создавать спринты, и забирается в работу.
Плюсы Story Mapping
Value & Effort (или Lean Prioritization) для идей
Другой хороший метод, который позволяет построить приоритеты на шкале — Value & Effort (или Lean Prioritization).
Шаг 1. Сначала вы берете 2 шкалы:
Тоже можно считать, что это оценка в часах (estimate), как в бэкглоге. Но можно измерять и в Story Point-ах (сравнительная оценка требований относительно друг друга) или в человеко-часах.
Шаг 2. Вы оцениваете все фичи по этим двум параметрам: по значимости и трудоемкости. Есть внешние системы (вроде Hygger или Airfocus Priorities&Roadmaps), которые позволяют в автоматическом режиме раскидать каким-то образом ваши фичи на такой вот доске. Оси при этом идут не от нуля — они подстраиваются под статистические данные, которые у вас получились.
Какие фичи забирать в первую очередь? Самые значимые и лёгкие, которые ближе всего к осям — они и по значимости в топе, и по стоимости адекватные:
Если в первую очередь мы забираем дешевые и хорошие, то потом — дорогие, но крутые:
Следом — все остальные. Фичи, которые слишком дороги и не имеют никакого смысла, вы либо оставляете «на потом», либо выбрасываете.
Где и как применять
При заказной разработке такую штуку имеет смысл проделывать с клиентом, если:
Эта методика не заставляет вас слепо верить алгоритму и брать именно рекомендованные им задачи, но благодаря ей у вас хотя бы будет подсказка, в каком направлении двигаться. Если в систему добавить новых задач, она может перестроиться. Ведь бывает, что вы сильно не уверены в своих оценках, и с течением времени аналитики их уточняют, либо вы сами уточняете оценки трудоемкости у программистов — в этом случае система также может перестраиваться в динамике. За счёт этого у вас будет более адекватная и картина мира.
MoSCoW
Еще один способ категоризации фич по нескольким группам — метод MoSCoW. Внутри — очень простые параметры:
M — Must Have: функционал, без которого вообще нельзя обойтись. Без него вы не сможете выпуститься, ваш продукт не заработает и вообще не будет нужен.
S — Should Have: функционал, который должен быть в проекте, но при прочих равных без него как-то можно обойтись.
C — Could Have: функционал, желательный для релиза.
W — Would Have: наименее практичный функционал — так скажем, «всё остальное».
Допустим, вы разрабатываете автомобиль. Must Have будут колеса, руль, ходовая часть, двигатель. Should Have — освещение ночью, сидения вместо стульев, двери и всё такое прочее. Could Have — автоматическая коробка передач и так далее. Таким же образом можно разобрать любой проект, где Must Have будет эдаким MVP.
Часто бывает, что приоритеты спускают сверху, от бизнеса, и они сконцентрированы на каких-то «хотелках» из Should Have, Could Have, Would Have, забивая на ключевые вещи (Must Have). Обычно мы это наблюдаем, например, на разработке дизайна интернет-магазина или дизайна какого-то проекта, где на систему оплаты доставки или чего-то, что на самом деле генерирует выгоду бизнесу, ставка делается в последнюю очередь. Почему? Потому что работать с Must Have больно и страшно: надо думать о том, как это будет монетизироваться, а в это никто не любит лезть, хотя это и неправильно.
Ещё один способ категоризации фичей, пришедший из маркетинга. Суть простая: есть две оси: «удовлетворенность пользователей» и «функциональность», и есть деление функционала на группы. Для каждой группы фич нужно понять, как меняется удовлетворенность пользователя от добавления этого функционала.
Первая группа — обязательный функционал: тот же Must Have из MoSCoW. Если эти фичи есть — уже хорошо. Об удовлетворенности речи не идёт: без них продукт никому не нужен. Более того, с течением времени функции, которые сначала были «изюминкой» проекта, становятся всё более обязательными. Пример: для серверного ПО канбан-доска когда-то была чем-то эдаким, а сейчас это тот самый мастхэв.
Другая группа — одномерные функции. Это значит, что есть прямая зависимость удовлетворенности пользователя от наличия этой функции. Как только функция появляется, удовлетворенность растет линейно. Если вернуться к примеру с созданием автомобиля, там это может быть климат-контроль.
Третья группа — функции, которые привлекательны. Это то, чего пользователь не ожидал, но когда он увидел хоть какую-то реализацию этого в вашем продукте, он офигел и сказал «о, круто!». Кто летал аэрофлотом, наверняка видел, как детям раздают «взятки», чтобы эмоционально привязать их к бренду.
Подарки для детей на борту «Аэрофлота» — источник
Как только такая функция появляется даже в посредственной реализации, удовлетворенность растет. А чем круче реализация, тем выше стремится график удовлетворенности.
Ещё одна группа — неважные функции. Их можно делать, можно не делать — всем будет безразлично.
Последняя группа — нежелательные функции. Когда их нет — все хорошо, как только они появляются — все становится плохо. Эдакие антифичи 🙂
Этот метод несколько сомнителен, поскольку непонятно, каким образом выбираются приоритеты у фич. По идее, нужно опрашивать пользователей: как они считают, хороша эта фича или не очень, а потом кластеризовать на основе мнения пользователей. При этом, еще и самих пользователей нужно разбивать на целевые группы и смотреть, как каждая функция к какой целевой группе относится.
Люди при опросах часто говорят ерунду и попросту врут. Они могут говорить, что это очень важная фича, но по факту они никогда не заплатят за неё деньги. Более того, если опрашивать пользователей, обратная связь по продукту может быть очень токсичной.
Вы планируете делать следующие релизы и опрашиваете группу людей. Кто-то из них может сказать: «А вот вы там платную функцию сделали, из-за неё продукт стал хуже, фи!» Только потому, что она за деньги, эта функция покажется кому-то ненужной. Хотя для бизнеса это может быть ключевая вещь, которая приносит прибыль.
Поэтому метод Kano — абсолютно из маркетинга, но как долгосрочная стратегия имеет место быть.
Классический метод приоритизации баг-листов
В основе — список приоритетов от 0 до 8:
0 — Критические баги
Когда тестер уткнулся и не может дальше проверять, когда система падает либо что-то ломается — в общем, когда дальше невозможно.
1 — Критичное юзабилити и забытые фичи
Здесь мы применяем в том числе метод покраски бэклога, технического задания, либо прототипа (в зависимости от того, что у нас есть на руках), чтобы определить, не пропустили ли мы что-то.
2 — Некритичные баги
Баги есть, но они не мешают тестировать продукт дальше, либо они позволяют пройти полностью по цепочке либо заказа, либо чего-то еще — то есть, дают полностью проверить наш продукт.
3 — Некритичное юзабилити
8 — Хотелки / не будем делать / на усмотрение менеджера
Да, промежуток между 4 и 8 сделан намеренно — менеджер при необходимости может докидать туда ещё какие-то задачи.
Для баг-листов способ хороший, но у него есть проблема. По большому счету мы в баг-листах оптимизируем метрику «готово — не готово». Объем работ понятен. Но часто встречается, что в некритичное юзабилити пытаются пропихнуть что-то такое, что находится на грани — вроде бы, юзабилити и вроде бы неплохо такое сделать, но по факту оно тянет на какую-то очень серьезную фичу.
Другая проблема — субъективизм тестировщика, который часто приходится перепроверять. Иногда это довольно трудоемкая история, когда вы лично просматриваете все баг-листы: смотрите, чего он там такого понаписал, и принимаете решение, что выкинуть, а что оставить.
Для приоритизации бэклогов такой метод не годится — для них нужны совсем другие критерии.
Оценка задач
Любая приоритизации должна отталкиваться от тех оценок, которые нам дали. Ведь трудоемкость действительно влияет на приоритетность какой-то функции. Но как определить трудоёмкость и в какой момент стоит обсуждать трудозатраты с программистом? Ведь до этого менеджеру всё равно нужно выставить хотя бы примерные оценки.
А если серьезно, обычно есть три варианта.
Приходит какой-то «верховный босс» и говорит, что из бэклога должно быть сделано прямо сейчас, и спускает вам оценки сверху. Это может быть технический директор, который расставляет оценки всех задач и говорит, что какая-то задача делается за столько-то, такая-то за столько-то. Или это можете быть вы сами 🙂
Берутся три оценки по времени: оптимистичная, пессимистичная и реалистичная, и строится график, называемый Гауссианой.
Для расчета наиболее вероятной оценки применяют формулу: (Оптимистичная + (Реалистичная * 3) + Пессимистичная) / 6.
В идеале наиболее вероятная оценка будет чуть дальше, чем реалистичная.
Нюанс в том, что не доказано, что в результате у нас получится нормальное распределение. Например, если взять группу людей и измерить их рост, то получится кривая, как на графике ниже: очень маленьких людей мало, очень высоких людей — тоже мало. И они не входят в норму. Остальные в выделенном диапазоне — и есть нормальное распределение.
Гауссиана подразумевает, что варианты, когда задача выйдет за отметку пессимистичной оценки или вообще никогда не будет сделана, стремительно уменьшаются. Но в ИТ-среде часто бывают задачи, которые, на первый взгляд, сделать «невозможно» — программисты для них требуют поменять постановку либо продолжают доказывать эту невозможность. Другая ситуация — человек оценил задачу в 1 час, потратил всё мыслимое и немыслимое время и пришёл к выводу, что не может сделать эту задачу.
Это наиболее простой и «чистенький» способ получить нормальные оценки, обсудить какие-то фичи, нюансы, детали. Даже на верхнем уровне по бэклогу можно такое проделать.
Минус Planning Poker — это довольно ресурсоемкая операция, поскольку нужно собирать всю команду вместе и читать бэклог. Но если вы применяете методы вроде Story Mapping, вам всё равно нужно собираться командой и делать предварительные оценки (хотя бы в днях, неделях — крупных величинах).
Плюсы Planning Poker
Техники скоринга
Помогают с определением приоритетов задач в бэклоге в условиях неопредленности — когда вы только планируете и оцениваете эффект от внедрения той или иной функции.
ICE Scoring
Аббревиатура состоит из трех параметров:
Чтобы оценить влияние той или иной фичи, стоит учесть несколько критериев:
Может основываться на:
Как измерять уровень уверенности — источник
Для получения ICE нужно умножить эти три параметра — это и будет приоритет на реализацию.
Плюсы: быстро и просто.
Минусы: у метода довольно ограниченная шкала — можно получить много задач высокого приоритета, потому что по ним будут понятны и постановки, сами задачи будут простые и будут казаться важными.
RICE Scoring
Здесь используется 4 параметра:
Функции, которые дают большой охват, в которых мы уверены и которые хорошо влияют на продукт и при этом дешевые по трудозатратам, находятся в топе по приоритетности в бэклоге.
Софт для приоритизации
Есть несколько программ для автоматической приоритизации — например, Hygger. Это система для Product Owner-ов, где есть много разных моделей, которые позволяют «поиграться» задачами.
Как выглядит Hygger изнутри — источник
То же самое проделать в любом гуглдоке: просто добавить три параметра, собрать данные — он посчитает. Это и будут ваши приоритеты. А дальше вы уже сами выбираете, что именно брать в спринт.
Иногда менеджеры для хранения всех тикетов и задач используют Jira. К сожалению, она не очень удобна для приоритизации — заточена на то, что кто-то расставляет приоритеты вручную, просто перетаскивая тикеты вверх-вниз по бэклогу. Это прикольно, если бэклог не на 1000 строк, но в какой-то момент вам станет утомительно делать это руками.
В Jira есть определенные способы классификации задач на эпики, компоненты, релизы, можно какими-то тегами задачи размечать. Есть несколько плагинов для скоринга (Issue Score for Jira, Priority Scoring Calculator), но по функциональности они не очень.
Из более-менее адекватных — внешние системы Hygger и Airfocus. Они интегрируются с Jira, но и стоят примерно столько же, сколько она сама. Поэтому самый простой способ — сделать интеграцию гуглдоков и Jira: выгружать туда бэклоги синхронно и уже там применять свои формулы, как вам нужно.
Как подружить Jira и Google Docs для приоритизации
Кроме приоритетов всегда есть проблема, как распределить по времени реализацию тех или иных задач. Когда есть только приоритеты, нет гарантии, что мы получим связанную систему (например, вы запланировали сделать корзину, а оказалось, что каталога еще нет). Поэтому помимо приоритетов также стоит использовать диаграммы Гантта, чтобы чтобы посмотреть связи в системе, насколько она корректно работает по компонентам и насколько оптимально вы распределяете ресурсы команды по времени.
В Jira, к сожалению, из «коробки» эта опция не очень хорошо реализована, поэтому тоже могут пригодиться несколько плагинов:
Как итог
Мы не избавляемся от субъективности — она остается на всех уровнях. В тот момент, когда мы говорим «это важная функция» или «это неважная функция» и когда мы даем какие-то оценки, субъективность сохраняется. Но благодаря перечисленным методам мы можем разбить эту субъективность на компоненты: по крайней мере, картинка будет более ясная.
Если вы используете такой параметр как «уверенность в оценке», вы можете с течением времени эту уверенность «докрутить». Например, у вас есть хорошая функция, которая и влияет на продукт позитивно, и дешевая, и охват дает большой, но уверенность в ней низкая. Проверьте её через метрики, аналитику, запрос экспертов, вопросы программистам — и уточните.
Для оценок хорош Planning Poker, плюс мы посмотрели несколько методик для категоризации задач. Если у вас идёт стратегическая сессия с клиентом, попробуйте Story Mapping со стикерами и распределением их по шагам пользователя. На внутренних продуктах тот же метод поможет выбрать функции, которые стоит взять в следующие релизы. Для бэклогов лучше остальных подходит RICE Scoring, чтобы оценить, какие задачи куда пойдут.
Но помните, что конечное решение — всегда за менеджером, а полученные с помощью методов циферки только задают направление.
До встречи в новых видео на нашем YouTube-канале!