Спойлер: это статья не про плохую архитектуру. Я расскажу о том, как хорошие решения, принятые в разное время, начинают конфликтовать друг с другом, когда команда растет быстрее системы.
Я Алексей Соболеков, лид архитектуры 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 годах:
Год | В работе | Готово | Приостановлен | Итого |
2024 | 1 | 71 | 14 | 86 |
2025 | 40 | 127 | 28 | 195 |
Расширение архитектурной функции позволило системно покрыть большее количество решений и снизить долю несогласованных изменений.
Следует отметить, что позднее, когда бизнес усилил фокус на ускорении вывода функциональности в продуктив, архитектурный процесс начал восприниматься командами как фактор, влияющий на скорость изменений. Это потребовало дополнительной калибровки модели взаимодействия: сокращения цепочек согласования, упрощения процедур и снижения избыточной детализации артефактов. Опыт показал, что любая управленческая модель должна регулярно адаптироваться к контексту - особенно в условиях быстрого роста и меняющихся приоритетов.
Выводы
Уроки, которые мы вынесли на старте проекта
Параллельный запуск платформы и продуктовой разработки. Одновременное развитие универсальной платформы и бизнес-функциональности привело к наложению двух архитектурных логик - платформенной и продуктовой. Это усложнило процесс принятия решений и требовало более четкого разделения приоритетов, ресурсов и этапов развития.
Наследование архитектурных подходов из предыдущих инициатив. Часть решений была логично заимствованы из контекста других проектов и вендорских практик. Однако, подходы, применимые к внедрению готовых, коробочных решений, при переносе в собственную разработку нуждаются в адаптации под конкретные цели бизнеса и ресурсные ограничения ИТ-команд.
Платформенный стрим без явного бизнес-владельца. Платформа играет ключевую роль для всей системы, однако отсутствие прямого бизнес-заказчика усложняет выстраивание приоритетов. Это показало важность синхронизации платформенных задач с продуктовыми метриками и ожиданиями бизнеса.
Неожиданный инсайт
Со временем архитектура перестала восприниматься только как технический артефакт и стала полноценным инструментом управления - способом структурировать диалог между командами, фиксировать договоренности, обсудить с топами архитектурные риски тех или иных решений, и снизить напряженность при принятии решений.
Архитектура стала не просто про технологии - она стала языком, на котором разговаривают бизнес, ИТ и руководство.
Что бы я сделал иначе, начиная проект заново
Сначала домены — потом платформа. Платформа показывает наибольшую эффективность, когда формируется как обобщение уже проверенных доменных решений, а не как гипотеза на раннем этапе проекта. Такой подход позволяет опираться на реальные сценарии и подтвержденную продуктовую ценность.
Платформа при наличии четко определенного бизнес‑владельца. Важно заранее понимать, какие продуктовые задачи она ускоряет и какие метрики улучшает. Синхронизация целей платформенной команды с доменными стримами помогает поддерживать общий фокус и устойчивый темп развития.
Архитектура как инструмент координации с первого дня. Роль архитектуры — помогать командам видеть варианты решений, обозначать риски и фиксировать договоренности, дополняя работу ИТ‑лидов, а не конкурируя с ними. Четкое распределение ролей и зон ответственности способствует более спокойному и предсказуемому принятию решений.
И это не конец изменений
Проект прошел через непростую и важную трансформацию. Масштабирование команды стало не только вопросом роста технической экспертизы, но и возможностью переосмыслить управленческие практики и архитектурные подходы.
При этом развитие продолжается. Впереди - новые корректировки бизнес-требований, усиление продуктового подхода, организационные изменения и внешний архитектурный анализ проекта F&R с участием консультантов. Но это уже тема для будущих статей.
