Особенно важно иметь это в виду при чтении следующей части книги, где разговор идет о гибкости. Мы будем обсуждать agile- и lean-методики, имеющие формальные определения. Одна из agile-методик, которую мы рассмотрим подробно, называется Scrum и имеет специфический набор рекомендуемых процедур. Некоторые ее преданные поклонники считают, что отклонение от рекомендаций не позволит вам стать гибкими. Кое-кто даже утверждает, что без сертифицированного scrum-мастера (это вполне обычная ситуация) не стоит ждать успеха. При всем уважении к agile-апологетам я с ними не согласен.
На самом деле имеет значение только то, что полезно в вашем случае. Что помогает получить нужный результат? Как команде стать продуктивной? Что помогает использовать цифровую динамику, а не бороться с ней? Отличный способ достижения этих целей — взяв понемногу из разных методологий и парадигм и изменив их согласно своим потребностям, составить уникальный набор методов гибкого управления. Будьте прагматиками, а не догматиками.
Когда вы выходите на необычный курс идей управления, вдохновленных опытом разработки программ, без колебаний берите те, которые подходят вашей компании. Если вам нравится какая-то идея, но она вам не подходит, откажитесь от нее. Может быть, вы воспользуетесь ею позже, когда продвинетесь на своем пути. Или же она вдохновит вас на создание собственных идей.
Имейте в виду две вещи. Во-первых, первая реакция на незнакомые идеи — сопротивление, пусть даже неосознаваемое. Однако ради роста и развития следует умерить влияние «психических антител» и рассмотреть новые подходы. Не спешите объявлять, что «это никогда не будет у нас работать», если вы даже не опробовали подход. Будьте открыты ко всему новому. Во-вторых, простой смены вывески будет недостаточно. Компаниям может показаться заманчивой мысль о перенимании языка этих концепций, но применять их они могут в качестве «облицовки» своих методов работы (вспомним естественную неприязнь человека к изменениям). Правильный путь — адаптировать идеи, чтобы они больше соответствовали условиям вашей компании. При этом стоит подумать над тем, что именно вы собираетесь изменить в методах своей работы. Что конкретно вы планируете делать? Как измените систему мотивации и процесс принятия решений, которые существенно влияют на ваш бизнес? Что будете делать завтра иначе, чем вчера?
Смелый поиск ответов на эти вопросы — суть духа хакерства.
Часть II. Гибкость
Глава 8. Зарождение agile-маркетинга
* * *
Стремление к большей гибкости в маркетинге и бизнесе в целом обусловлено движущими силами цифровой динамики — скоростью и адаптивностью, описанными в главе 3.
Скорость цифровых технологий позволяет нам хотя бы вероятностно действовать гораздо быстрее и реагировать на новые возможности и угрозы, изменение обстоятельств и обратную связь рынка. Адаптивность также дает потенциал относительно легко менять контент и услуги с цифровыми масштабом и точностью — во всяком случае по сравнению с механикой и экономикой традиционного маркетинга.
В слове потенциал в последнем предложении скрыт подвох. Этот потенциал предлагают цифровая среда и цифровые технологии, и в первую очередь программное обеспечение. Однако покупка разнообразных программных продуктов и подключение к интернету не предоставляют преимуществ автоматически. Обычно я объясняю, что ПО автоматизации маркетинга не дает возможности наблюдать, как робот выполняет все маркетинговые мероприятия, после того как вы нажали на кнопку запуска программы. Ведь это просто инструменты. А какую пользу вы из них извлечете, зависит от ваших действий.
Большинство компаний ограничены вовсе не техническими деталями применения этих инструментов. Главная их проблема — скорость и адаптивность более высокого уровня управления. Многие процессы и организационные структуры основаны на принципах работы доцифрового мира. Они пережиток той эпохи, когда скорость и адаптивность характеризовались другим масштабом. Но из-за инерции многие традиционные подходы к управлению меняются медленно.
Впрочем, есть и положительный аспект: перед нами открываются большие возможности. Переосмысление способов, с помощью которых мы управляем маркетингом, чтобы адаптировать его к новой среде, может значительно повлиять на гибкость бизнеса.
Чтобы вы лучше представили себе картину перемен, начнем с краткого обзора того, как возникли гибкие методы управления и как они «мигрировали» в маркетинг. Не удивляйтесь, если вначале вам покажется, что все это не имеет отношения к делу. В следующих главах я подробно объясню, как применить эти идеи в маркетинге.
Исходный Agile-манифест
Прилагательное agile имеет несколько значений. Первое мы находим в Оксфордском словаре английского языка: «способный двигаться быстро и легко»
[18]. Второе там же — «связанный с чем-либо или обозначающий метод управления проектом, используемый специально для разработки программного обеспечения, характеризующийся разделением задач на короткие этапы работы, частым пересмотром и адаптацией планов». Это второе значение мы и рассмотрим во второй части книги, потому что, хотя стремление быть гибким (в общем случае синоним слова шустрый
[19]) и похвально, достижение гибкости требует определенных изменений в способах работы.
Гибкие методы управления впервые были применены в конце XX века в сообществе разработчиков программного обеспечения. Так произошло потому, что эти специалисты первыми столкнулись с проблемами цифровой динамики. Они поняли, что их работа напоминает борьбу с растущими экспоненциально скоростью и масштабом, поскольку, по закону Мура, вычислительные мощности компьютеров удваивались каждые два года. Вследствие широкого признания адаптивности программного обеспечения они столкнулись со сложными требованиями, которые при этом постоянно менялись со скоростью, не свойственной другим наукам.
Гибкая разработка ПО начала набирать обороты в 2001 году, когда группа пионеров Agile подготовила «Манифест гибкой разработки программного обеспечения». Не поддерживая конкретную методологию, единомышленники сформулировали основополагающие принципы и ценности гибкого подхода к разработке ПО. Например, они провозгласили приоритет ценности поставки работающего программного обеспечения вместо подготовки исчерпывающей документации, а также ценности готовности к изменениям вместо следования первоначальному плану и тому подобное. Эти идеи нашли отклик у разработчиков
[20].
