Измените языковые настройки Топвизор для работы с сервисом на родном языке. Вы также сможете выбрать и установить язык интерфейса позже в настройках Аккаунта. Измените языковые настройки Топвизор для работы с сервисом на родном языке. ru Русский Выбрать

Управление бэклогом — руководство для SEO-специалистов

Управление бэклогом — руководство для SEO-специалистов

Перевод и адаптация статьи Адама Джента на The SEO Sprint. Рассказываем, что такое управление бэклогом и как SEO‑специалисты могут при помощи управления бэклогом достигать своих целей.

Представим, что у вас есть очередная задача по сайту для программиста. Кажется, что нужно лишь добавить её в Jira (или в другой инструмент управления проектами) и разработчики её реализуют. Но не всё так просто.

Основная проблема — в разрыве между списком задач по SEO и бэклогом разработчиков:

Список задач SEO и бэклог разработчиков 
Список задач SEO и бэклог разработчиков 

Любой список задач должен пройти через сложные внутренние процедуры, прежде чем он попадет в бэклог разработки. В этом хаосе легко забыть, потерять или проигнорировать задачи. Вот как примерно это выглядит:

Реальный разрыв между списком SEO‑специалиста и бэклогом разработчика
Реальный разрыв между списком SEO‑специалиста и бэклогом разработчика

Однако бэклогом можно управлять — и с помощью вполне простых приемов.

Что такое управление бэклогом

В области разработки и проектирования программных продуктов бэклог обычно представляет собой список задач в Jira, Azure, Trello и т. п

Пример бэклога разработчиков в Jira
Пример бэклога разработчиков в Jira

Управление бэклогом — это процесс добавления, корректировки и рефакторинга этих задач. 

Управление выполняется для того, чтобы техническая команда работала над самыми важными для пользователей или бизнеса задачами.

Хотя за управление списком задач как правило отвечает один человек (в скрам‑команде это обычно владелец продукта), важно отметить, что это командный процесс.

Владелец продукта или назначенный на эту роль человек отвечает за то, чтобы бизнес‑команды и команды разработчиков постоянно проводили рефакторинг задач, находящихся в бэклоге.

Почему важно управлять бэклогом

Управление бэклогом помогает преодолеть разрыв между стратегией и её реализацией — с помощью разделения более крупных задач на более мелкие и обладающие определённым приоритетом (их называют тикетами), готовые к следующему спринту.

Управление бэклогом разработки может повлиять на то, с какой частотой и систематичностью команда разработчиков выпускает релизы.

Разработчики и продуктовые команды работают совместно, чтобы непрерывно разбивать проекты на функциональные возможности, а затем возможности — на задачи, обладающие определённым приоритетом:

Схема работы
Схема работы

Управление бэклогом поможет:

  1. Сокращать в программном коде количество ошибок и дефектов: благодаря совместной работе бизнес‑команды и команды разработчиков над постановкой и уточнением задач программный код соответствует критериям готовности (Definition of done, DoD) при выпуске релиза.

  2. Повышать эффективность и производительность: согласованный процесс совместной работы всех команд улучшает настрой сотрудников и позволяет быстрее работать над программным продуктом.

  3. Решать проблемы: команды сосредоточены не просто на результатах, а на решении проблем бизнеса и клиентов, которые входят в состав более масштабной стратегии.

  4. Улучшить рабочий настрой и сплочённость сотрудников: последовательный процесс управления задачами помогает преодолеть коммуникационный разрыв между сотрудниками и сделать так, чтобы разные команды работали совместно.

Как продуктовые команды управляют бэклогом

Продуктовые команды управляют не одним бэклогом, а фактически разбивают его на три части:

  • бэклог возможностей;

  • бэклог продукта;

  • бэклог разработчиков.

3 бэклога продуктовой команды
3 бэклога продуктовой команды

Разделение бэклога разработки на три части помогает сконцентрировать усилия команды разработчиков и продуктовой команды, а также поддерживает цикл итераций разработки.

Рассмотрим подробнее каждый бэклог.

Бэклог возможностей

Бэклог возможностей — список идей и задач из разных источников.

Это первый бэклог, куда попадают и где хранятся все идеи:

Как выглядит бэклог возможностей 
Как выглядит бэклог возможностей 

Если вы работаете в компании, то могли заметить, что идеи быстро и массово поступают от множества заинтересованных в программном продукте лиц, включая:

  • высшее руководство;

  • разработчиков;

  • маркетологов;

  • специалистов по UX и дизайну;

  • пользователей, а также других лиц.

Именно на основе этого огромного списка смутных «возможностей» продукта команды анализируют тенденции и решают, что необходимо добавить в бэклог продукта.

Вы можете увидеть бэклоги возможностей у поставщиков инструментов для SEO — например, у Sitebulb есть список функциональных возможностей, который состоит из 195 запросов и в котором пользователи голосуют за различные идеи:

Список запросов на добавление функциональных возможностей в Sitebulb
Список запросов на добавление функциональных возможностей в Sitebulb

Но, скорее всего, всех 195 запросов нет в бэклоге разработки.

Создание соответствующих тикетов и управление ими было бы пустой тратой времени, ресурсов и сил. Кроме того, для этих проектов пришлось бы не просто составлять «пользовательские истории» — будет много работы, характерной для фазы Discovery.

Вместо этого создают бэклог возможностей для хранения тех задач и идей, которые могут пригодиться в будущем.

Бэклог продукта

Бэклог продукта или, точнее, дорожная карта продукта — это согласованные важные инициативы, которые компания стремится реализовать для обеспечения своего развития и удовлетворения потребностей клиентов.

Когда продуктовые команды завершают разработку стратегии с инициативами, за которыми закреплены определённый приоритет и задачи, она и будет выступать дорожной картой продукта, ориентированной на конкретные результаты.

Пример дорожной карты
Пример дорожной карты

Кроме того, в бэклог продукта также могут добавляться те задачи или идеи из бэклога возможностей, которые соответствуют стратегии бизнеса и продукта.

Однако использование бэклога продукта не ограничивается простым добавлением в него задач. На самом деле бэклог продукта используется как инструмент для коммуникации, оценки задач и совместной работы с разработчиками.

Продуктовые команды пользуются дорожной картой в простом формате «сейчас — на очереди — в будущем», по которой перемещаются задачи и инициативы.

Пример перемещения задач по дорожной карте
Пример перемещения задач по дорожной карте

Согласно этому формату дорожной карты продуктовые команды могут создать три колонки на канбан‑доске:

  1. Сейчас (Now) — те задачи или инициативы, над которыми в настоящее время работает команда в бэклоге разработчиков.

  2. На очереди (Next) — те задачи или инициативы, которые изучает и детализирует команда, чтобы подготовить их к отправке в бэклог разработчиков.

  3. В будущем (Later) — задачи, у которых более низкий приоритет, но над которыми будут работать в будущем.

Формат дорожной карты «cейчас — на очереди — в будущем» используется продуктовыми командами в качестве моста между бэклогом возможностей и бэклогом разработчиков. Это процесс взаимодействия с командой разработчиков, который помогает ей ориентироваться в том, какие следующие важные задачи следует брать в работу.

План продукта, на котором представлены столбцы «Сейчас», «На очереди» и «В будущем»
План продукта, на котором представлены столбцы «Сейчас», «На очереди» и «В будущем»

Вместо использования огромного списка задач в этом формате делается акцент на порядке и приоритете запланированных задач, чтобы команда разработчиков могла в них ориентироваться.

Вместо того чтобы перемещать задачи в пределах одного столбца, в этом формате можно быстро перемещать задачи из столбцов «На очереди» и «В будущем», основываясь на новых требованиях к выполнению задач или на их приоритете.

Кроме того, я обнаружил, что эта методика полезна для управления задачами в столбце «На очереди».

Она указывает команде разработчиков (и вам), какие задачи необходимо изучить, детализировать и согласовать, чтобы их можно было внести в бэклог разработки.

Бэклог разработчиков и его наполнение

Бэклог разработки — это не хранилище идей, а место, где команда разработчиков определила, поняла и оценила задачи.

Планирование пользовательских историй для бэклога разработчиков
Планирование пользовательских историй для бэклога разработчиков

Именно этот процесс помогает продуктовым командам следить за тем, чтобы задачи в бэклоге разработчиков были подходящего для спринтов (коротких временных интервалов, в течение которого скрам‑команда выполняет определённый объём работы) размера. В Agile контроль над размером задач помогает поддерживать движение цикла итераций.

Процесс разделения бэклога на три части и обеспечения работы над задачами, которые существенно повышают ценность продукта для клиентов или бизнеса, называют владением продуктом. Этим процессом занимается владелец продукта.

Схема работы бэклога
Схема работы бэклога

Важно отметить, что владелец продукта — это роль, хотя в некоторых командах это может быть и настоящая должность. Но у специалистов по SEO не всегда есть менеджер проекта или специалист по продукту для устранения этой задержки в реализации их задумок. Поэтому SEO‑специалистам, особенно штатным, возможно, придётся выполнять этот процесс самостоятельно, чтобы добиваться своих целей.

Как достигать SEO‑целей с помощью управления бэклогом

Относитесь к управлению бэклогом со всей серьёзностью

Компания или команда, которая относится к управлению бэклогом несерьёзно, столкнется со следующими последствиями:

  1. Раздутые бэклоги разработчиков: поскольку любой отдел компании может отправлять разработчикам задачи, они просто добавляются в постоянно растущий список без какого‑либо определения их приоритетности или ценности для аудитории продукта.

  2. Увеличение количества программных ошибок и дефектов: плохо сформулированные и непонятные тикеты приведут к тому, что релизы не будут оправдывать ожидания тех, кто такие тикеты создавал.

  3. Ухудшение продуктивности и замедление разработки: нестыковки между работой команды разработчиков и реальными потребностями бизнеса снижают продуктивность разработчиков, поскольку им приходится тратить больше времени на исправление программных ошибок и дефектов, возникших из‑за плохо сформулированных задач.

  4. Недовольные сотрудники: хаос в виде забрасывания разработчиков неясно сформулированными задачами может вызвать напряженность между заинтересованными в бизнесе лицами и разработчиками, что приведет к недовольству сотрудников.

  5. Увеличение риска и сроков подготовки релизов: ухудшение продуктивности и недовольство сотрудников приводит к выпуску объёмных релизов, которые могут представлять собой дополнительный риск для бизнеса.

Для исключения подобных ситуаций успешные продуктовые команды используют методики управления бэклогами, чтобы тщательно управлять задачами и указывать команде направление работы.

Используйте карту с разделами «Сейчас», «На очереди» и «В будущем»

Формат дорожной карты «сейчас — на очереди — в будущем» можно использовать для управления как задачами, так и инициативами по SEO при работе непосредственно с клиентскими командами разработчиков.

Автор оригинальной статьи использует доску Tech SEO Backlog для управления тикетами или задачами, перемещая их по доске по мере обсуждения и согласования с разработчиками требований к выполнению задач.

Пример дорожной карты в Notion со столбцами Complete («Завершено»), Now («Сейчас»), Blocked («Заблокировано») и Next («На очереди»)
Пример дорожной карты в Notion со столбцами Complete («Завершено»), Now («Сейчас»), Blocked («Заблокировано») и Next («На очереди»)

Инструменты наподобие Notion, Trello, Asana и т. п. можно использовать для быстрого создания дорожной карты такого формата и обмена ею с командами разработчиков в рамках процесса управления бэклогом.

Вы также можете использовать эти системы для хранения бэклога возможностей, который для клиента будет столбцом «В будущем».

Пример бэклога возможностей
Пример бэклога возможностей

Именно сюда вы можете заносить любые идеи или предложения по улучшению SEO, чтобы не забыть их и не заполнять бэклог разработчиков неясно сформулированными задачами.

Также формат дорожной карты «сейчас — на очереди — в будущем» можно использовать для информирования клиентских команд о состоянии работ по SEO и о прогрессе проектов. Эти инициативы связаны с задачами на доске Tech SEO Backlog.

Инициативы по SEO, для которых используется формат дорожной карты «сейчас — на очереди — в будущем» (Now — Next — Later)
Инициативы по SEO, для которых используется формат дорожной карты «сейчас — на очереди — в будущем» (Now — Next — Later)

Кроме того, и это самое главное, досками Notion, Trello и Asana можно делиться с клиентскими командами, чтобы обеспечить полную прозрачность в отношении хода выполнения задач.

Таким образом, бэклог теперь разделён на три понятных и доступных области. Такой бэклог выступает источником достоверных данных и ориентиром для разработчиков и заинтересованных лиц со стороны компании.

Возьмите проведение discovery‑процесса в привычку

Разработчикам не нужно знать, что находится в нижней части бэклога возможностей: им нужно сосредоточиться на задачах в колонке «На очереди» в бэклоге SEO.

Формат дорожной карты «сейчас — на очереди — в будущем» облегчает общение с разработчиками и помогает быстро определить, что именно нужно с ними обсудить.

Схема работы 
Схема работы 

Однако, как и при управлении бэклогом, очень важно еженедельное обсуждение требований к выполнению задач и оценка задач разработчиками.

Такое обсуждение не обязательно должно быть длительным, ведь на самом деле в Аgile‑фреймворках полно мероприятий, ограниченных по времени.

Поэтому для таких ивентов используется тот же принцип ограничения по времени. Достаточно будет 30‑минутной встречи с разработчиками, чтобы обсудить с ними задачи в столбце «На очереди». Требования к выполнению задач обсуждаются и определяются с разработчиком, который будет заниматься реализацией соответствующих изменений.

Количество таких мероприятий может зависеть от частоты появления задач, но лучше не более 2‑3 в неделю.

Это означает, что задачи обоснованно подтягиваются в бэклог разработки, а не отправляются туда «принудительно».

Форматируйте задачи для бэклога разработчиков

При создании задач в разделённом на три части бэклоге убедитесь, что у них правильный формат, поскольку они перемещаются между столбцами по принципу «В будущем» > «На очереди» > «Сейчас».

Задача, добавленная в столбец «В будущем», может быть очень расплывчатой и неясной — всего лишь идеей:

Пример задачи в бэклоге возможностей (столбец «В будущем»)
Пример задачи в бэклоге возможностей (столбец «В будущем»)

Но задача в столбце «На очереди» должна быть отформатирована так, чтобы её можно было скопировать и вставить (или отправить) в систему управления задачами, предназначенную для разработчиков. Задача должна соответствовать согласованным критериям готовности, чтобы разработчики и вы понимали, когда её можно считать выполненной.

Очень распространенный формат задач, который используют продуктовые команды и разработчики, — это пользовательская история (user story):

Пример пользовательской истории
Пример пользовательской истории

Форматирование задач может полностью зависеть от предпочтений продуктовой команды и команды разработки. Существуют сотни способов составления тикетов, и разные продуктовые команды составляют их по‑разному.

Возьмите рефакторинг задач в привычку

Наконец, не забывайте участвовать в соответствующих обсуждениях, когда команды разработчиков проводят рефакторинг задач в бэклоге разработки.

Рефакторинг — это проверка того, нуждаются ли задачи бэклога разработки в обновлении или изменении в связи с появлением новой информации или в связи с недавними релизами.

Проводить рефакторинг задач важно, потому что любые изменения могут повлиять на список задач в бэклоге разработчиков:

Пример бэклога в Jira
Пример бэклога в Jira

И на задачи в бэклоге продукта и бэклоге возможностей:

Рефакторинг задач в SEO-бэклоге
Рефакторинг задач в SEO‑бэклоге

Вы удивитесь, как быстро задача или требования к её выполнению могут устареть — всего через одну или две недели после её согласования, особенно если вы проверяете или тестируете свои релизы.

Поэтому обязательно проводите встречи с командой разработчиков или продуктовой командой, чтобы выполнять рефакторинг задач как можно чаще.

Главное

Управление бэклогом и задачами — это процесс, который при серьёзном отношении к нему может стать одним из лучших способов совместной работы с командами разработчиков.

Несколько простых изменений в обычных списках дел могут поменять подход к тому, как вы обмениваетесь дорожными картами и задачами с разработчиками.

Ключевые моменты в управлении бэклогом:

  1. Устанавливайте приоритеты для тикетов: всегда следите за тем, чтобы приоритеты ваших тикетов и задач соответствовали вашей стратегии: помните, что приоритеты меняются, поэтому в случае таких перемен должен меняться и порядок ваших тикетов.  

  2. Три бэклога: не пытайтесь свалить все мелкие задачи по SEO в бэклог разработчиков — лучше разделите задачи на бэклоги возможностей, продукта и разработчиков, чтобы управлять состоянием задач.

  3. Бэклоги в формате «сейчас — на очереди — в будущем»: в бэклоге продукта используйте не просто одноуровневый список, а список с этими тремя понятными столбцами, указывающий направление работы над продуктом.  

  4. Совместная работа: управление бэклогами — ничто без командной работы, поэтому на постоянной основе взаимодействуйте с разработчиками и другими заинтересованными лицами со стороны компании, которой вы оказываете услуги по SEO.

🧐 Ещё по теме:

Как разработать стратегию продвижения сайта для SEO: инструкция с примерами 

Как составить ТЗ разработчикам на турбо‑ и AMP‑страницы для инфостраниц (блоги, статьи)

9 1
Дмитрий Андрианов Дмитрий Андрианов А есть ссылка на этот шаблон в notion? 
Или может кто ещё поделится шаблонами разными для ведения проектов в notion.
0 18.01.2023 Ответить
Чтобы оставить комментарий, авторизуйтесь

Советуем почитать

Яндекс.Директ vs Google Ads

Яндекс.Директ vs Google Ads

Для начинающих контекстологов, если не уверены, какой рекламный канал использовать первым.
Что умеет сквозная аналитика Яндекса: преимущества и недостатки

Что умеет сквозная аналитика Яндекса: преимущества и недостатки

Разбираемся, как работает инструмент, что в нём хорошего и плохого, а также безопасно ли делиться данными из CRM с Яндекс.Метрикой.
Блог для SEO: подробный гайд по оптимизации

Блог для SEO: подробный гайд по оптимизации

Как продвигать блог компании, чтобы получить трафик и продажи. Покажем быстрый способ собрать семантику для блога для неспециалистов. Посчитаем примерный бюджет (3 варианта).