Планировать работу и управлять задачами многим компаниям помогает бэклог (backlog). Это перечень требований к проекту, которые обозначены в порядке приоритета. С его помощью команда разработки понимает, чем надо заняться в первую очередь, а что вполне может подождать. Дадим определение бэклога, расскажем, как его правильно вести и почему он так важен для успешной работы.
Что такое бэклог
Говоря простыми словами, бэклог — это перечень задач и изменений для реализации проекта. От обычного списка он отличается приоритизацией требований: чем выше стоит задача, тем более срочной она считается. Также в перечне можно указать дедлайны, ответственных за выполнение — каждая команда сама решает, какие пункты нужно включить.
Бэклог задач — не статичный инструмент. Он сохраняет гибкость, в него вносят коррективы по мере продвижения проекта вперед. Также он делает работу прозрачной: команда понимает, что он нее требуется, и может планировать свои действия.
Чаще всего этот инструмент применяется при разработке ПО, особенно в гибких методологиях. Собственно, сам термин и возник в то время, когда на рынке появился гибкий подход к управлению под названием Agile.
Основные виды бэклогов
Существует несколько типов:
Бэклог продукта — это полный перечень задач, находящихся в бэклоге на данный момент. В процессе работы этот список постоянно меняется: часть пунктов пропадает по мере выполнения и появляются новые. Процесс заканчивается только после того, как у продукта завершается жизненный цикл: он становится неактуальным, в него перестают инвестировать и т. д.
Бэклог спринта — речь идет о работе по уже упомянутой методике Agile. В этом случае команда определяет цель спринта на ближайшие 2-4 недели. После составляется перечень задач, которые нужно выполнить только за определенный этап. Список должен быть готов к началу спринта, а изменения могут вносить только участники команды — заказчик лишь наблюдает за изменениями.
Бэклог релиза — чаще всего используется при масштабных проектах. Ориентирован на задачи, которые связаны с достижением конкретной цели — выпуска продукта. Нередко объединяет в себе несколько отдельных спринтов.
Бэклог проекта — то, о чем уже говорилось выше: перечень, задающий текущую последовательность действий согласно приоритизации.
Элементы бэклога продукта
Бэклог состоит из нескольких частей.
Функции продукта. Технические возможности, которые несут пользу для конечного клиента. Состоят из пользовательских историй (user story) — описания целей с точки зрения конечного потребителя — и расставляются по приоритетности. Они должны быть информативными и обладать объективными критериями для оценки.
Баги и ошибки. Перечень недочетов, не дающих системе нормально функционировать и нуждающихся в исправлении. Баги бывают срочными, когда надо поправить ошибку в текущем спринте или задаче — в этом случае разработчики должны оперативно вмешаться и привести все в порядок. Если специалисты устраняют их сразу, то такие ошибки могут даже не заносить в бэклог. Еще есть баги не слишком срочные, которые нужно решить до конца конкретного этапа — их вписывают в бэклог спринта. Если же дефект не влияет на качество и работоспособность системы в текущем этапе, то их заносят в бэклог продукта.
Технический долг. Возникает, если в процессе работы входящие задачи переносились, чтобы ускорить разработку или релиз. Еще появляется, если при планировании возникли ошибки. Техдолг в любом случае нужно устранить, даже если жалко тратить на это время — в противном случае в дальнейшем он серьезно скажется на работоспособности и удобстве продукта.
Исследования. Для полноценной разработки продукта нужна информация о нем. К конечному потребителю она не относится, но эти сведения изучают и анализируют разработчики. Такую подготовку обязательно надо провести, чтобы понимать все функции будущей системы. Часто никакой рабочей документации нет, поэтому в основу исследований ложится результат мозгового штурма команды.
Иногда в бэклог включают идеи и гипотезы — улучшения, которые призваны повысить эффективность или конкурентоспособность разработки. Их добавление в бэклог не означает, что они будут приняты в работу — множество идей так и остаются на уровне предложений.
Как создавать и вести бэклог
Любой бэклог начинается с дорожной карты (Product Roadmap). Составление roadmap — это полноценный стратегический план, структура проекта, где прописаны все этапы, которые должна пройти команда. Технические подробности здесь можно не указывать, а вот сроки — желательно. Плюс обязательно добавить общее видение продукта, миссию, цели, чтобы команда четко представляла, чем предстоит заниматься.
Для планирования бэклога нужна его визуализация. Некоторые используют большие стенды со стикерами, но все-таки проще заменить физический носитель на виртуальные доски. Многие разработчики работают удаленно, в команде можно встретить людей из разных городов и даже стран, поэтому дистанционный доступ для них критически важен.
Самый простой вариант — составить три колонки, например, «Бэклог», «В работе», «Готово». В первую колонку нужно внести список задач продукта, к каждому пункту приписать сроки, приоритет, ответственного за выполнение. Когда статус задачи меняется, карточку перемещают между колонками. Не забывайте постоянно актуализировать информацию.
Составление backlog продукта состоит из нескольких шагов:
Сбор требований к продукту. Нужно пользоваться несколькими источниками данных: информацией от заказчиков и стейкхолдеров, которые расскажут какие функции важны для бизнеса, отзывами и предложениями от пользователей. Поищите конкурентов: наверняка на рынке есть похожие продукты, и анализ покажет, что ждет целевая аудитория.
Создание структуры. Она должна быть понятна всей команде. Как правило, бэклог включает крупные задачи, более мелкие user stories, технические задачи, исправление дефектов.
Расстановка приоритетов. Нужно провести оценку задач и рассортировать их — от критически важных к второстепенным и незначительным. Например, к срочным будет относить баг вроде «На сайте не проходит оформление заказа со стороны покупателя». А вот «Добавить анимацию в интерфейс» на этом фоне вполне подождет.
Обновление бэклога. Происходит по мере его ведения. Регулярно отслеживайте, как продвигаются задачи — убирайте выполненные, меняйте приоритетные. Крупные цели лучше дробить на более мелкие и укладывать их в спринты длительностью 1-2 недели — так команда будет постоянно видеть прогресс и оперативно устранять ошибки.
Приоритизация и управление бэклогом
Со временем бэклог разработки продукта грозит разрастись, стать запутанным и неудобным. Поэтому, как уже говорилось, пункты нужно постоянно менять и актуализировать. Используйте понятные функциональные требования: если задача поставлена размыто, разработчики могут не понять, что от них ждут — а исправлять косяки всегда оказывается дольше и дороже. Скажем, если написано «Улучшить интерфейс», то не ясно, что именно надо сделать и в какой срок. А вот формулировка «К понедельнику добавить для пользователей такую-то функцию» — совсем другое дело.
Если команда работает со спринтами — скорее всего, так и есть, — то перед каждым этапом надо проверить, есть ли все необходимые детали, в правильном ли порядке расставлены приоритеты. При спринт-планировании обговаривайте, удобно ли команде, или можно сделать бэклог еще эффективнее.
Важно, чтобы все элементы бэклога продукта можно было реализовать. Он не должен содержать изначально невыполнимых задач: например, команда из двух человек не в состоянии выпустить полностью готовое, протестированное приложение за месяц. Нужно или больше сотрудников, или больше времени.
Если план постепенно реализуется, то все хорошо: значит, инструмент действует, а разработчики движутся в верном направлении. Если же прогресса нет, а задачи только копятся, придется выяснить, в чем ошибка — неправильное планирование, не хватает рук, нереалистичные дедлайны.
Отслеживание изменений всей командой позволяет сотрудникам оставаться в курсе любых нововведений. Стоит периодически проводить встречи с разработчиками по оптимизации бэклога: в этом должны участвовать все, а не только менеджер продукта. Последнему вообще стоит регулярно коммуницировать с командой по поводу накопившихся задач, привлекать их к обсуждению продуктовых проблем. Это поможет минимизировать технические риски.
Оптимизация называется грумингом и включает в себя анализ отзывов, комментариев и новых идей на предмет применения, удаление ненужных задач, разделение крупных целей на мелкие. Словом, бэклог должен оставаться структурированным, четким, постоянно обновляемым.
За продукт и его организацию в компании обычно отвечает product manager. Продакт-менеджер — востребованная профессия, которая подходит для начала карьеры в IT. Это специалист, выступающий связующим звеном между командой, бизнесом и пользователями. Именно он отвечает за то, чтобы готовый продукт был понятным и полезным. Зарплата такого специалиста зависит от его опыта и конкретной компании, но в среднем в месяц можно получать 150—180 тыс. рублей. Если речь о зарубежных проектах, то там оплата намного выше.
Продакт-менеджеры нужны везде, где создаются цифровые продукты. Это IT-компании, банки, медиа, сфера онлайн-образования. Профессия быстро развивается, а значит, спрос на таких специалистов будет расти — как и предлагаемая рынком зарплата. В онлайн-школе ProductStar есть курс «Профессия: Продакт-менеджер». За 10 месяцев с нуля вы получите все необходимые знания и навыки для успешного построения карьеры. В ходе обучения вы будете решать реальные задачи от топовых игроков рынка, а проекты и итоговые результаты можно будет добавить в портфолио.
Примеры и кейсы использования бэклога в проектах
Приведем пример бэклога. Команде разработчиков поступил заказ на разработку интернет-магазина одежды. Сначала нужно создать план для реализации всех необходимых функций — фильтрация по категориям, интеграция с платежными системами, настройка профилей покупателей.
Затем наступает черед приоритизации. Такие цели как безопасность данных и обработка платежей получают высший уровень приоритетности. А интеграция с соцсетями — средний уровень, ею не надо заниматься в первую очередь.
Каждые две недели команда проводит груминг-сессию, уточняет задачи, корректирует приоритеты, обсуждает изменения в бизнес-требованиях, проводит анализ фичей и багов. В итоге на протяжении всего проекта бэклог остается упорядоченным и актуализированным, что ведет к успешному запуску онлайн-площадки.
Частые ошибки при работе с бэклогом и как их избежать
Полезный инструмент может превратиться в склад бесполезных заметок, в которых сложно найти требуемую информацию. Это происходит, если вносить в него все идеи подряд и не убирать потерявшие актуальность. В итоге целей становится много, разработчики не знают, с чего начинать, приоритеты тоже не расставлены — и бэклог становится хаотичным. Избежать подобного просто: группировать цели по категориям, актуализировать приоритеты и постоянно чистить список.
Другая проблема — избыточная детализация. В попытке сделать «как лучше», команда начинает расписывать все до мелочей. Бэклог становится избыточным, громоздким, заниматься его обслуживанием трудно. Выход — думать, где нужны подробности и уточнения, а где вполне можно обойтись без них.
Еще одна «болезнь» бэклогов — отсутствие сроков, из-за чего задачи висят в списке месяцами. Исправляется это постановкой временных ограничений хотя бы для наиболее приоритетных целей.
Также нельзя игнорировать технический долг. В бэклоге должны быть задачи по рефакторингу и улучшению кода.
Заключение
Бэклог — важный и динамичный инструмент при управлении проектами. Это не просто перечень задач, поэтому необходимо грамотно, структурировано подходить к его составлению, ведению и своевременному грумингу.
