Обратимся к тактике. Как вы сейчас приоритезируйте свой бэклог?
Если вы такой же, как и большинство продакт-менеджеров (читать: заняты 24/7), у вас, скорее всего, нет выбора. Вы относитесь к бэклогу, как к свалке идей, историй, функциональных запросов, багов и иных задач, связанных с вашим продуктом. В конце концов, эти сущности постоянно встречаются вам на пути, и их нужно где-то хранить, верно?
Скорее всего, у вас не так много времени, чтобы упорядочивать все эти продуктовые задачи прежде, чем добавлять их в бэклог, например, чтобы понять стратегическую ценность каждой из них и ресурсы, которые понадобятся для ее выполнения. Итак, если вы похожи на тех продакт-менеджеров, с которыми мы работаем в ProductPlan, вы, скорее всего, обнаружите, что ваш бэклог стал черной дырой.
Каким должен быть бэклог и почему нужно его приоритезировать
Но давайте начнем сначала: зачем вам вообще бэклог продукта?
В идеале продуктовый бэклог должен представлять собой список всех задач, связанных с продуктом, которые ваша команда должна выполнить в следующем спринте, и тех, которые ей нужно выполнить (в течение определенного времени) в будущем.
После следующего спринта, когда вы погружаетесь в задачи, скажем, на второй уровень приоритета – элементы бэклога становятся проблемой, поскольку они раздувают и нагромождают список, затрудняя его просмотр и сортировку.
Именно поэтому и важно расставлять приоритеты в бэклоге продукта – чтобы убедиться, что он не превращается в бесконечный список случайных идей, которые возникают у кого-то в голове относительного вашего продукта. Бэклог должен быть структурирован, организован и упорядочен таким образом, чтобы соответствовать наиболее стратегически важным задачам, над которыми должна работать ваша команда.
Подсказка: Если кто-то в вашей организации (или вы сами) можете произнести фразу «Давайте просто скинем это в бэклог», и эта идея может оказаться жизнеспособной, у вас проблемы.
Мы в ProductPlan хотим помочь менеджерам вести работу организованно и оставлять время для сосредоточения на стратегическом видении. И помимо плохих дорожных карт продукта, мы обнаружили, что неэффективный бэклог – очень часто самое большое препятствие для успешного продвижения продукта. Мы даже провели вебинар с нашими друзьями и партнерами по интеграции в Atlassian Jira, по результатам которого получили полезные советы по увязке стратегической дорожной карты с вашим бэклогом.
Мы рекомендуем вам ознакомиться с этим вебинаром. А пока давайте обсудим несколько практических советов по приоритизации вашего бэклога.
7 подсказок по приоритизации вашего бэклога
Придумайте систему группировки для ваших элементов бэклога
При организации элементов бэклога полезно задать категории для них. Не важно, как вы их назовете, важнее, что они дадут вам четкое представление о приоритетах. Бэклог определяет над чем команды будут работать в каждом из спринтов, поэтому нужна система, которая поможет вам быстро найти то, что вы ищете.
Вот пример категорий:
Как только вы определитесь с категориями, которые будут использоваться вашей командой, вы сможете аккуратно упорядочить и распределить элементы бэклога. Давайте посмотрим, как это выглядит на практике.
Шаг 1: Распределите элементы бэклога по категориям
Теперь при планировании следующего спринта вы легко разберётесь в элементах бэклога. Вы поймете к чему вам нужно прийти и оцените, с чем сможет справиться команда. Мы сможем сказать:
«Наша цель – доставить __________. Для этого мы должны доставить эти __________ элементов бэклога. Мы можем сделать ____________ объем работ. Итак, чтобы достигнуть цели, мы собираемся реализовать ___________.»
Из своих категоризированных элементов вы сможете выбрать те, которые войдут в следующий спринт. Ниже мы подробнее рассмотрим, как оценить эти элементы и включить их в бэклог спринта.
Шаг 2: Перенесите элементы бэклога в спринт
В конечном итоге, ваш бэклог спринта может выглядеть примерно так:
Такая система обеспечивает структуру, необходимую вашей команде, чтобы чувствовать свою ответственность. Чем более организован ваш бэклог, тем лучше себя все чувствуют, они знают, что их ждет, и они могут двигаться вперед.
2. Располагайте верхние элементы в вашем бэклоге так, чтобы из них строился ваш следующий спринт.
Одним из крайне полезных шагов в организации вашего бэклога является размещение его верхней части в виде содержимого вашего следующего спринта.
Так вы не будете постоянно смотреть на бэклог и спрашивать: «А когда мы доберемся до этого?» или «Когда мы сможем начать решать эту проблему?».
По такой стратегии верхние элементы вашего бэклога – это не просто «первоочередные» задачи без привязки к ним внутренних дат – у них есть встроенная временная шкала: ваш следующий спринт.
Конечно, вам понадобится механизм для определения того, какие элементы должны быть включены в следующий спринт вашей команды, и мы поговорим об этом дальше.
3. Не включайте в бэклог задачи с приоритетом ниже второго уровня.
Еще один простой способ определить, что попадет в бэклог, а что нужно отправить куда-то еще (например, в файл «Долгосрочные задачи»). Второй уровень приоритета – это логическая точка отсечения того, что попадает в бэклог и вот почему.
Вы поучаствовали в мозговом штурме, на котором команда записала на доске 20 жизнеспособных идей для продукта. Может, вы даже организовывали такую встречу. Очевидно, что все 20 идей вы реализовать в ближайшем будущем не сможете. Так что же вы делаете? Вы расставляете приоритеты: возможно, выбираете две или четыре лучшие из этих идей и разбираете их на истории, задачи и планы, над которыми ваша команда может начать работать.
Что касается всего остального на этой доске, вы, конечно, зафиксируете это, но вы не можете поместить все их в бэклог (или что еще более нереалистично, в свою дорожную карту). Бэклог должен быть скудным и реалистичным. В нем должны быть вещи, необходимые для вашего следующего спринта, и задачи второго приоритета, которые вы реализуете в течение следующих нескольких месяцев. Вот и все.
А вот для задач ниже второго приоритета есть другое предложение…
4. Создайте отдельный список для менее приоритетных (или долгосрочных) идей или запросов.
Есть нечто хорошее в том, чтобы создать список менее срочных продуктовых задач, поскольку он помогает вам ограничить список незакрытых задач только теми, которые действительно являются срочными или имеют высокую стратегическую ценность. Так ваш бэклог получается более стратегически ценным.
Менеджеры продуктов, которые просто сбрасывают каждый запрос, идею или задачу в конец своего бэклога, потому что у них нет другого надежного места для сбора и хранения этих элементов, усложняют каждый последующий обзор и переоценку своего бэклога. Так выше вероятность упустить, что-то важное при просмотре бэклога.
Поэтому создайте другие списки, в которых вы организуете продуктовые идеи, не внося их в бэклог. Для этого подойдет файл «Отличные идеи» и, возможно, список «Долгосрочных задач».
5. Используйте баллы (или используйте какую-либо другую систему количественной оценки) для определения общей ценности каждого элемента.
У нас в ProductPlan мы добавили инструмент взвешенной оценки в приложение product roadmap. Мы обнаружили, что, имея дело с ограниченным количеством времени, бюджета и ресурсов на разработку, менеджеры по продуктам нуждаются в механизме количественной оценки (или скоринга) общей стратегической ценности каждой предлагаемой функции или задачи по сравнению со всеми остальными — чтобы определить, что даст их продукту наибольшее стратегическое преимущество.
Но вы должны использовать аналогичную систему для оценки преимуществ и затрат элементов вашего бэклога.
Мы рекомендуем использовать модель оценки — будь то на основе предложенных ProductPlan показателей, включая «Ценность для клиентов», «Увеличение выручки» и «Затраты на внедрение», или использовать какую-либо другую систему для оценки каждого элемента, претендующего на место в вашем бэклоге.
Некоторые пункты займут место в вашем коротком списке первого приоритета (запланированных в работу в следующем спринте). Другие перейдут на второй уровень приоритета (планируется к разработке, например, в ближайшие три месяца). Все остальное ляжет в файл «Долгосрочные задачи». Когда вы упорядочите свой список, вы будете точно знать, почему каждый элемент находится там, где он стоит у вас в списке. Также вы можете объяснить и защитить свое стратегическое видение перед стейкхолдерами и другими командами.
6. Разработайте систему начисления баллов для распределения времени и ресурсов на разработку для каждого элемента.
При приоритизации вашего бэклога нужно учитывать один важный фактор для каждой задачи — это то, сколько времени понадобится на ее выполнение. Здесь заложено не только общее количество часов разработки, но и то, какие конкретно разработчики будут работать над ней и как долго.
Затем вы можете захотеть преобразовать эти часы (или дни, или полдня) в баллы. Например, написание кода для определенной истории может занять целый день, который вы, возможно, захотите оценить в один балл. Так вы упростите сопоставление элементов в вашем бэклоге друг с другом и получите более равномерный расчет необходимых ресурсов для всего списка (в отличие от высказывания: “Этот элемент должен занять у одного разработчика полдня, а этот, вероятно, займет у двух разработчиков по часу на каждого”.)
Небольшое предупреждение: не забывайте про «общую картину», когда пытаетесь оценить, сколько часов (и чьих часов) потребуется для выполнения задачи. Например, вы можете предположить, что исправление ошибки — это задача на половину балла, ведь вы разработали свою систему начисления баллов так, что один балл равен одному рабочему дню разработчика. Несмотря на то, что выявление и исправление неправильного кода и вправду может занять всего полдня, для выполнения этой задачи также потребуется написать автоматический тест для последующего тестирования. Поэтому вы должны быть консервативны в своих оценках времени — лучше переоценивать, чем недооценивать ресурсы, которые потребуются для выполнения задачи.
Еще одно предупреждение: не все баллы будут взаимозаменяемыми. Важно помнить, что ваша команда уникальна и обладает уникальным набором навыков, сильных и слабых сторон. Вот почему бэклог играет такую важную роль в планировании с командой развития ваших продуктов. Допустим, у вас есть только один или два разработчика, обладающих необходимыми навыками или опытом для работы с историей или функцией. Вам нужно тщательно планировать время («баллы») этих разработчиков, когда вы выбираете задачи для следующего спринта.
7. Регулярно пересматривайте ценность задач первого и второго приоритета
Важно понимать, что продуктовый бэклог – это живой документ, приоритеты в котором часто меняются. В конце концов, если вы последуете советам из этой статьи, верхняя часть вашего бэклога будет исчезать после каждого спринта по мере того, как ваша команда будет закрывать задачи. Логично, что какая-то часть элементов второго приоритета будет перемещаться вверх после каждого спринта.
Рекомендуем вам прочитать статью Джима Семика о банкротстве бэклога.
Если вы выполните все рекомендации из этой статьи, то у каждого элемента в вашем бэклоге будет стратегическая причина находиться там, где он находится. Вам будет гораздо проще обращаться к этому списку каждый раз. Вы сможете определить, требует ли какая-либо новая задача – изучение конкурентов, запросы клиентов или просто срочное решение проблемы — изменения приоритетов.
Самое главное, что вы не будете гадать над вашим бэклогом. Вы сможете принимать решения о расстановке приоритетов систематически.
Перевод материала подготовлен в преддверии старта курса «Project Manager. Advanced».