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

Если хотите вживую услышать доклады топовых спикеров, присоединяйтесь к конференции «Sbergile: продакты для продактов». 29 мая 2025 года она впервые пройдёт в открытом формате для всех — онлайн и бесплатно. Регистрируйтесь для участия!

Представьте: у вас есть несколько десятков сервисов, от CMS до систем аналитики и уведомлений. Одни написаны на Java, другие на Python, третьи используют ClickHouse или Greenplum. Вместо того, чтобы собирать всё в монолит, мы разбили их на сотни маленьких модулей, которые можно комбинировать как кубики Lego. И превратили во внутреннюю платформу «Среда», которая работает по принципу модульной микросервисной архитектуры. По сути, это конструктор, где каждый сервис или функциональность разбита на мелкие независимые модули. Платформа сама по себе ничего не делает, она лишь позволяет бизнесу самому соединять модули между собой и получать готовый продукт. Расскажу о том, как мы к этому пришли. 

Как мы сократили время вывода продуктов с 2 недель до 15 минут

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

Традиционно мы бы:

1. проанализировали требования;

2. поставили задачи;

3. написали ТЗ и согласовали с заказчиком;

4. разработали бэкенд и фронтенд;

5. протестировали, вывели в прод.

Но мы пошли другим путём:

1. создали конструктор динамического формирования страниц, в котором бизнес может сам настраивать контент;  

2. реализовали модули абстракции хранения страниц и их параметров в БД;  

3. разделили большое количество модулей на сервисы (ESP, Backend, Notifications, Filemanager, Analytic); 

4. дали администраторам возможность управлять доступом без участия разработчиков.

Например, мы собрали сервис Шина для обмена данными (аналог Kafka), файловый менеджер (похожий на S3), систему аналитики для сбора действий пользователей, систему авторизации и аутентификации, и ролевую модель с гибкими правами (с RLS — Row-Level Security).

Результат:

• Раньше добавление нового виджета, раздела или страницы на сайте, изменения в пользовательском меню и пр. на стеке HTML/CSS/JS занимало 2 недели, теперь — 15 минут.

• Бизнес получил возможность экспериментировать — менять пути пользователей или контент — без долгих релизов.

• В 320 раз выросла скорость вывода в эксплуатацию заявок от заказчиков.

• 0,31 % от первоначального времени стал занимать LT.

Главное преимущество такого подхода — гибкость. Если бизнесу нужно добавить новый виджет на главную страницу, это не требует двухнедельных согласований с дизайнерами и разработчиками. Вместо этого администратор заходит в конструктор, выбирает шаблон, настраивает данные — и через 15 минут функциональность уже в работе.

Почему не стоит делать «идеальный» продукт с первого раза

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

Пример: система согласования документов. К тому моменту, когда мы начали проект, у нас уже были готовые модули для уведомлений и форм, но не было процесса для согласований.

Варианты:

1. Захардкодить процесс под требования методологов (быстро, но не гибко).

2. Создать универсальный BPM-модуль (дольше, но масштабируемо).

Мы выбрали второй вариант и получили такие результаты:

• Вместо запланированного года на разработку — MVP за месяц.

• Бизнес смог сам настраивать этапы согласования, а не ждать правок от разработчиков.

Выводы:

• Бизнес-процессы меняются постоянно. Если закладывать гибкость с самого начала, то можно избежать бесконечных доработок.

• Лучше выпустить минимальный рабочий продукт, получить обратную связь от реальных пользователей и итеративно улучшать продукт, чем год делать «идеал», который окажется невостребованным.

Импортозамещение: как мы заменили Microsoft за год

Ещё один вызов — отказ от Microsoft, когда стало ясно, что её продукты уходят с рынка, а у нас в трайбе больше 150 кубов (Big Data) на их технологиях.

Проблемы:

1. не было доступа к редактированию БД банка, где хранятся данные; 

2. данные хранились в разных СУБД (ClickHouse, GreenPlum и др.); 

3. не было удобной визуализации большого объёма данных (пользователи привыкли к Excel); 

4. изменения в кубах занимали 28 дней.

Что мы сделали:

1. собрали первые прототипы на готовых OpenSource-компонентах;

   

2. создали свой ноукод-интерфейс для сборки отчётов (похожий на Excel); 

   

3. реализовали алгоритмы свёртки данных, фильтры, иерархии; 

4. интегрировали RLS, чтобы безопасно делиться данными с разными командами. 

Результат: 

• время сборки куба сократилось с 28 дней до 1,5;

• в 19 раз выросла скорость доставки UI изменений в OLAP-кубах; 

• пользователи получили привычный интерфейс (меньше стресса при переходе); 

• no-code интерфейс администрирования;  

• данные теперь можно комбинировать из разных источников без участия разработчиков.

Сейчас «Среда» — это платформа, которая помогает бизнесу и разработке говорить на одном языке. И мы продолжаем её развивать, потому что аппетит (у заказчиков) приходит во время еды. Чтобы у вас получилось ещё быстрее, чем у нас, советую обратить внимание на те ошибки, которые мы совершили, и избежать их. 

1. Слишком сложные модули.
   Ошибка: пытались сделать универсальный конструктор «на все случаи жизни».
   Решение: разбили его на мелкие специализированные блоки (например, отдельно — формы, отдельно — таблицы).

2. Недооценка нагрузки на шину.
   Ошибка: в первый месяц сервис уведомлений «лёг» из-за всплеска запросов.
   Решение: добавили кеширование и горизонтальное масштабирование.

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

Как внедрить такой подход в вашем проекте

1. Начните с малого. Выберите одну повторяющуюся задачу (например, создание типовых страниц) и автоматизируйте её через модули.

2. Используйте готовые решения. Не пишите свой BPM или файловое хранилище, возьмите OpenSource-решение (Camunda, MinIO) и адаптируйте под свои нужды.

3. Декомпозируйте всё. Даже большой продукт вроде CRM можно разбить на:

   • модуль форм; 

   • модуль уведомлений; 

   • модуль аналитики.

4. Дайте бизнесу инструменты. Научите команды самостоятельно собирать страницы в конструкторе, это сократит 80 % рутинных задач разработчиков.

В конце концов, модульная архитектура — это не про технологии, а про культуру разработки. Вы сможете сократить сроки в разы, если готовы:

• делить продукт на независимые блоки; 

• доверять бизнесу часть задач; 

• быстро тестировать гипотезы. 

Какие главные выводы мы сделали 

1. Привлекайте бизнес в процесс разработки. Не ждите готовых ТЗ, сами создавайте себе задачи и предлагайте решения.

2. Не бойтесь ошибаться. Не ошибается тот, кто ничего не делает. Информируйте о своих ошибках и собирайте обратную связь.  

3. Декомпозируйте задачи. Лучше сделать несколько простых модулей, чем один сложный монолит.

4. Доверяйте молодым разработчикам. Они ещё не знают, что «это невозможно», поэтому находят нестандартные решения.