Текст книги "Agile-маркетинг"

Глава 8. Зарождение agile-маркетинга

Стремление к большей гибкости в маркетинге и бизнесе в целом обусловлено движущими силами цифровой динамики – скоростью и адаптивностью, описанными в главе 3.

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

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

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

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

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

Прилагательное agile имеет несколько значений. Первое мы находим в Оксфордском словаре английского языка: «способный двигаться быстро и легко»[18]18
  Oxford English Dictionary, s.v. “Agile.” Проверено 6 августа 2015 года. www.oxforddictionaries.com/us/definition/english/agile.


[Закрыть]. Второе там же – «связанный с чем-либо или обозначающий метод управления проектом, используемый специально для разработки программного обеспечения, характеризующийся разделением задач на короткие этапы работы, частым пересмотром и адаптацией планов». Это второе значение мы и рассмотрим во второй части книги, потому что, хотя стремление быть гибким (в общем случае синоним слова шустрый[19]19
  Автор использует синонимический ряд английского языка, не имеющий прямых эквивалентов в русском языке. Прим. перев.


[Закрыть]) и похвально, достижение гибкости требует определенных изменений в способах работы.

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

Гибкая разработка ПО начала набирать обороты в 2001 году, когда группа пионеров Agile подготовила «Манифест гибкой разработки программного обеспечения». Не поддерживая конкретную методологию, единомышленники сформулировали основополагающие принципы и ценности гибкого подхода к разработке ПО. Например, они провозгласили приоритет ценности поставки работающего программного обеспечения вместо подготовки исчерпывающей документации, а также ценности готовности к изменениям вместо следования первоначальному плану и тому подобное. Эти идеи нашли отклик у разработчиков[20]20
  Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, and James Grenning et al, “Manifesto for Agile Software Development,” February, 2001. www.agilemanifesto.org. [Русский перевод: http://agilemanifesto.org/iso/ru/principles.html].


[Закрыть].

В Agile-манифесте провозглашалось следование нескольким гибким методологиям разработки программного обеспечения, но наибольшую популярность получила Scrum. Название навеяно понятием из игры регби, означающим схватку за мяч, в которую вступает группа игроков.

Scrum придумали Кен Швабер и Джефф Сазерленд[21]21
  Jeff Sutherland, Dilip Patel, Cory Casanave, Glenn Hollowell, and Joaquin Miller, eds., Business Object Design and Implementation: OOPSLA ’95 Workshop Proceedings (New York: Springer, 1997), 118.


[Закрыть] – одни из создателей Agile-манифеста. Термин описывает особый процесс управления проектами (в большей степени по разработке ПО, хотя методология адаптирована и для проектов других типов), во главе угла которого стоят короткие итерационные циклы работы, названные спринтами. В Scrum пропагандируется идея ведения прозрачного бэклога, или журнала приоритизированных задач, которые должны быть выполнены; работа в составе небольших кросс-функциональных команд, которые получили право контролировать планирование и выполнение своей работа для каждого спринта; ежедневные 15-минутные совещания всей команды «на ногах»; особые встречи с целью демонстрации сделанной работы; ретроспективные собрания для обсуждения способов получения результата и изменения процесса в следующем спринте.

Многие из этих идей вышли далеко за пределы формальных методов Scrum. Вероятно, вы уже сталкивались с короткими совещаниями (стендапами), бэклогом задач или ретроспективами. Хотя Scrum предлагает немало преимуществ, многие его принципы и процессы были творчески адаптированы и объединены с другими вариантами гибкого управления. Он основа большинства современных представлений о применении Agile в бизнесе.

Другой гибкий метод управления, оказавший значительное влияние на развитие Agile-методологии, – Kanban. Вдохновившись системой планирования «точно в срок», впервые внедренной Тайити Оно в компании Toyota в 1980-х годах[22]22
  Taiichi Ohno, Toyota Production System: Beyond Large-Scale Production (Cambridge, MA: Productivity Press, 1988). См. Оно Т. Производственная система Тойоты. Уходя от массового производства. М.: Институт комплексных стратегических исследований, 2008.


[Закрыть], Дэвид Андерсон создал версию Kanban для применения в разработке программного обеспечения[23]23
  David J. Anderson, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Upper Saddle River, NJ: Prentice Hall, 2004).


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

Наиболее популярный инструмент Kanban – канбан-доска для визуализации потока работ. Даже если вы не слышали такого названия, то наверняка видели доску, разделенную на колонки, как на рис. 8.1. Простейшая доска имеет три столбца: «Сделать», «В работе», «Готово». Задачи, как правило, написаны на стикерах; в первой колонке они расставлены по приоритетам, во вторую перемещаются, когда кто-нибудь берется за выполнение задачи, а в третью – после завершения. Даже при беглом взгляде на доску понятно, в каком состоянии находится общий процесс работы. Прозрачность очень полезна для команды и других заинтересованных сторон.

РИС. 8.1. ПРИМЕР ПРОСТОЙ КАНБАН-ДОСКИ

Как и в случае Scrum, люди кастомизируют отдельные элементы Kanban, эффективно перестраивая свои управленческие процессы. В самом деле, даже существует гибкая методология под названием Scrumban, разработанная Кори Ладасом. Это своего рода гибрид Scrum и Kanban[24]24
  Corey Ladas, “Scrum-Ban,” Lean Software Engineering. Опубликовано в июле 2008 года на сайте http://leansoftwareengineering.com/ksse/scrum-ban/.


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

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

Идеи Lean широко распространились в бизнес-сообществе в 2011 году, когда Эрик Рис опубликовал бестселлер The Lean Startup[25]25
  Издана на русском языке: Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели М.: Альпина Паблишер, 2018. Прим. ред.


[Закрыть], [26]26
  Eric Ries, The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (New York: Crown Business, 2011). См. Рис Э. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели М.: Альпина Паблишер, 2018.


[Закрыть]. Это подробная методология для предпринимателей из высокотехнологичных отраслей – не только разработчиков программного обеспечения, но и бизнес-команд – по созданию продуктов способами, увеличивающими шансы на успех. Рис выступает за итеративный подход при выводе на рынок новых продуктов, раннее и частое получение обратной связи от клиентов, проведение наглядных экспериментов для подтверждения бизнес-гипотез и быструю адаптацию в соответствии с результатами.

Если вам все это кажется agile-философией (упором на итерационное и адаптивное развитие бизнеса быстрыми циклами), то вы несомненно уже ухватили суть Agile. Однако здесь есть и философия бережливого производства, поскольку крайне расточительно создавать продукты, требующие огромных вложений времени и денег, прежде чем станет ясно, соответствуют ли они потребностям рынка. В прошлом это подтвердили наиболее впечатляющие провалы. Книга «Бизнес с нуля» поможет вам понять, как устранить такие потери по максимуму, отказавшись от объемного производства вещей, ненужных клиентам, за которые они не готовы платить. Это потрясающий пример взаимного дополнения гибкого и бережливого подходов.

Как это случилось со Scrum и Kanban, многие идеи из книги «Бизнес с нуля» вышли за рамки собственно методологии. Это и создание минимально жизнеспособного продукта (minimum viable product, MVP) – простейшее воплощение продуктов, на которых можно проверить основные предположения компании о том, чего хочет рынок. И готовность управленцев перейти к новой стратегии, если оказалось, что гипотезы ошибочны. И охотное использование A/B-тестирования в ходе создания продукта – разработка нескольких версий в целях дальнейшего наблюдения за тем, различается ли их воздействие на целевую аудиторию. И правильные выводы из оценки разных факторов при проверке предположений, заставляющие принимать решения на основе истинных, а не гипотетических данных при определении направления дальнейшей эволюции продукта.

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

По мере того как в 2000-х годах Agile и Lean приобретали популярность среди разработчиков ПО, маркетологи этих компаний тоже стали обращать на них внимание. Усилилось давление на маркетинг цифровой динамики, особенно в высокотехнологичных отраслях, и маркетологи искали более эффективные способы справиться с ним. Поэтому они начали присматриваться к коллегам из отделов разработки и, заметив, что там процветает гибкое управление, подумали: а не попробовать ли нам нечто подобное в своем отделе?

Некоторые маркетологи из сферы высоких технологий приступили к экспериментам с адаптацией методов гибкого управления и обменивались опытом. В 2006 году маркетолог Мэтт Блумберг опубликовал в своем блоге пост об agile-маркетинге. Он одним из первых использовал этот термин[27]27
  Matt Blumberg, “Agile Marketing,” Only Once (blog), запись от 28 февраля 2006 года. См. www.onlyonceblog.com/2006/02/agile_marketing.


[Закрыть]. Среди тех, кто выступил за такой подход, были маркетологи Мишель Аккарди-Петерсен, Дэвид Армано, Джон Касс, Джейсон Коэн, Фрэнк Дейс, Джим Эвел, Яша Кайкас-Вольф, Грег Мейер, Нил Перкин, Мигель Там и Майк Вольпе.

В 2009 году я начал консультировать тех читателей моего блога о маркетинговых технологиях, которые заинтересовались методами гибкого управления, в частности программами оптимизации конверсии сайтов. Незадолго до этого меня поразило то, как быстро компания American Greetings (которая пользовалась маркетинговым ПО, созданным моей компанией) вместо нескольких посадочных страниц в квартал на своем сайте стала запускать несколько сотен, экспериментируя с новыми способами привлечения клиентов. Оказалось, что такая гибкость гораздо эффективнее любой другой практики, особенно в постоянно изменяющейся конкурентной среде цифрового маркетинга.

В следующем году я предложил адаптировать Agile-манифест, написанный в контексте разработки программного обеспечения, к нуждам маркетинга. Мой вариант манифеста представлен на рис. 8.2[28]28
  Scott Brinker, “Ideas for an Agile Marketing Manifesto,” Chief Marketing Technologist Blog. Опубликовано 24 марта 2010 года на сайте http://chiefmartec.com/2010/03/ideas-for-an-agile-marketing-manifesto.


[Закрыть]. Два пункта остались прежними (люди и взаимодействие важнее, чем процессы и инструменты, а реагирование на изменения важнее, чем следование первоначальному плану), остальные же не совсем подходили для маркетинга. И я предположил, что ценности agile-маркетинга могли бы звучать так:

• многочисленные небольшие эксперименты важнее нескольких крупных активностей;

• тестирование и данные важнее мнений и условностей;

• мелкие аудитории пользователей важнее обезличенных массовых рынков;

• вовлеченность и прозрачность важнее официальной риторики.

РИС. 8.2. ЦЕННОСТИ МАНИФЕСТА AGILE-МАРКЕТИНГА

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

Другие маркетологи предложили свои варианты манифеста, многие из них повторяли одни и те же основные темы. В июне 2012 года несколько десятков специалистов собрались в Сан-Франциско, чтобы подготовить черновую версию манифеста agile-маркетинга, сформулированную из этих предложений, а также из идей книги «Бизнес с нуля»[29]29
  Текст манифеста agile-маркетинга доступен на сайте http://agilemarketingmanifesto.org.


[Закрыть].

Так agile-маркетинг получил официальный статус. И с тех пор его идеи продолжали распространяться и развиваться. Те, кто их применял, сочетали различные agile– и lean-методы, импровизировали, создавая собственные подходы, адаптированные к их потребностям. Такое пластичное определение agile-маркетинга гибкое само по себе.

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

Глава 9. От больших водопадов к небольшим спринтам

Очевидно, что для того чтобы приспособиться к цифровому миру, мы должны ускорить темпы работы маркетинга, не так ли? Однако вот в чем вопрос: как мы ускоряемся? Работать вдвое больше, пожалуй, неподходящий вариант. Впрочем, как и стремление приходить в офис раньше, оставаться позже, трудиться в выходные и праздничные дни. Компании уже пробовали такой подход. Метод кнута и пряника обеспечивает лишь короткий всплеск производительности, который рано или поздно угасает. Люди выматываются. А измотанные сотрудники работают некачественно, принимают плохие решения, злятся, а потом стремятся вырваться из замкнутого круга. Словом, это неконструктивный способ ускорения темпов работы.

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

Скажете, что это нереалистичные требования? Вовсе нет!

На мой взгляд, узкое место – не в скорости работы отдельных людей. Даже если все сотрудники компании научатся печатать в два раза быстрее, это не удвоит ее производительность – конечно же, если ваша компания не занимается транскрибацией[30]30
  Транскрибация – перевод текста, записанного на видео или аудио, в письменный формат. Прим. ред.


[Закрыть]. Проблемы со скоростью проявляются на более высоком уровне.

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

Водопадная модель

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

При использовании водопадной модели большой проект делится на отдельные этапы. Если речь идет о разработке ПО, то это обычно: 1) сбор требований; 2) проектирование архитектуры; 3) реализация программного обеспечения; 4) подтверждение соответствия ПО установленным требованиям; 5) внедрение программного обеспечения для активного использования. Водопадом эта модель называется потому, что между этапами нет никакого пересечения. Например, проектирование не начинается до завершения сбора требований, как и программирование до конца проектирования. Работа происходит каскадами, от одного этапа к другому. Ее изображение на схеме напоминает водопад (см. рис. 9.1). Вот так выглядит модель водопада при разработке программного обеспечения, и она очень похожа на подход к управлению маркетингом. В больших компаниях процессы часто тоже поделены на этапы: 1) исследование рынка; 2) разработка креативной концепции; 3) разработка креативных материалов; 4) распространение их в разных медиаканалах; 5) анализ эффективности.

РИС. 9.1. ОБЩАЯ СТРУКТУРА УПРАВЛЕНИЯ В ВОДОПАДНОМ СТИЛЕ

В целом типовой годовой маркетинговый план также основывался на водопадной модели: 1) долгое планирование будущего; 2) разработка материалов для выполнения плана; 3) внедрение результатов работ на рынке; 4) обзор достигнутого в конце года. А затем работа над маркетинговым планом на следующий год.

На первый взгляд, это довольно логично. Разве при создании программного обеспечения вы не хотите знать требования до начала проектирования? А располагать проектом архитектуры до начала кодирования? Вы не можете передать ПО в эксплуатацию до тех пор, пока вся программа не будет закончена, верно? В маркетинге все точно так же. Разве мы не хотим составить план до начала действий? А убедиться, что все сделано идеально, прежде чем распространять результаты работы? Звучит вполне здраво. Поэтому-то водопадная модель и была популярна в управлении бизнесом.

Опасности водопадов

Водопадная модель имеет несколько серьезных недостатков.

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

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

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

Второй недостаток водопадной модели связан с продолжительностью временных интервалов, в которых, как правило, она работает. От начала до завершения проекта нередко проходят месяцы или годы. Большая маркетинговая кампания обычно занимает не менее шести месяцев. Годовой план выполняется в течение двенадцати месяцев. Большие проекты в области информационных технологий, особенно по разработке программ в 1980–1990-е, могли длиться по два-три года. При таком долгосрочном планировании ранние этапы отделены от финальной поставки длительными периодами. За столь долгий срок все может измениться, хотите вы того или нет.

Даже если вы добились потрясающей четкости и включили в план именно то, что хотели, или то, на что гарантированно отреагирует аудитория, вы не можете предсказать, что произойдет завтра. Сменятся конкуренты. Усовершенствуются технологии. Изменятся ожидания клиентов. Расширится рынок. Цифровая динамика вызывает подобные перемены все чаще, и они становятся все грандиознее.

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