Scrum вне IT: как адаптировать гибкие методологии для маркетинга и продаж

Парадокс, который я вижу в половине компаний, приходящих на аудит бизнес-процессов: пока отдел разработки выпускает фичи раз в две недели, отдел маркетинга согласует одну кампанию три месяца. Дело не в людях и не в бюджетах — IT-команда давно работает по спринтам, а всё остальное предприятие продолжает жить по каскадной модели, где план утверждают на квартал вперёд и меняют его крайне неохотно.

Почему классическое каскадное планирование (Waterfall) убивает скорость в не-IT подразделениях

За 26 лет в бизнесе я видел десятки компаний, где отдел маркетинга работает по модели, от которой IT отказалось ещё в начале двухтысячных. Waterfall — это последовательное планирование: сначала полностью прописывается стратегия на квартал, потом утверждается бюджет, потом создаётся креатив, потом запускается кампания, и только через несколько месяцев команда узнаёт, сработало это или нет. У классического управления проектами есть своя логика — оно хорошо работает там, где условия предсказуемы и требования не меняются: в строительстве, производстве, регулируемых процессах. Но рынок так себя не ведёт. Пока кампания проходит через три уровня согласования, конкурент успевает протестировать пять гипотез и оставить рабочую.

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

Цифры это подтверждают. По данным опроса CMO, который проводили Forbes совместно с CMG Partners, у 93% руководителей маркетинга, перешедших на agile-практики, выросла скорость вывода кампаний на рынок — эту статистику собрало и агентство AgileSherpas в своём обзоре пользы agile-маркетинга. Дело не в том, что гибкие методологии волшебным образом делают работу лучше сами по себе — они просто сокращают время между гипотезой и фактом, а значит, компания тратит меньше денег на кампании, которые всё равно бы не сработали.

Скачай бесплатно PDF-инструкцию

ТОП9 ИНСТРУМЕНТОВ ДЛЯ РОСТА ПРОДАЖ

Скачать

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

Адаптация Scrum: как выглядят Спринт, Бэклог, Дейли и Ретроспектива в отделе продаж или маркетинга

Для тех, кто раньше со Scrum не сталкивался: Scrum — не обязательно только для работы с технологиями и программистами. Это фреймворк поверх agile-подхода, в котором команда работает короткими циклами — спринтами — и после каждого получает не отчёт о процессе, а готовый, проверяемый результат. В IT в команде обычно три роли: владелец продукта решает, что делать в первую очередь, скрам-мастер следит за самим процессом и убирает препятствия, а команда разработчиков делает работу. В маркетинге и продажах эти роли не исчезают — они просто достаются другим людям.

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

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

Спринт для не-IT команды я рекомендую делать короче, чем в разработке, — не две-четыре недели, а одну. Маркетинговая гипотеза устаревает быстрее, чем фича в приложении, и недельный цикл держит команду в тонусе, не давая скатиться обратно в спокойный квартальный ритм.

Дейли — это не статус-отчёт для начальника, а 15-минутная синхронизация внутри команды: что сделано вчера, что в работе сегодня, что мешает двигаться дальше. В отделах продаж такие встречи часто уже существуют под названием «утренняя планёрка», просто без структуры и с уклоном в разбор чужих ошибок — иногда достаточно просто сменить формат, а не вводить что-то новое.

Ретроспектива — самый недооценённый элемент. Раз в спринт команда честно разбирает, что сработало, а что нет, без поиска виноватого. Это работает только там, где людям не страшно признать, что гипотеза провалилась. Об этом хорошо писала исследовательница Гарвардской школы бизнеса Эми Эдмондсон: команды, где принято открыто говорить об ошибках и рисковать без страха наказания, учатся быстрее и реже повторяют одни и те же промахи (исследование психологической безопасности в командах). Без этого условия ретроспектива превращается в формальность или, хуже, в разбор полётов, после которого никто больше не признаётся в провалах честно.

Ещё один момент, который часто упускают: Scrum-команда самоорганизуется — задачи внутри спринта распределяют не сверху, а команда решает сама, кто что берёт. Это не демократия ради демократии: по теории самодетерминации Эдварда Деси и Ричарда Райана, внутренняя мотивация и качество работы выше именно там, где у людей есть автономия в принятии решений, а не жёсткое назначение задач сверху (теория самодетерминации Деси и Райана). Поэтому попытка внедрить Scrum, но продолжать раздавать задачи в приказном порядке, обычно ничего не даёт — вы получаете новые названия для старых совещаний.

Чтобы не собирать шаблоны бэклога, дейли-доски и формы ретроспективы с нуля, я обычно советую не изобретать велосипед: в базе знаний акселератора «К ЦЕЛИ» есть готовые шаблоны спринт-досок и чек-листы ретроспективы, которые я сам использую в трекинге компаний, — быстрее взять и адаптировать под себя, чем тратить первый спринт на оформление таблиц.

Пошаговый алгоритм: как запустить первый пилотный спринт в не-IT команде за 2 недели

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

1. Выберите пилотную команду и одну измеримую цель. Не весь отдел маркетинга сразу, а, например, три-четыре человека, отвечающие за один канал или один сегмент продаж. Цель должна быть измеримой: не «улучшить маркетинг», а «протестировать три гипотезы креатива» или «обработать сорок холодных лидов».
2. Назначьте владельца бэклога и фасилитатора. Владелец решает, что приоритетно, фасилитатор следит за ритмом встреч. На старте это может быть один и тот же человек, но лучше разделить роли — иначе приоритеты и процесс начинают смешиваться.
3. Соберите первый бэклог за один час. Выпишите все задачи и гипотезы, которые команда хотела бы проверить, и отсортируйте по ожидаемой ценности. Не старайтесь сделать список идеальным — он всё равно изменится после первого спринта.
4. Проведите планирование спринта. На встрече в 30-60 минут команда берёт из бэклога столько задач, сколько реально успеет закрыть за неделю, и фиксирует понятный критерий — когда задача считается завершённой.
5. Запустите ежедневные 15-минутные синхронизации. В одно и то же время, без обсуждения решений по существу — если тема требует разбора дольше пяти минут, её выносят в отдельную встречу после дейли.
6. Проведите демонстрацию результатов. В конце недели команда показывает не отчёт о процессе, а то, что реально готово: тестовый креатив, обработанные лиды, черновик воронки — то, на что заинтересованные стороны могут посмотреть и дать обратную связь.
7. Проведите ретроспективу и пересоберите бэклог. 30 минут: что сработало, что нет, что меняем на следующей неделе. Это единственный шаг, который нельзя пропускать даже при нехватке времени, — именно ретро превращает разовый эксперимент в систему.

Если хотите не просто прочитать алгоритм, а внедрить систему под руководством наставника — в акселераторе «К ЦЕЛИ» есть направление обучение бизнесу, где мы разбираем и настраиваем такие процессы на примере конкретной компании, а не абстрактных кейсов.

Чек-лист: 5 признаков того, что ваша команда готова к переходу на гибкие методологии

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

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

Если не набирается хотя бы четыре пункта из пяти — это не значит, что Scrum не подойдёт никогда, но начните с диагностики процессов, а не с внедрения фреймворка.

Частые вопросы о Scrum в не-IT командах

Итог

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

Хотите задать вопрос? Напишите автору:

WhatsApp

Telegram