В процессе разработки сервисов и программ создают бэклог продукта. Если кратко, это задачи, которые расставлены в порядке приоритета. Рассказываем, как и зачем создавать бэклог, в каких сервисах это удобно сделать.
Что такое бэклог
Бэклог — список задач по проекту, которые приоритизируют по уровню их важности. Этот инструмент — элемент методики Agile, гибкого управления проектами. Смысл Agile в том, чтобы быстро создавать программное обеспечение и гибко реагировать на изменения. Бэклог также направлен на это.
Представьте, команде разработчиков нужно создать мобильное приложение. Они разрабатывают MVP — минимально жизнеспособный продукт, затем дорабатывают новые функции. В бэклоге есть список функций, которые нужно доработать:
- онлайн-чат с техподдержкой
- тёмная тема
- push-уведомления
- вход по Яндекс ID
Именно в такой приоритетности и разрабатывают функции приложения. Если вдруг product owner — владелец продукта — с заказчиком решают в первую очередь разработать функцию экономии заряда батареи, эту задачу добавляют в бэклог первой. Суть в том, что поочередность задач в бэклоге можно менять. Именно это делает его полезным инструментом для многих проектов.
Так выглядит бэклог разработки в OkoCRM. Карточки с задачами можно добавлять, удалять, менять их приоритетность.
Бэклог — это простыми словами список задач, которые расставили в порядке приоритета. Команда берёт их в работу по очереди, а при необходимости очерёдность можно менять.
Допустим, в компании нужно систематизировать работу над контентом. Работу над статьями для блога и постами для социальных сетей можно вести по принципу бэклога. Для этого создают канбан-доску с этапами работы над контентом и бэклогом.
Выглядит это примерно так:
Бэклог для контента компании в OkoCRM.
Из чего состоит бэклог продукта
Функции
Функции — описание технических аспектов продукта. Они определяют, что именно должен делать продукт для удовлетворения потребностей пользователей.
Для каждой функции создают карточку, в ней описывают подробности по задаче, добавляют чек-листы, сроки, ответственных пользователей, оставляют комментарии и набрасывают файлы со ссылками.
Пример карточки с задачей по разработке функции в OkoCRM.
Ошибки и баги
При разработке любого продукта возникают ошибки, которые нужно дорабатывать. Их также добавляют в бэклог. Допустим, пользователи жалуются на некорректную работу уведомлений. Это баг, который команда должна исправить. Чтобы это сделать, задачу добавляют в бэклог и назначают её приоритет.
Допустим, ошибку нужно исправить в течение следующего спринта. Спринт — отрезок времени, отведённый для выполнения пула задач. Обычно длится 1-4 недели.
Технический долг
Технический долг — элементы бэклога или задачи, которые пришлось отложить. Причины могут быть разными: команда не успевает, потому что в бэклог добавили новые задачи или на этапе планирования бэклога неправильно рассчитали время выполнения задач.
Допустим, команде пришлось исправлять несколько серьёзных багов, это отняло много времени и запланированные функции стали техническим долгом.
Исследования
Ещё частью бэклога продукта являются исследования, которые помогают команде лучше понять потребности пользователей или изучить тренды в своей нише. Исследования могут состоять из экспериментальных задач, анализа рынка, тестирования гипотез.
На чем основан бэклог продукта
Для формирования бэклога продукта, создают дорожную карту проекта и пользовательские истории.
Дорожная карта. Это инструмент, с помощью которого визуализируют этапы разработки продукта. Для этого работу над ним разбивают на этапы, назначают для каждого из них сроки. Бэклог — это более подробное описание задач, а дорожная карта — описание проекта крупными мазками.
Road map строят с помощью диаграммы Ганта, делают схемы или карты, таблицу. Иногда на дорожной карте показывают зависимости, если от выполнения одного этапа работ зависит другой.
Пример дорожной карты проекта Rubus Fund.
Пользовательские истории. Это описание того, как должен выглядеть продукт, чтобы он был удобным для пользователя. Причём описание составляют от лица пользователя, заинтересованного в продукте. Например, «Как клиент интернет-магазина, я хочу оплачивать покупки по qr-коду, чтобы сократить время оплаты».
User Story помогают понять, какие функции важны пользователям и почему. Чтобы разработать пользовательские истории, изучают потребности целевой аудитории, проводят интервью и фокус-группы. Затем составляют эпики — более подробное описание пожеланий пользователей, из которых и формируют истории.
Допустим, нужно разработать мобильное приложение CRM-системы. У текущих пользователей узнают, какие модули CRM должны быть в мобильной версии, какие функции для них важны. Например, пользователям важно работать с таск-трекером, вести сделки и автоматизировать работу с документами. Это эпик, который состоит из трёх пользовательских историй:
- Как пользователь приложения, я хочу ставить задачи в таск-трекере, чтобы систематизировать работу над проектом
- Как пользователь приложения, я хочу работать со сделками, чтобы вести продажи в любое время с телефона
- Как пользователь приложения, я хочу автоматизировать работу с документами, чтобы быстро их заполнять
Именно по такой формуле строится пользовательская история ↓
Так можно описать требования пользователей в пользовательских историях.
Где работать с бэклогом
Команды, которые разрабатывают программы, работают в CRM-системах, планировщиках и таск-трекерах. Удобно, когда все возможности этих сервисов объединены в одном инструменте. Например, в OkoCRM есть модули и для команды разработчиков, и для отделов продаж и маркетинга.
В OkoCRM в разделе «Проекты» есть канбан-доски, на которых можно вести бэклог и другие этапы работы над продуктом или любыми проектами. Вот как это выглядит ↓
Пример бэклога в OkoCRM, который позволяет упорядочивать работу команды.
Функции, которые доступны для управления проектами в OkoCRM:
- Настройка канбан-доски: можно установить любые этапы работы
- Шаблоны задач, которые можно создавать для однотипных опций, например, для тестирования ошибок или отчетов
- Трекер времени работы
- Дата начала и окончания работ
- Метки
- Чек-листы с подзадачами
- Статистика работы команды
- Хранение файлов, ссылок, паролей
- Управление доступами участников проекта
Можно выбирать сервис, ориентируясь не только на функционал, но и на интерфейс, скорость работы, качество техподдержки. Советуем должным образом протестировать эти моменты, когда выбираете инструмент для работы с бэклогом.
Пошаговая инструкция: как собрать бэклог продукта
Шаг 1. Составить четкую дорожную карту проекта
Чтобы создать дорожную карту, нужно изучить целевую аудиторию и составить пользовательские истории. На основе этой информации разрабатывают дорожную карту. Представим, что нужно составить дорожную карту для разработки мобильного приложения CRM-системы. У нас есть такие пользовательские истории:
- Как пользователь приложения, я хочу ставить задачи в таск-трекере, чтобы систематизировать работу над проектом
- Как пользователь приложения, я хочу работать со сделками, чтобы вести продажу в любое время с телефона
- Как пользователь приложения, я хочу автоматизировать работу с документами, чтобы быстро их заполнять
- Как пользователь приложения, я хочу работать с заявками клиентов, чтобы быстрее им отвечать
- Как пользователь приложения, я хочу вести клиентскую базу, чтобы сохранять информацию о клиентах
Зная, какие важные функции нужно разработать для пользователей, составляем дорожную карту↓
Road map можно разработать в любом удобном виде: схемой, таблицей, диаграммой.
Шаг 2. Создать элемент невыполненной работы
Теперь нужно понять, какие задачи необходимо выполнить для завершения каждого этапа. Делаем декомпозицию цели и составляем перечень задач. Например, чтобы создать модуль «Сделки» в мобильном приложении, нужно выполнить такие задачи:
- продумать дизайн
- написать код
- протестировать работу модуля
- исправить ошибки и баги
- протестировать модуль под нагрузкой
Шаг 3. Приоритизировать задачи
Пока у нас получился просто список задач, нужно провести приоритизацию бэклога. Для этого каждую задачу можно оценить по методу RICE, то есть проанализировать 4 фактора:
- Reach, охват — какое количество людей затронет внедрение новой функции. Параметр измеряется в количестве человек
- Impact, воздействие — насколько кардинально новая функция изменит пользовательский опыт. Параметр измеряется по шкале от 1 до 3
- Confidence, уверенность — насколько вы уверены, что новая функция будет полезной для пользователей. Измеряется в процентах от 50% до 100%
- Effort, усилия — сколько усилий, то есть времени, нужно на внедрение функции. Параметр чаще всего считают в человеко-часах или человеко-днях. Допустим, он может быть равен 6, если на задачу нужно потратить 6 дней
Чтобы посчитать показатель RICE, перемножают охват, воздействие и уверенность, затем делят на усилия. Значение считают для каждой задачи, чем выше цифра, тем важнее задача.
Шаг 4. Постоянная доработка бэклога продукта
Бэклог — не строго установленный список задач, поэтому с ним постоянно работают: меняют приоритетность задач, добавляют новые, удаляют ненужные.
Допустим, пользователи часто пишут в техподдержку и просят добавить в мобильное приложение возможность настраивать метки в карточках сделок. Такую задачу добавляют в бэклог и назначают её приоритетнее других, а по остальным задачам также меняют приоритетность.
Подытожим
- Бэклог — список задач по проекту, которые приоритизируют по уровню их важности. Этот инструмент — элемент методики Agile, гибкого управления проектами
- Бэклог состоит не только из функций, которые нужно разработать для сервиса, но и из других элементов: багов и ошибок, исследований, технического долга — задач, которые не успели сделать
- Для разработки продукта нужно составить пользовательские истории и разработать дорожную карту проекта. Затем этапы работы разбивают на задачи и приоритизируют их.
