Приоритизация бэклога на примерах из 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). Например, не стоит заниматься дизайном магазина в первые дни, если ещё не реализована функция продажи.
- Лучше иметь законченный продукт с багами, чем первоклассно работающие отдельные функции, с которыми невозможно запустить первую версию.
- Чтобы выполнять действительно важные задачи, бэклог нужно поддерживать в актуальном состоянии: регулярно собирать обратную связь от пользователей и клиента, отказываться от ненужных задач и добавлять новые.
При работе с бэклогом часто требуется быстро уточнять детали задач. Для этого будет полезна база знаний. Она помогает хранить всю связанную информацию в одном месте — от требований клиента до истории предыдущих решений команды. Это ускоряет планирование и уменьшает количество вопросов в процессе работы.
