A A A

Как работают по Agile команды веб-разработчиков, в сети написано предостаточно. А как насчет отдела PPC в агентстве интернет-рекламы?

Кирилл Винокуров, глава департамента платного трафика агентства интернет-маркетинга Inweb, делится кейсом работы своего отдела по Agile: как пришла идея и чем это обернулось спустя полгода (с конца 2016 года).

Почему в отделе контекстной рекламы?

Настройка рекламной кампании в агентстве интернет-маркетинга (от сбора семантики и заканчивая запуском) обычно занимает от 2 до 4 недель.

Чем лучше этот процесс можно оптимизировать, тем больший выигрыш получает как бизнес, так и агентство, и вот почему:

  • Бизнес может иметь сезонный характер и обращается в агентство, ожидая результат не сегодня — завтра. Агентство ему это предоставить не может, потом сезонность теряется, бизнес не получает продаж и разочаровывается в подрядчике и контекстной рекламе в целом. Подрядчик же в лучшем случае остается ни с чем, а в худшем — теряет репутацию
  • Нетерпеливые владельцы бизнеса могут не дождаться окончания настройки и «отвалиться» в течении месяца.
  • Агентство может позволить себе большее количество клиентов одновременно за счет оптимизированного процесса настройки РК.

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

Почему Agile?

Потому что принципы Agile универсальны. Прочтите, если вы еще не знаете их:

Люди и взаимодействие важнее процессов и инструментов

Работающий продукт важнее исчерпывающей документации

Сотрудничество с заказчиком важнее согласования условий контракта

Готовность к изменениям важнее следования первоначальному плану

 

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

Наивысший приоритет — потребности рекламодателя.

Изменение приоритетов рекламной кампании приветствуется.

Рекламные кампании следует запускать как можно быстрее.

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

Как мы внедряли Agile

Мы разбили процесс перехода на четыре этапа.

Этап I: Визуализация проектов

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

В первоначальном виде карта состояний Agile выглядела приблизительно так:

scx8B67fIc_vFTuHw23bgPA

Карта состояний, базирующаяся на временных этапах

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

sOJx8jp39EFDGaWdzoUi1sw

  • Сформированы задачи. По проекту четко сформулированы задачи для достижения результата.
    Как правило, сюда попадают проекты на этапе настройки рекламной кампании, или проекты, где необходимо обновить рекламные кампании. Задачи из этого квадрата имеют наивысший приоритет.
  • Необходимы доработки. Проекты, в которые нужно внести изменения, но пока не определено, какие.
    Сюда попадают все проекты, в которых клиент или специалист не доволен результатом, однако стандартные решения не работают. Для решения задач в этих проектах подключается PPC-аналитик и/или руководитель РРС-департамента.
  • Заморозка. Периодически возникает ситуация, когда работы по проекту останавливаются из-за внешних причин (не сезон, закончился рекламный бюджет, весь товар распродан).
  • Режим покоя. Тут находятся проекты, для которых достаточно стандартного мониторинга (минус-слова, минус-площадки, мониторинг позиций и расхода бюджета).

Этап II: Поддержка проектов и сотрудников в тонусе

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

Формат следующий: все сотрудники отдела собираются у доски и коротко обсуждают каждый проект из двух верхних квадратов. По каждому проекту обсуждается три вопроса:

  • Что было сделано вчера?
  • Что будет сделано сегодня?
  • Что мешает в исполнении задач?

В среднем такой митинг занимает от 10 до 25 минут. Благодаря регулярным совместным обсуждениям все специалисты делятся наработками по своим проектам, могут почерпнуть наработки и инструменты из других проектов и в случае форс-мажора заменить друг друга.

Этап III: Подсчет загрузки отдела и сотрудников

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

1 специалист * 8 рабочих часов * 5 рабочих дней  = 40 рабочих часов

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

40 рабочих часов == 80 очков.

Также мы учли, что специалист не может работать 100% своего рабочего времени над проектами, поэтому мы используем формулу коррекци через КПД, который изначально равен 0,8 и падает с ростом количества проектов на одного специалиста:

80 * 0,8 = 64 очка

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

Этап IV: Покер планирования при распределении проектов

Покер планирования в Scrum — одна из популярных методик оценки сложности задач и проектов. Идея такова: все специалисты отдела независимо проводят оценку сложности проекта, работая с «картами» возрастающего достоинства: 1 очко, 2 очка, 4 очка и так далее.

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

Для контекстной рекламы номиналы карточек были присвоены следующим задачам:

  • Структура аккаунта — 1 очко
  • Настройка целей — 2 очка
  • Написание объявлений — 4 очка
  • Сбор семантики — 8 очков

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

Что получилось

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

  • Контактное лицо должно быть либо владельцем, либо лицом, принимающим решение. Время на согласование правок в рамках Scrum должно быть минимальным, иначе проект рискует надолго поселиться в квадрате “заморозка”.
  • Готовность к постоянным изменениям — высокая интенсивность изменений в рекламных кампания требует некоторых изменений в процессах клиента. Так, например, для одного эксперимента в AdWords в тематике спортивного питания клиенту пришлось убрать целую категорию товаров  с сайта.
  • Четко должны быть сформированы KPI успешности — все эксперименты должны давать четкое представление, стало лучше или хуже. Иначе можно спуститься к экспериментам ради экспериментов.
  • Отсутствие формальной отчетности. Из-за большого количества изменений формальные отчеты становятся непрактичными и редко дают представление о реальном состоянии дел.
  • Готовность изменить привычный ритм работы специалистов. Одна из главных проблем внедрить в привычный ход вещей специалистов. Scrum не дает расслабиться, каждый специалист каждый момент времени на виду.

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

  • Среднее время ухода проекта «в продакшн» снизилось до недели;
  • Повысилась отзывчивость на изменения потребностей и приоритетов заказчика,
  • Пропала большая часть проволочек и задержек с нашей стороны благодаря ежедневной прямой коммуникации внутри команды;
  • Отсутствует проблема «забытых» проектов;
  • Повысился средний уровень ознакомленности сотрудника с текущими проектами и профессиональный уровень в целом;
  • У сотрудников отдела появилось ощущение прямой причастности к успеху общего дела.

Если вы нашли ошибку, выделите участок текста и нажмите Ctrl + Enter или , чтобы сообщить нам.