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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Главное

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

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

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

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

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

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

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

Ещё по теме:

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

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