Привет! Меня зовут Геннадий Хараев, я Service Delivery Manager в интернет‑магазине МегаФона. Ниже мой откровенный рассказ о том, как за последний год мы полностью перезагрузили процессы, команды и технологическую платформу. Я сознательно избегаю точных цифр – важнее настроение, идеи и принципы, которые стоят за нашими изменениями.
Почему мы вообще взялись за трансформацию?
Когда я пришёл в проект, интернет‑магазин напоминал большой океанский лайнер: впечатляет, но поворачивает медленно. У нас было всё, что свойственно зрелому, но слегка уставшему продукту: длинные релизные циклы, хрупкий монолит, разрозненные команды, ручные тесты, пул запросов от бизнеса, который рос быстрее, чем мы успевали реагировать. Cкладируя задачи в бесконечную «коробку бэклога», мы рисковали не заметить по‑настоящему ценные возможности.
Мы использовали классический Waterfall-подход, где каждый этап должен был завершиться, прежде чем начинался следующий. Он создавал узкие места и вызывал раздражение.
Команды были организованы по функциональному принципу: фронтенд в одном углу, бэкенд — в другом, бизнес-команды вообще жили в своей вселенной. Все это приводило к несогласованным приоритетам и требовало длительных переписок, чтобы что-то сдвинулось с места.
У нас был не полностью прозрачный процесс. Руководству приходилось тратить время, чтобы понять, что происходит в проекте, полагаясь на устные отчёты.
Наконец, наш технологический стек тормозил развитие. Монолитная архитектура и отсутствие автоматизированного тестирования усложняли процесс масштабирования и устранения ошибок.
И тогда стало понятно и бизнесу, и руководству: без системных изменений мы окажемся в положении догоняющих. Нам нужно было ускориться, сделать процессы лёгкими, а продукт — одновременно дружелюбным для клиента и технологичным.
По итогу, компания инвестировала в развитие интернет-магазина МегаФона и сделала его одним из приоритетных проектов на ближайшие несколько лет.
#1 Первый шаг: Переосмыслить роли и ответственность
Появление роли SDM: Мост между командами и бизнесом
Одним из первых решений стало внедрение роли Service Delivery Manager в каждую зону бизнеса. SDM — это тот, кто держит руку на пульсе: понимает бизнес‑приоритеты, чувствует боли команды, владеет картиной целиком. Когда я стал SDM, я увидел в этой роли возможность стать связующим звеном — мостом между разработчиками, продуктовыми менеджерами и бизнесом. Моя цель была не в том, чтобы контролировать каждый шаг, а в том, чтобы убирать препятствия, выравнивать приоритеты и направлять всех к общей цели. Мы ввели роли SDM для каждого ключевого этапа пути клиента: preCheckout (каталог и рекомендации), checkout (заказы и платежи) и postCheckout (логистика и поддержка). Каждый SDM стал главным координатором своего направления, отвечающим за то, чтобы всё двигалось вперёд, а у команды было всё необходимое для успеха. Мы превратились в своего рода дирижёров, помогающих инструментам звучать согласованно.
Помню одна из первых вещей, на которую я обратил внимание, — сколько времени мы тратили на недопонимание. Команды работали усердно, но часто концентрировались не на тех задачах, потому что приоритеты были неясны. Также были проблемы с загрузкой на одного разработчика и не только, а кроссвзаимодействие команд из разных подразделений, можно было в принципе не дождаться нужного функционала или ручки для запуска.
Что изменилось? Команде стало проще ориентироваться в приоритетах, а бизнесу — разговаривать с «единым окном» вместо множества специалистов. В коротком цикле вопросов стало меньше, а энергии — больше. Было приятно видеть, как быстро дела пошли в гору, когда все оказались на одной волне.
Стрим как точка притяжения: От силосов к стримам
Одним из самых значимых изменений стало переосмысление структуры команд. Вместо разделения по техническим ролям (фронтенд, бэкенд и т.д.) мы создали кросс-функциональные стримы, ориентированные на путь клиента. Стрим preCheckout отвечал за всё- от каталога товаров до персонализированных рекомендаций и SEO. Стрим Checkout сосредоточился на том, чтобы сделать процесс покупки максимально удобным, интегрируя платёжные системы и акции. А стрим postCheckout занимался логистикой, интеграцией с партнёрами и поддержкой после покупки.
Это изменение стало настоящим прорывом. Дав каждому стриму автономию в принятии решений в своём домене, мы избавились от бесконечных согласований, которые раньше тормозили работу. Команды закрепились за стримами и они начали чувствовать себя хозяевами своего участка, что повысило их мотивацию и креативность. Никогда не забуду, как некоторые коллеги выдохнули, когда поняли, что перестанут переключатся от задачи к задаче и начнут работать по одному направлению.
Теперь все: аналитик, разработчик, тестировщик — смотрят в одну сторону и чувствуют, что именно их вклад делает путь клиента удобнее.
#2 Второй шаг: Синхронизироваться с реальными потребностями бизнеса
Ещё одним важным шагом стало укрепление связи с менеджером по продукту. Раньше цели бизнеса и приоритеты разработки казались двумя разными мирами. Мы изменили это, введя регулярные синхронизации: еженедельные встречи для краткосрочного планирования и ежеквартальные — для стратегических задач. Каждая новая фича должна была отвечать чёткой бизнес-цели, будь то упрощение процесса покупки или повышение лояльности клиентов.
Эти встречи были не просто формальностью — они выстраивали доверие. Совместно с менеджером и аналитиком, мы обсуждаем, что нужно бизнесу и как мы можем это реализовать. Это было как перевод с одного языка на другой, чтобы все понимали, зачем нужна каждая задача. Со временем это помогло нам сосредоточиться на функциях, которые действительно важны для клиентов, таких как умные рекомендации или ускоренная обработка заказов.
Со временем эта привычка переросла в культуру: менеджеры продукта с помощью бизнес-аналитики стали готовить понятные документы, а системные аналитики преобразовывать их в понятные требования для разработки. Процессы больше не «спускаются», они рождаются из диалога. Это сделало их проще и понятнее.
#3 Третий шаг: Навести порядок в процессе создания ценности
Kanban вместо беговой дорожки
Мы не стали спорить, какая модель управления «самая Agile». Взяли Kanban как простой визуальный язык. При этом мы отказались от жёсткого Waterfall-подхода и не забыли добавить лимиты незавершённой работы (WIP). Если вы видели Kanban-доску в Jira, вы знаете, что это зеркало души команды — все задачи, узкие места и победы видны как на ладони. Мы заставляли себя завершать задачи, прежде чем браться за новые. Это кажется простым, но стало настоящим откровением. Вдруг мы перестали жонглировать десятком недоделанных фич и начали доводить работу до продакшена. Доска жёстко ограничивает количество задач «в работе», а значит, каждый фокусируется на завершении, а не на бесконечном старте нового.
Эффект удивил: у ребят появилось чувство завершённости, дизайнеры и тестировщики перестали просыпаться в последний момент, а обсуждения сместились с «Когда начнём?» на «Что мешает закончить?».
Ежедневные стендапы — сердце процесса. Каждое утро мы собираемся (виртуально или лично), чтобы обсудить, что сделано, что застряло и что дальше. Не всегда всё идет гладко — бывали дни, когда эмоции зашкаливали или приоритеты менялись. Но эти короткие встречи держат нас в тонусе и двигают работу вперёд.
Обновление технологий: От монолита к микросервисам
С технической стороны мы знали, что наш старый монолитный стек тормозит развитие. Это было как пытаться ремонтировать дом, живя в нём, — каждый шаг был медленным и рискованным. Мы решили мигрировать на микросервисную архитектуру на базе Kubernetes с современным стеком, включая Node.js, и всеми современными штуками. Это не мгновенный переход - потребуются месяцы планирования, перепилки, сессии отладки, но оно того стоит. Ожидаем, что процесс завершится в 2026 году.
Новая архитектура сделает платформу надёжнее и проще в масштабировании. Если один сервис упадет, он не потянет за собой весь сайт. Деплои уже стали быстрее и менее стрессовыми благодаря автоматизации.
Автономное качество
Тестирование — ещё одна область, где мы сделали большой шаг вперёд. Раньше тестирование было в основном ручным, что означало медленную и подверженную ошибкам работу. Мы внедрили Allure TestOps, интегрировали его с Jira и начали запускать автоматические тесты параллельно. Это позволило ловить баги раньше и выпускать более чистый код. Команда QA стала настоящими героями. Они взаимодействовали с разработчиками с самого начала, чтобы требования были чёткими и тестируемыми, а тест-кейсы создавались, когда еще только пишутся требования. Это сильно отличалось от старых времён, когда код просто перебрасывали «через забор» в надежде, что всё сработает.
Тестировщик превратился из «последнего рубежа» в партнёра разработчика: он участвует на этапе идеи, думает о сценариях, помогает выбрать оптимальный подход. Ошибки ловятся там, где почти ничего не стоят.
Мониторинг как ежедневная привычка
Чтобы обеспечить отличный пользовательский опыт, мы активно использовали инструменты мониторинга, такие как Grafana для метрик производительности и Sentry для отслеживания ошибок. Эти инструменты дают нам информацию в реальном времени о том, как работает платформа и где возникают проблемы. Когда что-то идет не так — например, страница медленно загружается, — мы быстро реагируем.
Оптимизация Jira: Единый источник правды
Наша Jira в начале была настоящим хаосом. У каждой команды были свои пространства и доски, процессы и подходы - было невозможно увидеть общую картину. Мы полностью перестроили ее, создав единое пространство с кастомными полями для приоритизации и стандартизированными процессами. Также добавили выгрузки в Qlik для отслеживания ключевых метрик, чтобы видеть прогресс наглядно. Это не было чем-то эффектным, но значительно упростило всем жизнь. Все команды стали жить по единым стандартам и требованиям, что очень сильно сплотило кроссплатформенные команды и для всех все стало просто.
Создание культуры обучения: Практики, которые остаются
По мере изменений мы сосредоточились на создании практик, которые будут долговечными. Мы начали проводить регулярные ретроспективы — сессии, где обсуждали, что получилось, что нет и как стать лучше. Это дало возможность учиться и расти. Мы также приняли подход Domain-Driven Design (DDD), разделив платформу на чёткие домены (preCheckout, Checkout, postCheckout), что ускорило разработку.
Ещё одним важным шагом стало привлечение системных аналитиков и тестировщиков на ранних этапах. Вместо того, чтобы тестировать или проверять в конце, они участвовали в процессе с момента написания требований. Это помогает ловить проблемы в требованиях раньше и экономить время на доработках. Также мы вложились в документацию, создав в Confluence централизованную базу знаний. Теперь, если кому-то нужно разобраться в чём-то, не нужно рыться в письмах или чатах — всё находится за пару минут.
#4 Четвёртый шаг: Расширить горизонты
Маркетплейсы и партнёрские витрины
МегаФон не ограничивается только собственным магазином. Мы строим экосистему точек контакта: маркетплейсы, партнёрские сервисы. Наша задача, которая является одной из самых захватывающих частей трансформации, - это интеграция с крупными маркетплейсами, такими как Ozon, Wildberries и Яндекс.Маркет. Они открыли новые каналы для привлечения клиентов, увеличив трафик и продажи.
Процесс пока не завершен, но это не только про технологии — мы учимся понимать, чего хотят клиенты. Наблюдаем, как поступают новые заказы. Это было своего рода напоминанием, ради чего мы всё это делаем.
Сквозной поток от идеи до продажи
Мы выстроили прозрачный upstream‑downstream: бизнес формулирует гипотезы → приоритеты выстраиваются в зависимости от результата → менеджер превращает их в эпик → стрим реализует → CI/CD доводит до продакшена → бизнес собирает данные об эффекте. Нет «чёрных ящиков», любой этап прозрачен.
#5 Пятый шаг: Взгляд в будущее или «что дальше?»
Трансформация — это не только проект с датой окончания, это стиль жизни. Сегодня мы раз за разом задаём себе вопросы:
Что ещё тормозит поток создания ценности?
Где у нас незаметно подрастает технический долг?
Какие навыки команде пригодятся завтра?
Как новые AI‑технологии могут подарить клиенту ещё более персонализированный опыт?
Ответы плавно превращаются в инициативы, инициативы — в задачи стримов, а дальше — всё по отлаженному конвейеру.
Двигаясь вперёд, я с энтузиазмом смотрю на наши планы. Мы укрепляем культуру непрерывного совершенствования, пробуем новые идеи. Мы продолжаем инвестировать в DDD, используя техники вроде Event Storming, чтобы находить скрытые возможности в наших системах. Управление техническим долгом — ещё одна приоритетная задача: регулярные «спринты чистки» помогают держать кодовую базу лёгкой и гибкой.
Обучение тоже в фокусе. Мы поощряем инженеров и SDM осваивать новые инструменты и методологии, например углублённых курсов по DDD. Для клиентов мы исследуем омниканальные возможности, связывая интернет-магазин с мобильными приложениями, физическими магазинами и чат-ботами для единого опыта. И это только начало с ИИ и машинным обучением — представьте рекомендации, которые будто читают мысли клиентов.
Уроки, которые я вынес: Советы коллегам
Оглядываясь назад, трансформация Ecom в МегаФоне научила меня нескольким важным вещам.
Во-первых, люди — сердце любых изменений. Инструменты и процессы важны, но без доверия и сотрудничества ничего не выйдет.
Во-вторых, важен фокус на клиенте — каждая фича, каждое изменение должны улучшать их опыт. И наконец — не бойтесь экспериментировать. Некоторые из наших самых больших побед стали результатами попыток сделать что-то новое, даже если это казалось рискованным.
Путь ещё не окончен. Мы продолжаем учиться, улучшать и стремиться к большему. Но видеть, как далеко мы продвинулись — как наша платформа стала быстрее, команды — счастливее, а клиенты — довольнее — делает всё это стоящим. Если вы работаете над подобной трансформацией, мой совет прост: слушайте команду, синхронизируйтесь с бизнесом и держите клиента в центре. Остальное приложится.
Вместо списка достижений я оставлю мысль: «люди, процессы и технологии — три стороны одного треугольника». Подтягиваешь одну — ощущаешь напряжение в остальных. Стоит уделить внимание всем трём, и система приходит в гармонию: команда чувствует смысл в работе, бизнес — уверенность в результате, клиент — удобство и удовольствие.
Этот путь небыстрый и нелинейный, но именно он превращает интернет‑магазин в живой организм, способный меняться вместе с рынком. Надеюсь, моя история вдохновит вас на собственные шаги преобразований.
С Вами был:
Если у вас похожие задачи или идеи, давайте обмениваться опытом!
