Приоритизация бэклога на примерах из IT: как закрывать действительно важные задачи?
Задачи в бизнесе могут быть простыми и короткими, а могут — сложными и долгими. Чтобы понимать, что и когда нужно сделать, при планировании все задачи подробно описывают и складывают в один список — бэклог.
Для успешной работы над проектом бэклог нужно правильно составлять и поддерживать. Разберём, как это сделать, на примере разработки приложения для покупки и чтения книг.
Что такое бэклог
Бэклог — это список элементов-задач, которые нужно выполнить. Это просто инструмент для планирования работы, поэтому его можно использовать в разных сферах, таких как разработка, финансы, маркетинг, строительство. Иногда бэклог проекта содержит объединённые одной целью задачи, а иногда разные:
Создание моста через реку будет проходить через несколько последовательных этапов: проектирование строительных схем, закупка материалов, подготовка территории.
Список дел юридической компании может быть более разрозненным, потому что нужно вести несколько проектов, например: договориться о цели по одному, подготовить материалы второго, проконсультировать нового клиента. Эти задачи связаны между собой только верхнеуровнево, потому что относятся к одной компании.
Зачем что-то автоматизировать и как это может приносить пользу
Что нужно знать про задачи бэклога
Чтобы расставить приоритеты рабочим активностям, им нужно присвоить понятные критерии.
Перед оценкой задач надо разобраться, как вообще они появляются и что из себя представляют.
Пример: наша IT-компания проектирует приложение для продажи электронных книг. Нужно сделать так, чтобы пользователь получал ознакомительный фрагмент по нажатию на кнопку. Как понять, насколько важна эта задача? Куда ставить её в бэклоге?
Чтобы дальше было понятнее, мы разберём два тезиса: юзер-стори и эпики.
Юзер-стори описывает, что нужно пользователю
Параметр, который показывает один из запросов пользователей к продукту.
Говоря простыми словами, юзер-стори объясняет, что должен уметь делать финальный сервис-приложение и для кого. Поэтому юзер-стори фиксируют ожидания пользователей от продуктов. Обычно они записываются на карточках и содержат название, номер, оценку трудозатрат и описание.
Юзер-стори может выглядеть так:
Как пользователь (разработчик, администратор), …
я хочу делать… ,
чтобы получить… .
Когда я делаю… ,
происходит следующее: … .
Пример с загрузкой ознакомительного фрагмента книги в приложении для чтения:
Как пользователь,
я хочу получить больше информации о книгах в магазине. Для этого я хочу иметь возможность нажимать на кнопку «прочитать фрагмент»,
чтобы загрузить этот фрагмент себе на телефон.
Когда я нажимаю на кнопку «прочитать фрагмент»,
происходит загрузка файла на мой телефон или электронную книгу, и я могу прочитать эту часть.
Получается, что юзер-стори описывает один из шагов сценария взаимодействия пользователя и продукта. Такой анализ позволяет лучше понять свою целевую аудиторию, их желания и потребности. Это помогает выделить самые основные приоритетные задачи и начать работу с них.
Возможности, которые описывают в юзер-стори, обычно можно реализовать за короткий интервал работы — спринт. Есть краткосрочные, среднесрочные и долгосрочные юзер-стори. По краткосрочным задачам всегда много информации, поэтому оценки ресурсов и времени на них точнее. Разобрать большую задачу сложно, поэтому иногда их выделяют в эпики.
Эпик — большая юзер-стори
Он тоже описывает часть сценария взаимодействия пользователя и приложения. Но при этом подразумевает более масштабные изменения и дополнения в проекте.
За один спринт команда не успеет закончить такой объём работы, поэтому эпик делится на несколько тесно связанных между собой юзер-стори. Чётких критериев, что считать эпиком, нет. Поэтому не всегда понятно, когда большая юзер-стори становится маленьким эпиком. Дробить этап на подзадачи или делать его в один подход, решают менеджеры проекта и системные аналитики.
Пример: если юзер-стори — это загрузка ознакомительного фрагмента, то эпиком может быть процесс покупки книги. Этот процесс может разделиться на несколько юзер-стори:
поиск книги по автору, названию или изданию;
выдача всей доступной информации о книге;
загрузка ознакомительного фрагмента;
оплата книги;
загрузка книги на устройство целиком.
Как приоритизировать бэклог
Когда состав юзер-стори ясен, нужно определить, какие задачи следует взять в работу в первую очередь. Общий принцип такой: выделить самые важные задачи и оценить их сложность. Это позволит эффективно двигаться к цели, выполняя шаги по приоритетам.
Чтобы понять сложность и трудозатратность задач, их часто оценивают в стори-поинтах.
Стори-поинты — система оценок для понимания юзер-стори и эпиков.
Это абстрактная оценка задач, отличная от часов, дней и других вариантов. Может выбираться индивидуально в каждом проекте для каждой команды. Вот как это работает.
Берётся простая задача с понятным планом исполнения, например, подключение эквайринга для оплаты сервиса онлайн.
Ей присваивается оценка в 1 стори-поинт.
Задача фиксируется и берётся за основу, чтобы сравнивать с ней остальные. Добавление раздела техподдержки может быть оценено в трудозатратах как 5 задач по добавлению новой страницы — иначе говоря, 5 стори-поинтов.
В чём польза оценки в стори-поинтах:
Система позволяет сосредоточиться на эффективности внутри команды, а не сравнивать разные отделы между собой.
Со стори-поинтами не получится закрывать контракты только исходя из затраченных часов. Получается более честный и удобный для клиента подход.
Команды могут осознанно или неосознанно накручивать оценки в обычных критериях, таких как часы. Со стори-поинтами так не получится, их сложно переложить на обычные критерии. В итоге рабочий процесс ориентирован на закрытие цели проекта, а не на простой расход ресурсов.
Пример: в проектировании нашего приложении задачей на 1 стори-поинт может быть добавление ограничения на размер загружаемого файла.
Шаг 1. Распределить бизнес-цели задач
Стори-поинты — не главный критерий распределения приоритетов. Важнее то, что мы получим после завершения каждой конкретной задачи.
Погружением в бизнес-тонкости и техническое устройство IT-проекта занимается системный аналитик. Он общается с клиентом, разбирается в тонкостях бизнеса и требованиях к продукту. Потом передаёт это знание команде и помогает разработчикам спроектировать создание программы так, чтобы финальный продукт решал все поставленные задачи.
Если какие-то запросы в продукте второстепенны, то их стараются сделать с минимальными усилиями. Например, если первая черновая версия приложения должна быть готова уже через месяц, нужно точно решить, что в продукте имеет критическое значение — функционал для пользователей или дизайн.
После этого все этапы можно оценить в стори-поинтах и поставить в план спринта.
Шаг 2. Перенести в бэклог спринта
Бэклог спринта — короткий перечень задач, которые должны быть выполнены до конца спринта. Команда каждый раз проверяет, что из основного списка нужно сделать в ближайшее время, и переносит эти карточки в этот бэклог.
Целью спринта может быть одна или несколько задач. Это зависит от возможностей и размера команды.
Шаг 3. Расставляем задачи
Создаём по юзер-стори для каждой небольшой задачи. Если задачи получаются большие, разбиваем их на промежуточные этапы и создаём эпик. Юзер-стори эпика связаны одной темой. Для оценки сложности устанавливаем задачу — эталонный стори-поинт — и решаем, сколько таких стори-поинтов нужно будет потратить на все остальные карточки бэклога.
Разобравшись с каждой, можно расставлять приоритеты.
Описание принципа расстановки приоритетов может выглядеть сложно. Чтобы было проще, пользуются инструментами управления знаниями, которые помогают ничего не упустить из виду и пользоваться актуальной информацией. Например, Minerva Knowledge.
Другие методы приоритизации бэклога
Помимо стори-поинтов есть ещё другие техники оценки и выставления приоритетов задач. Вот несколько популярных.
Story Mapping
Способ визуализации юзер-стори с оценкой приоритетов. В результате видно, какие из них важнее и как они связаны с пользовательскими действиями.
Задачи в этом случае расставляются в виде графика-карты с этапами использования продукта. Например, в книжном приложении могут быть такие этапы, которые будут идти один за другим:
Авторизация в приложении.
Поиск книги.
Добавление в корзину.
Покупка.
Пример: На этапе регистрации у пользователя есть несколько вариантов действий:
войти через почту;
войти телефон;
использовать единое окно входа;
начать пользоваться приложением без регистрации.
Теперь все задачи на этапе регистрации тоже надо расставить. Они будут располагаться одна над другой, при этом самая важная (например, вход через почту) будет наверху, а менее важные (например, без регистрации) — ниже.
Value & Effort (Lean Prioritization)
Позволяет сосредоточиться на задачах с максимальной ценностью для проекта при минимальных затратах.
Для этого нужно построить график из 4 частей:
лёгкие задачи с высокой ценностью;
сложные задачи с высокой ценностью;
лёгкие задачи со средней или низкой ценностью;
сложные задачи со средней или низкой ценностью.
Задачи с высокой ценностью и низкими усилиями идут в первую очередь. После этого можно брать задачи посложнее и с высокой ценностью. Сложные функции с малой ценностью откладываются на потом либо не реализуются вовсе.
Вот как могли бы оцениваться задачи в нашем сервисе для чтения:
Добавить отзывы пользователей — высокая ценность, потому что повышает доверие. Требует средних усилий для выполнения.
Рекомендовать книги на основе ИИ — высокая ценность, высокая сложность.
Изменить шрифт на экране чтения — низкая ценность, минимальные усилия.
Kano
Метод приоритизации, который оценивает функции продукта по их влиянию на удовлетворённость пользователей. Разделяет функции на пять категорий:
базовые,
ожидаемые,
желательные,
привлекательные,
ненужные.
Kano помогает понять, какие функции действительно нужны пользователям, какие могут стать вашим конкурентным преимуществом, а какие лучше не добавлять вообще. Вот что может быть в книжном сервисе из каждой категории.
Базовые функции:
Покупка и скачивание книг.
Экран для чтения без багов.
Быстрый поиск книг.
Без этих функций клиенты просто не смогут пользоваться продуктом. При этом их наличие не вызовет восторга или удивления, потому что они подразумеваются по умолчанию.
Ожидаемые функции:
Удобная сортировка книг по автору или жанру, добавление в «Избранное».
Стабильная работа приложения.
Чем лучше они реализованы, тем выше удовлетворённость пользователей.
Желательные функции:
Персональные рекомендации книг на основе вкусов.
Темы оформления.
Эти функции не ожидают, но их наличие может повысить лояльность.
Нейтральные функции:
Добавление редких шрифтов или эффектов перелистывания страниц.
Большинство пользователей не заметят разницы между версиями с этими возможностями или без них, поэтому усилия по разработке и внедрению могут быть потрачены впустую.
Ненужные функции:
Реклама других приложений в библиотеке.
Они могут вызывать раздражение, даже если их просто реализовать.
Как в итоге выглядит бэклог продукта
Бэклог продукта — это набор приоритизированных задач для выполнения, к которым ещё не приступили. Это одна из трёх важных частей всего проекта:
Бэклог продукта.
Бэклог спринта.
Инкремент — появление новой функциональности.
Типичный бэклог состоит из фич — новых функций в проекте. Но может включать и исправление багов, изменения, исследования и другие задачи.
В разных методологиях бэклоги могут различаться. Вот несколько примеров.
В Scrum выделяют самые важные фичи или юзер-стори для каждого спринта.
Канбан обычно используют в Continuous Delivery — когда программу делают небольшими частями, для стабильной работы. Новые задачи добавляют постепенно, чтобы команда успевала их выполнять.
В Scaled Agile Framework ведут ряд разных бэклогов разного размера, а не единый бэклог всего продукта. Например, инициативы организации, разные решения, их элементы, юзер-стори.
В Waterfall бэклог обычно не используется — в этой схеме план работы составляется заранее и в строгой последовательности. Поэтому в Waterfall очень важен предварительный этап аналитики, когда нужно выявить все требования к проекту и выстроить архитектуру и порядок реализации.
Как вести бэклог продукта
Бэклог и план работы постоянно пересматриваются для поддержания в актуальном состоянии. В процессе могут появиться новые требования и понимание продукта, поэтому что-то надо будет остановить и выбросить, а что-то добавить.
Для оценки бэклога разбирают:
отзывы пользователей после внедрения новых функций;
соображения разработчиков.
Например, после первых тестов пользователи начинают жаловаться, что в приложении не хватает удобной сортировки книг. Разработчики анализируют задачу и выясняют, что для реализации такого запроса нужно обновить структуру баз данных и добавить функцию фильтров. В итоге повышается приоритет для задачи «добавить сортировку книг», а задача «добавить тёмную тему» переносится на следующие спринты.
Бэклог продукта ведёт продакт-оунер или менеджер продукта. Но при этом список этапов проекта должен быть доступен всей команде.
Благодаря тому, что приоритеты задач регулярно проверяются и обновляются, команда занимается только актуальными задачами. Поэтому в каждый спринт попадает только то, что необходимо сделать в первую очередь.
При этом бэклог спринта тоже обновляется на ежедневных митапах.
В итоге: как правильно приоритизировать бэклог
Вот краткий список советов, которые важно помнить при планировании и работе с бэклогом.
Бэклог — список всех задач, которые надо сделать. Каждую из них нужно проанализировать на критичность для проекта и оценить трудозатраты на её выполнение.
В первую очередь должны быть выполнены задачи, которые необходимы для минимально работающего продукта (MVP). Например, не стоит заниматься дизайном магазина в первые дни, если ещё не реализована функция продажи.
Лучше иметь законченный продукт с багами, чем первоклассно работающие отдельные функции, с которыми невозможно запустить первую версию.
Чтобы выполнять действительно важные задачи, бэклог нужно поддерживать в актуальном состоянии: регулярно собирать обратную связь от пользователей и клиента, отказываться от ненужных задач и добавлять новые.
При работе с бэклогом часто требуется быстро уточнять детали задач. Для этого будет полезна база знаний. Она помогает хранить всю связанную информацию в одном месте — от требований клиента до истории предыдущих решений команды. Это ускоряет планирование и уменьшает количество вопросов в процессе работы.