Очевидно, что для того чтобы приспособиться к цифровому миру, мы должны ускорить темпы работы маркетинга, не так ли? Однако вот в чем вопрос: как мы ускоряемся? Работать вдвое больше, пожалуй, неподходящий вариант. Впрочем, как и стремление приходить в офис раньше, оставаться позже, трудиться в выходные и праздничные дни. Компании уже пробовали такой подход. Метод кнута и пряника обеспечивает лишь короткий всплеск производительности, который рано или поздно угасает. Люди выматываются. А измотанные сотрудники работают некачественно, принимают плохие решения, злятся, а потом стремятся вырваться из замкнутого круга. Словом, это неконструктивный способ ускорения темпов работы.
Нам нужно более надежное решение. Ведь в идеале мы не просто хотим ускорить темп. Наша цель — стимулировать команды трудиться лучше, принимать оптимальные решения. Люди должны чувствовать себя счастливыми на рабочих местах и испытывать неподдельную любовь к компании, в которой работают.
Скажете, что это нереалистичные требования? Вовсе нет!
На мой взгляд, узкое место — не в скорости работы отдельных людей. Даже если все сотрудники компании научатся печатать в два раза быстрее, это не удвоит ее производительность — конечно же, если ваша компания не занимается транскрибацией. Проблемы со скоростью проявляются на более высоком уровне.
В целях ускорения управленческого ритма надо понять, как мы определяем, над чем работает компания, куда она направляет свою энергию. В первую очередь мы хотим быстрее получать обратную связь, так как это позволяет постоянно обновлять планы исходя из полученных данных.
Начнем с рассмотрения традиционного подхода к управлению проектами, известного как водопадная (каскадная) модель. Он использовался для описания разработки программного обеспечения до начала agile-революции. Оказывается, он также характеризует исторически сложившийся подход к планированию маркетинга.
При использовании водопадной модели большой проект делится на отдельные этапы. Если речь идет о разработке ПО, то это обычно: 1) сбор требований; 2) проектирование архитектуры; 3) реализация программного обеспечения; 4) подтверждение соответствия ПО установленным требованиям; 5) внедрение программного обеспечения для активного использования. Водопадом эта модель называется потому, что между этапами нет никакого пересечения. Например, проектирование не начинается до завершения сбора требований, как и программирование до конца проектирования. Работа происходит каскадами, от одного этапа к другому. Ее изображение на схеме напоминает водопад (см. рис. 9.1). Вот так выглядит модель водопада при разработке программного обеспечения, и она очень похожа на подход к управлению маркетингом. В больших компаниях процессы часто тоже поделены на этапы: 1) исследование рынка; 2) разработка креативной концепции; 3) разработка креативных материалов; 4) распространение их в разных медиаканалах; 5) анализ эффективности.
РИС. 9.1. ОБЩАЯ СТРУКТУРА УПРАВЛЕНИЯ В ВОДОПАДНОМ СТИЛЕ
В целом типовой годовой маркетинговый план также основывался на водопадной модели: 1) долгое планирование будущего; 2) разработка материалов для выполнения плана; 3) внедрение результатов работ на рынке; 4) обзор достигнутого в конце года. А затем работа над маркетинговым планом на следующий год.
На первый взгляд, это довольно логично. Разве при создании программного обеспечения вы не хотите знать требования до начала проектирования? А располагать проектом архитектуры до начала кодирования? Вы не можете передать ПО в эксплуатацию до тех пор, пока вся программа не будет закончена, верно? В маркетинге все точно так же. Разве мы не хотим составить план до начала действий? А убедиться, что все сделано идеально, прежде чем распространять результаты работы? Звучит вполне здраво. Поэтому-то водопадная модель и была популярна в управлении бизнесом.
Водопадная модель имеет несколько серьезных недостатков.
Первый: водопад предполагает, что на ранних этапах планирования и проектирования мы уже точно знаем, чего хотим. В результате разработчики ПО быстро попадают в зависимость от недальновидных предположений. Несмотря на то что они подробно расспрашивали клиентов о требованиях, при виде законченного программного продукта заказчики часто меняли мнение: «Ах, вот что получилось? Но я предпочел бы, чтобы все это работало по-другому».
Пребывание в самом низу водопада после долгих месяцев работы, когда приходится карабкаться назад к ранее завершенным этапам, чтобы переделать проект, отнимает много времени и деморализует. Вот почему Agile-манифест ратовал за разработку работающего программного обеспечения вместо подготовки исчерпывающей документации. Чтобы выявить настоящие потребности людей, лучше всего сразу и часто показывать им прототипы. Пусть опробуют их и выскажут свои замечания. В случае провала составление подробнейших спецификаций может привести к драматическим последствиям, но часто эти спецификации — фикция.
При использовании водопадной модели в маркетинге происходит то же самое. При планировании большой кампании, в которой выходу на рынок предшествует огромное количество проектных и производственных работ, делается попытка предугадать, на что откликнется аудитория. Подробно формулируя маркетинговые программы для годового плана, компания пытается предсказать, что окажется наиболее эффективным в течение ближайших двенадцати месяцев. К сожалению, в гадании маркетологи не сильны. Гораздо полезнее увидеть результат проверки концепции и идей, а затем скорректировать их, ориентируясь на отклик пользователей.
Второй недостаток водопадной модели связан с продолжительностью временных интервалов, в которых, как правило, она работает. От начала до завершения проекта нередко проходят месяцы или годы. Большая маркетинговая кампания обычно занимает не менее шести месяцев. Годовой план выполняется в течение двенадцати месяцев. Большие проекты в области информационных технологий, особенно по разработке программ в 1980–1990-е, могли длиться по два-три года. При таком долгосрочном планировании ранние этапы отделены от финальной поставки длительными периодами. За столь долгий срок все может измениться, хотите вы того или нет.
Даже если вы добились потрясающей четкости и включили в план именно то, что хотели, или то, на что гарантированно отреагирует аудитория, вы не можете предсказать, что произойдет завтра. Сменятся конкуренты. Усовершенствуются технологии. Изменятся ожидания клиентов. Расширится рынок. Цифровая динамика вызывает подобные перемены все чаще, и они становятся все грандиознее.
К сожалению, водопадная модель плохо адаптируется к таким изменениям. Мы получаем результат, но он не совпадает с потребностями рынка; возвращаемся на ранние этапы, нередко выбрасывая уже сделанную работу, или отчаянно пытаемся исправить положение в последнюю минуту, прилагая неимоверные усилия. И эти «пожарные» меры почти всегда превращаются в лозунг «просто работать интенсивнее». Вот почему в Agile-манифесте заявляется, что реагировать на изменения важнее, чем следовать первоначальному плану. Водопадная модель была отвергнута, потому что не соответствовала быстроменяющейся реальности цифрового мира. Требовался другой подход.
Гибкая методология Scrum, которую я кратко описал выше, предлагает другой подход. Вместо длительных, четко обозначенных этапов проекта она работает с серией спринтов. Спринт длится сравнительно короткий срок, нередко неделю, но не более месяца. Обычная его продолжительность — две-три недели. Каждый спринт включает в себя фрагмент планирования, короткий отрезок времени, выделенный на разработку работающего продукта (не гигантских размеров), и время на анализ и оценку обратной связи от заинтересованных сторон в компании или на рынке. Затем начинается следующий спринт, уже с учетом опыта и полученной информации.
Большой проект или маркетинговая кампания вряд ли будут завершены в ходе единственного спринта. Напротив, для их выполнения понадобится непрерывная последовательность многих спринтов, в каждом из которых будет идти постепенный прогресс. Преимущество такого подхода заключается в том, что в течение всей работы можно вносить изменения для адаптации к меняющимся требованиям. Продолжительные программы, такие как контент-маркетинг и формирование спроса, могут быть организованы как непрерывный поток спринтов, охватывающий весь период существования программы.
Что происходит за время спринта? Давайте сделаем краткий обзор его процесса, по крайней мере так, как это часто практикуется в маркетинге и показано на рис. 9.2. Формальная scrum-методология в разработке программного обеспечения отличается незначительно. Для нужд маркетинга, как правило, используется упрощенный вариант.
РИС. 9.2. ОБЩАЯ СТРУКТУРА AGILE-СПРИНТА
Спринты — это выполнение пунктов из приоритизированного списка задач. В последующих главах мы подробно опишем, как определить и визуализировать задачи и их выполнение. Пока же рассматривайте задачу как часть работы, которую можно выполнить за один спринт. Поэтому большие задачи разбивают на мелкие.
Крайне важно, чтобы задачи в бэклоге были приоритизированы в том порядке, в каком они должны быть выполнены. В этом случае команда и другие заинтересованные стороны договорятся о том, над чем пойдет работа дальше; гибкой процедуру делает возможность в любое время внести изменения в бэклог. Могут быть добавлены новые задачи, изменены или удалены существующие, их относительная приоритетность также может измениться. В начале нового спринта, перед планированием, бэклог задач должен быть обновлен в соответствии с актуальными приоритетами.
Планирование спринта — это встреча всех членов команды с целью изучения наиболее приоритетных заданий в списке, оценки объема необходимых работ и взятия обязательства выполнить их в этом спринте. Такая встреча длится недолго. Как правило, ее продолжительность строго ограничена фиксированным промежутком времени (не больше двух часов при недельном спринте). На планирование двухнедельного спринта отводится не более четырех часов, трехнедельного — не более шести.
Стоит отметить, что планирование спринта — это процесс выбора, а не навязывания. Команда, которая будет делать работу, решает, какие задачи она сможет выполнить, и выбирает их из бэклога. Менеджер не навязывает их, давая распоряжение: «Вы должны выполнить вот эти одиннадцать задач». Он может контролировать, какие задачи находятся в списке и как расставлены приоритеты, но команда самостоятельно решает, чем будет заниматься в спринте. Для некоторых компаний это серьезное изменение в организации работы. Нередко поначалу такой принцип встречает серьезное сопротивление. Тем не менее этот подход гораздо лучше приспособлен к реалиям цифрового мира.
После планирования спринта начинается его исполнительный этап. Большая часть времени в спринте отводится на выполнение командой выбранных задач. Гибкие методики, такие как Scrum, часто рассматриваются как облегченные способы управления по причине низкого соотношения временных затрат на административные нужды и реальную работу.
В ходе спринта команды ежедневно устраивают 15-минутные совещания, по терминологии называемые ежедневным скрамом. Есть и еще одно название — стендап, потому что, как правило, в течение всей встречи участники стоят, чтобы не затягивать мероприятие дольше 15 минут. Для сведения к минимуму затрат на координацию такие совещания всегда проводятся в одно и то же время в одном и том же месте и начинаются без опозданий.
В ходе ежедневного стендапа каждый член команды отвечает на три вопроса: что я сделал вчера? Что я буду делать сегодня? Какие препятствия могут помешать мне или команде достичь цели спринта? Задача таких встреч — с полной прозрачностью синхронизировать работу членов команды. О потенциальных проблемах, которые могут помешать ходу работ, говорят открыто. Если же не удается сразу найти решение, команда не зацикливается на ситуации, а поручает кому-либо изучить ее позже.
По окончании спринта проводятся два завершающих мероприятия. Первое — это обзор спринта. Команда и все заинтересованные лица собираются, чтобы по пунктам разобрать результат. При разработке ПО обзор, как правило, включает демонстрацию продукта. В маркетинге под этим может подразумеваться демонстрация нового контента, элементов кампании или активностей в социальных сетях, а в отношении уже распространенных цифровых маркетинговых материалов — оценка предварительных данных об их эффективности. Обычно на обзор спринта отводят один-два часа.
У обзора спринта три цели. Во-первых, дать команде возможность получить признание за достигнутый результат. Во-вторых, продемонстрировать сотрудникам компании, чем занят маркетинг, потому что многие из них плохо представляют, что происходит. Обзор спринта можно сделать более открытым, рассылая приглашения широкому кругу участников, даже всему персоналу компании, чтобы способствовать распространению маркетинговых идей и инициатив во всей компании.
Третья цель обзора спринта — самая важная. Это получение отзывов заинтересованных сторон о проделанной работе, обсуждение полученной информации, выявление новых проблем и принятие решения о том, чем заниматься дальше. В ходе обзора в список задач почти всегда добавляются новые либо обновляются старые. Это делается для того, чтобы наращивать обороты и учиться на опыте только что завершившегося спринта. Как мы увидим в следующей главе, этот способ представляет собой мощное средство поощрения итеративного мышления в подходах к маркетингу.
Второе завершающее спринт мероприятие — ретроспектива спринта. В ней участвуют только члены команды, и на нее также отводится один-два часа. Если в обзоре спринта обсуждается, что было сделано, то ретроспектива посвящена тому, как это было сделано.
Команда отвечает на три вопроса: что было хорошо во время этого спринта? Что пошло не так? Что можно улучшить в следующем спринте? Часто принимаются решения об изменениях в процедурах и инструментах, а также во взаимодействии с другими группами. Команда может внести незначительные коррективы — например, перенести ежедневные стендапы на другое время или решить пользоваться другой программой видеоконференций. Но изменения могут быть и более фундаментальными — скажем, изменение хода работы или длительности спринтов с трех до двух недель.
Ретроспективы не должны использоваться для разборов полетов, которые обычно имеют негативный эмоциональный окрас. Наоборот, в них должно быть много положительных моментов, потому что команда может внести итеративные и инкрементные изменения в свою работу, чтобы ее улучшить и повысить эффективность компании.
Одно из ключевых преимуществ ретроспектив состоит в том, что они встраивают механизмы управления, предоставляющие компании возможность постоянно адаптировать процессы и их функционирование, а не только продукт. Проведение ретроспектив нейтрализует аргументы вроде «мы всегда так делали», которые мешают любым переменам.
В самом конце спринта часто устраивают небольшой праздник, например час неформального общения или обед для команды. А потом начинается следующий спринт.