Как квотирование связано с бэклогом
Backlog в управлении продуктом: что делать, когда идеи нарастают «как снежный ком»
В условиях высокой конкуренции важно концентрироваться на самом приоритетном. Конкуренты постоянно выпускают новые фичи. Их так много, что просто не хватает времени на их изучение. Клиенты в развитии продукта также играют важнейшую роль, предлагая улучшения, конструктивную критику и свежие советы. В общем, идеи растут «как снежный ком».
В любом продукте, скорее всего, хотят внедрять те функции, которые поднимут на новый уровень доходы, увеличат возвраты (retention) или виральность (virality).
Здорово, если вы уже внедрили какой-либо количественный фреймфорк, например, Pirate Metrics (AARRR). Он помогает сконцентрироваться на самых важных этапах вашей воронки продаж, а именно на AARRR (acquisition, activation, retention, referral, revenue).
Однако вернемся к большому скоплению идей и инициатив.
Определяем проблему
Итак, проблема следующая — у вас скопилось много идей из разных источников: из Intercom, Zendesk, Satismeter, из личных бесед с клиентами, от сотрудников. Вам становится все сложнее выбирать идеи для очередного спринта. Причем, цена ошибки очень высока: вы рискуете сделать такую фичу, которая будет невостребованная аудиторией и не принесет ожидаемых бенефитов. Например, она не увеличит конверсию в регистрацию или ARPD.
Backlog постоянно растет и управлять им становится все сложнее — менеджер продукта тратит много времени на его аудит, во время которого он просматривает идеи, расставляет приоритеты, выбрасывает то, что перестало быть актуальным. Каждый раз нужно мониторить все идеи. Самое время “перелопатить” известные техники приоритизации и найти свое решение.
Находим решение
Мы в Hygger.io предлагаем системное решение этой проблемы выбора. Решение состоит из трех основных блоков:
Структурирование бэклога
Как правило, Backlog — это обычный список. В Hygger бэклог — это двухмерная Kanban доска. Более того, пользователя предлагаются Labels (тэги) и Swimlanes. Этого более чем достаточно, чтобы структурировать ваш бэклог любого размера.
Например, колонками на этой Kanban доске могут быть этапы работы над идеями:
Вместо процесса вы можете сделать в колонках релизы, чтобы распределить идеи. Кстати, Hygger умеет считать Capacity для колонок — чтобы вы могли равномерно распределять задачи по релизам.
С помощью Swimlanes вы можете разделить идеи. Например, так:
Лейблы можно использовать для чего угодно, например, для того, чтобы отметить идеи конкретных клиентов. Или идеи конкретных сотрудников. Или отметить особо важные идеи. Или отметить Сandies — мелкие фичи, которые делают продукт “вкуснее” для пользователей. Эти Сandies усилий практически не требуют, на скорость работы не влияют. Но замечая их, пользователи чувствуют заботу о них и больше доверяют.
Идеи упорядочены по полочкам, теперь можно приступать к их оценке. Оценка поможет вам в будущем сделать правильный выбор.
Оценка идей по Value и Effort
Оценить все идеи удобно с помощью двух критериев: Value или Impact и Effort.
Говоря абстрактным языком, Value — этот вклад, который идея или фича может дать в ваш продукт. Для корректной оценки вам нужно сначала понять, что вы хотите улучшать с помощью этой фичи.
Допустим, что вы внедрили Pirate Metrics (AARRR), тогда ваши цели могут быть такими:
Процесс оценки идей по Value в компании такой:
Когда вы оценили все идеи, вы можете переходить к этапу выбора идей. Не обязательно делать это сразу после окончания оценки — иногда лучше взять паузу и дать идеям отлежаться. Вы можете получить новые данные, например, из внешней среды, которые могут повлиять на оценку Value или Efforts.
У нас в компании процесс пересмотра идей является постоянным и фоновым. Но мы это делаем на графике, а не на Kanban доске, потому что на графике самые важные идеи четко отделены от всякой ненужной мелочи. Вы можете пересматривать идеи от самых важных до ненужных, если вам позволяет время. Главное то, что важные идеи вы пересматриваете вначале, и на них у вас всегда найдется 5 минут.
Выбор идей с помощью визуального инструмента Backlog Priority Chart
Те идеи, которые вы оценили, вы можете увидеть на графике.
На графике есть две шкалы — Value и Efforts, а также 4 квадранта:
График удобен тем, что позволяет оценивать идеи друг относительно друга. Во время оценочной сессии идеи оцениваются, как правило, независимо друг от друга. Но когда мы начинаем сравнивать идеи, которые оценены одинаково, друг с другом, явно какая-то идея будет более полезной или менее трудозатратной. Исходя из этого, мы можем скорректировать оценки идеи, их Values или Efforts.
Итак, вы оценили идеи, отобрали с помощью графика самые полезные идеи, и теперь вы можете отправлять их в разработку — на Kanban доску или на Спринт-доску.
Заключение
Подводя итог, кратко выделим главное:
Что такое бэклог продукта: основы
Узнайте, как создать и вести бэклог продукта
Бэклог продукта — это один из инструментов agile-разработки, который представляет собой перечень требований к продукту и задач, расставленных по приоритету.
Разделы
Как вести бэклог продукта
За составление бэклога продукта отвечает product owner (владелец продукта). В его формировании может также принимать участие scrum-мастер и другие напрямую заинтересованные лица, например, вовлеченные стейкхолдеры. Список задач составляют на основании дорожной карты и требований к продукту. Product owner регулярно пересматривает и обновляет бэклог если это необходимо, чтобы команда разработчиков на его основании могла выполнять свою работу и продвигаться к поставленной цели.
Согласно методологии скрам требования из бэклога продукта служат основой для проработки задач в спринтах, которые представляют собой временные интервалы для выполнения работ. Перед каждым этапом разработки команда проводит встречу со scrum-мастером, чтобы обсудить план работ и сформировать бэклог спринта.
Для того, чтобы процесс был максимально прозрачным для всех участников команды, используют виртуальные или физические доски. Посмотрите пример ниже. По вертикали расположен бэклог и основные этапы разработки. Цифрами отображены задачи, требующие решения. Чтобы изменить статус какой-либо из них, необходимый стикер перемещают из одного столбца в другой. Количество этапов (вертикальных столбцов) зависит от продукта, над которым работает команда и специфики ее работы.
Похожие доски используют и в методологии канбан. Однако, в этом подходе работу над продуктом не разбивают на спринты, а создают только один бэклог. В scrum процесс разработки продукта делят на этапы, поэтому возникает путаница между такими понятиями как «бэклог продукта» и «бэклог спринта». В следующем разделе вы ознакомитесь с отличиями этих двух инструментов.
Чем бэклог продукта отличается от бэклога спринта
Главное отличие заключается в том, что бэклог продукта представляет собой полный перечень требований и задач для разработки того самого продукта. Это основа, которая ведет к достижению главной поставленной цели.
Бэклог спринта помогает визуализировать процесс работы на пути к достижению краткосрочных целей. Он представляет собой список задач, которые необходимо выполнить на конкретном этапе разработки, чтобы реализовать один из элементов продукта. Созданием бэклога спринта руководит скрам-команда, а не владелец продукта. Участники формируют перечень задач в начале каждого этапа работы.
В следующем разделе вы узнаете, что собой представляет бэклог продукта и как его создать.
Как создать бэклог продукта
Бэклог требует регулярного обновления, поскольку в процессе работы могут появиться новые конкуренты, измениться требования на рынке, цены и прочие факторы, влияющие на функционал создаваемого продукта. Для разработки бэклога продукта используют product roadmap, user stories и customer journey map. Давайте подробнее разберем, для чего необходим каждый из этих инструментов.
Следуйте пошаговому плану ниже, чтобы разработать бэклог продукта при помощи этих трех инструментов.
На скриншоте ниже вы видите, как может выглядеть бэклог продукта. В таблице указана приоритетность задач и их описание, объем и сложность работ по каждой из них в цифровом эквиваленте — story points.
Для постановки задач в своем бэклоге используйте методику SMART. Обязательно пропишите подробно элементы, которые необходимы для работы во время ближайших одного или двух спринтов. Задачи для последующих этапов скорее всего необходимо будет корректировать на основании полученных результатов и обратной связи. Главное, тщательно собирайте и анализируйте всю информацию, чтобы регулярно обновлять и актуализировать свой бэклог продукта.
11 советов по оптимизации бэклога
Управление бэклогом продукта может вызывать вопросы даже у самых опытных менеджеров и собственников продукта. Когда бэклог нарастает, как снежный ком, приходится принимать неотложные меры. Основные из них — в этой статье.
Как управлять бэклогом эффективно? На этот вопрос помогут ответить 11 практических советов для тех, кто стремится навести порядок в бэклоге и “довести” его до идеального состояния.
1. Начните с подготовительной работы
Перед тем, как приступать к управлению бэклогом продукта, то есть очередью скопившихся задач (product backlog), оцените стратегию своего продукта: все ли с ней в порядке. Хорошо описанная стратегия — это способ реализовать свое видение продукта. Это начало начал, без которого дальнейшая жизнь продукта не представляется возможной. Этап подготовки стратегии происходит с одновременным исследованием и анализом рынка.
2. Сфокусируйтесь на главном
Сосредоточьте свой бэклог на предстоящем релизе, так как это стратегическая составляющая, в которой описаны все детали продукта и истории пользователей, которые должны быть реализованы. Долгосрочные планы по развитию продукта удобнее всего описывать в дорожной карте продукта (product roadmap).
3. “Содержите” бэклог в управляемом состоянии
Иногда собственники продуктов и менеджеры могут допускать 50, 100, 200 и даже больше накопившихся вопросов и задач. Такой бэклог выглядит неконтролируемым и, порой, безнадежным. В этом случае, им довольно сложно управлять и создавать прозрачность. Логично, что сказать, куда двигается продукт при таких обстоятельствах, не так просто.
Как менеджер продукта, менеджер проекта или product owner, вы должны решить, как максимизировать результат, минимизируя затраты и усилия.
4. Используйте дорожную карту
Управление бэклогом с помощью удобной дорожной карты поможет “набросать” и спланировать способы использования и реализации вашего продукта и его жизненного цикла. Часто этот документ является основой успешного управления бэклогом.
Product roadmap поможет визуализировать предстоящие релизы с их целями и этапами. Вот как дорожную карту помогает реализовать сервис Roadmunk:
5. Коммуницируйте и сотрудничайте
Сотрудничество менеджера продукта с командой разработчиков является важным аспектом управления бэклога. Активная коллаборация по всем вопросам скопившихся задач даст быстрый и эффективный результат. Привлекайте членов вашей команды к обсуждению продуктовых проблем. Это поможет выявить технические риски, повысить понимание и осведомленность о продукте и получать более четкие и ясные запросы от клиентов.
6. Поделитесь бэклогом с заинтересованными сторонами
Не нужно скрывать актуальное состояние бэклога. Сделайте его прозрачным для заинтересованных сторон (stakeholders), чтобы все могли проверить последний статус продукта и предоставить полезную обратную связь. Это поможет в принятии трудных решений.
7. Устраивайте встречи по оптимизации бэклога
Бэклог вашего продукта будет здоровым, если вы регулярно будете ухаживать за ним вместе с командой разработчиков. Для этого есть специальный процесс или командное мероприятие, известное, как product backlog grooming или refinement.
Оптимизация бэклога или груминг имеет решающее значение для управления продуктом, потому что этот процесс увеличивает шансы на создание того продукта, который действительно хотят получить пользователи.
Проанализируйте отзывы и комментарии и примените новые идеи для задач бэклога. Удалите ненужные и добавьте самые актуальные, разбейте крупные таски на более мелкие, в общем, поддерживайте задачи бэклога в чистом и здоровом состоянии.
8. Работайте с историями пользователей
Истории пользователей (user stories) также очень важны, но их обычно не достаточно для полного понимания того, как проходит взаимоотношение с продуктом. Используйте непосредственное взаимодействие с пользователями и фиксируйте результаты в бэклоге.
9. Регулярно актуализируйте дорожную карту
Проверяйте и вносите изменения. Если вы работаете по Agile, изменений, скорее всего, будет достаточно. Обновляйте состояние roadmap в промежутке от трех недель до трех месяцев. Это обычно зависит от того, насколько “молод” ваш продукт и насколько динамичен рынок.
10. Назначайте приоритеты
Приоритизация — ключевой момент в работе с бэклогом. Не всегда просто определить, как скоро должен быть реализован конкретный таск. Своевременное решение по конкретному вопросу позволяет избежать ошибок, понять как поступать дальше и не позволить бэклогу разрастаться.
Многие менеджеры продуктов используют для определения приоритетов удобные параметры Value и Efforts для каждой идеи.
Сравнение этих комбинации помогает лучше определять значимость и “вес” задач и выбирать наиболее важные из них для ближайшей работы.
11. Визуализируйте
Для визуализации задач бэклога и определения их приоритетности, можно использовать обычный лист бумаги, доску или простейшие таблицы Excel. Однако для удобства и эффективности работы менеджеров продуктов, разработаны специальные инструменты и сервисы.
Пример такого инструмента — Backlog Priority Chart в Hygger.io.
А как вы управляете очередью задач продукта? Какие из перечисленных шагов по оптимизации продуктового бэклога показались вам наиболее полезными?
Техники скоринга и приоритизации бэклогов
Ну что, как там ваши планы на изоляцию? Зимние вещи убрали? Желанные киношки посмотрели? Пылящиеся книжки прочитали? А до полезностей, как всегда, нет времени. Да ладно, не оправдывайтесь — для тех, кто никак не выкроит часок для просмотра видео с нашего канала на Ютубе, мы сделали быстроусвояемую статью. Имейте совесть, всего-то 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-канале!