У вас бывает так, что к обсуждению одной и той же темы, вы снова и снова возвращаетесь в кругу разных людей? Для меня лично это признак того, что пора писать об этом в блоге :-). Уже несколько раз на конференциях и вне их заходил разговор о том, как расставлять приоритеты в бэклоге продукта. Суммируя обсуждения с коллегами, а также выполняя обещание расскажу о нескольких способах расстановки приоритетов.
Пожалуй, самым «официально» надёжным способом является финансовый анализ ожидаемой прибыли. Вы наверняка слышали про термин ROI (Return of Investment) и во многих книгах говориться, что Владелец Продукта (Product Owner) отвечает за ROI проекта. Кроме этого подхода есть ещё подход NPV (Net Present Value) и другие.
Парадокс заключается в том, что на практике очень сложно встретить такие подходы при планировании проектов и выпусков (релизов). Иногда громоздкость мешает быстрому принятию решений, а чаще всего менеджеры продуктов не знают всех необходимых данных. Никто не отрицает, что знать «Бизнес-ценность» требований очень полезно, и ваша компания может постараться выработать свой собственный подход с помощью бизнес игры.
И все-таки, человеческий мозг устроен так, что когда он сталкивается с очень сложной проблемой, то лучший способ – это абстрагироваться и принимать решения с помощью более простых сущностей. Для этого мы играем в покер при оценке сложности и для этого же мы можем применять нефинансовые подходы к расставлению приоритетов.
Среди всех таких подходов к приоритетам, пожалуй, самым простым и удобным является расстановка приоритетов с помощью относительного взвешивания. Он основан на том, что мы учитываем относительную выгоду и относительные потери для каждой темы или эпоса, которые могут быть реализованы в следующем выпуске. Этот подход рассказывают на курсах Scrum Alliance для Владельцев Продукта (Certified Product Owner), и практически любая компания может начать с него, прежде чем выработает свои более специализированные подходы.
Техника подхода достаточно проста:
- Создайте таблицу со списком эпосов или тематических групп функциональности
- В одной колонке указывайте выгоды от включения этой темы в следующий выпуск продукта
- В следующей колонке указывайте потери, если НЕ включить эту тему в следующий выпуск
- Ещё одна колонка нужна для подсчёта ценности каждого эпоса/темы как сумма выгоды и потери (Ценность = Отн. Выгоды + Отн. Потери)
- Чтобы сделать все строки сравнимыми между собой, то нужно перейти к ценности в процентах, т.е. для каждой строки посчитать отношение ценности строки и общей суммы всех строк (Ценность в %% = Ценность строки / Σ(Ценностей строк))
- Ещё одной колонкой записываем наши оценки сложности полученные, например, с помощью Planning Poker
- В следующей колонке получаем сложность в процентах, т.е. для каждой строки считаем отношение сложности строки и общей суммы всех строк (Сложность в %% = Сложность строки / Σ(Сложностей строк))
- И теперь в последней колонке сможем автоматически посчитать приоритет по магической формуле ПРИОРИТЕТ = ЦЕННОСТЬ в %% / СЛОЖНОСТЬ в %%
Соответственно чем больше будет значение приоритета, тем важнее для вас эта тема или эпос и тем выше они должны находиться в вашем бэклоге продукта.
Пара советов:
- Упростите оценку выгод и потерь до простой шкалы от 0 до 9. Таким образом, вы избежите ненужных дискуссий и подсчётов.
- Расставляйте приоритеты для максимально больших блоков – эпосов, тем или групп функций. Ценность и приоритет отдельных историй вы уже сможете определить, когда начнёте планировать спринты – не тратьте зря время, углубляясь в ненужные детали.
Майк Кон описывал этот подход в своей книге, и недавно, для удобства всех Владельцев Продукта, сделал бесплатную онлайн версию этого инструмента. Рекомендую посмотреть на Free Relative Weighting Tool и воспользоваться ним при ближайшем планировании релиза.
Кроме относительного взвешивания есть ещё методы нефинансового анализа приоритетов, такие как Кано анализ, оценивание тем и сканирование групп требований. Об этом мы напишем как-нибудь в другой раз и вы обязательно узнаете об этом первыми, если подпишитесь на нашу ленту новостей.
Мне чаще всего приходилось сталкиваться с тем, что заказчик как раз вообще не представляет как подсчитать “относительные выгоды”. Чаще всего менеджер продукта (вне зависимости от того, является он Владелельцем Продукта или нет) ставит приоритеты по интуиции, а это не всегда оправдано и наглядно.
Инструмент дает возможность прикинуть ожидаемую выгоду по простой шкале. Плюс участь возможные штрафы, если мы решим выкинуть функцию. После этого простое деление дает приоритет.
Даже если вы менеджер проекта исполняющий роль Владельца Продукта – для вас это удобный инструмент наглядности для ваших заказчиков. Заказчики расставляют значения в колонке 1 и 2, т.е. они озвучивают то, на сколько для них важны те или иные функции.
А потом уже когда команда даст оценки вы ставите приоритеты, чтобы достигнуть максимальной эффективности.
Кстати, для “продвинутых пользователей” можно добавить еще колонки кроме “относительнйо выгоды” и “относительных потерь”. И даже присвоить им некие коэфициенты, если они по разному влияют на ваши оценки. Например, потери для нас не сильно критичны – их коэфициент 0.5.
Тогда Ценность каждого элемента должна считаться с учетом этого коэфициента и соответственно повлияет на приоритеты.
Странно как-то….
Чтобы использовать такой метод нужно быть очень смелым – опираться на относительные выгоды и потери при выборе функциональности к реализации, а потом доказать состоятельность данного подхода лицу принимающему решению (грубо говоря тому, кто даёт бабло – реальное, а не относительное).
Есть примеры планирования реальных проектов по такой методике?
Да, конечно подход относительных вeсов не заменяет финансовые подходы! В статье собственно и шла речь о том, что когда нет возможности применить финансовое планирование, то нужно переходить к относительным оценкам.
Возможно я не правильно истолковал прошлый вопрос и не смог сразу пояснить. Есть подходы основанные на ROI, IRR, deferred benefit и т.п. Если будет интересно, могу кинуть ссылочку, где про них рассказывается подробнее.
На практике, большинство проектов испытывают трудности уже после того как они начали работать 😉
Тимофей, спасибо за ответ, теперь понятно.
Всё-таки это не полноценная замена ROI как такового: ROI чаще применяется при инициации проекта, чтобы получить отмашку, на его реализацию, а описанный подход больше подходит к последуюущему этапу – определению порядка выполнения работ.
Но всё равно интересно, теперь буду думать, когда-бы попробовать его применить 🙂
Спасибо.
С удовольствием почитаю, если дадите ссылку.