бэклогов
Сегодня коснёмся продуктового менеджмента и разберём приоритизацию бэклогов. Продуктовый менеджмент стоит чуточку выше, чем проджект-менеджмент: он больше про управление продуктами в целом и тесно связан с маркетингом. На закуску посмотрим техники скоринга и оценку задач.
Когда есть есть бэклог, менеджеру нужно каким-то образом расставлять в нем приоритеты. Скрам говорит, что первыми должны идти самые важные с точки зрения бизнеса задачи. Но тут возникает две проблемы.
Первая — справедливый момент субъективизма: часто приоритеты выставляются так, как владельцу бизнеса взбредет в голову. Но иногда владелец может сильно «галлюцинировать» и нести откровенную чушь, но при этом быть уверен, что все так и есть.
Вторая проблема: слишком много стейкхолдеров верхнего уровня со стороны бизнеса на больших проектах или в крупных компаниях. У каждого из них могут быть свои противоречивые требования. Если собрать, например, пять топов большой компании и попросить их приоритизировать свои требования, скорее всего, каждый будет утверждать, что его задачи имеют нулевой приоритет, и их нужно делать прямо сейчас.
Хорошие новости — есть несколько методик, которые помогают в этом случае:
- договариваться о приоритетах — выбирать, что важнее, а что можно отложить;
- устанавливать критерии приоритизации бэклога (чуть менее субъективные, чем чья-то галлюцинация — увы, совсем без субъективизма не получится).
Шаг 1. Строим последовательность того, как юзеры будут пользоваться вашим продуктом и какие шаги они будут предпринимать. Простой пример:
Результат: весь список задач разбит по шагам пути пользователя, плюс у каждой фичи есть приоритеты (чем ниже фича висит в листе, тем у неё ниже приоритет с точки зрения всего пути пользователя).
Допустим, у вас действительно набралось очень-очень много задач. Тогда вы выписываете их все на стикеры и делаете Story Mapping. Лучше — в команде.
Другой вариант — у вас идёт брейншторм, вы придумываете, каким дальше будет ваш продукт и какие фичи брать в работу. У команды много идей, какие-то хотелки вам «насыпал» маркетинг — нужно понять, каким образом это всё вообще кластеризовать. Story Mapping особенно хорошо работает в такой ситуации.
Оговорка: этот метод применим именно с точки зрения продуктового менеджмента, когда есть много задач, непонятно, какие из них первыми брать в проработку. Грубо, когда мы только продумываем сам продукт и то, какой функционал он будет включать. Дальше это уже режется на кусочки, из которых можно создавать спринты, и забирается в работу.
Плюсы Story Mapping
- Метод позволяет построить связи в системе, на основе которых потом проще формировать спринты.
- Когда много стейкхолдеров и много людей, у которых есть интересы в проекте, метод позволяет договориться о реальных приоритетах — что более важно, а что менее.
Шаг 1. Сначала вы берете 2 шкалы:
1) Значимость фичи
Значимость каждой фичи с точки зрения бизнеса — это примерно то же, что и «ценность для бизнеса» в обычном бэклоге. Величина оценивается в условных единицах, лучше всего — в деньгах. В целом, любой параметр, который вы оптимизируете, можно брать за Value. Это может быть количество пользователей, которых вы привлечете в проект, или уменьшение оттока пользователей в проекте.
2) Количество усилий, которое необходимо затратить на каждую из фич
Тоже можно считать, что это оценка в часах (estimate), как в бэкглоге. Но можно измерять и в Story Point-ах (сравнительная оценка требований относительно друг друга) или в человеко-часах.
Шаг 2. Вы оцениваете все фичи по этим двум параметрам: по значимости и трудоемкости. Есть внешние системы (вроде Hygger или Airfocus Priorities&Roadmaps), которые позволяют в автоматическом режиме раскидать каким-то образом ваши фичи на такой вот доске. Оси при этом идут не от нуля — они подстраиваются под статистические данные, которые у вас получились.
Где и как применять
При заказной разработке такую штуку имеет смысл проделывать с клиентом, если:
- он сам запутался,
- он генерирует странные идеи и требования,
- у него есть определенное ограничение по бюджету, и он не понимает, как лучше его распределить.
Эта методика не заставляет вас слепо верить алгоритму и брать именно рекомендованные им задачи, но благодаря ей у вас хотя бы будет подсказка, в каком направлении двигаться. Если в систему добавить новых задач, она может перестроиться. Ведь бывает, что вы сильно не уверены в своих оценках, и с течением времени аналитики их уточняют, либо вы сами уточняете оценки трудоемкости у программистов — в этом случае система также может перестраиваться в динамике. За счёт этого у вас будет более адекватная и картина мира.
Первая группа — обязательный функционал: тот же Must Have из MoSCoW. Если эти фичи есть — уже хорошо. Об удовлетворенности речи не идёт: без них продукт никому не нужен. Более того, с течением времени функции, которые сначала были «изюминкой» проекта, становятся всё более обязательными. Пример: для серверного ПО канбан-доска когда-то была чем-то эдаким, а сейчас это тот самый мастхэв.
Люди при опросах часто говорят ерунду и попросту врут. Они могут говорить, что это очень важная фича, но по факту они никогда не заплатят за неё деньги. Более того, если опрашивать пользователей, обратная связь по продукту может быть очень токсичной.
Когда тестер уткнулся и не может дальше проверять, когда система падает либо что-то ломается — в общем, когда дальше невозможно.
1 — Критичное юзабилити и забытые фичи
Здесь мы применяем в том числе метод покраски бэклога, технического задания, либо прототипа (в зависимости от того, что у нас есть на руках), чтобы определить, не пропустили ли мы что-то.
2 —Некритичные баги
Баги есть, но они не мешают тестировать продукт дальше, либо они позволяют пройти полностью по цепочке либо заказа, либо чего-то еще — то есть, дают полностью проверить наш продукт.
3 — Некритичное юзабилити
4 — Тексты
8 — Хотелки / не будем делать / на усмотрение менеджера
Да, промежуток между 4 и 8 сделан намеренно — менеджер при необходимости может докидать туда ещё какие-то задачи.
Другая проблема — субъективизм тестировщика, который часто приходится перепроверять. Иногда это довольно трудоемкая история, когда вы лично просматриваете все баг-листы: смотрите, чего он там такого понаписал, и принимаете решение, что выкинуть, а что оставить.
Для приоритизации бэклогов такой метод не годится — для них нужны совсем другие критерии.
1. Игра престолов
Приходит какой-то «верховный босс» и говорит, что из бэклога должно быть
сделано прямо сейчас, и спускает вам оценки сверху. Это может быть технический директор, который расставляет оценки всех задач и говорит, что какая-то задача делается за столько-то, такая-то за столько-то. Или это можете быть вы сами :)
Такое часто встречается (хотя сами мы так стараемся не делать). Обычно по ходу декомпозиции какие-то вещи уточняются, появляются какие-то детали и нюансы. Часто с этими оценками могут быть не согласны разработчики или реальность может быть немножко сложнее, чем вы себе запланировали. Плюс у бизнеса всегда есть подсознательное понимание, за какое количество часов он готов купить эту фичу, а за какое уже не готов (и это всегда где-то на грани).
2. Оценка из теории вероятности
Берутся три оценки по времени: оптимистичная, пессимистичная и реалистичная, и строится график, называемый Гауссианой.
Гауссиана подразумевает, что варианты, когда задача выйдет за отметку пессимистичной оценки или вообще никогда не будет сделана, стремительно уменьшаются. Но в ИТ-среде часто бывают задачи, которые, на первый взгляд, сделать «невозможно» — программисты для них требуют поменять постановку либо продолжают доказывать эту невозможность. Другая ситуация — человек оценил задачу в 1 час, потратил всё мыслимое и немыслимое время и пришёл к выводу, что не может сделать эту задачу.
Поэтому опираться на этот метод можно, но по факту это та же «игра престолов», да и сложновато по каждой задаче давать три оценки плюс считать по формуле. И нет никакой гарантии, что в итоге всё не выйдет за рамки этих оценок и расчётов.
3. Planning Poker
Это наиболее простой и «чистенький» способ получить нормальные оценки, обсудить какие-то фичи, нюансы, детали. Даже на верхнем уровне по бэклогу можно такое проделать.
Минус Planning Poker — это довольно ресурсоемкая операция, поскольку нужно собирать всю команду вместе и читать бэклог. Но если вы применяете методы вроде Story Mapping, вам всё равно нужно собираться командой и делать предварительные оценки (хотя бы в днях, неделях — крупных величинах).
Плюсы Planning Poker
- оценки распределяются в зависимости от опыта сотрудника, и здесь можно договориться;
- оценки даются сначала закрыто, и только потом открываются — нет давления авторитета (как в случае с оценками, спущенными «сверху»).
Аббревиатура состоит из трех параметров:
- Impact — влияние на продукт либо с точки зрения бизнеса, либо сколько денег принесет, либо что эта фича даст, насколько она крутая. Параметр задается в диапазоне от 1 до 10.
- Confidence — уверенность в оценке сложности или в оценке влияния фичи. Например, вы придумали какую-то функцию и думаете, что она хорошо повлияет на проект. Аналитики не было, данные неточные и пока приоритет основывается только на вашем личном мнении. Чем ниже уверенность в вашем личном мнении, тем ниже показатель. Задается также в диапазоне от 1 до 10.
- Ease — трудозатраты или простота реализации. Также задается от 1 до 10. Чем проще функция, тем у нее выше балл.
Влияние
Чтобы оценить влияние той или иной фичи, стоит учесть несколько критериев:
- она улучшает конверсии,
- она привлекает новых пользователей,
- она удерживает существующих пользователей,
- она добавляет ценности продукту.
Уверенность
Может основываться на:
- личном мнении, мнении команды, мнении сторонних экспертов;
- UX-исследованиях;
- опросах;
- интервью;
- наблюдениях, в том числе — за конкурентами;
- MVP;
- A/B-тестах;
- сторонних исследованиях;
- аналитике;
- топовых обращениях в техподдержку;
- топовых запросах от сейлз-менеджеров;
- топовых запросах клиентов.
Плюсы: быстро и просто.
Минусы: у метода довольно ограниченная шкала — можно получить много задач высокого приоритета, потому что по ним будут понятны и постановки, сами задачи будут простые и будут казаться важными.
Здесь используется 4 параметра:
- Reach — охват: сколько пользователей у нас от этой фичи получат хоть какое-то удовлетворение, либо заметят эту фичу, либо будут ей пользоваться. Можно измерять количественно: например, 500 миллионов пользователей ощутят на себе эту функцию. Можно измерять в процентном отношении — например, 30% пользователей будет использовать эту фичу.
- Impact — влияние: насколько эта функция на самом деле нам нужна, насколько она нам поможет, насколько функция крутая.
- Confidence — уверенность: аналогично с ICE Scoring, уверенность в наших оценках и прогнозе влияния.
- Effort — трудоемкость.
Иногда менеджеры для хранения всех тикетов и задач используют Jira. К сожалению, она не очень удобна для приоритизации — заточена на то, что кто-то расставляет приоритеты вручную, просто перетаскивая тикеты вверх-вниз по бэклогу. Это прикольно, если бэклог не на 1000 строк, но в какой-то момент вам станет утомительно делать это руками.
В Jira есть определенные способы классификации задач на эпики, компоненты, релизы, можно какими-то тегами задачи размечать. Есть несколько плагинов для скоринга (Issue Score for Jira, Priority Scoring Calculator), но по функциональности они не очень.
Из более-менее адекватных — внешние системы Hygger и Airfocus. Они интегрируются с Jira, но и стоят примерно столько же, сколько она сама. Поэтому самый простой способ — сделать интеграцию гуглдоков и Jira: выгружать туда бэклоги синхронно и уже там применять свои формулы, как вам нужно.
В Jira, к сожалению, из «коробки» эта опция не очень хорошо реализована, поэтому тоже могут пригодиться несколько плагинов:
- Portfolio (тоже дорогой);
- BigPicture (тяжелый);
- MS Project;
- Merlin Project для MacOS.
Если вы используете такой параметр как «уверенность в оценке», вы можете с течением времени эту уверенность «докрутить». Например, у вас есть хорошая функция, которая и влияет на продукт позитивно, и дешевая, и охват дает большой, но уверенность в ней низкая. Проверьте её через метрики, аналитику, запрос экспертов, вопросы программистам — и уточните.
Для оценок хорош Planning Poker, плюс мы посмотрели несколько методик для категоризации задач. Если у вас идёт стратегическая сессия с клиентом, попробуйте Story Mapping со стикерами и распределением их по шагам пользователя. На внутренних продуктах тот же метод поможет выбрать функции, которые стоит взять в следующие релизы. Для бэклогов лучше остальных подходит RICE Scoring, чтобы оценить, какие задачи куда пойдут.
Но помните, что конечное решение — всегда за менеджером, а полученные с помощью методов циферки только задают направление.