Впровадження Agile в відділі платного трафіку – досвід агентства Inweb

Як працюють по Agile команди веб-розробників, в мережі написано задосить. А як щодо відділу PPC в агентстві інтернет-реклами?

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

Чому у відділі контекстної реклами?

Налаштування рекламної кампанії в агентстві інтернет-маркетингу (від збору семантики та закінчуючи запуском) зазвичай займає від 2 до 4 тижнів.

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

• Бізнес може мати сезонний характер і звертатися в агентство, чекаючи результат не сьогодні – завтра. Агентство йому це надати не може, потім сезонність втрачається, бізнес не отримує продажів і розчаровується у підряднику і контекстній рекламі в цілому. Підрядник же в кращому випадку залишається ні з чим, а в гіршому – втрачає репутацію.
• Нетерплячі власники бізнесу можуть не дочекатися закінчення налаштування і “відвалитися” протягом місяця.
• Агентство може дозволити собі більшу кількість клієнтів одночасно коштом оптимізованого процесу настройки РК.

Ми часто стикалися з подібними ситуаціями, і не могли дозволити собі витрачати час неефективно. Але і від зниження якості налаштування відмовлятися не збиралися. Це і стало головним поштовхом до того, щоб почати перехід на Agile.

Чому Agile?

Тому що принципи Agile універсальні. Прочитайте, якщо ви ще не знаєте їх:

Люди і взаємодія важливіше процесів та інструментів

Продукт який працює важливіший за вичерпну документацію

Співпраця з замовником важливіша за узгодження умов контракту

Готовність до змін важливіша проходження попереднім планом

В реаліях роботи з контекстною рекламою ці чотири стовпи виглядають так:

Найвищий пріоритет – потреби рекламодавця.

Зміна пріоритетів рекламної кампанії вітається.

Рекламні кампанії слід запускати якомога швидше.

Регулярна комунікація команди – найбільш практичний спосіб обміну інформацією.

Як ми впроваджували Agile

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

Етап I: Візуалізація проєктів

Насамперед зібрали інформацію по всіх активних проєктах відділу і перенесли їх на карту станів – особливим чином розподілений простір, розбитий на категорії. Категорії повинно підібрати так, щоб окинувши оком дошку, можна було одразу оцінити стан завантаженості відділу.

У первісному вигляді карта станів Agile виглядала приблизно так:

Карта станів, що базується на тимчасових етапах

Таку структуру відкинули за непрактичністю одразу ж. Пов’язано це було з проєктами “довгожителями”, особливо – інтернет-магазинами. Наприклад, один з великих онлайн-магазинів одягу, з яким ми працювали, очікував від нас поновлення рекламних кампаній по товарах з нових колекцій. Вибрати відповідну категорію для такого завдання, а також ще для безлічі бізнес-процесів інших клієнтів, було неможливо. Тому з часом табличка змінилася, і стала виглядати таким чином:

• Сформовано завдання. За проєктом чітко сформульовані завдання для досягнення результату.
  Як правило, сюди потрапляють проєкти на етапі налаштування рекламної кампанії, або проєкти, де необхідно оновити рекламні кампанії. Завдання з цього квадрату мають найвищий пріоритет.
• Необхідні доопрацювання. Проєкти, в які потрібно внести зміни, але поки не визначено, які.
  Сюди потрапляють всі проєкти, в яких клієнт або фахівець не задоволений результатом, однак стандартні рішення не працюють. Для вирішення завдань в цих проєктах підключається 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 не дає розслабитися, кожен фахівець кожен момент часу в тонусі.

Дотримуючись цих умов, наш відділ підвищив межі здійсненного під час постановки завдань. Підвищилися як технічні, так і нетехнічні метрики ефективності:

• Середній час догляду проєкту “в продакшн” знизилося до тижня;
• Підвищилася чуйність на зміни потреб і пріоритетів замовника;
• Пропала велика частина зволікань і затримок з нашого боку завдяки щоденній прямій комунікації всередині команди;
• Відсутня проблема “забутих” проєктів;
• Підвищився середній рівень обізнаності співробітника з поточними проєктами та професійний рівень в цілому;
• У співробітників відділу з’явилося відчуття прямої причетності до успіху спільної справи.