8 гибких процессных стратегий для бережливых маркетинговых команд

Мы увлеченные технофилы, работаем удаленно и создаем собственные приложения (включая Turbine, приложение для управления персоналом и Fizz+Ginger, техническое SEO-приложение для пользователей HubSpot). Мы работаем в технологических компаниях, включая Microsoft, Symantec, LinkedIn и HP, и у нас есть опыт разработки программного обеспечения (наш генеральный директор десять лет руководил компанией, занимающейся компьютерными играми).

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

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

Первоначально этот контент был доступен как часть нашей электронной книги «Экономически эффективный маркетинг для амбициозных B2B-компаний» (начиная со стр. 21). Таким образом, у вас есть возможность загрузить исходный материал в формате PDF, если вы заполните эту форму:

1. Коллегиальное редактирование

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

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

2. Тестовый маркетинг

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

В маркетинге, особенно в онлайн-маркетинге, практически все можно (и должно) тестировать. Получает ли эта страница больше конверсий, чем та? Этот CTA лучше? И так далее. Это дает нам четкое представление о том, что лучше всего подходит для максимизации рентабельности инвестиций.

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

3. Никаких скручиваний, никакого выгорания

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

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

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

4. Пользовательские истории, а не спецификации

Гибкая разработка не имеет отношения к формальным методам, подробным спецификациям или любым другим способам, которыми менеджеры проектов пытаются оградить себя от капризов клиентов. (Дополнительную информацию см. в Маркетинговом словаре дьявола.)

Вместо этого он просит клиента и разработчика сотрудничать в описании желаемого результата. Формат простой, короткие пользовательские истории, например: «пользователи могут создать новую учетную запись» или «Как X, я хочу Y из-за выгоды Z». Чем конкретнее будут эти истории, тем лучше. Маркетологи могут использовать аналогичный подход, указывая результаты, такие как стиль или тема статьи, а не входные данные, такие как количество часов, которое потребуется для ее написания. (Это то, чем мы занимаемся. Здесь, в Articulate, нет табелей учета рабочего времени!) Сотрудничество с нашими клиентами — это то, что мы действительно ценим — оно приводит к более качественному и ценному результату.

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

5. Оценивайте сложность, а не продолжительность

Вы, вероятно, используете Jira или ClickUp или что-то еще для управления проектами. Эти инструменты управления проектами избегают обычной методологии водопада и расписаний. Вместо того, чтобы просить разработчиков указать, сколько времени займет «история», гибкие инструменты управления проектами спрашивают, насколько она сложна и насколько важна по сравнению с другими задачами.

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

6. Встречи «стоя»

Вместо бесконечных статусных совещаний и телеконференций agile-разработчики устраивают «стоячие» собрания в начале недели (или дня) для обмена информацией. Мы делаем то же самое (фактически работаем удаленно). И, как следует из названия, если люди встают, они, как правило, не так много говорят!

7. Ожидайте перемен, не боритесь с ними

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

Гибкая разработка поощряет участие клиентов и предполагает, что проект будет меняться со временем. Разбивая его на короткие спринты (см. следующий пункт) и небольшие четко определенные пули, agile-проект становится более гибким.

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

8. Спринты, а не марафоны

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

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

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

Так что, маркетинговые команды, не унывайте. Вам не нужно быть инженером-программистом или мастером йоги, чтобы быть гибким.