Эта история — не про плохой 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 действительно превращается не в центр затрат, а в центр хронического разочарования.

И это — самая дорогая ошибка, которую может сделать бизнес.