Привет, Хабр! Я Светлана Чернышова, руководитель управления в рязанском хабе Т-Банка. Моя статья — часть проекта к 20-летию Т-Банка «20 в 20», в котором мы рассказываем об ИТ-хабах в разных городах и о людях, которые живут в этих инженерных сообществах.

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

В статье рассказываю о том, что происходит с техническим лидером, когда его зона ответственности растет не по дням, а по часам. О том, как приходится переосмысливать не только процессы, но и саму роль — от решения задач до создания условий, в которых другие могут принимать правильные решения. Ну и немного про Рязань, конечно 😉

Платформа, которая держит 90 тысяч встреч в день

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

За одной встречей с представителем стоит не просто время и место. За ней стоит сложная система, которая ежедневно:

• распределяет около 90 тысяч встреч;

• учитывает более 20 параметров на каждую: от географии и графика сотрудника до приоритетов клиента и прогноза нагрузки;

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

• работает в режиме 24/7 без права на простои.

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

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

Я думала, что руководитель — это про экспертизу и контроль, но опыт с масштабированием показал, что это про людей, ответственность и постоянное сомнение в себе. Делюсь уроками, которые я выучила на своем пути.

Урок первый: от ручного контроля к системе ответственности

Когда команда небольшая, технический руководитель может держать в голове почти все: какие сервисы существуют, кто за что отвечает, где основные риски, как устроена бизнес-логика. На уровне 20—30 человек такая модель еще работает. Но при росте до сотни инженеров и десятков сервисов личная экспертиза перестает масштабироваться.

Мы начали сталкиваться с проблемами:

• изменения в одной команде влияли на другие, но об этом узнавали уже постфактум;

• похожие компоненты дублировались, потому что команды не знали о существовании решений в соседних направлениях;

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

Управлять платформой путем личного контроля стало невозможно. Нужно было строить систему ответственности.

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

Технически это означало:

• введение владельцев сервисов (service owners);

• создание единой карты сервисов с указанием команд, SLA/SLO; 

• внедрение архитектурных ревью через ADR (архитектурные решения записываются и публикуются);

• регулярные синхронизации между лидерами для согласования стратегии.

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

Это был поворотный момент. Масштаб требовал не больше контроля, а больше прозрачности, автономии и доверия.

Урок второй: от накопленных To-Do-задач до блокирующего техдолга

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

Но по мере роста начали проявляться системные проблемы:

• релизы становились дольше и сложнее;

• изменения в одном модуле ломали неожиданные части системы;

• масштабировать приходилось весь монолит целиком, даже если нагрузка росла только в одном сценарии;

• время поставки правки из-за зависимостей выросло с дней до недель.

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

Мы начали с анализа, какие сущности логически связаны, какие потоки данных доминируют, где чаще всего происходят конфликты при разработке. На основе этого выделили автономные домены:

• систему назначения и распределения встреч;

• систему управления сотрудниками;

• набор решений для интеграций с внешними системами;

• работу с клиентскими заказами и трекингом отправлений.

Каждый стал отдельным сервисом с собственной базой данных, API и командой-владельцем.

Один из ключевых моментов — мы изменили культуру разработки:

• каждая команда отвечает за свой сервис «от железа до пользователя»;

• архитектурные решения фиксируются в ADR;

• новые зависимости между сервисами согласовываются на уровне архитектурного комитета.

В итоге время релиза сократилось в 3 раза, аварийность упала на 40%, команды стали автономнее и быстрее вносить изменения. Технический долг не исчез, но перестал быть барьером. Вместо того чтобы тормозить, техдолг стал катализатором изменений.

Урок третий: от ручного планирования к алгоритмической платформе

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

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

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

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

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

Помимо задач автоматизации мы сталкиваемся со сложными инженерными вызовами, такими как замена СУБД Oracle на PostgreSQL. Когда говорят о миграции с Oracle на PostgreSQL, обычно представляют классическую техническую задачу: экспортировали данные, загрузили данные, переключили сервисы. На практике все значительно интереснее. В нашем случае нужно было перевезти мастер-систему управления встречами Платформы доставок в рамках проекта по импортозамещению Oracle и перехода на DBaaS. Задача выглядела типовой:

• более 3 ТБ данных;

• около 280 таблиц;

• 13 сервисов-потребителей;

• 4 команды разработки;

• десятки интеграционных и аналитических процессов.

Быстро выяснилось, что основная сложность проекта не в самой СУБД. За годы вокруг базы выросла целая экосистема сервисов, интеграций и процессов. Мы столкнулись с несколькими проблемами:

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

• часть SQL-запросов активно использовала Oracle-специфичные особенности;

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

Вместо прямого переноса мы пересмотрели накопленные за годы решения.

В результате сократили объем данных с 3 ТБ до 350 ГБ, вывели часть исторических сценариев в DWH, оптимизировали тяжелые запросы и подготовили более десяти сервисов к единовременному переключению на новую платформу.

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

Урок четвертый: от сервиса к платформе, от приложений к экосистеме

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

Один из ярких примеров — собственный логистический агрегатор. Раньше доставку банковских продуктов в ПВЗ мы организовывали через стороннего партнера. Это было удобно, но не масштабируемо и дорого. Мы не могли гибко управлять тарифами, охватом или интеграциями.

За шесть месяцев мы разработали универсальный агрегатор, объединив интеграции с ведущими транспортными компаниями: СДЭКом, Яндексом, Ozon и другими. Теперь любое подразделение может подключиться к одной платформе и получить доступ ко всем перевозчикам — с выгодными тарифами и охватом более 100 000 пунктов выдачи по России и за рубежом.

На базе этой технологии уже запущены четыре стратегических направления:

• доставка банковских продуктов в ПВЗ — экономичный и удобный способ получения карты;

• Т-Шопинг — полноценная платформа для доставки товаров от селлеров до клиентов;

• сервис трекинга посылок с более 150 000 уникальных пользователей в месяц;

• С2С-сервис — отправка посылок между физлицами с выбором оптимального способа и кэшбэком.

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

Еще одно крупное направление моей работы — мобильная платформа «Майти», SuperApp для сотрудников с аудиторией более 50 тысяч пользователей.

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

Каждое приложение имело:

• отдельные механизмы авторизации;

• разные push-инфраструктуры;

• собственные аналитические контуры;

• независимые релизные циклы;

• параллельную реализацию похожих функций.

Технически это работало, а с точки зрения эффективности — нет. Мы создавали один и тот же код дважды. И поняли: проблема не в продуктах, а в отсутствии платформы.

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

Поэтому мы выбрали противоположный путь — не разделение, а объединение. Двигались итерациями:

• создали единый контейнер, где пользователь мог выбрать MAgent или MyWork;

• внедрили единую авторизацию и автоматическое определение роли;

• построили единую главную страницу, где доступная функциональность зависит не от приложения, а от роли сотрудника.

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

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

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

Именно этот сдвиг — от выполнения заказа к созданию возможностей — стал для меня одним из самых важных уроков масштабирования.

Урок пятый: главная работа руководителя — создавать условия

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

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

Это касается всего:

• архитектуры;

• процессов;

• метрик;

• культуры ответственности;

• взаимодействия между командами;

• развития людей.

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

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

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

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

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

Как среда ИТ-хаба помогает расти

В этом году нашему ИT-хабу в Рязани исполнилось 8 лет — этап, на котором мы с гордостью смотрим на пройденный путь и включаем дальний свет.

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

Здесь запускались первые курсы T-Образования, преподавателями которых стали наши сотрудники — лидеры профессий Java и QA. Более трех CTO выросли в нашем хабе.

И самое важное, в Т все определяют люди, а не география. У нас нет ограничений по карьерному росту. Можно драйвить свою траекторию в Рязани так же, как в Москве или Новосибирске, — и влиять на продукты, которые меняют жизнь. Моя история — хорошее подтверждение.

Мы активно вовлечены в локальное ИТ-сообщество. Проводим open-толки и митапы — как в офисе, так и за его пределами. Развиваем молодые таланты: запускаем проектные практикумы под присмотром менторов, помогаем студентам получить реальный опыт и найти свой путь. Большинство сотрудников — выпускники РГРТУ, 90% команды пришли оттуда.

Сейчас в хабе работает более 200 сотрудников. Самые многочисленные стримы — Java и QA.

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

8 лет — это разгон. Впереди новые вызовы, рост, сильное комьюнити и еще больше возможностей для гордости.

Вместо заключения

Когда я пришла в Платформу доставок тимлидом команды из 20 человек, мне казалось, что масштаб — это про больше сервисов, больше инженеров, больше встреч в день. Я ошибалась.

Масштаб — это про другие вопросы:
💡 Не «как сделать», а «как создать условия, чтобы другие могли сделать».
💡 Не «кто отвечает», а «как построить систему, где каждый чувствует ответственность».
💡 Не «что автоматизировать», а «как превратить процесс в платформу».

Я учусь быть тем, кто помогает другим находить ответы. Это некомфортно, часто сопровождается сомнениями. Но именно в этом и состоит рост — не только платформы, но и меня, как руководителя.

Спасибо рязанскому ИТ-Хабу за возможность расти здесь, в городе, где из выпускников вузов растут архитекторы, из тимлидов — CTO, а из идей — продукты, которые меняют жизнь тысяч.

Если у вас был похожий путь, если вы тоже переживали сдвиг от контроля к доверию, от сервиса к платформе, делитесь в комментариях. Всегда интересно слышать, как мы, инженеры и лидеры, проходим этот путь — каждый по-своему.