Привет, Хабр!
Если вы не разработчик и не понимаете, каким способом разработка определяет приоритет вашей задачи (спойлер: лунный календарь или ретроградный Меркурий к этому не имеют отношения), то эта статья будет вам полезна.
Если вы продакт-менеджер, который видел все в этой жизни, и отчаялся настолько, что уже готов приоритизировать бэклог по картам таро, то эта статья будет вам полезна.
Если вы разработчик и устали гореть от того, что задачи в бэклоге выстраиваются по пирамиде Маслоу или рандомайзеру, то эта статья будет вам полезна (как минимум, разбавите рутину на следующем стендапе).
В общем, в новом посте рассказываем про популярные способы для приоритизации бэклога команды разработки и почему мы запилили свой.
Кастомный метод Content AI
Начнем с разбора фреймворка под кодовым названием «Кастомный метод».
Зачем нам все эти мучения?
По мере развития нашего многолетнего, объемного и сложного продукта ContentCapture (это кросс-платформенное решение для интеллектуальной обработки информации), мы все чаще стали испытывать сложности в приоритизации его бэклога. Продукт обрастал не только новыми фичами из роадмапа, но и функциями, которые просили заказчики. Балансировать между этими двумя важными составляющими становилось все сложнее, приоритизация выполнялась практически вручную, а неприоритетные тикеты покрывались трехслойной пылью на дне бэклога.
Почему и зачем мы пришли к такой формуле?
1. В В2В-продуктах сложно (даже сказали бы почти невозможно) организовать массовые опросы заказчиков. А на этом строятся все качественные методы приоритизации бэклога.
2. Как правило, заказчики зрелого продукта — крупный энтерпрайз, от которого часто поступают запросы на доработку разного масштаба. И собственная формула приоритизации бэклога помогает балансировать между такими запросами и задачами, направленными на стратегическое развитие продукта.
3. Кастомная формула помогает максимизировать результат от разрабатываемых фич. И здесь не так важно, пришли эти фичи в качестве запроса от энтерпрайза, были в дорожной карте продукта или спонтанно родились на очередном спринте. В классических методах, причем как в качественных, так и в количественных, скорее всего у многих задач получится одинаковый приоритет, а в специально разработанной формуле для конкретного продукта их удастся ранжировать с высокой точностью и оптимальностью.
4. Исходя из нашей практики, оценка трудозатрат часто бывает ошибочной. Когда над одной фичей трудятся несколько команд с разным стеком, разработчики не всегда учитывают межкомандные взаимодействия. Кроме того, разработчики не всегда могут использовать для оценки трудозатрат референсы на уже выполненные задачи (если мы хотим в продукте сделать что-то принципиально новое и инновационное). Все это приводит к чересчур оптимистичным ожиданиям.
Как ранжируется бэклог по нашей формуле?
Здесь все по классике: каждой фиче дается оценка, на основе которой составляется приоритизированный бэклог. Считается эта оценка по формуле:
Пояснения к формуле
Сразу уточним, что каждое звено формулы, за исключением оценки трудоемкости и риска разрастания, считаются по числам Фибоначчи. Вот их значения.
По итогу каждая фича получает общую оценку, в соответствии с которой она ранжируется с остальными задачами и попадает на определенную строчку бэклога.
Пример
Дано: фича — распознавание русского рукописного текста (если что, мы ее уже внедрили, тут рассказали как).
Определить: насколько задача приоритетна для развития продукта.
Решение: считаем каждую составляющую формулы.
Вероятность успеха — 8 (многие клиенты просили эту фичу, мы уверены на 80%, что они готовы заплатить за ее внедрение)
Выручка с проекта — 13 (у нас есть уверенность в намерениях только части заказчиков)
Частотность запросов — 5 (получили 6 запросов от клиентов на эту фичу)
Период выручки — 13 (рассчитываем, что мы получим выручку за фичу уже в текущем квартале)
Блокер — 13 (фича — срочная и важная)
Оценка трудоемкости — 90 (рассчитываем, что разработаем фичу за 90 дней)
Риск разрастания — п. 1 (50%) + п. 6 (15%) = 65%, что соответствует 5 в числах Фибоначчи
Осталось все значения подставить в формулу:
8×13×5×13×13 — 90×5 = 87 430
Ответ: вес функции по распознаванию русского рукописного в бэклоге продукта равен 87 430.
Далее сравниваем значения всех задач в бэклоге и ранжируем их по убыванию (от приоритетной к менее важной).
Pros and cons
Плюсы кастомного метода
учитывает потенциальную выручку от реализации конкретной фичи
оценивает количество запросов клиентов на внедрение фичи
оценивает трудовую емкость с коэффициентом риска
позволяет учесть эскалацию потребности фичи в горящих сделках
помогает найти баланс в развитии продукта: учитывает как запросы пользователей, так и требования для реализации продуктовой стратегии, включая те аспекты, о которых заказчики еще не догадываются
Минусы кастомного метода
необходимость проводить эксперименты с параметрами формулы для точной настройки баланса в каждом отдельном случае: для одних приоритет — выручка, для других — рост пользовательской базы, а для третьих — возврат инвестиций от фичи
для точности необходима квартальная переоценка параметров, которая может быть выполнена вручную или с помощью настройки специального ПО для управления бэклогом
RRC (для багов)
RRC — это такая же формула приоритизации, только для багов. Идея метода проста: прежде всего чинить такие проблемы, которые мешают большему количеству людей самым серьезным образом.
Regress — откат (функция перестала работать или никогда не работала)
Reach — охват пользователей, страдающих от бага
Criticality — критичность бага
Метод хорош тем, что позволяет не только отсортировать бэклог багов, но и сформулировать критерий качества для выпусков продукта. К примеру, поставить цель исправить в новом релизе все ошибки, у которых RRC-score меньше 3.
Формула такая — каждой компоненте присваивается цифра, их сумма дает score бага. Чем он ниже, тем баг приоритетнее.
Плюсы: формула проста в применении. Внутри команды можно прийти к взаимной калибровке. Положительный эффект у техподдержки из-за детального разбора каждого бага.
Минусы: требуется общее представление ЦА продукта и его ценности для подсчета компонент Reach и Criticality; балансирование между количеством пользователей и критичностью багов.
Качественные и количественные методы
В этом разделе рассмотрим 6 популярных фреймворков, которые нам не подошли. Каждый из них проанализирован с точки зрения применения к нашим продуктам, а в разделе «минусы» выделили основные причины, по которым они не оправдали наших ожиданий.
Но вначале небольшой дисклеймер. В процессе приоритизации бэклога хороший продакт-менеджер в первую очередь руководствуется здравым смыслом. Существующие модели приоритизации – это всего лишь инструменты, которые помогают «обернуть» бэклог в определенную логику, повышают прозрачность процесса развития продукта и дают команде понимание, куда и почему продукт движется. Также стоит отметить, что на выбор модели приоритизации влияют: стадия развития продукта, тип клиентов, пользующихся этим продуктом, и степень зрелости компании, в которой продукт создается.
Все методы приоритизации бэклога можно условно разделить на две группы: качественные и количественные.
Качественные методы
Под качественными методами подразумевается определение неких качественных свойств той или иной функциональности продукта для того, чтобы оценить необходимость и приоритетность ее внедрения.
MoSCoW
Название метода MoSCoW произошло от игры слов сослагательного наклонения в английском языке – Must-Should-Could-Would. Всем компонентам бэклога фактически присваивается одно из четырех свойств. Упрощенно рассмотрим каждое из них на примере такого продукта как автомобиль.
Must have — это критические функции, которые обязательно должны быть в продукте (наличие колес)
Should have — это важные функции, которые должны бы были быть в продукте (наличие автоматической коробки передач)
Could have — это полезные функции, которые могли бы быть в продукте (наличие кондиционера)
Would have — это функции, которые хорошо бы, чтобы были в продукте (современная стереосистема)
Плюсы: простой и интуитивно понятный фреймворк; с его помощью проще общаться с бизнесом, стейкхолдерами или с клиентами без технической базы.
Минусы: есть большая вероятность попасть в ловушку субъективности, переоценив или недооценив ту или иную фичу. Если даже говорить на примере автомобиля, то для кого-то наличие стереосистемы — must-have, а для кого-то и до would не дотянет. К тому же фича, которую оценили как Would have, со временем может стать Should have или даже Must have. Поэтому приоритеты надо периодически пересматривать. На наш взгляд, метод больше подойдет стартапам или продуктам, которые находятся в самом начале своего пути.
Карта пользовательских историй
Этот метод также неплох в ситуациях, когда продукт разрабатывается с нуля. Здесь приоритизация строится на проведенных интервью с пользователями и командой. После на их базе описываются некие пользовательские истории, для реализации которых уже определяются конкретные фичи и их последовательность внедрения.
Плюсы: продукт строится от пользователя; можно быстро определить круг работы для MVP.
Минусы: невозможно подсчитать, сколько продукт принесет денег или какова его ценность для компании. Если же продукт большой, сложный и зрелый, то карта историй становится громоздким документом, с которым сложно эффективно работать.
КАНО
КАНО — самый, на наш взгляд, сложный из качественных фреймворков приоритизации. Метод может использоваться не только для приоритизации бэклога, но и, к примеру, для приоритизации задач по стратегии.
Модель работает так. Все функции в продукте делятся на три основные группы. В первую входят обязательные функции, без которых пользователь не будет использовать продукт. Во вторую — производственные функции, чем они шире и разнообразнее, тем выше удовлетворенность клиента. В третью входят функции восхищения или привлекательные функции — те, которые пользователь не ожидает, но он очень рад, если они появляются.
Для приоритизации этих трех групп строится система координат: от плохой к хорошей реализации по горизонтали и от нравится-не нравится по вертикали.
После каждому клиенту задается два вопроса:
как отнесетесь к тому, что этой характеристики не будет в продукте, или она будет, но очень плохо реализована?
насколько вам понравится, что у продукта появится эта характеристика?
На основе ответов строится матрица, по ячейкам которой располагаются все функции, в том числе наглядно показывая их приоритизацию.
Плюсы: более сбалансированный подход к качественной оценке важности фич. Также помогает построить продукт в соответствии с ожиданиями целевой аудитории.
Минусы: в основном метод хорошо работает для В2С-продуктов. Для В2В может возникнуть сложность на этапе опроса клиентов, т.к. реализация таких продуктов в основном происходит через партнеров. Если до клиента все же удалось дойти, то не факт, что он в полной мере поймет функцию, о которой идет речь в опроснике, или верно оценит ее потенциал, исходя из личного восприятия. И в целом для получения минимально репрезентативных данных, нужно провести большое количество интервью.
Количественные методы приоритизации
Количественные методы приоритизации отличаются от качественных тем, что строят гипотезы на основе количественных показателей фич.
Ценность vs Усилия (Value vs Effort)
Еще этот метод часто называют ROI (Return on Investment) или Benefit vs Cost (выгода против затрат).
Этот подход встречается во многих компаниях, причем порой не в качестве самостоятельного метода, а дополнительного — для того чтобы убедиться, что другие модели приоритизации плюс-минус отвечают именно бизнес-потребностям пользователя, а также эффективности разработки для компаний непосредственно.
Суть подхода заключается в оценке двух параметров для каждой новой функции — бизнес-ценности и сложности реализации.
Бизнес-ценность может оцениваться по-разному: для кого-то это деньги, для кого-то количество платящих пользователей, для кого-то влияние на текущие или стратегические цели в числовом выражении. В параметре сложности реализации, как правило, используется числовая оценка затрат либо стоимости внедрения. Считаются они как в абсолютных значениях, так и в абстрактных Story Points.
После определения этих двух параметров, первый делится на второй и получается некий коэффициент фичи. Затем полученные коэффициенты сортируются по убыванию, тем самым приоритизируя бэклог в зависимости от ценности для бизнеса по отношению к затратам.
Плюсы: гибкость, дополнительный метод для проверки текущей модели приоритизации.
Минусы: финальный коэффициент может не отражать реальную картину разработки, может не подойти крупному бизнесу с несколькими видами продуктов.
ICE
Супербыстрый фреймворк, с помощью которого каждая фича оценивается по десятибалльной шкале по трем параметрам — влияние (Impact) на результат продукта, уверенность (Confidence) в оценке влияния и сложность реализации (Ease). Затем считается среднее арифметическое трех показателей, на основе которого составляется общий рейтинг фич в бэклоге.
Плюсы: быстро и просто.
Минусы: оценка фич очень субъективна, для сложных продуктов с большим бэклогом подходит плохо.
RICE
Тот же подход, что и ICE, но чуть сложнее из-за дополнительного показателя — охвата (Reach). Здесь речь про количество пользователей, которое удастся охватить, внедрив новую фичу. Reach также обычно считается по 10-балльной шкале.
У подсчета RICE есть два существенных отличия от ICE:
Confidence оценивается уже в процентах.
Итоговый балл считается не средним арифметическим, а по формуле: R×I×C / E
Плюсы: оценка охвата помогает более точно приоритизировать бэклог.
Минусы: метод не сможет высоко оценить задачи, которые просят внедрить крупные клиенты, поэтому менять приоритет придется вручную.
DIVE
DIVE — это модифицированный подход метода DIE для приоритизации бэклога.
D — запрос (Demand)
I — влияние на бизнес (Impact)
E — усилия (Effort) по разработке
Такой фреймворк подходит тем, чей бэклог состоит из прямых запросов клиентов и стратегических вещей, придуманных внутри компании.
Компонента V (VIP) возникла как способ учесть в бэклоге, что запросы не от всех заказчиков имеют одинаковый приоритет.
Новая функция оценивается по каждой компоненте. Итоговые значения складываются, и получается общий score-фичи. Чем он меньше, тем задача приоритетнее.
Важный момент — формула хорошо работает на устоявшихся продуктах и помогает балансировать между поддержкой и внедрением новых фич.
Плюсы: простая формула, помогает балансировать задачи команды по поддержке и разработки, при этом еще и учитывать давление со стороны клиента и отдела продаж.
Минусы: плохо работает на новых продуктах.
WSJF (Weighted Shortest Job First)
Суть метода WSJF заключается в том, что разработка делает наиболее важные и самые короткие по трудозатратам работы. Вычисляется все это по формуле: стоимость задержки делится на трудозатраты.
При этом стоимость задержки — это сумма трех параметров: бизнес-ценность для пользователя, критичность по времени и либо снижение рисков, либо появление каких-то новых возможностей для продукта. Каждый из этих трех параметров оценивается от 1 до 10, далее они суммируются между собой и делятся на трудозатраты. На выходе получаем оценку работы каждой фичи.
Плюсы: позволяет избежать когнитивных искажений и легко встраивается в конкретный бизнес.
Минусы: масштабные и стратегически важные задачи будут всегда оказываться в конце бэклога, что точно не приведет к развитию продукта. Чтобы этого избежать, придется много экспериментировать и калибровать оценки.
Вместо вывода
У каждого метода есть свои плюсы и минусы, каждый из них хорош в определенных условиях для различных проектов, продуктов и компаний. Самое главное — всегда руководствоваться логикой и подходить к методам оценки гибко.
Еще одна важная оговорка в работе с фреймворком: любой метод будет работать только с задачами, разбитыми от бизнес-смысла (объединение нескольких задач во что-то осмысленное для бизнеса), иначе он не будет работать вообще.
Всегда стоит помнить, что ни один фреймворк нельзя использовать вслепую и никакие методы приоритизации не заменят человеческого решения. Однако для хорошего продукта применение фреймворков обязательно. И на это есть три причины.
Во-первых, продакт может убедиться в том, что его мнение по поводу приоритизации бэклога правильное.
Во-вторых, повышается прозрачность решений продакта для остальных участников.
В-третьих, неудобные фичи или баги не складируются в пыльный ящик, а заставляют о них помнить и работать над ними.
Наиболее подходящий метод приоритизации должен выполнять несколько обязательных вещей:
вовлекать каждого члена команды, стейкхолдера, а в некоторых случаях и клиентов
приносить практические результаты и давать информацию, которая поможет улучшить продуктовую стратегию
побуждать членов команды думать о том, как любая идея влияет на цели компании и определять приоритеты, исходя из этого
избавить от роя бессмысленных и бесполезных идей
Выбор метода приоритизации — итеративный процесс. Только пробуя разные подходы, можно получать обратную связь, измерять эффективность и найти тот, который отвечает нужным требованиям.
Поделитесь в комментариях, какие методы приоритизации используете в своих командах. Или открываете бэклог, как коробку конфет, когда не знаешь, какая жесть тебе попадется сегодня?
