Эта история - не про плохой Agile, не про «тупых маркетологов» и не про «оторванных от реальности айтишников».
Она про разрыв ожиданий, который возникает, когда разные миры начинают работать как будто они одинаковые.
Исходная точка: когда всё работало
Есть крупный маркетинговый продукт. Основные потребности ИТ-услуг - лендинги, мини-игры, рейтинги, промо-механики, A/B-тесты, быстрые гипотезы.
Исторически этот продукт работал просто:
есть идея;
есть краткое описание;
есть веб-студия или небольшой подрядчик;
«сделайте нам вот это».
Что происходило дальше:
разработка - за несколько дней или неделю;
правки вносятся по ходу;
требования уточняются «на лету»;
сроки плавают, но это "норма";
результат — пусть не идеальный, но быстро в проде, а главное - не нужно разбираться в тонкостях работы ИТ.
Для маркетинга это привычная модель:
Скорость важнее архитектуры, эксперимент важнее чистоты кода.
Поворот: своя IT-компания
В какой-то момент было принято стратегическое решение - выделить разработку в отдельную IT-структуру.
Формально — логично:
контроль,
качество,
масштабируемость,
снижение зависимости от подрядчиков.
Фактически — появляется дочерняя IT-компания, в которую нанимают сильных людей:
выходцев из крупных ИТ корпораций,
продуктовой разработки,
enterprise-подходов,
«настоящего» Agile.
И вот здесь начинается конфликт.
Два мира — два языка
Мир маркетинга
Маркетинговая платформа живёт так:
гипотеза → быстрый тест;
требования размыты;
«посмотрим по ходу»;
частые изменения;
результат важнее процесса;
прототип ≈ MVP;
решение можно поменять через 7 минут.
Для них разработка — инструмент эксперимента. Нет общего понимания процесса разработки, т.к. он не выстрадан через многолетнюю разработку ИТ решений. И это нормально для мира маркетинга!
Мир классического IT
IT-компания живёт иначе:
Definition of Ready;
Definition of Done;
спринты;
планирование;
фиксированный scope;
изменения — через backlog;
релизы — только запланированные;
без требований — в работу не берём.
Для них разработка — инженерный процесс, а не креативная импровизация. Все должно быть описано четко, процесс разработки не должно идти по пути "укладываем рельсы из кабины паровоза". И это тоже нормально для мира ИТ.
Точка взрыва: «Почему так долго и дорого?»
Маркетинг приходит и говорит:
- «Нам нужен рейтинг с таким-то функционалом».
IT отвечает:
- «Опишите требования».
- «Ну, примерно вот так, а дальше посмотрим».
- «Так не работаем».
В итоге:
IT закладывает риски;
учитывает возможные изменения;
добавляет GAP-доработки;
сроки растут;
оценки становятся «слишком большими».
Маркетинг в недоумении:
- «Веб-студии делали это за неделю. Почему теперь месяц?»
- «Потому что мы делаем правильно».
И никто не счастлив
Изначальные сроки выглядят для маркетинга слишком длинными (хотя если все сделано правильно, то итоговое время разработки должно быть меньше, чем у веб-студий, тк все риски уже заложены, когда веб-студии будут "укладывать рельсы"). Тем не менее, сдвиги каких-то фичей все еще возможны, из-за ошибок в требованиях или "разработчик заболел", что еще больше фрустрирует заказчика.
Маркетинг пытается подпихнуть идеи в процессе разработки, однако встречает строгое "нет, давайте положим это в беклог", так как "так принято".
... Вздох, - а у веб-студий можно...
В итоге складывается картина, что страдают все. Одним не нравится чопорность и закостенелость ИТ, другим - абсолютно (по их мнению) неорганизованная работа маркетинга.
Главная ошибка: ожидать одинакового поведения от разных систем
Ключевая проблема не в людях и не в компетенциях. Проблема — в переносе модели работы без осознания контекста.
Маркетинг ожидал:
такую же гибкость, как у подрядчиков;
такую же скорость;
такое же отношение к изменениям.
IT-компания ожидала:
зрелого заказчика;
формализованных требований;
уважения к процессам.
Обе стороны были правы. И обе стороны ошибались.
Почему веб-студии «могли», а IT - «не может»
Потому что у них разные цели и ограничения.
Веб-студия:
не отвечает за долгосрочную поддержку;
часто (всегда, если это не собственный фреймворк) жертвует архитектурой;
работает «на результат здесь и сейчас»;
принимает хаос как часть бизнеса.
IT-компания:
думает о масштабировании;
несёт ответственность за сопровождение;
платит за технический долг;
вынуждена минимизировать неопределённость.
Это не «хорошо» и не «плохо». Это разные модели.
Что на самом деле пошло не так
Не был договорён формат взаимодействия
IT стали воспринимать как внутреннюю веб-студию. Но без права работать как веб-студия.
Не был оговорен формат продуктов
Эксперименты ≠ продуктовая разработка. Прототипы ≠ MVP.
Не было переводчика между мирами (основная проблема)
Product / Delivery / BizDev роли отсутствовали или были формальными. Маркетинг говорил идеями, IT - процессами. Не была разработана бизнес архитектура продуктов (много чего делалось по нескольку раз, одно и тоже, но это заслуживает отдельной истории).
Вывод: IT — это не центр затрат
И не «волшебная кнопка», которая делает «быстро и как у веб-студии».
IT - это:
центр баланса ожиданий,
центр перевода смыслов,
центр управления неопределённостью.
Если этого не понимать - IT всегда будет:
«медленным»,
«дорогим»,
«непонятным».
Что нужно было сделать (и что делать другим)
Разделить контуры
Маркетинговый sandbox
быстрые прототипы;
эксперименты;
высокая терпимость к изменениям.
Под это стоит выделить отдельную группу разработчиков (фозможно только frontend), которые быстро могут накидывать и деливерить гипотезы, чтобы проводить тесты. Если тест успешный - отдаем далее.
Продуктовый контур
стабильность;
требования;
архитектура;
масштаб.
Здесь мы уже собираем продуктв и встраиваем в продуктовую архитекуру, чтобы не писать одно и тоже по 10 раз, чтобы разработать свой фреймворк, которые сокращает время прототипирования для команды sandbox и упрощает встраиваение успешных тестовых продуктов в экосистему.
Признать право на хаос
Не весь хаос - зло. Но он должен быть управляемым и локализованным. И все участники этого хаоса должны его принять.
3. Ввести роль переводчика
Product / Delivery - не формальность, а ключевая функция:
перевод ожиданий бизнеса в язык IT;
защита команды от «прилетело срочно»;
объяснение бизнесу, почему «так нельзя, но вот так можно».
4. Договориться об ожиданиях заранее
что такое «быстро»;
что такое «готово»;
где можно менять требования;
где - нельзя.
Финал
IT не обязано быть удобным. Маркетинг не обязан быть формализованным. Но обе стороны обязаны договориться, иначе IT действительно превращается не в центр затрат, а в центр хронического разочарования.
И это - самая дорогая ошибка, которую может сделать бизнес.
