Agile-маркетинг. Хакерские практики для эффективного бизнеса

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

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

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

* * *

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

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

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

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

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

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

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

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

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

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

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

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