Как рождаются финтех‑продукты в условиях регуляторики, импортозамещения и вечного дефицита сеньоров, и почему всё держится на одном человеке, который одновременно технарь, наставник и дипломат?

В ИТ‑среде финтех‑компаний давно не редкость услышать: «мы перешли на стримы». Но за этим модным словом скрывается не просто перестановка людей по полочкам. Это попытка совместить несовместимое: скорость стартапа, надёжность инфраструктуры и строгость регулятора. И в эпицентре этого сложного баланса — ИТ‑лидер команды. Он не Scrum Master, не техлид и не просто менеджер проекта. Он — операционный центр кросс‑функциональной команды. Тот, кто превращает бизнес‑идею в рабочий продукт, а хаос требований — в стабильный поток доставки.

Расскажу, как это работает изнутри, на примере реальных процессов в крупной российской финтех‑компании, где стримы — не «buzzword», а повседневная реальность.

Стрим — это не название, а уровень ответственности

Стрим (stream) в нашем контексте — это объединение от 3 до 10 кросс‑функциональных команд, работающих в рамках одного бизнес‑домена или функционального направления. Например: «Альтернативное кредитование», «Цифровой банк» или «Омниканальная поддержка клиента».

Каждая команда — это 7–12 человек:

  • 2–3 системных аналитика;

  • 2–3 бэкенд‑разработчика;

  • 2–3 тестировщика (ручные и автоматизаторы);

  • и ИТ‑лидер во главе.

Сверху — иерархия лидеров:

  • ИТ‑лидер команды →

  • ИТ‑лидер кластера (курирует 3–5 команд) →

  • ИТ‑лидер стрима (отвечает за всё производство в стриме).

Параллельно существует бизнес‑вертикаль:

  • Владелец продукта, он же лидер →

  • Лидер кластера →

  • Лидер стрима (CPO).

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

Три кита ИТ‑лидера: сроки, качество, ресурсы

Если бы потребовалось одной фразой описать суть роли, я бы сказал:

ИТ‑лидер — это тот, кто превращает «сделайте быстро и дёшево» в «вот что мы реально можем — и когда».

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

На выходе — три ключевых артефакта:

  • утверждённая архитектура;

  • чёткий состав MVP (прототипа);

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

И здесь начинается главная работа ИТ‑лидера. Если заказчик недоволен сроками (а это почти всегда), то ИТ‑лидер не говорит «нет», а предлагает компромисс. Он садится с владельцем продукта, и вместе они обрезают функциональность, оставляя ядро ценности. Это не уступка, а совместное принятие реальности.

Важно: ИТ‑лидер не просто «передаёт задачи команде». Он гарантирует, что план выполним при имеющихся ресурсах. И если ресурсов не хватает, то он либо инициирует их перераспределение между командами кластера, либо запускает подбор.

Архитектура: не зритель, а соавтор

Многие считают, что архитектурные решения — удел «архитекторов в башне из слоновой кости». В финтехе это давно не так. Архитекторы действительно «шарятся» на весь стрим (обычно их не меньше двух на стрим), но ИТ‑лидер — обязательный участник архитектурной проработки. Почему? Потому что он знает:

  • какие компоненты уже есть в ландшафте;

  • какие команды могут стать смежниками;

  • где лежат «заминированные» legacy‑модули.

В одном из проектов мы проектировали новую систему в самый разгар импортозамещения АБС. Нужно было, чтобы решение работало и с новой, и со старой АБС на случай срыва сроков миграции. ИТ‑лидер здесь сыграл ключевую роль: он помог архитекторам увидеть реальные точки интеграции, а не теоретические схемы. В итоге система вышла в срок и без переписывания после смены АБС.

Команда — не «ресурсы», а люди. И это важно

В условиях дефицита квалифицированных кадров (а в финтехе он хронический) ИТ‑лидер вынужден работать с тем, что есть, и воспитывать то, чего не хватает.

Во многих крупных финтех‑компаниях есть внутренние школы для джунов. После обучения стримы получают списки потенциальных стажёров. ИТ‑лидер сам решает, кого брать, и берёт на себя роль ментора. Это не формальность. Это регулярные беседы один на один, планирование развития и поддержка в первых «боевых» задачах.

Я лично воспитал не одного специалиста, который теперь ведёт свои команды. И до сих пор убеждён: крепкая команда строится не только на KPI, но и на доверии, общих интересах и живом человеческом общении — от негласных традиций до совместных активностей вне работы. Потому что выгорание начинается там, где исчезает человеческое тепло.

Фильтр, щит и термометр

Одна из самых недооценённых функций ИТ‑лидера — защита команды от внешнего шума.

В финтех‑компании бесконечные запросы от архитектурных комитетов, безопасности, других стримов и регулятора (в нашем случае — ЦБ). ИТ‑лидер — фильтр. Он решает, что доносить команде, а что «гасить» на входе. Его задача — чтобы команда занималась производством, а не бюрократией.

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

Как говорят в одной из моих команд:

ИТ‑лидер — это тот, кто замечает, что тебе тяжело, даже если ты молчишь.

Решения в тумане: когда план рушится, а дедлайн — нет

Ни один крупный финтех‑проект не обходится без сюрпризов. Интеграция с legacy‑системой «вдруг» ломается, регулятор вводит новые требования за неделю до релиза, коллеги из другого стрима не успевают доделать API. В такие моменты ИТ‑лидер принимает тактические решения в условиях неопределённости. Он не ждёт «идеальной информации», а анализирует риски, взвешивает варианты и действует, потому что остановка дороже ошибки.

Но главное — он не оставляет команду одну под огнём. Он берёт ответственность на себя, даже если решение окажется неидеальным.

Цена роли: моральная нагрузка как данность

Успех продукта — это не просто релиз. Это ночи, проведённые с диаграммами зависимостей, отказ от отпуска в пик загрузки, разговоры с родными: «Да, я снова задержусь».

ИТ‑лидер несёт повышенную моральную нагрузку:

  • за сроки — перед бизнесом;

  • за качество — перед архитекторами;

  • за команду — перед каждым её членом.

И всё это без права на публичную панику. Потому что если лидер теряет спокойствие, то команда теряет ориентиры.

Будущее ИТ‑лидера: от производственника к стратегу

Сегодня ИТ‑лидер — в основном «производственник». Завтра он всё больше будет становиться стратегом в миниатюре. Уже сейчас мы видим, как ИИ входит в рабочие инструменты. Например, система для проведения онлайн‑встреч DION автоматически формирует протоколы и заметно разгружает лидеров и аналитиков.

Из‑за повышенных требований к безопасности (особенно в финтех‑компаниях) внешние ИИ‑сервисы пока под запретом. Всё будет строиться на внутренних моделях.

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

Заключение: команда — это отражение лидера

В финтех‑среде легко утонуть в процессах, регламентах и рисках. Но настоящие продукты рождаются там, где есть люди, которые верят в общую цель.

ИТ‑лидер — не тот, кто «управляет». Он — тот, кто создаёт условия, в которых команда может творить, расти и доставлять ценность.

Как я люблю говорить:

Успех — это когда твой продукт используют миллионы. Но настоящий успех — когда твоя команда после релиза не разбегается, а идёт вместе к следующей цели.

А как у вас устроены стримы? Кто — ИТ‑лидер, техлид или что‑то третье? Делитесь опытом в комментариях!

P. S. Статья основана на реальном опыте руководителя стримов в крупной российской финтех‑компании. Имена и проекты обезличены, но боли — настоящие.