Как команде работать по Agile

Как команде работать по Agile

Представим, что разработчику, дизайнеру или маркетологу нужно создать решение, у которого нет аналогов на рынке. Понять, каким должен быть конечный продукт, и составить четкий план разработки не получится — никто не знает, как он должен выглядеть, можно только строить и проверять гипотезы. Для разработки такого продукта нужен другой подход — двигаться небольшими шагами и тестировать промежуточные результаты на заказчике или пользователях.
Автор
Антон Бевзюк,
head of engineering Mindbox
Методология, которая использует силу маленьких шагов, чтобы снизить риски, называется Agile. Head of engineering Mindbox Антон Бевзюк рассказал, где ее используют, как работает agile-команда, и что учесть перед тем, как использовать методологию.

Что такое Agile и чем он отличается от традиционных подходов к управлению проектами

Традиционный способ управления проектами, который называют Waterfall, используют, если на старте понятно, как будет выглядеть результат. Например, к сайту нужно подключить платежную систему, чтобы покупатель мог оплачивать заказы картой. Команда изучает документацию к платежной системе, оценивает, сколько времени займет проект, готовит план работ, согласовывает с заказчиком бюджет и сроки, фиксирует договоренности в контракте. Если задачи по контракту выполнили в срок и не вышли за рамки бюджета, проект считается успешным.
Картинка
Проект делится на этапы: сбор требований, анализ, дизайн решения, разработка, тестирование, внедрение и сопровождение. Следующий этап начинается после того, как завершен предыдущий. Схема проекта напоминает водопад — отсюда и название подхода к управлению — Waterfall
Представим, что команде нужно создать сервис для автовладельцев, который поможет им вовремя обслуживать машину. Цель проекта, аудитория продукта и то, какие потребности он закроет, понятны. Но как он должен работать и какие функции в него добавить, команда может только предполагать. И нет гарантий, что эти предположения верные. В таких условиях использовать waterfall-подход невыгодно. Если спланировать и выполнить проект, опираясь на гипотезы, есть риск разработать функции, которые не нужны клиенту или пользователям. Чтобы переделать продукт, придется начинать проект заново и тратить дополнительный бюджет.
В условиях неопределенности выгоднее использовать гибкую методологию — Agile. Подход напоминает метод научного поиска: команда постоянно генерирует гипотезы, тестирует их с минимальными затратами и корректирует план, если гипотезы не подтвердились.
В Agile продукт разрабатывают короткими итерациями, обычно длиной одну-две недели. В начале итерации команда планирует, что будет разрабатывать, в конце — собирает обратную связь от клиента и пользователей, анализирует результаты работы и на основе этих выводов решает, как дальше развивать продукт.
Схема проекта по Agile: команда работает короткими итерациями — спринтами
Например, в продукт для автомобилистов решили добавить чат-бот, который будет отвечать на вопросы о документах и сроках замены деталей и давать рекомендации по диагностике. Вместо того чтобы разрабатывать полноценную функцию, команда решила провести опрос среди пользователей и выяснить, насколько бот поможет решить проблему клиента. Оказалось, что пользователи доверяют рекомендациям бота о сроках замены деталей и расходников, но результаты диагностики предпочитают обсуждать с экспертом сервисного центра. В итоге решили разработать версию бота с чат-центром: часть функций автоматизировать и добавить возможность переключиться на диалог с экспертом, если у пользователя вопрос по диагностике.

Где применяют Agile и почему он подходит маркетологам

Сначала Agile применяли только в разработке ПО, но за последние 20 лет он де-факто стал стандартом для разных отраслей. Гибкие подходы успешно используют в финансах, маркетинге, промышленности, дизайне и даже строительстве. Agile подходит и для коммерческих стартапов, и для крупных компаний в госсекторе.
Какие задачи в разных сферах решают с помощью Agile:
Быстро выводить на рынок востребованные решения. В нефтехимической компании СИБУР не следуют планам на десятилетия вперед — считают это ненадежным. Даже за пять лет рынок может кардинально измениться, а планы — устареть. Вместо долгосрочной стратегии у компании краткосрочные бизнес-планы, которые адаптируют под новые задачи. Идеи новых проектов сразу проверяют на жизнеспособность в три этапа:
  1. Оценка. Сравнивают с аналогами, считают бюджет, проверяют, целесообразен ли проект сейчас. Если идея экономически оправдана, выделяют деньги на ранее проектирование, чтобы точнее оценить затраты.
  2. Раннее проектирование. Создают чертежи, рассчитывают расходы и определяют, насколько реально воплотить идею в жизнь. Это помогает избежать лишних расходов на этапе полноценного запуска.
  3. Реализация. Если есть финансы, запускают проект.
По такому циклу запустили крупнейший проект «Сибура» — «ЗапСибНефтехим» с бюджетом около 9 млрд долларов.
Вместо иерархии с жесткими уровнями управления в компании действует совет руководителей. Это команда из лидеров разных направлений, которые напрямую влияют на проект. Совместное обсуждение позволяет быстро принимать решения, отбрасывать неподходящие идеи и двигаться вперед без лишней бюрократии.
Сэкономить ресурсы на коммуникации. Строительная компания «Самолет» перешла на Agile из-за роста команды: отдел архитектуры и дизайна увеличился с 20 до 150 человек. До этого каждый сотрудник вел задачи в удобной для него системе. В большой команде стало сложно отслеживать прогресс по задачам и находить причины проблем. Внедрили таск-трекер с доской задач, где каждый видит статус и дедлайн. Это позволило сократить количество встреч, переписок и упростить контроль: команда понимает, что происходит, а руководство видит общую картину.
Создание маркетинговой стратегии. Компания запускает новый продукт на рынке умных устройств для дома. Рынок растет и меняется очень быстро — появляются новые тренды, конкуренты и технологии. Задача — создать маркетинговую стратегию для продвижения нового продукта. На старте проекта непонятно, какие каналы и методы будут эффективными: сработает ли таргетированная реклама в соцсетях и у блогеров, нужно ли подключать офлайн-мероприятия. Вместо того чтобы разрабатывать подробный маркетинговый план на год, создают план на два-три месяца и тестируют кампании на небольшой аудитории. Если реклама на одной платформе не продает, а другая, наоборот, приносит результат, стратегию корректируют и перераспределяют ресурсы на более успешные направления или подключают новые. Такой подход поможет получить максимальную отдачу от маркетингового бюджета.

Пример итеративной работы в маркетинговом проекте

Разберем, как принципы Agile использовал один из клиентов Mindbox — магазин техники Quke. Большую часть выручки ему приносили продажи смартфонов через прайс-агрегаторы. После ухода агрегаторов с рынка в 2022 году компания стала продавать на маркетплейсах, но это было менее выгодно из-за комиссии. Реклама тоже обходилась дорого. Поэтому решили работать с собственной клиентской базой, чтобы сохранить маржинальность маркетинга.
Двигались итерациями, тестируя разные гипотезы:
  1. Провели исследования, чтобы понять, стоит ли вкладываться в CRM-маркетинг. На старте сложно было предсказать окупаемость CRM-маркетинга — клиенты обновляют смартфоны редко, примерно раз в три года. Изучили поведение клиентов в пунктах выдачи заказов и выяснили, что многие покупают не только для себя, но и в подарок родственникам и коллегам. Это подтвердило потенциал работы с базой.
  2. Подключили сервисы для CRM-маркетинга. Компания разработала собственные сервисы для массовых и транзакционных рассылок, а для автоматических подключила готовое решение. Подход не сработал: сегментация базы и подготовка рассылок отнимала много времени и ресурсов — каждый раз нужна была помощь ИТ-отдела. Решили объединить массовые и триггерные рассылки в одной системе, чтобы ускорить их подготовку.
  3. Внедрили первую платформу. Через два месяца использования новой платформы стало ясно, что она не решает проблему. Массовые рассылки нужно готовить быстро, чтобы успевать за инфоповодами, а их верстали по два-три дня. Кроме того у платформы была невыгодная тарификация у платформы была невыгодная — нужно было оплачивать каждое письмо, а не подписку на период. Поэтому решили найти более гибкий инструмент, в котором маркетологи смогут готовить рассылки самостоятельно.
  4. Выбрали и интегрировали новую платформу. После анализа рынка и опыта работы с предыдущими инструментами команда составила список критериев и по ним выбрала Mindbox. Интерфейс платформы позволяет готовить рассылки быстро и без помощи разработки, смотреть аналитику по всем кампаниям или отдельным письмам. Отправка писем не тарифицируется — клиент оплачивает только подписку. Если нужна помощь, поддержка ответит в течение нескольких часов. Интеграция заняла 1,5 месяца. Mindbox помог не только сэкономить ресурсы, но и в два раза увеличить долю выручки от email-канала.
В условиях неопределенности невозможно сразу предсказать, какой инструмент идеально подойдет для CRM-маркетинга. Итеративный подход по Agile помог Quke недорого протестировать гипотезы и собрать данные об ограничениях разных решений, которые на старте были неочевидны. На первом этапе, исследуя поведение клиентов, изучили, окупится ли CRM. В следующих итерациях тестировали готовые решения, но они оказались неэффективными из-за медленной подготовки рассылок и высокой тарификации. Постепенный анализ слабых мест позволил уточнить требования к платформе и выбрать оптимальный набор модулей Mindbox, который решает задачу бизнеса.
Пошаговое тестирование, ошибки и изменения в подходе помогли снизить риск внедрить неподходящую платформу

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

Agile-манифест — это набор из четырех ценностей и 12 принципов. Их придумали для разработки программных продуктов, но они могут применяться и в маркетинге. Мы адаптировали agile-манифест для CRM-маркетологов. Формулировки ценностей оставили без изменений, но пояснили, как их применяют в маркетинге:
  1. Люди и взаимодействие важнее процессов и инструментов. Например, вместо того, чтобы просить клиента заполнить бриф, команда проводит интервью. Так получается собрать больше информации и сэкономить время на переписке.
  2. Работающий продукт важнее подробной документации. Это значит, что документация нужна, но важнее сначала доработать что-то в продукте или проекте, чем описать эти доработки. Например, нужно доработать CDP-платформу — изменить формат отчетов по кампаниям. Менеджер добавляет в документацию только ключевые требования к доработке и передает требования разработчикам. Они создают базовую версию новой функции, передают на тестирование, получают обратную связь и сразу вносят корректировки. Когда разработку закончат, менеджер может дополнить документацию.
  3. Сотрудничество с клиентом важнее согласования условий контракта. Часто идеи доработок возникают уже после того, как проект стартовал. Чтобы брать в работу новые задачи, но не конфликтовать с условиями контракта, команда может работать по time and material (почасовая оплата или за итерацию) или зафиксировать стоимость и сроки, а план работ оставить гибким.
  4. Готовность к изменениям важнее следования первоначальному плану. Например, компания запустила цепочку для стимуляции повторной покупки: отправляла пуши и письма с акциями на товары. В пушах учитывали историю покупок и поисковые запросы, а в письмах присылали просто товары с самыми большими скидками. Аналитика показала, что покупатели лучше реагируют на персонализированные офферы, а из писем в магазин переходят редко. Решили отказаться от старой логики рассылки — добавили в письма динамический блок, который предлагал товары с учетом поведения пользователей.
Разберем, что означают agile-принципы в переводе на маркетинговый.
Адаптированный для маркетинга принцип
Пример
Приоритет — удовлетворение потребностей аудитории через регулярное и раннее создание полезного для нее оффера.
CRM-маркетолог анализирует данные о покупках и поведении клиентов. Например, видит, что они обычно обновляют смартфоны каждые 2 года, а чехлы к ним — каждые 6-7 месяцев. Опираясь на эти данные, клиенту отправляют предложение со скидкой или бонусом на предзаказ новой модели. В итоге клиент получает ценное предложение до того, как начнет искать товары у конкурентов.
Готовность к изменениям даже на поздних этапах кампаний повышает их эффективность.
В туристической компании YouTravel заметили, что клиенты из одной страны давали высокий средний чек. Казалось, что стоит усилить рекламу в этом регионе. Но интервью с аудиторией показало, что такие заказы — редкость. Чаще всего туры покупали из-за границы дети для своих родителей. В регионе же пользовались услугами знакомых агентов, а не онлайн-сервисами. Охват аудитории оказался намного меньше, чем ожидалось, и от гипотезы отказались, чтобы не тратить бюджет на неэффективную рекламу.
На протяжении всего проекта или кампании подрядчики и бизнес работают вместе.
В проекте по интеграции Mindbox клиент и менеджер платформы работают как одна команда. Менеджер изучает особенности бизнеса заказчика, прописывает архитектуру проекта и составляет документацию для разработчиков, обучает заказчика настраивать Mindbox. Если у компании нет в штате CRM-маркетолога, менеджер на время берет на себя часть операционных задач.
Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, нужно создать для этого условия и довериться команде.
В команде Mindbox ждут опытных специалистов, тех, кто хочет расти и готов отвечать за результат своей работы. В обмен компания предлагает зарплату выше, чем на остальном рынке, компенсации, возможность удаленной работы и проекты без микроменеджмента. Результат такого подхода — рост компании на 40% последние шесть лет.
Личное общение — лучший способ обменяться информацией и обсудить спорные моменты.
В «РБК Pro» ведут таблицу с задачами по доработке и каждые две недели созваниваются с менеджером Mindbox, чтобы обсудить их статус. Так получается быстрее разобраться, где сложности, а информация не теряется в переписках.
Реальное изменение поведения пользователя — основной показатель прогресса.
Компания внедрила триггерные рассылки с рекомендациями на основе покупок клиентов. Вначале отправляли письма сразу после покупки, но конверсии были низкими — пользователи не проявляли интереса. После анализа поведения выяснилось, что похожие товары чаще покупают через несколько месяцев. Рассылку адаптировали под поведение покупателей, и она стала приносить больше конверсий.
Клиент, маркетологи и разработчики продукта работают в темпе, который можно поддерживать без выгорания.
Проекты Mindbox устроены так, что большую часть задач обсуждают в рабочее время. Исключение — форс-мажоры, которые могут повлиять на бизнес. Например, нужно исправить настройки в механике накануне распродажи.
Постоянное внимание к качеству, выбору лучших инструментов и подходов увеличивает гибкость проекта.
Технические сбои в сценариях снижали конверсию автоматических рассылок «Нетологии». У Mindbox была страница для отслеживания проблем в рассылках, но клиенту было неудобно ей пользоваться. Mindbox переработал страницу с ошибками вместе с «Нетологией» — уточнили требования к странице с отчетом, а затем предложили протестировать новый интерфейс. С новым отчетом об ошибках дорабатывать сценарии проще, и конверсия страдает меньше.
Простота, или искусство минимизации лишней работы, нужна, чтобы тратить дополнительные ресурсы, когда это действительно нужно.
Маркетолог тестирует гипотезу для повышения продаж через email-рассылку. Первое решение — сделать массовую отправку скидок на популярные категории. Результаты показывают, что конверсия низкая: пользователи открывают письма, но не покупают. Тогда маркетолог пробует более сложный подход: сегментирует базу и отправляет каждому сегменту персонализированные скидки на основе интересов и покупок. Конверсия растет. Простое решение не сработало, но помогло без лишних трат понять, что улучшить.
Лучшие идеи рождаются у самоорганизующихся команд.
В Mindbox самоуправление: нет начальников и подчиненных. Вместо них — ответственные за задачи и ведущие команд.
Команда должна регулярно анализировать свою работу и искать способы улучшения эффективности.
Команда разработки Mindbox собирается после каждой итерации на ретро: радуется успехам и обсуждает, как улучшить процессы и функции продукта.

Методологии Agile: Scrum и Kanban

Agile — это философия, которая объединяет множество фреймворков и методов, самые известные из которых — Scrum и Kanban.
Scrum — это фреймворк для создания продукта в условиях неопределенности. Команда двигается к цели продукта короткими итерациями — спринтами, фокусируется на достижении конкретной краткосрочной цели в течение одной-четырех недель. В начале спринта команда выбирает цель, которую хочет достичь, и планирует свою работу. В течение спринта команда каждый день собирается на короткую 15-минутную встречу, чтобы обсудить прогресс и преодолеть препятствия, возникающие на пути к цели спринта. В конце спринта команда показывает готовое изменение заказчикам и получает обратную связь.
Kanban — это метод, который помогает улучшить любой процесс. Вся работа команды визуализирована на доске, где каждый может видеть, на какой стадии находится задача, какие у нее сроки, кто отвечает за задачу. Задачи вытягиваются из входящей очереди. Каждая задача проходит через несколько этапов, например: «Запланировано», «В работе», «На проверке», «Завершено». На некоторых колонках есть ограничения работы в процессе (WIP Limit). По задачам собирается статистика: сколько времени на них потратили, на каком этапе застревали задачи. Эта информация используется для управления потоком задач.
Картинка
Карточки на канбан-доске в редакции Mindbox
Kanban можно использовать и с Agile, и с Waterfall. Он подойдет в следующих случаях:
  • Если задачи поступают нерегулярно и их нужно выполнять по мере появления, как это происходит в службе поддержки с запросами от пользователей. Канбан помогает команде техподдержки обрабатывать каждый запрос в порядке его поступления, равномерно распределяя нагрузку между специалистами.
  • Если нужно гибко управлять работой и быстро реагировать на изменения. В маркетинговом агентстве при работе над рекламными кампаниями клиент может в любой момент запросить изменения, например, скорректировать рекламные баннеры или добавить новую площадку для размещения. Kanban позволяет гибко управлять задачами, добавлять новые приоритеты и реагировать на изменения сразу, не нарушая общий процесс.
  • Если важно видеть все задачи в работе и контролировать прогресс их выполнения. В разработке программного обеспечения, где ведутся несколько параллельных задач, kanban-доска помогает команде отслеживать, на каком этапе находится каждая задача — от планирования до тестирования и выпуска. Это позволяет контролировать прогресс и избегать узких мест в процессе разработки
Scrum и Kanban не противоречат друг другу. Наоборот — их очень часто сочетают.

Советы, как использовать Agile на проекте

Воспринимать внедрение Agile не как проект, а как постоянное улучшение процессов. Agile-манифест — это 12 коротких принципов и четыре ценности. Но чтобы внедрить их в работу, нужно постоянно оптимизировать процессы в команде, адаптировать под них структуру команд или даже целой компании. Это похоже на развитие личности: человек меняется постепенно и постоянно.
Сделать Agile частью культуры компании, а не одной команды. Топ-менеджмент должен понять и принять ценности и принципы Agile — поддерживать гибкость, изменения и быстрый обмен информацией. Важно, чтобы все отделы — от разработки до маркетинга и продаж — работали по одним и тем же правилам и принципам. Если только одна команда использует Agile, а остальные продолжают работать по старинке, это создаст барьеры и непонимание. Например, разработчики в банке используют Agile: работают спринтами, быстро реагируют на изменения, регулярно получают обратную связь от пользователей. А руководство не доверяет гибким методологиям и продолжает требовать детальные планы на год вперед. Это может демотивировать сотрудников и даже спровоцировать их уход из компании.
Применять Agile только там, где он нужен, — в проектах с высокой неопределенностью. Agile помогает справиться с ней за счет гибкости. Но если нужно просто реализовать уже известное решение, тестирование гипотез будет бесполезным и затратным. Для таких проектов больше подойдет Waterfall.
Убедиться, что команда понимает, как каждая задача влияет на бизнес и пользователей. В Agile важно не просто написать код или нарисовать прототип, а решить проблему клиента. Если каждый в команде сосредоточен только на своей зоне ответственности и выполняет только задачи, которые распределяет менеджер, можно упустить из виду общую цель — сделать продукт, который действительно нужен пользователям.