Очень люблю устраивать весеннюю уборку, и не только в доме. Впрочем, для наведения порядка во всех аспектах деятельности любое время года будет подходящим. Работать и жить в хаосе слишком утомительно. Майские праздники хороши тем, что позволяют притормозить привычный ход событий и критически посмотреть на свою повседневную работу: действительно ли ваше рабочее пространство удобно и понятно. И, пожалуй, самое частое место, где можно обнаружить беспорядок – это бэклог продукта.
Каждая команда, которая ведёт разработку ПО в соответствии с практиками Agile, имеет бэклог продукта или по крайней мере думает, что он у неё есть. Кажется, что это очень простой инструмент, но на практике я регулярно сталкиваюсь с неумением им пользоваться для планирования работы разработчиков. Давайте попробуем разобраться, для чего нужен бэклог продукта и как извлечь из него максимум пользы.
Откуда берется беспорядок в бэклоге?
Бэклог продукта представляет собой упорядоченный и пополняемый список всех известных на настоящее время требований к продукту. Это очень простое определение расставляет сразу три коварные ловушки:
1. «Все известные требования» на самом деле должны быть действительно требованиями к конкретному продукту. Очень часто можно столкнуться с ситуацией, когда в бэклог попадают вообще все бизнес-идеи, гипотезы, интересны мысли и мечты заказчиков, маркетологов, аналитиков и разработчиков. Практически всегда такая ситуация наблюдается, когда нет дорожной карты развития продукта.
В таком виде – это не инструмент планирования развития продукта, а «записная книжка», куда заносятся не требования, а заметки «чтобы не забыть и не потерять». На самом деле прежде, чем попасть в бэклог продукта, будущие элементы работы должны пройти проверку на важность для стратегических целей развития продукта. Иначе бэклог станет источником ненужной работы: все будут очень заняты, но движение к поставленным целям увязнет во второстепенных незначительных задачках.
2. Выражение «известные на настоящее время требования» должна подталкивать к мысли о том, что мы имеем дело с динамическими запросами от заказчика. Но далеко не всем это очевидно. Бизнес-идеи, гипотезы, пожелания к улучшениям UX\UI и так далее не просто могут, они обязательно будут меняться со временем. И зачастую довольно сильно и срочно. Меняются приоритеты, уточняются ожидания, переоценивается выгода, и всё это происходит непрерывным потоком.
Элементы работы в бэклоге имеют свой срок годности. Если бэклог слишком раздутый, в нем находятся требования на три года вперёд, то многие из них протухнут гораздо раньше, чем до них доберётся очередь. Переприоритизировать такой бэклог, выискивать в нем задачки важные и нужные для текущего периода развития продукта очень трудозатратно.
3. «Упорядоченный и пополняемый список» на самом деле не просто список. Бэклог продукта не самый простой инструмент, он предназначен для управления динамическими требованиями, а не просто списком задач, типа техзадания. Он задаёт темп движения требований и должен стимулировать команду как можно быстрее реализовывать запросы бизнес-заказчиков. Причём элементы бэклога имеют разную размерность и разную степень проработки.
Просто приоритизированный список побуждает заводить календарный план-график и выстраивать длинную очередь задач не в соответствии с целями развития продукта, а исходя из предположения, что «все равно их надо будет сделать». При этом происходит непрерывное пополнение бэклога новыми требованиями от бизнеса и совершенно не понятно, куда их в этот жёсткий план вставлять. Возникает ощущение, что команда перегружена работой. Чтобы разораться так ли это на самом деле, необходимо визуализировать сложный путь и индивидуальные характеристики элементов бэклога.
Эти три ловушки очень часто срабатывать все вместе. И можно наблюдать ситуацию, когда номинально бэклог продукта есть, но планирование оперативной работы команды ведётся не на его основании, а путём договорённостей и бесконечных уточнений, что съедает огромное количество бесценного ресурса – времени.
Поэтому весенняя уборка или любая другая похожая активность в бэклоге продукта становится отличным вложением в избавление от ненужной работы. Кажется, что эта процедура потребует много времени, которое следует тратить на основную работу. Но эти затраты с лихвой окупится экономией времени, когда ваш бэклог станет действительно инструментом оперативного планирования. Как говорит известная притча, топор сначала надо заточить, а потом уже валить лес.
Наведение порядка в бэклоге за четыре шага
Прежде чем воспользоваться этой инструкцией, убедитесь, что у вас действительно есть бэклог продукта. Один продукт должен иметь один бэклог. При этом, например фреймворк Скрам требует, чтобы и управление этим бэклогом находилось в руках одного человека. И это очень мудрое требование, потому что на практике очень часто можно наблюдать ситуацию, когда бэклог пополняется кем угодно, когда угодно и как угодно, а потом невозможно найти источник требований, задачи дублируются. Приоритеты противоречат друг другу, объем загрузки команды разработки зашкаливает и так далее.
Чтобы этого избежать, зафиксируйте в явном виде, где находится ваш бэклог, какими инструментами визуализации вы пользуетесь для структурирования списка задач, и кто несёт ответственность за управление бэклогом персонально. Эти правила работы с бэклогом должны быть известны всей команде разработчиков, бизнес-заказчикам и всем заинтересованным лицам, которые так или иначе работают с требованиями.
После этого можно приступать к уборке.
Шаг 1. Устранить хаос
Этот шаг наиболее значим для больших бэклогов, не ограниченных по количеству требований и по времени. Характерная история, когда бэклог наследовался из технического задания или длительное время пополнялся без ограничений. В этом случае первым делом необходимо аккуратно сформировать границы бэклога и вынести мусор за их пределы.
Рекомендуется ограничивать размер бэклога горизонтом в 3–6 месяцев. То есть ставить задачи, актуальность для бизнеса имеет значение именно в этот период.
Обратите внимание: не подбирать количество задач, которые возможно реализовать ресурсами команды за это время, а проанализировать, какие задачи наиболее значимы для бизнеса с точки зрения стратегических целей развития продукта. И только если задач окажется действительно много по ощущениям разработчиков, следует обсудить, что возможно цели бизнеса слишком амбициозны и не выглядят реалистичными.
Исходя из вышесказанного очевидно, что на мероприятии по устранению хаоса должна присутствовать команда разработки или по крайней мере её делегаты, которым команда доверила принимать решение, бизнес-заказчики и все лица, обладающие правом ставить требования на разработку, и, разумеется, тот, кто уполномочен управлять бэклогом продукта (в терминах Скрама это Владелец продукта).
Сама процедура упорядочивания бэклога может проходить в разных форматах, но очень важно, чтобы этот формат был простым и понятным всем участникам и имел легко документируемый результат.
Я часто пользуюсь в такой ситуации известным методом Impact/Effort (Значимость/Усилия). Все находящиеся в бэклоге требования сортируются на доске в виде визуальных элементов, разложенных по простой шкале «Необходимая-Полезная задача/Простой-Сложный сценарий». Во время этого упражнения нет необходимости сколько-нибудь глубоко анализировать каждое требование, достаточно очень верхнеуровнево оценить значимость и объем работ. Визуально на доске будет видно, как много задач попала в каждый сектор шкалы. После чего можно будет отстроить первичную структуру бэклога.
Во время такой процедуры необходимо отсеять все задачи, которые бизнес не ожидает получить в среднесрочном горизонте 3–6 месяцев, а также почистить бэклог от неактуальных, «протухших», неважных задач или дублей.
Шаг 2. Задать темп и направление работы
После того, как сформированы границы бэклога, можно задать приоритеты получившемуся списку требований. Бизнес-заказчикам известны целевые состояния, которые последовательно должен достигать продукт в своём развитии, те свойства, которые он должен приобрести и те возможности, которые он должен предоставлять пользователем через месяц, два и так далее. Поэтому список требований в бэклоге должен быть структурирован в соответствии с этими целями для их последовательного достижения.
Если команда проделала сортировку по методу Impact/Effort дальше я рекомендую собрать составы работ вокруг целей, чередуя «необходимые» и «полезные» задачи в списке приоритетов. Тогда команда разработки будет стремится выполнить состав работ в соответствии с поставленной целью, но останется пространство для маневра – отказаться от «полезных» задач, если ресурсы команды не позволяют реализовать весь объем требований в обозначенный период достижения цели.
Почему важно исходить именно из целей бизнеса? Сами по себе цели развития продукта меняются не часто. Бизнес планирует долгосрочный горизонт и оценивает объем инвестиций в продукт. Поэтому выстраивая состав работ вокруг обозначенной цели Владелец продукта получает определённую страховку от перепроритизации задач. В работу берётся именно то, что важно и нужно бизнесу в ближайшем горизонте.
И приятным бонусом является то, что после структурирования бэклога в соответствии с целями на 3–6 месяцев, потребуется не так много уточнений, поскольку направление и темп развития продукта, и следовательно деятельность команды разработки, оперативный план работы, приобретают определённость и чёткость. Особенно, если помимо бэклога в управлении развитием бэклога используется дорожная карта, что позволяет наследовать цели с верхних уровней стратегического планирования бизнеса, а не брать их с потолка.
Шаг 3. Обеспечить полноту информации
Первые два шага организуют структуру элементов работы, но все ещё не дают достаточно информации, необходимой для того, что бы можно было спроектировать вариант реализации требований. Элементы бэклога могут быть сформулированы, как угодно, а для того, чтобы создать техническое решение, эти элементы должны быть понятны разработчикам.
Реализация задач требует полноты информации об ожиданиях заказчиков, чтобы выбрать наилучший вариант решения. Но нет необходимости снабжать этой информацией все элементы работы в бэклоге. Наибольшей полнотой должны обладать требования, которые пойдут в работу в ближайшие пару недель.
Чтобы не тратить время на понимание, какие из поставленных задач уже пора обсуждать аналитикам и заказчикам, необходима удобная и понятная визуализация бэклога.
Очень часто можно увидеть бэклог просто в виде списка, приоритизированного сверху вниз. И почти так же часто этого недостаточно для оперативного планирования, для ответа на вопрос, чем будет занята команда в ближайшую итерацию.
Требуется визуализация жизненного цикла требований в бэклоге: что уже прорабатывается, что готовится к следующей итерации планирования, какой ещё объем задач по данной цели остаётся, а сколько целей в ближайшие месяцы ожидается реализовать.
Для того, чтобы показать динамику работы с требованиями, я рекомендую визуально пространство бэклога делить на этапы обработки требований (например, вертикальными столбцами на доске “в ожидании”, “ведется анализ”, “на уточнении” и т.п.). Разумееется, это не единственный вариант, средств визуализации очень много, и каждая команда может подобрать удобные ей варианты представления информации.
И ещё очень важной составляющей визуализации, о которой часто забывают, является дизайн самих элементов работы в бэклоге: набор маркеров и правил оформления, позволяющих визуально определить бизнес-заказчика, срочность и важность задачи, наличие рисков и крайних сроков и так далее. Как минимум я рекомендую ставить информативные заголовки на каждый элемент работы. Чтобы сочинить такой понадобится несколько секунд, но в будущем это сэкономит много сил на то, чтобы не искать пояснения о содержании.
Шаг 4. Сформировать правила управления бэклогом
Как уже говорилось выше, мало навести порядок в бэклоге, необходимо его там поддерживать, а для этого кто-то должен нести ответственность за управление требованиями. Если вы работает по фреймворку Скрам, эту ответственность принимает на себя Владелец продукта; если вы управляете работой, опираясь на Канбан-метод, этим занимается менеджер запросов сервиса. И даже если у вас нет определенной организации труда на основе каких-то практик, обычно роль ответственного за бэклог можно проявить и закрепить за кем-то из разработчиков.
Управление бэклогом подразумевает выстраивание системы правил взаимодействия всех заинтересованных лиц, участвующих в развитии продукта. Эти правила в явном виде отвечают на вопросы как осуществляется пополнение бэклога, каким образом осуществляется актуализация состава работ и как элементы бэклога готовятся к принятию в работу.
При этом обязательно необходимо разделить полномочия и зоны ответственности в процессе управления бэклогом. Бизнес-заказчики являются источником требований и обеспечивают актуальную и своевременную информацию относительно них, разработчики обязуются принимать и реализовывать требования как можно быстрее. Владелец бэклога обеспечивает взаимодействие между всеми и постоянный непрерывный обмен информацией, используя бэклог для поддержания информационного потока.
Agile-практики вводят регулярные мероприятия по пополнению и актуализации бэклога, и я рекомендую следовать этим циклам обмена информацией, даже если ваша команда не практикует Скрам или Канбан. Регулярность позволяет зарезервировать в календаре строго ограниченное время, отведённое на нужные вопросы. Вам не придётся много раз уточнять информацию, пользуясь массой всяких каналов передачи сообщений и проводя много времени в ожидании ответа. Достаточно один раз в неделю или две собраться и самым быстрым и верным способом, вербально, пообщаться о текущих вопросах.
Что вы получаете в итоге?
Бэклог продукта — это не просто структурированный список требований. Он предназначен для оперативного планирования, для того, чтобы балансировать нагрузку на разработчиков. Он позволяет приземлить среднесрочные цели и ожидания бизнеса о том, каким темпом и в каком направлении должен развиваться продукт на конкретный список задач, которые команда берет в работу каждую неделю.
Это инструмент визуализации того, какая работа должна быть сделана. Поэтому важно, чтобы любой соучастник развития продукта легко мог прочитать и пополнить всю информацию, сопровождающую реализацию требований.
Бэклог обеспечивает прозрачность процесса принятия задач в работу и позволяет накапливать опыт, в том числе измерять характеристики рабочего процесса, чтобы балансировать нагрузку на команду разработчиков и при этом не терять темп, нужный бизнесу для развития продукта. Неупорядоченный, хаотичный бэклог требует огромного перерасхода ресурсов команды на управление требованиями.
Потратив сравнительно немного времени на «заточку топора», вы получите удобный инструмент, реально экономящий время и избавляющий от бесконечных согласований и переговоров.
