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