Можно ли выиграть от использования Agile в SEO?

Осенью 2016 года Сбербанк сообщил о запуске масштабной программы Sbergile (Sberbank + Agile), которая основана на методологии Agile software development («Гибкая методология разработки»). Герман Греф рассказал, как это выглядит на практике, поскольку событие позиционируется как самое значимое в истории компании. Подразделение ИБ (информационной безопасности) банка начало работать по новому алгоритму с целью оптимизировать управленческие процессы в условиях постоянно меняющейся бизнес-среды.

На манифесте Agile основано много методик — Scrum, XP, FDD, — которые используются ИТ-компаниями, Google, Amazon, Bank of America, HSBC и другими лидерами мировой экономики.

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

Почему Agile?

SEO-проекты даже в своем классическом представлении уже пересекаются с подходом Agile:

• Процесс разделен на периоды длиной в месяц (30 дней).
• Заказчик определяет только цель, нет четких задач, ТЗ.
• Работа в условии множества переменных. Требования постоянно обновляются.

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

Адаптация Agile-манифеста для SEO

Основополагающие принципы «гибкой» разработки ПО были приняты еще в 2000-х, но с тех пор все чаще используются и в других сферах. Мы сформулировали свой «SEO-манифест» на их основе, который планируем внедрить в работу в ближайшем будущем.

• Наивысшим приоритетом является удовлетворение потребностей заказчика — то есть регулярное и раннее внедрение SEO-рекомендаций на сайте, что позволяет достичь высоких позиций в поисковиках и привлечь органический трафик.
• Внедрение SEO-рекомендаций и контента следует проводить частыми и регулярными итерациями, постоянно замеряя результаты в поисковых системах.
• Изменение первоначального ТЗ приветствуется даже на поздних стадиях продвижения.
• SEO-изменения на сайте и видимость ресурса в ТОП-10 по расширенному списку ключевых запросов — основной показатель прогресса в проекте.
• Постоянное внимание к техническому состоянию сайта и SEO-релевантности повышает гибкость проекта.
• На протяжении всего проекта оптимизаторы и представители бизнеса ежедневно работают вместе.
• Личное общение является наиболее эффективным способом обмена информацией как с командой проекта на стороне SEO-подрядчика, так и между ее участниками.
• Над проектом должны работать мотивированные специалисты. Для этого нужно создать условия и обеспечить поддержку.
• Стремление к минимизации лишней работы.
• Самоорганизующаяся SEO-команда.

Итак, продвижение ведется циклами по 1 месяцу, в конце каждой итерации заказчик должен получить ценный для него результат — полезные изменения на сайте, в позициях или трафике. Вся SEO-команда взаимодействует с заказчиком в ходе проекта, любые обоснованные изменения приветствуются и принимаются оперативно.

Команда проекта

В Scrum как одной из методик Agile используется три роли:

• Product Owner (Владелец продукта).
• Scrum Master (Скрам-мастер).
• Team (Команда).

В SEO-проектах в роли Product Owner и Scrum Master может выступать Менеджер проекта. Но по Scrum у этих ролей конфликт интересов: для Владельца продукта важно добиваться максимально эффективных результатов, для Скрам-мастера — выполнять запланированные задачи в срок и не допускать изменений в ход спринта.

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

• Стратегический менеджер (Product Owner), призванный формировать требования, расставлять приоритеты, а также корректировать их с учетом реалий (об этом — чуть ниже).
• Менеджер проекта (Scrum Master) в его традиционном понимании, который отвечает за взаимодействие команды, постановку задач, ход их выполнения и сдачу-приемку работ.

Команда проекта в SEO выглядит так:

• Оптимизатор проекта.
• Программист.
• Веб-мастер.
• Копирайтеры.
• Менеджер проекта со стороны клиента.
• Разработчики со стороны клиента.

Дополнительно к работе могут подключаться:

• Юзабилист.
• Аналитик.
• PR-отдел клиента.
• Маркетологи клиента.
• Продуктологи клиента.
• Другие отделы, участвующие в согласовании документов и материалов.

Разрозненность команды обусловлена особенностями работ в SEO. Очевидно, что этот коллектив не подчиняется напрямую ни Скрам-мастеру, ни Владельцу продукта. Самый удачный вариант, на наш взгляд, — договориться с клиентом о выделении временного ресурса под SEO-проект с его стороны. Но и в отсутствие этой возможности процесс можно выстроить достаточно эффективно.

Старт проекта — Product Backlog

Описание Scrum-процесса.

В составлении Backlog’а есть несколько особенностей.

Требования от заказчика поступают в очень общем виде. Например: «увеличение видимости в ТОП-10» или «Рост трафика». Для Product Backlog — списка входящих требований для реализации командой — такого уровня детализации недостаточно, требуются более «смартированные» задачи. Поэтому к формированию списка подключается Оптимизатор проекта. Он решает, какие рекомендации необходимо внедрить на сайт, чтобы добиться ожидаемых заказчиком результатов. Оптимизатор также определяет вес каждого требования, его влияние на конечный итог.

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

Sprint Planning Meeting

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

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

Особенности для SEO:

• Очень мало шансов, что на SEO-проект выделят исполнителей на полный рабочий день. Поэтому определение объема задач можно оставлять за исполнителями, с учетом их загрузки. Как правило, Стратегический менеджер старается выторговать у клиента максимальный ресурс.
• Учитывая все те же разрозненность и «разношерстность» команды, спринт делается на 1 месяц. Такая продолжительность уже привычна для клиентов в SEO.

Sprint Backlog

Составим пример спринта, описанного выше.

В первый месяц он будет достаточно простым и типичным для разных проектов:

• Проведение поискового и технического аудита сайта.
• Формирования семантического ядра (если семантика не была сформирована на старте).
• Распределение ключевых запросов, определение посадочных страниц.
• Согласование распределения запросов с заказчиком.

Спринт получился простым. В зависимости от масштабов проекта он может быть короче 30-ти дней.

Теперь составим спринт на второй месяц:

• Исправление некорректных ссылок
• Удаление дубликатов страниц.
• Обновление sitemap.xml.
• 5-10 других технических рекомендаций.
• Внедрение оптимизированных тегов (H1, Title).
• Копирайт для 20 посадочных страниц.

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

В ходе проекта важно сохранить цель спринта. Нельзя допускать изменений в списке задач в Sprint Backlog. И здесь мы сталкиваемся с еще одной особенностью SEO-проекта:

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

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

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

• Для решения требуется больше ресурсов/времени. Тогда определяется вес соответствующего требования и его порядок в Product Backlog; возможно, рациональнее в следующий спринт взять другую задачу, а эту отложить на 1 или больше спринтов.
• Решение возможно, но предварительно требуется решить другую задачу. В этом случае аналогично корректируется вес требования и его порядок в списке требований.
• Решение невозможно в связи с ограничениями платформы или бизнеса. Для таких задач должны разрабатываться альтернативные решения. Если и они не подходят, необходимо проанализировать, как отсутствие этих задач скажется на целях проекта, и в случае необходимости пересмотреть стратегию.

Weekly meeting

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

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

Статус задач фиксируется на Kanban доске.

Упрощенный пример Kanban доски с использованием сервиса Trello.com. Используется 4 основных списка: Список задач спринта, Задачи в работе, Задачи в проверке и Выполненные.

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

Sprint Review

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

К моменту обзора спринта Менеджер проекта готовит отчет по проекту. Вся команда может оценить результаты своих стараний или (в случае их отсутствия) запланировать дополнительные задачи.

Sprint Goal

Не обойдем стороной и такой артефакт Scrum, как Sprint Goal (Цель спринта). Цель спринта должна описывать, ради чего выполняется отдельно взятый спринт, какой конечный результат получит заказчик.

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

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

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

• Исключить основные ошибки индексации.
• Расширить структуру каталога.
• Определить новые возможности роста (провести Анализ конкурентов).

Кто выигрывает в результате?

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

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