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

Я Алексей Соболеков, лид архитектуры F&R в Magnit Tech. Это мой личный взгляд на события, и в команде существуют разные их интерпретации.

В 2024 году команда F&R (подробности тут: Архитектура высоконагруженной платформы Magnit F&R) в MAGNIT TECH  столкнулась с нетривиальным вызовом: всего за один год необходимо было вырасти с 20 до 220 человек для формирования состава команд. Формально все выглядело благополучно — проект запущен, бюджет подтвержден, приоритет высокий. Но именно с этого момента в ИТ-команде разработки F&R начали накапливаться системные проблемы.

Что могло пойти не так?

Спустя год после старта проекта руководители ИТ-стримов зафиксировали три ключевые проблемы:

●        Планирование — работы планировались непрозрачно, цели спринтов регулярно не достигались, сроки дорожной карты последовательно продлевались.

●        Организация — зависимости между командами стали блокирующими, значительная часть времени уходила на коммуникации, зоны ответственности начали пересекаться.

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

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

Постепенно стало ясно: корень проблем  не в людях и не в процессах, а в исходных проектных решениях, принятых на старте. Именно они задали траекторию будущих конфликтов:

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

●        Структура стримов, изначально построенная с высокой зависимостью доменных команд от стрима платформы, снижала их автономность и замедляла принятие решений.

●        Концептуальная архитектура, в которой сосуществовали две разные логики развития: сначала платформа, затем продукт, или сначала продукт, затем платформизация.

Предпосылки противоречий

Концептуальная архитектура

Архитектура решения была определена задолго до того, как проект официально начался. До старта собственной разработки F&R «Магнит» рассматривал внедрение коробочных платформенных решений от вендоров Relex и DataViva, построенных вокруг LowCode-подхода. Такие платформы у вендоров появились как результат многолетней унификации решений под различные FMCG — сети и уже содержали зрелое технологическое ядро, поверх которого выполнялась настройка под конкретного клиента.

Параллельно в «Магните» стартовал относительно небольшой ИТ-проект по миграции существующих расчетов пополнения магазинов с Oracle Database на open-source-технологии. В этой логике выбор платформенной архитектуры, схожей с вендорскими решениями, выглядел естественным: собственная система должна была удовлетворять тем же бизнес-требованиям.

Когда же начался масштабный проект F&R, команда миграции, ставшая ядром стрима «Пополнение», уже обладала собственным техническим и функциональным видением. Так, архитектура системы пополнения, сформированная в рамках проекта миграции, фактически сформировала начальную концепцию архитектуры F&R.

В итоге это привело к следующим последствиям:

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

●        Исходная архитектура F&R формировалась под задачи и ограничения других проектов. По мере проработки собственных требований F&R разрыв между целевой архитектурой и фактически реализуемой не сокращался, а увеличивался, усиливая архитектурные противоречия.

Так, из-за стремления переиспользовать прежние наработки и лучшие практики вендоров, архитектура F&R вобрала в себя требования и решения из других контекстов.

 Дорожная карта

На старте проекта, в 2024 году, была сформирована дорожная карта внедрения F&R. В еe основе лежала идея создания платформы F&R на базе существующих наработок по промо-прогнозированию и пополнению запасов магазинов.

Изначально предполагалось параллельно решать сразу несколько крупных задач: спроектировать целевую архитектуру системы, разработать платформу F&R, реализовать на ней бизнес-функционал прогнозирования и пополнения, а также запустить MVP с последующим пилотом на 600 магазинах одного распределительного центра сети «Магнит».

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

На практике это привело к ряду последствий. Одновременное проектирование требований, разработка платформы и реализация бизнес-функционала означали, что и бизнес-требования, и архитектурные решения систематически запаздывали. Командам приходилось принимать временные, «костыльные» решения, чтобы не останавливать разработку.

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

Так, под давлением сроков, параллельно начала формироваться более функционально ориентированная модель реализации, а изначальная концепция единой платформы постепенно превратилась в большой архитектурный долг.

Структура стримов проекта

Структура стримов формировалась на основе двух ключевых идей: сквозного процесса планирования и единой технологической платформы, покрывающей весь функционал F&R. Было выделено пять стримов: Интеграция, Прогнозирование, Пополнение, Платформа и UX/UI.

Стримы делились на два типа. Доменные стримы — Прогнозирование и Пополнение — отвечали за бизнес-логику и развитие функциональности. Сервисные стримы — Интеграция, Платформа и UX/UI — обеспечивали технологическую основу решения.

Главное противоречие: Продукт или Платформа

Ретроспективный анализ стримов проекта выявил повторяющийся ключевой вопрос: создаем ли мы Продукт или Платформу? Отсутствие четкого ответа порождало следующий: что представляет собой технологическая платформа и где проходят ее границы?

Созданный в проекте стрим Платформа отвечал за создание ядра системы с использованием LowCode-подхода. Со стороны бизнеса ожидалось, что платформа позволит существенно сократить time-to-market для новых функций и изменений, ускорив внедрение и сопровождение системы.

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

Произошло размытие ответственности и зон владения между стримами, что создало дополнительный, неочевидный слой коммуникаций и согласований, а также подготовило почву для архитектурных разногласий.

В архитектуре оформились два взаимоисключающих тезиса:

●        «Мы создаем универсальную платформу, которую в будущем можно будет внедрять в других компаниях — говорила команда платформы.

●        «Наша задача закрывать конкретные бизнес-требования «Магнита» в сжатые сроки, а не только строить универсальную платформу будущего» — возражал бизнес и архитектура.

Этот спор перерос в затяжное противостояние, в котором каждая сторона отстаивала собственную логику развития системы. Правых и неправых тут не было, это системный конфликт продуктового и платформенного подходов:

●        Продуктовая архитектура оптимизирует time-to-market на коротком горизонте.

●        Платформенная архитектура долгосрочно ускоряет time-to-market, но, на стадии своего создания тормозит и ограничивает продукт.

При росте команд противоречия Продукт против Платформы усиливался кратно.

 

Развязка архитектурного вопроса

По итогам 2024 года был завершен концептуальный архитектурный дизайн проекта, запущен MVP и проведены нагрузочные испытания системы. Нагрузочное тестирование позволило выявить критические архитектурные проблемы в стримах UI и Пополнение/Платформа.

Отзывчивость (latency) UI оказалась значительно ниже ожидаемой из-за использования Trino в роли единого источника данных для UI. Такой выбор был ключевой частью платформенной концепции, предполагающей единое хранилище данных для слоя вычислений и пользовательского интерфейса — основу сквозного применения LowCode-логики как для расчетов, так и для валидации данных UI. На практике этот подход не оправдал ожиданий. Подробно эта история разобрана в статье на Хабре Как стартовать с Data Lakehouse и перейти на Data Lake.

При этом доменная функциональность UI заметно отставала от потребностей бизнеса. Основная причина заключалась в том, что бизнес-логика UI разрабатывалась параллельно с созданием самой UI-платформы, которая находилась на ранней стадии развития.

Стримы Пополнение и Платформа столкнулись с иными ограничениями. Нагрузочные тесты показали существенное отставание по пропускной способности (throughput) решения. Экстраполяция результатов тестов на полный объем розничной сети показала, что такие расчеты займут 40 часов вместо максимально допустимых 4-х часов.

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

Нагрузочные тесты MVP стали точкой, после которой стало ясно, что выбранная на старте конфигурация платформенного подхода требует пересмотра с учетом масштаба. Здесь архитектурный конфликт перестал быть теоретическим и стал операционным.

 Реорганизация: от Платформенной модели к Доменной

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

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

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

Параллельно был внедрен детальный формализованный производственный процесс с жесткими сроками согласования архитектурных решений.

Архитектурные комитеты начали работать по регламенту:

●        максимальный срок анализа решения — 5 рабочих дней, еще 5 дней — на согласование;

●        единый формат архитектурных артефактов с обязательным прохождением процедуры согласования;

●        автоматическое эскалирование и принятие решения через CTO при истечении срока обсуждения.

Постепенно, при поддержке руководства, удалось устранить основные блокировки в согласованиях. Архитектурные сессии перестали быть площадкой для конфликтов и превратились в рабочий инструмент принятия решений.

Результаты стали заметны достаточно быстро:

●        архитектурные решения начали приниматься согласованно и в прогнозируемые сроки;

●        команды стали видеть общую цель вместо конкурирующих позиций;

●        коммуникации стали управляемыми, а зоны ответственности — более четкими;

●        покрытие арх. решениями функциональности стало шире и глубже.

●        появились ресурсы для проверки гипотез (Proof Of Concept).

Статистика архитектурных задач в проекте F&R в 2024 и 2025 годах:

Расширение архитектурной функции позволило системно покрыть большее количество решений и снизить долю несогласованных изменений.

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

 Выводы

Уроки, которые мы вынесли на старте проекта:

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

●        Наследование архитектурных подходов из предыдущих инициатив. Часть решений была логично заимствованы из контекста других проектов и вендорских практик. Однако, подходы, применимые к внедрению готовых, коробочных решений, при переносе в собственную разработку нуждаются в адаптации под конкретные цели бизнеса и ресурсные ограничения ИТ-команд.

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

Неожиданный инсайт

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

Архитектура стала не просто про технологии — она стала языком, на котором разговаривают бизнес, ИТ и руководство.

Что бы я сделал иначе, начиная проект заново:

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

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

●        Архитектура как инструмент координации с первого дня. Роль архитектуры — помогать командам видеть варианты решений, обозначать риски и фиксировать договоренности, дополняя работу ИТ-лидов, а не конкурируя с ними. Четкое распределение ролей и зон ответственности способствует более спокойному и предсказуемому принятию решений.

И это не конец изменений

Проект прошел через непростую и важную трансформацию. Масштабирование команды стало не только вопросом роста технической экспертизы, но и возможностью переосмыслить управленческие практики и архитектурные подходы.

При этом развитие продолжается. Впереди — новые корректировки бизнес-требований, усиление продуктового подхода, организационные изменения и внешний архитектурный анализ проекта F&R с участием консультантов. Но это уже тема для будущих статей.