В корпоративном кредитовании команды часто живут в двух реальностях. С одной стороны — безупречные бэкенд‑метрики, соблюдённые SLA и работающие по логам процессы. С другой — поддержка, которая ежедневно приносит пачки отзывов «Ничего не работает», и клиенты, которые уходят, потому что «всё сложно» и «непонятно».

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

История 1. Осьминог на кредитном комитете: как мы искали продуктовые идеи с помощью МФО

Полгода назад, подводя итоги 2025 года и формируя цели на 2026‑й, я поставила перед собой задачу разработать продуктовую стратегию — долгосрочный вектор, который можно перевести в конкретные решения для клиентов и бизнеса. В скором времени был и вижен, и стратегия. Но, скорее всего вы знаете, что продуктовая стратегия отвечает на вопрос «Куда мы идём». Также, скорее всего, вы знаете, что она не объясняет, какие именно продукты, сервисы и процессы должны привести нас к этой цели.

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

Эта система координат необходима для качественной работы. Но при поиске новых идей она же может слишком рано включать внутреннего критика, когда во время стандартного брейншторма в команде почти сразу включается конвергентное мышление, в котором участники начинают оценивать предложения ещё до того, как они сформулированы: «Это не пройдёт комплаенс», «Таких данных у нас нет», «Смежные системы не возьмут в работу», «Это слишком дорого». Порой чувствуешь себя Фаустом, разговаривающим с Мефистофелем: «Я — дух, всегда привыкший отрицать».

Но если вам уже надоело просто «допиливать» существующие продукты и хочется выбить команду из шаблонного мышления, попробуйте не обычный брейншторм, а метод фокальных объектов (МФО). Это метод генерации новых идей через перенос свойств случайных объектов на объект, который требуется усовершенствовать.

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

Метод состоит из нескольких последовательных действий:

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

Ключевой момент — случайные объекты не являются готовыми аналогами продукта. Они нужны как источник непривычных свойств.

Давайте покажу на примере.

Сформулировать кейс

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

Кейс сформулировали так: «Как сделать оборотное финансирование для среднего бизнеса более прозрачным, предсказуемым и адаптивным, не ухудшая качество кредитного портфеля и не увеличивая операционную нагрузку на банк?»

Это уже достаточно конкретная задача и задаёт направление поиска.

Дальше задали контекст клиента. К примеру, у нас это была производственная компанию со следующими особенностями:

1. Выручка зависит от сезонности.
2. Закупки сырья нужно финансировать заранее.
3. Отгрузки клиентам происходят с отсрочкой платежа.
4. Часть оборотного капитала заморожена в запасах.
5. Потребность в деньгах меняется в течение года
6. Финансовый директор не всегда понимает, какой объём лимита будет доступен через месяц.
7. Важно своевременно информировать банк об изменениях в бизнесе и не допускать ухудшения качества портфеля.

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

Чтобы идеи не остались разговором, заранее определили, какой результат считаем полезным:

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

Как проходила сессия

Для сессии можно использовать генератор случайных слов, книгу, журнал, карточки или предметы, которые находятся в переговорной. Обычно достаточно трёх‑пяти объектов. Желательно, чтобы они были из разных областей и не напоминали банковские продукты. Например, осьминог, вулкан, гардероб, телескоп, муравейник.

В этой статье разберём один объект — осьминога. Он кажется особенно неподходящим для корпоративного кредитования, а значит, хорошо показывает механику метода.

На первом этапе мы не связываем объект с кредитованием. Просто описываем, как он устроен и как себя ведёт:

• У него несколько щупалец.
• Щупальца могут действовать параллельно.
• Часть нервной системы распределена по телу.
• Он быстро адаптируется к среде.
• Меняет цвет и фактуру.
• Исследует пространство через прикосновение.
• Умеет прятаться
• При угрозе выпускает чернила и меняет сценарий поведения.

Важно не ограничиваться очевидными прилагательными вроде «морской» или «мягкий». Для МФО полезнее свойства, функции и механики:

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

Теперь начинаем переносить признаки на фокальный объект

На оборотное финансирование в нашем случае. У корпоративного клиента редко бывает только одна потребность в ликвидности. Одновременно ему могут требоваться деньги на:

• закупку сырья;
• финансирование запасов;
• исполнение контракта;
• выплату заработной платы;
• закрытие кассового разрыва;
• …
• валютные платежи.

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

Но переносим свойство «Несколько рук работают параллельно, но относятся к одному организму» и вот у нас есть гипотеза параллельных контуров финансирования:

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

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

Примечание. Все свойства рассматривать нет смысла, остановимся на одном.

Как из ассоциации получить проверяемую гипотезу

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

• Какое свойство мы перенесли?
• Как оно могло бы проявляться в продукте?
• Для какого клиента это имеет ценность?
• Какую проблему клиента решает?
• Какие данные или события запускают новый сценарий?
• Что меняется в процессе?
• Какие риски появляются?
• Как проверить идею на небольшом пилоте?

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

Итоговая гипотеза такая: «Для компаний с несколькими параллельными потребностями в оборотном капитале протестировать структуру подлимитов по типам финансирования и сравнить её с единым лимитом по показателям прозрачности использования, скорости выборки, загрузки менеджеров и качества портфеля».

Так случайная ассоциация превращается в объект продуктовой проверки.

Как провести такую сессию у себя

До встречи нужно подготовить:

• описание фокального объекта;
• цель изменений;
• краткое описание клиента и его проблемы;
• список ограничений;
• критерии оценки;
• способ фиксации идей;
• фасилитатора.

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

Этап генерации (45–60 минут):

• представить кейс и объяснить правила;
• выбрать 3–5 случайных объектов;
• выписать свойства каждого объекта;
• переносить свойства на фокальный объект;
• фиксировать все идеи без критики;
• развивать идеи уточняющими вопросами.

Фасилитатору важно останавливать фразы вроде «Это невозможно» и «Так никто не делает». Вместо этого можно спросить:

• «Представим, что это возможно. Как выглядел бы сценарий?»
• «Какую проблему это решает?»
• «Какая часть идеи кажется наиболее ценной?»
• «Что из этого можно проверить без полноценной разработки?»

Этап отбора. После завершения генерации команда возвращается к конвергентному мышлению. Идеи можно оценить по пяти критериям (клиентская ценность, экономика, риск, право/комплаенс, реализуемость).

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

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

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

Ограничения метода

У метода есть несколько ограничений.

• Во‑первых, МФО плохо работает, если кейс сформулирован слишком широко. «Как улучшить корпоративное кредитование?» — плохая постановка. «Как сократить неопределённость клиента при использовании возобновляемого лимита?» — значительно лучше.
• Во‑вторых, случайные объекты должны действительно быть случайными. Если команда заранее выбирает только «полезные» или технологичные предметы, метод быстро превращается в обычную аналогию.
• В‑третьих, нельзя смешивать генерацию и оценку. Если специалист по рискам начинает комментировать каждую идею в момент её появления, команда снова возвращается в конвергентный режим.
• В‑четвёртых, итогом должны быть не просто необычные сочетания, а проверяемые гипотезы. Иначе сессия останется хорошим упражнением на воображение.

Метод фокальных объектов — это не замена рискам и аналитике, а способ отключить внутренний стоп-кран ещё до того, как идея родится. В корпоративном кредитовании мы привыкли сразу искать ограничения, из-за чего часто просто «допиливаем» существующие продукты. Необычные метафоры вроде “осьминога” помогают выскочить из этой колеи и задать неудобные вопросы: “а что, если делать лимиты гибкими”, “ловить сигналы бизнеса раньше отчётности” и уйти от крайностей «всё доступно или всё заблокировано»? Смысл МФО в том, чтобы сначала выбить команду из шаблонного мышления и веером нагенерировать смелых решений, и только потом прогнать их через суровый фильтр корпоративной реальности.

Бонус‑кейсы с воркшопов: идеи, которые «созревали» вместе с рынком

Снятие налички на кассе магазинов

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

Досрочное погашение и онбординг в проблемных точках

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

Жизнь клиента корпоративного кредитования простирается далеко за пределы сервиса. Я хочу дотянуться до клиента дальше, чем сейчас, и сделать его жизнь проще. На таких сессиях может прийти много идей по разным векторам. Не факт, что ты их сразу заберёшь в бэклог делать, но они тебе дадут стимул «на подумать». Вот основная идея этих воркшопов.

История 2. Как сделать CJM, когда оно стоит как крыло от самолёта

Хватит про осьминогов, давайте ближе к привычному — к CJM.

Когда мы начали писать стратегию на будущий год (из предыдущей истории), я подумала: а что, если посмотреть на сервис не как на набор экранов и виджетов, а как на отпечаток какого‑то этапа пользовательского пути и построить CJM: с чем пришёл, зачем и что делает потом.

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

В нашем случае сервис участвует в нескольких этапах жизненного цикла корпоративного кредита:

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

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

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

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

Но наша аудитория — крупный корпоративный бизнес. В реальности это квест уровня «хард»: надо попробовать найти ЛПР какой‑нибудь авиакомпании, пробить стену службы безопасности, а потом, обойдя переносы и отмены, добраться до кабинета с табличкой «Оставь надежду, всяк сюда входящий». И вот твоё исследование умерло, так и не начавшись (но не попало в ад, потому что оно уже там).

А гипотезы и понимание направления развития продукта нужны были команде уже вчера.

Как собрать настоящий путь от триггера до результата, если твоя ЦА — крупный корп?

Ответ: бюджетно.

Однажды я подготовила фрейм в Miro, где накидала сценарии, которые пользователи могут проходить в процессе корпоративного кредитования, внезапно и без объявления собрала 20 человек из команд разработки (свою и смежную) — разработчиков, аналитиков, дизайнеров, — и разбила на группы, раздала этапы и отдала на разграбление два swimlane:

• триггеры и мотивы: какую задачу юзер на самом деле пытается решить?
• действия: что он делает фактически и где страдает от ручного труда?

Этапы кредитного процесса у юрлиц разбиваются на крупные блоки:

• осознание потребности;
• подача заявки, выбор банка для подачи заявки;
• сам старт заявки;
• заключение договора и так далее.

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

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

«Я — казначей, в календаре стоит встреча, чтобы обсуждать инвестиционный проект, и мне, как казначею, нужно примерно понять, сколько средств компания может выбрать в текущий момент и сколько будет стоить финансирование по условиям договора; успеет ли компания получить деньги к дате платежа поставщику?»

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

А потом в этой пьесе появился CFO. И ему не нужен экран, перегруженный деталями каждого транша и всеми графиками погашения, ему нужно понять, может ли компания позволить себе эту сделку и не упрётся ли в ограничения лимита?

Другая команда взяла этап выборки траншей и последующего мониторинга платежей. Они решили разложить этот этап на примере приезда Канье Веста! Смоделировали реальный аврал организатора: от суматошного поиска денег на выкуп билетов и перелёт команды до суровой рутины. На CJM вместо абстрактного шага «выдать кредит» нарисовали карту конкретных вех: отдельный транш под срочную бронь билетов, отдельный — под логистику и поездку. Для каждого этапа в карте четко зафиксировали жизненный повод, дату, подтверждающую бумагу и конкретный источник погашения — например, первые поступления от билетных операторов.

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

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

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

Главный эффект воркшопа

Но главный эффект воркшопа был в другом: мы увидели, насколько по‑разному внутри команды понимаем путь клиента.

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

Два часа воркшопа, на котором я «заставила» команду разработки представить себя на месте клиента — и у нас родилось десяток гипотез. Да, это пока не доказанные факты, а наши коллективные галлюцинации. Но теперь с этим объёмным, живым «монстриком» можно идти валидироваться об реальную ЦА, аналитику и саппорт.

А главный инсайт в том, что мы как раз определяем, что наш сервис далеко не везде достаёт клиента. Это раз. Второе — у клиента могут быть в одном этапе совершенно две разные роли. Например, тот же ЛПР, у которого набор информации для принятия решения отличается от операционного сотрудника, которому нужно работать с операционной выборкой траншей.

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

Ограничения внутреннего воркшопа

Воркшоп нельзя рассматривать как замену реального интервью с клиентом, потому что это некорректно. У внутреннего воркшопа есть серьёзные ограничения:

• команда слишком хорошо знает систему изнутри;
• участники говорят терминами продукта и баз данных, а не бизнеса клиента;
• команда может бессознательно оправдывать неудобные решения;
• внутренние процессы легко принять за пользовательские потребности;
• красивая доска в Miro создаёт иллюзию, что мы уже знаем, как живут клиенты.

Поэтому такая карта не может быть истиной в последней инстанции. Она показывает не «как всё устроено на самом деле», а что команда предполагает и какие гипотезы нужно вынести на проверку.

Но до воркшопа на грумингах звучало «Давайте выведем на экран ещё один финансовый показатель», команда проектировала UI/UX из позиции «Смотрите, сколько у нас данных и что мы умеем», а за спиной тихо строилась фабрика фичей.

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

Сейчас у нас вопросы другие: «Какую задачу этот показатель решает? Для какой роли? На каком этапе? Что человек сделает с ним дальше?»

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

Иногда первый полезный шаг в UX‑исследовании — не бежать сломя голову «в поля», а честно зафиксировать, что именно ваша команда думает о пользователе прямо сейчас. А потом пойти и проверить это на реальных клиентах. Но это уже совсем другая история.

История 3. Как метрика Time to Interactive помогла победить «призрачный» негатив клиентов

Любой крупный финтех — это баланс между идеальной архитектурой и скоростью Time‑to‑Market. Когда‑то давно для запуска сервиса был сделан базовый заявочный процесс:

• клиент оформляет заявку в интерфейсе;
• заявка последовательно проходит через 4 банковские системы;
• на выходе она либо исполняется автоматически, либо попадает на ручную регистрацию сотруднику бэк‑офиса.

Главный нюанс: единой мастер‑системы со сквозной статусной моделью у процесса не было.

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

Последствиями были пачки негативных отзывов от пользователей, которые приносила поддержка, с одной и той же формулировкой — «Ничего не работает!». Если открыть логи, то видно, что заявки уходят, четыре банковские системы по цепочке успешно их обрабатывают, а операции исполняются. По договору у банка есть 2 дня на обработку (SLA), и система железобетонно укладывается в этот срок. Backend‑инженеры рапортуют, что всё штатно.

Но клиентский негатив продолжает расти, а фидбек «Ничего не работает» ясности не добавляет. Если по логам бэкенда всё проходит штатно, значит, проблема возникала ещё до отправки формы?

Как мы сместили фокус с серверных метрик на пользовательский опыт

Мы решили это проверить и сместили фокус с серверных метрик на пользовательский опыт и измерили Time to Interactive (TTI) — но не в классическом смысле общей готовности страницы, а точечно: разницу между моментом отрисовки страницы и моментом отрисовки нужного нам элемента — главной целевой кнопки. То есть не «когда страница в целом стала интерактивной», а конкретно «когда стала кликабельна кнопка, которая ведёт клиента дальше по сценарию».

Результаты замеров — это шок‑контент. Уберите от экранов детей, стажёров и джунов: средний TTI кнопки составлял 18 секунд.

Один час на планете Миллер равен семи годам на Земле. А 18 секунд ожидания кнопки в финтехе — это вечность для нервной системы клиента. За это время человек успевает сделать три глотка кофе, подумать, что страница «зависла» или сайт «сломался», яростно покликать по неактивной кнопке, закрыть вкладку и уйти писать разгневанный отзыв.

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

Что мы нашли в цепочке инициализации

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

Пока этот тяжёлый расчёт не завершался, фронтенд не активировал ключевое действие.

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

Выводы

Не верьте только бэкенд‑логам. Если по метрикам сервера всё «зелёное», это не значит, что пользователь счастлив. Негатив может формироваться на этапе ожидания UI.

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

Отсутствие сквозной статусной модели — не приговор. Даже если у вас нет бюджета на пересборку архитектуры и мастер‑систему статусов, оптимизация первичного взаимодействия (TTI) позволяет закрыть боль клиентов без миллионных инвестиций в бэкенд.

Заключение: что остаётся после таких историй

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

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

Если после этой статьи вы хотя бы раз спросите...:

• «А какую проблему это решает?»
• «Для какой роли?»
• «На каком этапе?»
• «Что человек сделает с этим дальше?» —

…значит, эти истории уже сработали.

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

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

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

Пошаговое встраивание в Python-приложение

1. Подключение библиотеки

Для подключения библиотеки в проект необходимо скопировать в ваш проект файлы обертки (папка bindings), саму библиотеку (папка bin) и конфиг распознавания (папка data-zip с файлом bundle_…se). Обертку и библиотеку нужно подключить в проект:

и импортировать библиотеку:

2. Создание движка распознавания

Движок распознавания создается из конфига распознавания (data-zip/bundle_…se). В параметрах необходимо указать путь к нему и параметр ленивой инициализации (True/False). При значении False все внутренние объекты будут инициализированы сразу не дожидаясь, когда они понадобятся для какой-то конкретной сессии.

3. Настройка распознавания

Настройка распознавания (settings) включает в себя выбор режима распознавания (mode), маски документа (document type masks), а также при желании указание дополнительных опций. Для распознавания документа по одному изображению используется режим singleshot (если документ распознается по нескольким картинкам — default). Для внутреннего паспорта РФ требуется специфицировать маску документа, указав rus.passport.national в доступных к распознаванию документах.

4. Распознавание документа

Сессия распознавания паспорта РФ подразумевает распознавание одного документа (по одному или нескольким кадрам). Для распознавания другого документа создайте новую сессию, настройки можно оставить те же. Создание сессии осуществляется путем указания ранее созданных настроек (settings) и персонализированной подписи (personalized_signature).

Загрузка изображения паспорта РФ по пути (path_to_image):

Распознавание паспорта:

Получение результата:

5. Извлечение информации из результата распознавания

Тип документа

Вывод:

Описание документа

Вывод:

Текстовые поля

Включают все текстовые строки, которые были извлечены с документа

Вывод:

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

Поля изображений

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

Вывод:

Заключение

Как можно убедиться, распознавание паспорта можно легко встроить на Python. На выходе система Smart Engines возвращает структурированный результат, включая текстовые данные, подписи, печати и другие реквизиты и атрибуты документа.

При этом распознавание паспорта на Python – не единственный вариант интеграции Smart ID Engine. Та же библиотека может работать и как часть мобильного или десктоп-приложения, а также прямо в браузерах или мессенджерах. Выбор конкретного варианта зависит от того, какие документы нужно распознавать и откуда поступает изображение – подробнее об этом можно прочитать на сайте Smart Engines.

Реклама. Рекламодатель: ООО «Смарт Энджинс Сервис» ИНН 7728328449, erid: 2W5zFJof1MB

Я никогда так не ошибалась.

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

При этом ТЗ всё ещё не было.

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

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

Хочешь сделать лотерею — думай «как лотерея»

На старте мы знали только одну вещь: клиент должен получить возможность покупать лотерейные билеты внутри мобильного банка. Всё остальное было как в тумане.

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

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

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

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

В лотерее главное — ожидание

Именно тогда в проекте появился эмоциональный CJM. Если обычный клиентский путь отвечает на вопрос «что делает клиент», то эмоциональный пытается ответить на вопрос «что он чувствует». Для лотереи эта разница оказалась принципиальной. Человек покупает не набор цифр и даже не шанс на выигрыш. Он покупает надежду, ожидание и эмоциональный опыт.

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

Но дальше начинался длинный период ожидания.

Чем ближе был тираж, тем сильнее рос интерес, а вместе с ним количество вопросов: когда розыгрыш, где его посмотреть, как я узнаю результат? После тиража возникала уже другая потребность: как можно быстрее снять неопределенность и понять, выиграл я или нет?

Мы буквально наносили эти эмоциональные состояния на каждый этап CJM и смотрели, где продукт оставляет клиента один на один с ожиданием.

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

Все остальное время клиент ждет: ждет тираж, ждет результаты, ждет уведомление, ждет выигрыш. Получалось, что основная часть клиентского опыта строится вокруг ожидания(?)

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

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

Закон — это база для требований

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

Однако очень быстро стало понятно, что нормативные документы являются не ограничением, а полноценным источником требований.

Одним из основных источников требований стал Федеральный закон 138-ФЗ «О лотереях». Например, именно из законодательства и условий проведения конкретной лотереи мы выясняли, что покупатель становится участником лотереи сразу после оплаты и оформления лотерейного билета, какие обязанности возникают у распространителя: от условий участия и онлайн-распространения билетов до правил выплаты выигрышей и работы с данными участников.

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

И тут выяснилось неожиданное: привычного нам сценария «отменить покупку» здесь просто нет.

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

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

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

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

• Нужно ли идентифицировать клиента?
• Какая у него налоговая ставка?
• Является ли он налоговым резидентом?
• Какой доход он уже получил с начала года?
• Кто выступает налоговым агентом?
• Какие данные необходимо получить из внутренних систем банка?
• Какие документы нужно сформировать?
• Какие данные передать партнеру?
• В какой момент считать выплату завершенной?

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

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

Еще одной областью, которая неожиданно ворвалась в проект, стала фискализация — требования Федерального закона 54-ФЗ о применении контрольно-кассовой техники. До работы над Альфа-Манией я, как и многие, воспринимала онлайн-кассы как что-то существующее где-то рядом с бухгалтерией и налоговой отчетностью. Однако очень быстро выяснилось, что чек является такой же частью клиентского опыта, как экран оплаты или push-уведомление. Нужно понимать, в какой момент формируется чек, кто отвечает за его выпуск, какие реквизиты должны передаваться, как обрабатываются ошибки и что происходит в нестандартных сценариях.

В результате обсуждение требований 54-ФЗ стало занимать в календаре не меньше места, чем обсуждение мобильных интерфейсов.

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

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

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

Это была статья про Discovery

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

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

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

А лучший способ проверить, что получилось из пяти месяцев Discovery, сотен требований и десятков интеграций, — пройти этот клиентский путь самостоятельно. Так что заходите в Альфа-Манию, покупайте билетик и, конечно, удачи в тираже :)

И, если получится, про то, как финтех сделал свою лотерею, я расскажу в следующей статье. Не переключайтесь.

Реклама. Рекламодатель: АО "АЛЬФА-БАНК" ИНН 7728168971, erid: 2W5zFGzLAg1

Потом проект вырос, в команду пришли ещё люди, и стало понятно: этот красивый монолит пора разделять.

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

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

Как говорил один мой коллега, перефразируя классическое “вам шашечки или ехать”:

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

Половина нужна только Android, другая только iOS. Но метод один. Потому что так более по программистцки, как написано в каждой второй статье про архитектуру автотестов.

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

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

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

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

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

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

Локаторы: работай с тем, что дают

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

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

OpenCV - есть ещё вариант с распознаванием элементов по картинке. Для некоторых кейсов реально выручает. Но это отдельная тема на целую статью, может напишу потом.

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

Я не топлю за то, что кроссплатформенный фреймворк абсолютное зло. Есть ситуации, где он работает:

Приложение простое, пара экранов, стандартные контролы, минимум кастомного UI.

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

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

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

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

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

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

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

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

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

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

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

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

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

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

В итоге миграцию свернули, потратив около десяти человеко-месяцев и потеряв доверие бизнеса. Сервис до сих пор работает в исходной реализации, а команда переходит к плану, описанному ниже.

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

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

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

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

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

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

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

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

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

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

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

Feature toggles: как включать новую логику без риска

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

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

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

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

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

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

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

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

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

Например, есть старый модуль расчета скидок. Он учитывает промокоды, сегмент пользователя, историю покупок, регион и партнерские условия. Команда пишет новый сервис скидок. Чтобы не переключать пользователей сразу, можно запустить теневой режим:

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

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

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

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

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

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

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

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

Миграция данных: самая сложная часть

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

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

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

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

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

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

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

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

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

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

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

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

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

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

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

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

Пример: как тот же сервис мигрировали со второй попытки

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

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

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

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

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

Типичные ошибки при работе с legacy

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

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

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

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

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

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

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

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

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

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

Когда Strangler Fig особенно оправдан

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

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

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

Когда модернизацию лучше не делать

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

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

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

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

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

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

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

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

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

Всё началось с безобидного, почти рутинного тикета в саппорт:

«У меня тут несколько одинаковых карт создалось. Я вроде один раз нажимал, а их штук пять висит в приложении».

Для финтеха подобная фраза — не мелкая UI-аномалия, а сигнал тревоги высшего уровня. Когда речь идёт о платёжных инструментах, дубль сущности мгновенно переходит из разряда «странностей» в категорию «полноценный инцидент».

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

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

Мы начали разбираться. Стандартный мониторинг показывал норму: дашборды зелёные, в логах тихо, метрики CPU и памяти без отклонений. При этом в базе обнаруживались дубликаты, которых быть не должно. И только тогда, когда мы внимательно посмотрели на коммунальный API Gateway, то поняли что одно изменение от другой команды поменяло идемпотентность работы endpoint-а.

Проблема была структурно невидима для тех, кто находился ближе всего к ней. Отсутствие видимой проблемы не равно отсутствию риска — система просто ждала подходящего момента.

Что произошло: хронология инцидента

Архитектура была классической: Клиент → API Gateway → микросервисы,.

Сценарий развивался почти незаметно для стандартных средств наблюдения:

1. Фронтенд: Пользователь нажимает кнопку «Выпустить карту».

2. Gateway: Запрос начинает обрабатываться в API Gateway.

3. Микросервис по созданию карт: честно выполняет работу: создаёт запись в БД и возвращает `200 OK` в Gateway.

4. Новый микросервис: API Gateway вызывает новый микросервис и получает HTTP 500 в ответ от него. Исключение возникает уже после успешного вызова нашего микросервиса, и это ключевая точка разрыва: Gateway считает весь запрос неудавшимся, а ответ нашего микросервиса теряется.

5. Клиент: получает HTTP 500

6. Реакция: Пользователь видит красную плашку ошибки и логично решает: «Не сработало, пробую снова». Более того, с точки зрения протокола HTTP - запросы, в ответ на которые пришла ошибка HTTP 500, можно пытаться отправлять опять.

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

Круг замкнулся. Эпидемия началась.

В компании такого уровня это не было предусмотрено. И это такая обидная ошибка.

Как так получилось?

Вскрылось ошибочное предположение:

«В API Gateway вызов микросервиса создания карт всегда идет последним».

Таким образом идемпотентность достигалась «формально» - ведь если создание карты завершалось с ошибкой - это точно означало что и вызов API Gateway тоже завершится с ошибкой. Сработало ложное чувство безопасности.

Ответ на вопрос “почему так было сделано?” очень простой - это было осознанное упрощение на старте. Все знали об этом, но задача на фикс потерялась в недрах бэклога на очень долгое время. Это классический пример того, как архитектурное допущение и отложенный рефакторинг годами живут в проде, пока их не вскрывает редкая последовательность отказов.-

Что потребовалось изменить

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

FAQ: Часто задаваемые вопросы

1. Почему нельзя просто заблокировать кнопку на фронте?

Блокировка кнопки решает проблему только при стабильной сети. Если запрос ушёл, сервер создал сущность, но ответ потерялся — кнопка разблокируется по таймауту, и пользователь нажмёт снова. Это не устраняет корневую причину, а лишь слегка снижает вероятность дубля.

2. Чем идемпотентность отличается от дедупликации в БД?

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

3. Как долго хранить ключи идемпотентности?

На практике мы хранили ключи в основной базе данных без ограничения срока — затраты на хранение UUID по всем сущностям оказались небольшими. В общем случае минимальный срок зависит от конкретных сценариев использования — кому-то хватит и часа, а кому-то нужна неделя. В любом случае, окна должно быть достаточно, чтобы покрыть сценарии, когда пользователь возвращается к повтору запроса, например, на следующий день или когда клиентское приложение автоматически перезапускает отложенные запросы после восстановления сети. Бессрочное хранение не обязательно, но слишком короткий TTL создаёт риск дублей при длительных сетевых проблемах.

4. Что делать со старыми клиентами, которые не шлют request_id?

Мы сделали несколько версий API для создания карт — под разные версии приложения. Для новых клиентов работала полноценная идемпотентность с клиентским ключом. Для старых версий приходилось принимать риски и генерировать request_id на стороне сервера. Альтернативой может быть хэширование payload запроса, но это менее надежно и сложнее: таймстемпы и случайные поля могут отличаться от вызова к вызову. Поэтому мы выбрали подход с генерацией ключа на сервере для устаревших клиентов: риски дублей на переходный период оказались меньше, чем сложность поддержки двух схем валидации одновременно.

5. Обязательно ли делать идемпотентность для всех методов API?

Идемпотентность требуется только для методов, которые изменяют состояние системы — POST, PUT, PATCH и иногда DELETE. Методы чтения (GET, HEAD, OPTIONS) не изменяют данные, поэтому считаются идемпотентными по умолчанию.

6. Как понять, что в вашей системе уже есть скрытая проблема с дублями?

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

Если метрик ещё нет, вот три косвенных признака, которые помогут заподозрить неладное:

• В базе данных периодически появляются записи с одинаковым содержимым, созданные с разницей в несколько секунд.
• Пользователи жалуются на дубликаты карт, заказов или платежей, но вы не можете воспроизвести проблему локально, списываете на то, что пользователи что-то делают не так
• В логах API Gateway периодически всплывают HTTP 500 ошибки, но downstream-сервисы при этом отрабатывают успешно.

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

Итог

Главный урок, который мы вынесли: идемпотентность — это общая ответственность всех команд разработки, и поломать её может быть проще, чем кажется. А добавить в уже работающую систему быстро и дёшево — почти невозможно.

Метрик на всплески повторных запросов у нас не было. А зря — это самый дешёвый способ увидеть проблему до того, как она обрушит продакшен. Системы, спроектированные на 10% нагрузки, ломаются на 60% — и обычно это становится неожиданностью для команды.

Практический чек-лист: что проверить в своей системе уже сегодня

• Убедитесь, что все критические мутирующие эндпоинты поддерживают ключ идемпотентности.
• Настройте алерты на аномальное количество запросов на создание сущностей от одного пользователя за короткий промежуток времени.
• Проверьте, как ваш API Gateway обрабатывает ошибки — не теряет ли он ответы downstream-сервисов.
• Убедитесь, что фронтенд корректно обрабатывает не только 200, но и 500, 502, 504, не провоцируя пользователя на повторные клики без необходимости.

Эксперты Centicore Group собрали чек-лист из 12 пунктов, которые реально работают при выборе интегратора, а когда у вас станет вопрос подрядчика – вы можете воспользоваться этим списком.

1. Опыт в вашей индустрии

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

Что проверять:

1. Портфолио с проектами в вашей сфере. Нужны конкретные кейсы: что делали, какой стек, какие результаты.
2. Понимание специфики. Если интегратор сразу задаёт правильные вопросы про ваши бизнес-процессы — хороший знак. Если предлагает типовое решение без погружения в специфику — советуем искать дальше.
3. Измеримые результаты. Везде понятные показатели: на сколько сократили время обработки заявок, сколько проект занял по времени, какая команда специалистов и к чему в итоге пришли.

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

2. Что по техстеку и обновлениям

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

На что смотреть:

1. Соответствие вашему контуру. Если у вас закрытый on-premise, а подрядчик умеет деплоить только в публичные облака — вам не по пути.

2. Релевантные сертификаты и лицензии. Если делаете финтех — нужен опыт прохождения PCI DSS. Если работаете с госсектором или персональными данными — ищите подрядчика с лицензиями ФСТЭК и ФСБ.

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

4. Геополитические и санкционные риски. В 2026 году для российского рынка это один из ключевых рисков. Что здесь нужно проверять:

• Зависимость от иностранных облаков и компонентов.
• Отдельно open-source библиотек и фреймворков с высокой санкционной уязвимостью.
• Наличие у подрядчика плана «Б» на случай новых ограничений (альтернативные поставщики, российские облака, on-premise).
• Опыт работы с проектами, которые уже проходили через санкционные ограничения.

Красный флаг: Подрядчик говорит «у нас всё на AWS и мы не видим в этом проблемы» или не может ответить, как будет развивать систему при усилении ограничений.

5. Отношение к ИИ-инструментам и low-code решениям. В 2026 году почти все интеграторы так или иначе используют ИИ (Cursor, GitHub Copilot, Claude, внутренние агенты). Важно понимать политику компании. Что проверять:

• Есть ли у подрядчика регламент использования ИИ-инструментов (что разрешено, что запрещено, как проверяется код, сгенерированный ИИ).
• Насколько активно они применяют low-code/no-code платформы и как это влияет на качество и поддержку решения.
• Готовы ли они комбинировать ИИ + ручную разработку или полностью полагаются на «ИИ всё сделает».
• Есть ли у них экспертиза по prompt engineering и проверке качества ИИ-генерируемого кода.

Красный флаг: Подрядчик либо полностью игнорирует ИИ («мы всё пишем руками»), либо говорит «мы всё делаем через ИИ и это в 10 раз быстрее» без упоминания проверок и рисков.

3. Насколько гибкие в разработке

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

Что важно:

1. Подход к кастомизации показывает философию компании. Если подрядчик сразу говорит о готовом решении и предлагает подстроить бизнес-процессы под него — это провал для специфичных задач. Подбор решения под клиента, а не наоборот — признак зрелого подхода.
2. Работа с изменениями — реальность любого проекта. Требования меняются в процессе, это нормально. Agile не на словах, а на деле означает готовность пересмотреть приоритеты, адаптировать бэклог, обсуждать изменения.
3. Понимание бизнес-задачи отличает хорошего интегратора от посредственного. Технари часто зацикливаются на том, как реализовать, забывая спросить, зачем это нужно. Вопрос о том, какую проблему решает функция, должен звучать чаще, чем обсуждение технологии.

Спросите, как подрядчик работает с меняющимися требованиями в середине спринта. Если ответ сводится к пунктам контракта и доп.оплате — это может быть, но для начала лучше обсудить приоритеты и найти компромисс.

4. Прозрачность процессов

Вы должны понимать, что происходит на проекте в любой момент.

Как оценить прозрачность:

1. Структура коммуникации определяет скорость решения вопросов. Кто ваш контакт — менеджер без технической экспертизы или техлид команды? Как быстро получаете ответы? Есть ли прямой доступ к разработчикам для обсуждения технических деталей?
2. Регулярная отчётность — это не бюрократия, а инструмент контроля. Демо каждый спринт, доступ к таск-трекеру вроде Jira, понимание прогресса в реальном времени. Компании с 24/7 поддержкой обычно имеют настроенные процессы коммуникации и реагирования.
3. Документация показывает зрелость процессов. Если подрядчик не может показать примеры технической документации, процессов разработки, архитектурных решений — это тревожный звонок.
4. Совпадение ценностей и корпоративной культуры. Технические навыки важны, но если ценности не совпадают — проект будет постоянным источником конфликтов. Попросите пообщаться не только с техлидом, но и с 1–2 разработчиками, которые будут работать над проектом. Задайте вопросы про их реальный опыт работы в компании. Что проверять:

• Отношение к удалённой работе и овертаймам (есть ли культура «гореть на проекте» или уважают work-life balance).
• Прозрачность внутри компании (как принимаются решения, насколько открыто руководство общается с командой).
• Отношение к качеству vs скорость (готовы ли отказываться от «быстрых костылей» ради долгосрочного результата).
• Корпоративные ценности: как компания относится к клиентам, к сотрудникам, к этике в разработке.

Красные флаги:

1. Вам говорят, что всё хорошо, но конкретики нет. Нет демо, доступа к репозиторию, промежуточных результатов. А потом в день дедлайна выясняется, что половины функционала нет. Нормальная практика — давать клиенту видимость работы: задачи, коммиты, тесты.
2. Проводите демо результатов каждые 1-2 недели. Так будете видеть рабочий код, сможете проверить функционал, задать вопросы напрямую техлиду. Ошибки дешевле исправлять на ранних этапах, чем в продакшене.
3. Команда говорит одно на собеседовании, а на деле — жёсткий overtime, токсичная культура и «мы просто кодим, а менеджеры решают».

5. Команда и культура разработки

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

Что проверять:

1. Квалификация разработчиков определяет скорость и качество работы. Соотношение мидлов и сеньоров в команде показывает, кто будет делать архитектурные решения, а кто — рутинные задачи. Если в команде только джуны под управлением одного сеньора — это риск.
2. Текучка кадров — критический показатель стабильности. Высокая текучка означает проблемы: либо с зарплатами, либо с управлением, либо с атмосферой. Всё это отразится на вашем проекте.
3. Практики разработки видны в деталях. Code review, автоматизированное тестирование, CI/CD — это страховка от багов в продакшене. Спросите, как организован процесс: делают ли ревью кода, какое покрытие тестами, как часто деплоят.

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

6. Пост-интеграционная поддержка

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

На что смотреть:

1. Гарантии и доработки. Что будет, когда система упадет из-за архитектурной ошибки вендора? Условия фикса багов и доработок после релиза должны быть зафиксированы в контракте.
2. Контроль ответственности. Должно быть четко расписано, где заканчивается зона ответственности интегратора и начинается зона ваших админов, девопсов или первой линии поддержки.
3. Документация и передача знаний. Подрядчик обязан выгрузить не только исходники, но и актуальную документацию: ADR (архитектурные решения), схемы инфраструктуры, регламенты развертывания.

Юридическая и договорная часть. Условия расторжения договора и стратегия. Кто владеет кодом и данными после завершения проекта. Штрафы за срыв сроков и SLA. Право на аудит кода и инфраструктуры.

7. Безопасность и комплаенс

1. Проверяйте сертификаты и стандарты: ISO 27001 по информационной безопасности, соответствие ФЗ-152 о персональных данных, отраслевые стандарты вроде PCI DSS для платёжных систем.
2. Пентесты, аудит кода на уязвимости, шифрование данных, управление доступами — всё это должно быть в процессе по умолчанию.
3. Убедитесь, что контракт чётко прописывает, кому принадлежит код, как защищаются ваши данные, какие санкции за утечку.

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

8. Реальные кейсы и рекомендации

Самый очевидный и простой способ проверить подрядчика — поискать в открытом доступе упоминания и кейсы в медиа или на специальных площадках. Вот на что смотреть:

1. Соблюдение сроков — классический больной вопрос IT-проектов. Уложились ли в первоначальные оценки? Если были задержки — как объясняли и решали?
2. Работа с изменениями — насколько гибко подрядчик реагировал на новые требования? Были ли конфликты по поводу доп.функционала?
3. Качество коммуникации — как быстро отвечали, насколько понятно объясняли технические вещи, был ли прямой контакт с командой?
4. Пост-поддержка — что происходило после запуска? Быстро ли реагировали на проблемы? Помогли ли с развитием продукта дальше?

9. Финансовая прозрачность

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

На что смотреть:

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

Красные флаги:

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

10. Масштабируемость решения

Интегратор не сдает вам в аренду серверы, поэтому он должен спроектировать систему так, чтобы при х10 росте нагрузки вам не пришлось переписывать ядро, менять СУБД или сносить весь проект.

1. Проектирование под рост бизнеса отличает стратегическое мышление от тактического. Хороший интегратор спросит о ваших планах: сколько пользователей сейчас, сколько планируется через год, через три года. И заложит архитектуру с запасом.
2. Постепенное расширение функционала дешевле полной переделки. Модульная архитектура, микросервисы, API-first подход — всё это позволяет добавлять новые возможности без переписывания существующего кода.
3. Управление техническим долгом. Любая разработка накапливает технический долг: быстрые решения, костыли, устаревшие зависимости. Профессионалы планируют рефакторинг, выделяют время на улучшение кода, следят за обновлениями библиотек.
4. Vendor lock-in и технологическая независимость. Хороший интегратор не строит систему так, чтобы вы навсегда зависели от его экспертизы, конкретного облака или проприетарного инструмента. Проверяйте: на каких лицензиях работает стек, можно ли сменить подрядчика без переписывания системы, кто владеет кодом и есть ли возможность развивать продукт силами инхаус-команды.

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

11. Скорость и качество коммуникации

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

1. Время отклика на первый запрос — если на ваше обращение отвечают через неделю — представьте, как будет идти коммуникация в процессе проекта.
2. Интегратор должен задавать вопросы не только про технические требования, но и про то, какую проблему бизнеса решает система. Это показывает стратегическое мышление.
3. Хороший подрядчик не просто делает, что сказали, а предлагает улучшения: как сделать эффективнее, дешевле, быстрее. Это требует глубокого понимания вашего бизнеса.

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

12. Репутация на рынке и стабильность

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

Что оценивать:

1. Время на рынке — один из положительных сигналов, но не гарантия. Компании с опытом 8+ лет, как правило, пережили кризисы, накопили экспертизу и выстроили процессы. Но возраст сам по себе не означает качество: проверяйте кейсы, репутацию и стабильность команды, а не только дату основания. Стартапы могут быть инновационными — просто риски у них другие.
2. Финансовая устойчивость проверяется косвенно: по масштабу проектов, количеству офисов, размеру команды.
3. Участие в профессиональных мероприятиях показывает открытость. Компании, которые выступают на конференциях, пишут статьи, делятся опытом, обычно уверены в своей экспертизе. Это также помогает проверить репутацию через знакомых в индустрии.
4. Партнёрские отношения с крупными вендорами — ещё один индикатор.

Проверка на негатив:

• Поищите упоминания компании в негативном контексте: судебные споры, публичные конфликты с клиентами, жалобы сотрудников. Одна претензия — не приговор, но если их много — стоит задуматься.
• Отсутствие следов в интернете тоже настораживает. Нормальная IT-компания в 2026 году должна быть видна: сайт, соцсети, публикации, упоминания в медиа.

Как использовать чек-лист

1. Первичный скрининг отсекает неподходящих кандидатов. Пройдитесь по критичным пунктам: опыт в индустрии, технологический стек, безопасность, репутация. Если есть красные флаги — не тратьте время на глубокую оценку.
2. Глубокое интервью для финалистов. Возьмите 2-3 компании, которые прошли скрининг, и проверьте остальные пункты детально. Встречи с командой, разбор кейсов, общение с референсами, обсуждение процессов.
3. Пилотный проект снижает риски. Перед большим контрактом протестируйте подрядчика на небольшой задаче. Это покажет реальное качество работы, скорость коммуникации, соблюдение договорённостей. Дешевле потратить месяц на пилот, чем год на исправление ошибок.

Чек-лист работает, когда применяете его последовательно. Не пропускайте пункты, которые кажутся очевидными — именно там часто скрываются проблемы. И помните: идеального подрядчика не существует. Важно найти того, чьи сильные стороны совпадают с вашими приоритетами, а слабые — не критичны для проекта.

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

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

Если вы технический директор или фаундер ИТ-компаний, которым нужен надёжный подрядчик для реализации проекта из финтеха, госсектора или нефтегаза — тоже найдёте решение.

Постановка задач и бизнес-требования

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

Госсектор: когда ГОСТы встречаются с CJM

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

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

Поэтому сейчас ИТ-команды в госах всё чаще занимаются проработкой клиентских путей (Customer Journey Map, CJM). Инженерная задача — это не просто закодить фичу, а умудриться соединить удобный современный пользовательский интерфейс (UI) с соблюдением требований ГОСТов, Гостеха и законодательства о защите персональных данных (ИСПДн).

Нефтегаз: цена ошибки и жизнь без права на фейл

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

Именно из-за таких рисков ИТ-команды в нефтегазе сейчас в основном работают на вспомогательных процессах: делают HR-сервисы, логистические системы и модули информационной безопасности. Этот сегмент стабильно растёт на 8% в год. Разработка здесь означает создание максимально надёжных внутренних инструментов с требованиями к отказоустойчивости. Любая, даже самая мелкая гипотеза проверяется в жёстко изолированной среде до выкатки в продакшен.

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

Финтех: когда разработчик становится экономистом

В финтехе всё диктует регуляторика. Постановления ЦБ, расчёт макропруденциальных лимитов (МПЛ), показателей долговой нагрузки (ПДН), интеграция антифрод-систем — всё это не настройки на потом, а основа бизнес-логики.

Места для свободного манёвра мало

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

Инфраструктура и безопасность

Представьте, что вы привыкли по клику раскатывать контейнеры в облаке, качать любые библиотеки из npm и сразу проверять гипотезы без долгого согласования. А теперь забудьте об этом. В энтерпрайзе то, что в продуктовом стартапе кажется паранойей, считается базовым гигиеническим минимумом. И если вы думаете, что безопасность — это просто настроить VPN и закрыть пару портов, то добро пожаловать в реальный мир.

Госсектор: как поженить ГОСТы и нейросети

На бумаге всё красиво: заказчики хотят модные сайты, удобные личные кабинеты и мобильные приложения. По факту — работают в реалиях, где основное требование — соответствие ГОСТам, Гостеху и ИСПДн (законодательство о защите персональных данных). Главная боль разработчика здесь — это соединить современный диджитал с требованиями безопасности. На выходе должен получиться легитимный сервис с техпроектом и документацией.

Использовать внешние API нельзя

Вы не можете просто скормить код ChatGPT, потому что за отправку данных госоргана на внешние сервера по головке не погладят. Нужно разворачивать опенсорсные LLM прямо on-premise, внутри закрытого контура заказчика. Чаще всего в ход идут Llama и её производные, либо отечественные решения от Сбера и Яндекса. Модели дообучаются на локальных конфиденциальных датасетах. Чтобы никто, случайно или специально, не слил данные наружу, выстраивается ML-шлюз. Отдельная языковая модель ставится прямо на пути всех исходящих API-запросов из внутреннего контура во внешний мир. Если какой-нибудь сотрудник или смежный сервис формирует запрос к внешней нейросети, и локальная модель распознаёт в промпте что-то, хотя бы отдалённо похожее на конфиденциальную информацию, она не разрешает выполнить этот запрос. Нужно аппаратно и программно фильтровать ИИ-трафик другим ИИ.

Нефтегаз: разработка в абсолютном вакууме

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

Вам придётся забыть про привычные среды

Разработчики массово перекатывают сервисы на отечественные Linux-дистрибутивы: RedOS, AltLinux, AstraLinux. Любимые СУБД меняются на MariaDB и PostgreSQL.

Всё работает исключительно через демилитаризованные зоны (DMZ). Весь ваш код, все пайплайны хранятся и собираются в локальных инстансах GitLab, у которых вообще нет выхода во внешний интернет. При этом регулярно прилетают обязательные пакеты обновлений от ФСТЭК, которые влияют не только на ядро операционки, но и на прикладные компоненты.

Финтех: микросервисы и оркестрация

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

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

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

Вы завязаны на работу соседних команд

Если у коллег отвалился API, изменился формат ответа или они выкатили релиз без обратной совместимости — ваш функционал ложится вместе с ними. Добавьте сюда жёсткие требования регулятора по расчётам ПДН (показатель долговой нагрузки) и МПЛ (макропруденциальные лимиты), интеграцию которых нужно проверять на каждом этапе. Безопасность в финтехе — это многоуровневая криптография и непрерывный мониторинг аномалий на уровне каждой транзакции. Потому что здесь потерянный байт или упавшая интеграция — прямые финансовые потери банка и штрафы от регулятора.

Внедрение ИИ и новых технологий

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

Госсектор: генерация бюрократии и предиктивная аналитика

С распространением нейросетей в ведомствах появился совершенно новый класс инженерных задач. По статистике Centicore Group практически в каждом новом проекте для государственных структур есть модули на базе машинного обучения. При этом востребованы не универсальные облачные чат-боты, а узкоспециализированные решения, которые разворачиваются строго on-premise, на серверах заказчика. Чаще всего под капотом используются открытые языковые модели семейства Llama, а также адаптированные российские аналоги от Яндекса и Сбера.

С какими конкретными задачами здесь сталкиваются разработчики?

1. Создание генераторов технической документации. На практике процесс выглядит так: системный аналитик нажимает кнопку, передаёт короткое описание задачи, а нейросеть автоматически генерирует две страницы полноценных требований, написанных сухим, регламентированным бюрократическим языком.
2. Внедряется сложный нейропоиск по внутренним базам нормативно-правовых актов (НПА), где классический полнотекстовый поиск уже не справляется с объёмами данных.
3. Разрабатываются специализированные ИИ-консультанты для сферы закупок. В систему загружается техническое задание (ТЗ), а алгоритм сам подсказывает сотруднику нужный код классификатора ОКПД-2 для корректного оформления заявки.

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

Нефтегаз и крупное производство: компьютерное зрение вместо текстов

Промышленный энтерпрайз массово закупает и внедряет системы компьютерного зрения (CV). Глубокий анализ коммерческих тендерных площадок показывает, что до 80% всех запросов на искусственный интеллект в этом секторе приходится именно на сложную работу с видеопотоком.

Типовые сценарии для бэкенд-разработчика и ML-инженера здесь выглядят иначе. Камера, установленная на производственной линии, в реальном времени должна отслеживать бракованную деталь (например, дефектную бутылку на движущемся конвейере) или непрерывно контролирует правильность выкладки товара на физических витринах. При обнаружении любой аномалии бэкенд должен не просто записать лог, а автоматически сформировать полноценный инцидент в корпоративной CRM-системе и отправить пуш-уведомление ответственному администратору.

Ещё одна массивная задача в отрасли — OCR (оптическое распознавание символов). Речь идёт о потоковом распознавании сканов первичной документации абсолютно любого, даже нестандартного формата, с автоматической нормализацией и отправкой извлечённых данных напрямую в базы 1С.

Финтех: сложная аналитика конверсий

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

Матрица выбора для ИТ-специалиста

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

Выбирайте нефтегаз, если:

• Вы готовы писать и собирать код в полностью изолированных сетевых контурах через демилитаризованные зоны (DMZ).
• Вас совершенно не пугает деплой через локальные инстансы GitLab, у которых напрочь отрезан любой доступ к внешнему интернету.
• Вы готовы своими руками переводить огромный серверный парк на AstraLinux, RedOS, AltLinux и поддерживать работу с СУБД MariaDB и PostgreSQL.
• Долгий цикл релиза вас не демотивирует, потому что вы понимаете: цена ошибки на реальном промышленном производстве недопустимо высока.
• Вам профессионально интереснее интегрировать прикладное компьютерное зрение (CV) для выявления брака на конвейерах, чем развёртывать генеративные текстовые чат-боты.

Выбирайте госсектор, если:

• Вы предпочитаете работать по чётким, детально задокументированным ТЗ, а не пытаться угадать размытые продуктовые требования бизнеса.
• Вам интересна нетривиальная архитектурная задача: как органично соединить современный пользовательский UI с жёсткими требованиями Гостеха и ИСПДн.
• Хочется на реальной практике разворачивать on-premise LLM (решения семейства Llama, Яндекса, Сбера) внутри защищённых периметров.
• Вас привлекает идея настраивать ML-шлюзы для автоматической фильтрации трафика и защиты корпоративных контуров от утечек.
• Интересна автоматизация бюрократии: разработка умного нейропоиска по базам НПА, потоковая генерация документов и ИИ-подбор кодов ОКПД-2.

Выбирайте финтех, если:

• Вы готовы прямо на проекте глубоко разбираться в расчётах МПЛ, ПДН и банковских алгоритмах досрочного погашения.
• Вас не пугает, что жёсткая, бескомпромиссная регуляторика ЦБ ложится в основу абсолютно каждой технической задачи в бэклоге.
• Вы умеете проектировать и поддерживать сложную, высоконагруженную микросервисную архитектуру, где каждый изолированный фронтовый сервис интегрирован с десятками смежных систем (скорингом, антифродом, базами кредитных историй).
• Вам интересна архитектурная работа с цифровым рублём — масштабная переработка флоу транзакций и внедрение новых сущностей в реляционные базы данных.

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

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

Чтобы успешно выкатить продукт в таких реалиях, недостаточно просто уметь писать чистый код. Нужна команда, которая знает, как легально протащить релиз через DMZ, развернуть on-premise LLM без риска утечек и завернуть современный пользовательский интерфейс в требования Гостеха и ИСПДн. Если вашему бизнесу предстоит сложный проект в госсекторе или промышленном энтерпрайзе, специалисты Centicore Group готовы реализовать его под необходимые требования.

ИИ и увольнения: реальная причина сокращений или корпоративное оправдание?

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

Осторожное начало: как компании избегали темы ИИ и сокращений

Когда генеративные ИИ-инструменты по типу ChatGPT начали стремительно распространяться в 2022–2023 годах, компании крайне осторожно обсуждали их влияние на занятость. Одни полностью избегали этой темы, опасаясь общественного резонанса. Другие настаивали, что ИИ не имеет отношения к их решениям о сокращении персонала. Например, в первые годы внедрения таких технологий руководители подчеркивали, что ИИ используется для автоматизации рутинных задач, а не для замены сотрудников.

Однако к 2025 году риторика изменилась. Компании начали открыто признавать связь между внедрением ИИ и сокращениями. Такие организации, как Accenture, Salesforce, Klarna, Microsoft и Duolingo, заявили, что оптимизация процессов с помощью ИИ позволяет им снизить затраты, повысить эффективность и, как следствие, сократить штат. Например, Accenture упоминала использование ИИ для автоматизации задач в консалтинге, а Duolingo отмечала, что ИИ помогает создавать контент быстрее, уменьшая потребность в некоторых ролях.

ИИ как удобное оправдание?

Фабиан Стефани, доцент кафедры ИИ и труда Оксфордского интернет-института, в интервью CNBC выразил сомнения в том, что текущие сокращения действительно вызваны технологическими прорывами. «Я очень скептически отношусь к тому, что нынешние увольнения связаны с реальными достижениями в эффективности благодаря ИИ. Скорее, это использование ИИ как оправдания для сокращений», — отметил он. По его мнению, компании проецируют на ИИ свои стратегические решения, чтобы избежать критики.

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

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

Что говорят исследования о влиянии ИИ?

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

Аналитики Goldman Sachs Research прогнозируют, что ИИ может затронуть 6–7% рабочих мест в США, но эффект, скорее всего, будет временным. Новые технологии, как правило, перераспределяют рабочие роли, а не уничтожают их полностью. Например, автоматизация рутинных задач может высвободить сотрудников для более творческих или стратегических функций. Однако этот переходный период может быть болезненным для работников, чьи навыки оказываются невостребованными.

Реальные примеры: как компании используют ИИ

Чтобы лучше понять ситуацию, рассмотрим несколько примеров. Microsoft, активно интегрирующая ИИ в свои продукты, сократила часть сотрудников в подразделениях, где автоматизация заменила ручной труд. Klarna, шведская финтех-компания, объявила о сокращении штата, ссылаясь на то, что ИИ-инструменты теперь выполняют задачи, ранее требовавшие участия сотрудников. Duolingo, в свою очередь, использует ИИ для генерации учебного контента, что позволило сократить количество подрядчиков в этой области.

Однако критики указывают, что такие сокращения часто совпадают с другими стратегическими изменениями. Например, компании могут одновременно оптимизировать затраты, реструктурировать команды или перераспределять ресурсы в новые направления, используя ИИ как удобное объяснение.

Скрытые мотивы и долгосрочные перспективы

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

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

Что ждёт рынок труда?

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

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

Проблемы зафиксированы у Perplexity, Fortnite, Steam, Snapchat, Asana, Roblox, Duolingo, Coinbase, Canva, Venmo, McDonald’s, Apple TV и множества других платформ, завязанных на инфраструктуру AWS.

Согласно данным Downdetector, пик жалоб пришелся на 11:00 МСК, когда было зафиксировано более 5700 обращений, хотя реальное число пострадавших, вероятно, значительно выше.

Половина интернета — в офлайне

AWS — это не просто сервис Amazon, а фундаментальная часть интернета. Она обеспечивает работу миллионов веб-приложений, API и баз данных.

Именно поэтому даже частичный сбой в дата-центрах Amazon мгновенно отражается на десятках отраслей — от финтеха до гейминга.

Показательно, что даже панель статуса AWS Health Dashboard в момент инцидента оказалась недоступна, выдавая ошибку «This site can’t be reached».

Что известно о причинах

Официальных комментариев от Amazon на момент публикации нет, но все признаки указывают на проблемы в восточном регионе Вирджинии (us-east-1) — ключевом узле AWS, через который проходит значительная часть мирового трафика.

Компания Perplexity AI одной из первых подтвердила зависимость инцидента от инфраструктуры AWS.

Perplexity сейчас не работает. Причина — сбой на стороне AWS. Мы уже занимаемся восстановлением.

С аналогичным сообщением выступили представители Asana, которые сообщили о «полной недоступности всех сервисов» и ожидании обновления от Amazon.

Реакция пользователей

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

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

Что дальше

AWS пока не раскрывает детали, но инженеры компании, по данным внутренних каналов, уже работают над «локализацией и перезапуском кластеров в Вирджинии».

Сбои AWS происходят редко, но их эффект показывает, насколько уязвим современный интернет: когда падает Amazon — падает и все остальное.

Кого опрашивали

Мы опросили 145 человек, из которых:

• 45.5% оказались разработчиками,
• 11% — тимлидами и техлидами,
• 6.9% — айти-авторами или редакторами,
• 6.9% — аналитиками,
• 5.5% — продакт- или проджект-менеджерами,
• 4.8% — маркетологами,
• 3.4% — CEO компаний,
• 3.4% — контент-менеджерами,
• 2.8% — SMM-специалистами,
• 2.8% — дата-сайентистами и ML-инженерами,
• 2.1% — дизайнерами или иллюстраторами,
• 1.4% — деврелами или техпиарщиками,
• 0.7% — SEO-оптимизаторами.

Большинство опрошенных или 18,5% работают в бигтехе, на втором месте — 13,7% — аутсорс, 12.1% – финтех, 9.7% — госкомпании, 8.9% — фриланс, 8.1% — стартапы, 5.6% — эдтех и ещё 23.4% отметили категорию другое.

Среди опрошенных большинство имеют грейд мидл — 43.8%, сеньоров — 25.7%, джуниоров – 17.1%, менеджеров — 9.5%, собственный бизнес – у 3.8%.

Более половины или 52,4% не развивают личный бренд, 28,6% — задумываются об этом, а 19% активно этим занимаются.

При этом 18.6% пишут статьи для развития личного бренда, 17.8% ведут блоги, 17.1% ничего не делают, 11.6% преподают, 10.9% менторят, 7.8% выступают с докладами, 5.4% занимаются наукой. Ещё 3.9% ответили, что пишут книги, аналогичное количество ведёт подкасты, ​​3.1% — участвует в хакатонах.

Как используют ИИ при создании контента

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

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

«Если попросить его написать какие то атомарные короткие блоки, методы, функции, то ИИ неплохо справляется».

«Нейросеть может накинуть идеи, дать свежий взгляд на проблему, помочь с рутинным переписыванием кода. В контексте AI-агентов — под тщательным присмотром, чтобы избежать последствий галлюцинаций».

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

15.5% — генерирует с помощью нейросетей идеи, 11.4% — создают иллюстрации. 9.4% — обращаются к ИИ для саммаризации. 8.5% — для расшифровки аудиозаписей, 7.6% — для переводов, 6.7% — при редактуре статей, 5.3% — для создания постов, 4.7% — для написания статей, 3.2% — для создания презентаций, 2% – для видео-контента, 1.5% — для сео-оптимизации. 4.4% отметили, что вообще не используют ИИ, а 3.8% — что используют, но для каких-то других целей.

Среди других целей отмечали создание баннеров и логотипов, фреймов постов, подбора «цепляющих» заголовков:

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

Большинству респондентов нравится Chat GPT — 32.6%; Gemini выбрали 8.7%; Gigachat и Yandex GPT набрали поровну, по 7%; Midjourney и DeepL — по 6.5%; Kandinsky — 3.9%; Dall-E2 — 3%; RoBERTa — 0.9%.

23.9% отметили, что предпочитают другие нейросети. Среди них — Deep Seek (особенно популярен среди собственных вариантов респондентов), Claude (на втором месте по популярности), Grok (на третьем месте), Sonar и Qwen (обе на четвёртом). Также опрошенные назвали Cursor, v0.dev, Gemma, ollama, Perplexity, Kling, Luma DM, SD1.5, Sora, Suno, Шедеврум.

Хотя с последним опыт респондентов был неоднозначным:

«Т.к. “тестировала” Шедеврум, получаемый в результате контент выходит спорным: не все условия учитываются, тяжело работает со специфичными запросами (или вообще не понимает их), бывают непонятные артефакты или нарушение построения (анатомического и пр.)»

Отношение к ИИ в контенте

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

При этом 4.9% были категоричны и отметили, что относятся негативно или даже запрещают использовать ИИ сотрудникам. Ещё 1.6% не используют сами и обязательно пишут негативный комментарий, если замечают признаки использования.

Из негативных аспектов 33.1% опрошенных отмечают галлюцинации нейросетей.

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

«Нормально использовать его, если есть опыт применения и знаешь, где ИИ может накосячить. Перепроверяешь за ним такие места».

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

1) Плохой промпт = плохой результат

2) Даже при хорошем промпте нейросети склонны всё равно ошибаться и врать. Был случай, когда разработчик просто скопипастил в код прода пример псевдокода из документации, который оптимизировался нейросетью. Надо ли говорить, что всё закончилось производственным фиаско… развитие нейронок подразумевает, что нужно самому развиваться еще быстрее и быть на шаг впереди, чтобы быть в состоянии грамотно анализировать и фильтровать то, что они выдают».

21.6% критикует ИИ за странный стиль и метафоры. 18.4% считают, что видят, когда текст писал робот и им неприятно. Среди менее очевидных неприятностей, связанных с ИИ: 11.4% называют ограничения использования из-за санкций/импортозамещения, 9% — цену подписки, 5.7% — личное недоверие к ИИ.

«Если говорить в общем, контент, генерируемый ИИ, всегда лишён личного начала. Да, где-то торчат уши автора (автора промта). Но и всё на этом. Примерно как: президент озвучил идею , что неплохо бы поддержать семью… А дальше, ну вы сами знаете. То есть, для генерации творческого контента ИИ — инструмент так себе. Среднего уровня оруэлловский станок для написания романов.

Другое дело — техническая писанина и код. Вот тут ИИ на своем месте. Но всё же, нуждается в тщательном контроле на всех этапах работы. Свою нишу ИИ в контенте занял, и ему есть, куда расти, но ведь это просто инструмент. А он не может быть совершеннее своего изобретателя. Тема ИИ — не творчество в широком смысле. Его удел — техническая часть».

У некоторых опрошенных сама ценность ИИ вызывает сомнение — они считают, что явление слишком переоценено:

«ИИ используется уже много лет в совершенно разных сферах. Но когда он стал доступным массовому пользователю, начал невероятную войну хайпа. Теперь каждая продуктовая компания должна внедрить ИИ в свой продукт. Открывается огромное количество стартапов, которые собирают деньги только благодаря наличию двух букв “AI” в своём названии. Контент, сгенерированный с помощью ИИ, просто завалил интернет.

Дело в том, что написанный ИИ текст, программный код, либо сгенерированная картинка или видео видны сразу, что понижает ценность этого контента (по моему мнению). Я считаю, что если есть желание использовать ИИ в создании контента, то нужно, чтобы ты его делал с помощью ИИ, а не ИИ делал его с твоей помощью. Через какое-то время хайп пойдёт на спад, контентмейкеры и компании найдут баланс в использовании современных ИИ технологий и именно тогда он начнет приносить наибольшую пользу человечеству. На данный момент ИИ генерирует 80% хайпа и 20% пользы, а должно быть, как минимум, диаметрально противоположная картина. P.S. все цифры и заявления, приведенные в этом комментарии, не основаны ни на каких исследованиях, чисто на моих ощущениях».

Ряд опрошенных беспокоит, что ИИ отучает нас, то есть человечество, мыслить:

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

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

«Удобный и полезный инструмент. Но нужен навык, чтобы им пользоваться. Нейросети могут довольно быстро выдать вариант “на 4”. Чтобы получилось “на 5”, нужно приложить немало усилий. Ну и я вижу, что студенты пытаются делегировать 100% домашки нейронкам и очень удивляются, когда их в этом разоблачают».

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

Как минимум, большинство опрошенных не считают ИИ-контент — злом:

«Не считаю, что ИИ-контент — это что-то ужасное, Как и не думаю, что «мертвый интернет» придёт в скором времени, но надеюсь на повышение качества такого контента, либо на ограничение его показов».

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

«С нейросетями так же как с автомобилями: использовать можно, а иногда даже необходимо, но нужны правила и те, кто проверяет и наказывает за несоблюдение. Пока что в мире бардак. Кто, как смог, собрал себе какие-то драндулеты и катается по городу, пугая прохожих 🙂».

А как используете ИИ в контенте вы? Пишите в комментариях!

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

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

Во время работы я наткнулся на подход, который мне очень понравился: ADR — Architectural Decision Record, или «протокол архитектурных решений».

По сути, это документ, в котором фиксируются все изменения, внесённые в архитектуру: само решение, его влияние и полученные уроки.

Проще говоря, это как личный дневник — только для всей команды.

Почему это важно?

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

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

Будущие разработчики скажут вам спасибо. Подумайте о человеке, который через пять лет будет разбираться в вашем коде. Если вы не оставили объяснений, он, скорее всего, будет мучиться, пытаясь понять, зачем было сделано то или иное изменение. А теперь представьте другого разработчика в другой компании, который находит ADR-документ с чётким объяснением принятого решения. Он, без сомнения, будет вам благодарен.

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Ценность ADR я впервые осознала в 2019 году. В команду, где работала, активно набирали новых ребят, и приблизительно раз в неделю кто-нибудь из новых разработчиков спрашивал "а почему это сделано так, а не иначе?" Приходилось постоянно давать ответы на одни и те же вопросы, и тогда-то я и поняла, насколько будет удобно записывать ответы где-нибудь в документацию в confluence и просто кидать ссылку новичкам.

В 2019 году я еще не знала сам термин ADR и говорила "документация". С термином я познакомилась совсем недавно — этим летом, на курсе по архитектуре монолитных приложений. Тогда я поняла, насколько эффективно можно использовать ADR для ускорения разработки и уменьшения TTM. Дело в том, что начиная разрабатывать новый проект, разработчик первое время (от месяца до полугода! всё зависит от размера проекта) погружается в проект — разбирается, как всё устроено, чтобы вносить изменения соответственно архитектуре. В этот период разработчик, по сути, составляет собственные adr — обычно в виде мыслеобразов в своей голове :) Если записать основные решения, разработчик сможет намного быстрее погрузиться в проект.

Как писать ADR?

Существует несколько общепринятых правил, но вы всегда можете адаптировать их под себя.

Вдохновившее меня соглашение можно найти на GitHub . Вы также можете ознакомиться с процессом ADR на Amazon.

Вот пример шаблона, который вы можете использовать.

Такой тип документа может находиться прямо в репозитории проекта, в Confluence или, например, в JIRA.

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

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

Синьор-фронтендер из ВК Маргарита Лукина, автор телеграм-канала «Фронтенд кухня»:

Многие руководители хотят видеть на своём проекте разработчиков, которые "сразу, без раскачки" начнут перформить. Совсем избежать периода погружения невозможно, но можно ускорить его в десятки раз за счёт ADR

Если нужно комплексное решение, единая платформа с привычным набором: DDoS-защита, антибот, WAF, DNS, CDN и другие необходимые для веба вещи, то есть платформа NGENIX — одна из ведущих российских альтернатив Cloudflare для проектов любого масштаба.

Что такое NGENIX и почему его выбирают?

NGENIX — российская облачная платформа, которая сочетает в себе защиту от атак, ускорение загрузки, управление DNS и SSL-сертификатами, фильтрацию вредоносного трафика. Инфраструктура развернута в России и СНГ. Переезд с Cloudflare возможен за считанные часы, без риска блокировок Роскомнадзором и с техподдержкой, которая отвечает на русском с понятным SLA.

Основные функции и возможности платформы:

• Защита от DDoS — отражение атак до 7+ Тбит/с и 5 млн RPS, включая атаки на DNS;
• Фильтрация вредоносных ботов — блокировка парсеров, скрейперов и автоматизированных атак;
• Облачный WAF — предотвращает взломы и эксплуатацию уязвимостей;
• Доставка контента (CDN) — благодаря распределённой сети из 50+ узлов в России и СНГ, запросы обслуживаются ближайшим к пользователю сервером;
• Авторитативный DNS — отказоустойчивая система с обработкой до 100+ млн запросов в секунду;
• SSL/TLS-сертификаты — поддержка стандартов шифрования RSA, ECDSA и ГОСТ 34.10, автоматический выпуск и продление SSL-сертификатов Let's Encrypt, поддержка загрузки и использования собственных сертификатов (включая самоподписанные);
• Управление доступом — организация доступа к сайту или приложению при помощи простых правил или подписанных ссылок;
• Стриминг видео — стабильная передача в высоком качестве и в различных форматах;
• Распределенный мониторинг доступности — возможность отслеживать доступность сайта 24/7, оперативно реагировать на инциденты и получать метрики доступности в формате Prometheus;
• Аналитика — 35+ готовых отчётов с задержкой всего в 1 минуту.

Всё это доступно через единый интерфейс.

Инфраструктура под задачи любого масштаба

• 50+ узлов в РФ и СНГ — максимальная близость к пользователю;
• Пропускная способность 7+ Тбит/с — запас на любые пиковые нагрузки;
• На платформе используются разные виды балансировки: Anycast BGP, DNS и HTTP;
• Единый SLA на все сервисы платформы;
• Поддержка 24/7 с быстрой реакцией.

Реальный кейс: переход с Cloudflare за несколько часов

Один из клиентов NGENIX — крупный московский девелопер — столкнулся с блокировкой Cloudflare со стороны Роскомнадзора. Благодаря оперативной техподдержке переход на NGENIX занял всего несколько часов.

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

Тарифы — под любые масштабы

У NGENIX есть тарифы как для стартапов, так и для корпораций:

• Promo — 6 900 ₽
• Lite — 13 900 ₽
• Start — от 23 900 ₽
• Pro — от 59 900 ₽
• Ultimate — индивидуально, с кастомной настройкой, премиальным SLA и выделенным менеджером.

Кому подойдёт?

• Владельцам, администраторам и командам как небольших и средних сайтов и сервисов, так и крупных проектов в сферах: e-commerce, SaaS, OTT, а также госструктурам и финтеху.
• Компаниям, утратившим доступ к зарубежным облачным сервисам, нуждающимся в быстром и удобном переходе;
• Командам с ограниченным количеством специалистов по безопасности — платформа обеспечивает комплексный набор функций под единым интерфейсом.

Если вы использовали Cloudflare ради скорости, защиты и стабильности — NGENIX даст тот же набор инструментов, но с локальной инфраструктурой, без проблем с регуляторами и с поддержкой, которая говорит с вами на одном языке.

DDoS-Guard: кастомная защита от атак уровня L3–L7 с гибкой настройкой под ваш проект

Если вы думаете, что защита сайта от DDoS-атак — это что-то вроде базового щита на периметре, который «где-то там» на краю сети отсекает подозрительный трафик, то стоит взглянуть, как работает DDoS-Guard. Эта платформа предлагает куда более глубинный подход: защита на всех уровнях от L3 до L7, с возможностью тонкой настройки под архитектуру вашего проекта.

Не просто фильтр, а эшелонированная оборона

DDoS-Guard — это инфраструктурная экосистема, которая умеет:

• отражать любые типы DDoS-атак: как волюметрические, так и прикладного уровня;
• анализировать HTTP-трафик и блокировать вредоносные запросы в реальном времени;
• оптимизировать TTFB и ускорять загрузку контента за счёт встроенного CDN;
• маскировать реальный IP и строить эшелонированную защиту через Reverse Proxy;
• управлять правилами фильтрации на уровне каждого домена, поддомена или даже URI;
• кастомизировать защиту под конкретные угрозы: от скрейпинга до TOR-трафика.

Защита на базе собственного софта и ИИ

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

За счет использования anycast-маршрутизации и собственной сети узлов, DDoS-Guard минимизирует задержки — запросы обрабатываются на ближайшем к пользователю центре фильтрации. Это критично для e-commerce и финансов, где лишняя секунда отклика может стоить клиентской корзины.

Реальный кейс: защита одного из крупнейших онлайн-сервисов по продаже лекарств

Один из клиентов DDoS-Guard — сервис из топ-3 аптечных агрегаторов в России — обратился с проблемой: высокий TTFB, нестабильная маршрутизация после сбоев и уязвимость к ботам и парсерам.

После миграции с Cloudflare результат оказался ощутимым:

• скорость сайта выросла на 40%;
• появились гибкие правила фильтрации и кастомный каскад антискрейпинга;
• доступность под нагрузкой восстановлена полностью.

И всё это — без «боли» переезда: миграция прошла быстро, с сопровождением инженеров DDoS-Guard.

Кому подойдёт?

DDoS-Guard — это решение не только для корпораций. Сервис работает с банками, госорганами, e-commerce и телекомом, но в то же время:

• небольшим проектам подойдёт тариф Basic (визитка, лендинг, каталог);
• малому и среднему бизнесу — Normal и Medium с фильтрацией TOR, кастомными TLS-наборами;
• крупным продуктам — Premium и Enterprise, где возможны уникальные L7-модули и фильтры на уровне API.

Сегменты, где защита особенно критична: СМИ, маркетплейсы, финтех, игровые платформы, госуслуги.

Что говорят внутри

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

StormWall: когда защита сайта — дело минут, а не дней

Если ваш проект работает в интернете, то вопрос киберзащиты — это не «если», а «когда». DDoS-атаки стали буднями даже для малого бизнеса, не говоря уже о финансовых сервисах, SaaS, e-commerce или онлайн-играх. И вот тут в игру вступает StormWall — российский разработчик решений для защиты сайтов, сетей и онлайн-сервисов с опытом более 12 лет.

Быстрая и комплексная защита от DDoS — без компромиссов

StormWall — это не просто прокси с анти-DDoS, а целая облачная экосистема, заточенная под разные типы инфраструктуры. Заказчику доступны сразу три варианта защиты:

• Для сайтов и приложений — включает DDoS-защиту, антибот, WAF;
• Идеально для интернет-магазинов, медиа, финтеха и госсайтов;
• Для сетей и автономных систем — работает на уровнях L3/L4, актуально для провайдеров, дата-центров и телекомов;
• Для сервисов на базе TCP/UDP — используется в играх, VoIP, стриминге, VPN и других чувствительных к задержкам сервисах.

За счёт собственной сети фильтрации с пропускной способностью 5+ Тбит/с и 9 дата-центров по всему миру, платформа может нейтрализовать даже самые сложные мультивекторные атаки.

Антибот, WAF, CDN — всё из одного окна

StormWall — это не только анти-DDoS. В арсенале платформы есть и другие полезные инструменты:

• Web Application Firewall (WAF) — защита L7 от SQL-инъекций, XSS и других попыток взлома;
• Антибот — фильтрация трафика по сигнатурам и поведенческим признакам;
• CDN — для ускорения контента, доставки видео, апдейтов и стабильной работы под нагрузкой;
• DNS, reverse proxy, API gateway — всё интегрировано в инфраструктуру с управлением через личный кабинет.

Быстрая миграция, как это было у АТОЛ

Весной 2022 года на облачные сервисы и онлайн-кассы АТОЛ обрушились мощные DDoS-атаки. Компания была вынуждена срочно искать профессиональное решение для защиты — и выбрала StormWall. За 10 минут специалисты развернули защиту, и уже через 30 минут вредоносный трафик был отфильтрован.

Даже при ежедневных DDoS-атаках мощностью 50–100 Гбит/с сервисы разработчика продолжают работать бесперебойно — клиенты-ритейлеры уверены в стабильности и надёжности его ПО.

Кому подойдёт StormWall?

• E-commerce и ритейл — устойчивость к пикам в «чёрную пятницу»;
• Банки и финансы — SLA и отказоустойчивость на уровне инфраструктуры;
• Госуслуги — соответствие реестру российского ПО;
• Разработчики игр, стриминговые платформы, SaaS — защита TCP/UDP и CDN для скорости;
• Малый бизнес — тарифы от 7 200 ₽ в месяц и помощь при миграции.

Почему выбирают StormWall

• Поддержка 24/7, ответ до 15 минут;
• Сервис как услуга — от настройки до сопровождения;
• Собственные технологии на C с eBPF и DPDK, асинхронные микросервисы на Python и JavaScript;
• Реестр российского ПО, лицензии СЗКИ/ТЗКИ;
• Модульность и кастомизация фильтрации под каждого клиента;
• Поддержка BGP, reverse proxy, API gateway, машинное обучение внутри фильтров.

Тарифы — от малого до enterprise

• Для сайтов: от 7 200 ₽/мес;
• Для сетей и сервисов: от 18 000 ₽/мес;
• Enterprise — по запросу, под SLA, с кастомными модулями фильтрации.

Вывод: российские аналоги уже закрывают ключевые задачи Cloudflare

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

Если нужен комплекс «всё в одном» — с CDN, WAF, DNS и отказоустойчивостью, стоит смотреть на NGENIX: инфраструктура в России, понятный SLA и миграция за часы без проблем с регуляторами. DDoS-Guard — выбор для проектов, которым нужна глубина кастомизации и защита на всех уровнях L3–L7. StormWall берут за скорость внедрения и большой спектр решений — от сайтов до сетей и игровых сервисов.

Главный вывод: закрыть задачи Cloudflare в России сегодня реально — выбор зависит от масштаба бизнеса, критичности инфраструктуры и требований к гибкости настроек.

Участникам предоставляется доступ к менторской поддержке и отраслевой экспертизе, возможность сотрудничества с компаниями из инвестиционного портфеля Газпромбанка. В этом году программа включает три трека: Финтех, Диптех и Наука, каждый из которых ориентирован на разный уровень зрелости проектов — от стадии идеи до готового продукта с подтвержденным рыночным спросом.

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

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

• Маркетинг и новые каналы продаж, развитие клиентского сервиса и оптимизация клиентского пути;
• Кибербезопасность, управление рисками, антифрод (внутренний, пользовательский, внешний, транзакционный);
• Моделирование и скоринг, управление и работа с данными;
• Удобные и безопасные транзакции;
• Управление человеческим капиталом.

В этот трек принимаются проекты от стадии MVP с подтвержденной работоспособностью прототипа.

Технологический конкурс DeepTech-проектов ориентирован на привлечение инвестиций компаниями, разрабатывающими передовые решения по направлениям:

• Новые технологии сбережения здоровья;
• Экономика данных и цифровая трансформация государства;
• Космические технологии;
• Новые атомные и энергетические технологии;
• Новые материалы и химия;
• Средства производства и автоматизации;
• Технологическое обеспечение биоэкономики.

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

Трек акселератора «Наука» открыт для ранних проектов, основанных на научных разработках. Участие возможно даже на стадии идеи — при наличии потенциала для технологического роста и будущей коммерциализации. В трек «Наука» приглашаются университеты - участники программы стратегического академического лидерства «Приоритет-2030» и проекта «Передовые инженерные школы».

Технологические направления проектов:

• Новые материалы и химия (катализаторы, малотоннажная химия, нефтехимия, моделирование и синтез катализаторов;
• Новые технологии сбережения здоровья (биомедтех, агротех,бионика, медицинские изделия);
• Средства производства и автоматизации (производственные технологии, станкостроение;
• Новые атомные и энергетические технологии (системы накопления энергии, электрохимия);
• Развитие многоспутниковой орбитальной группировки (космические технологии, плазменные двигатели, лазерная связь);
• Экономика данных и цифровая трансформация (микроэлектроника, квантовые технологии).

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

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

При запуске акселератора организаторы опирались на успешный опыт предыдущего сезона и вывели его на новый уровень с расширенной программой и углубленной экспертизой. В прошлом году в программу подали заявки более 280 проектов по 14 направлениям. Эксперты Газпромбанка отобрали 20 финалистов, шесть из которых стали победителями. Все финалисты получили рекомендации по развитию продукта и провели встречи с профильными бизнес-заказчиками. По итогам акселератора два проекта уже запустили пилотные внедрения, еще пять находятся на стадии структурирования.

Смотреть видео о прошлогоднем акселераторе

Заявки принимаются до 10 октября 2025 г. в треки «финтех» и «диптех» и до в трек «наука» до 30 сентября через официальный сайт программы.

По вопросам участия: accelerator@twinscom.ru

Сайт: www.gazprombank.ru/business/accelerator-gpbtech-2025/

Реклама. Рекламодатель АО БАНК ГПБ, ИНН 7744001497, erid 2W5zFGRVg6c

Progressive Web Apps (PWA) позволяют сайту в браузере работать как полноценное приложение — с установкой на домашний экран, мгновенной загрузкой и офлайн-возможностями. В отличие от классических мобильных приложений, PWA не требуют публикации в App Store или Google Play — они разворачиваются прямо из браузера, что особенно ценно в экосистемах с закрытыми магазинами приложений.

Но настоящую мощь PWA раскрывает WebAssembly (WASM) — технология, которая выводит веб-приложения на новый уровень производительности. WASM позволяет выполнять ресурсоемкие вычисления прямо в браузере: распознавание документов, анализ изображений, работу с графикой — все это теперь возможно без потери скорости и без постоянных запросов к серверу.

Мы в Smart Engines реализовали PWA, которое хранит все необходимые ресурсы (включая WASM-модули) в локальном кеше благодаря Service worker. В отличие от браузерного кеша, Service worker при повторном обращении к ресурсу не создает HTTP- запросов, а отдает файлы сразу. Это позволяет значительно ускорить отзывчивость приложения.

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

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

Хотите увидеть, как это работает на практике? Давайте перейдем к демонстрации!

Интеграция решения распознавания паспорта РФ в PWA довольно проста.

Кеширование

Для кэширования ресурсов вы регистрируете Service Worker по простому примеру из MDN и добавляете все необходимые ресурсы при регистрации. Это стили, скрипты и wasm-файлы.

Установить сайт на экран

В Chromium-браузерах (Edge, Opera, Brave) событие beforeinstallprompt срабатывает, когда сайт удовлетворяет критериям установки PWA. Вы можете перехватить это событие и показать свой баннер с предложением установки.

К сожалению, Safari на iOS не поддерживает это событие. Для него принято использовать скрипт, например a2hs.js. который показывает уведомление с предложением и инструкцией, как добавить сайт на экран устройства самостоятельно. Это менее удобно, но на iOS эта возможность существовала задолго до PWA, даже до 11 версии iOS, после которой появилась поддержка offline-функций.

Распознавание паспорта РФ

Для внедрения распознавания необходимо создать worker.js - файл, который будет производить вычисления, не нагружая UI браузера.

Внутри воркера мы загружаем скрипт и создаем инстанс библиотеки распознавания

Теперь нам необходимо создать и настроить сессию распознавания.

Указываем режим распознавания и маску документа. Можно указать маску как rus.passport.* тогда поиск будет осуществляться как национального паспорта так и биометрического заграничного (“rus.passport.biometric”)

Следующей настройкой мы просим вернуть в результате изображение документа, исправленное по перспективе.

Теперь мы инициализируем сессию:

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

Теперь мы можем передать его на распознавание.

Объект result содержит в себе всю информацию о документе: текстовые поля, координаты шаблона и полей документа, изображения (подписи, печати, изображение документа).

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

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

Если система больше не ожидает получить более качественное изображение на вход, она переводит флаг терминальности сессии в true и вы можете забрать результат.

Распознавание на клиенте не ограничивается только камерой. Документ может быть прикреплен из галереи или быть упакован в многостраничный PDF. Все эти форматы можно отрисовать на canvas и передать на распознавание.

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

Если вам интересно узнать больше про возможности искусственного интеллекта на WebAssembly, рекомендуем почитать нашу прошлую статью про распознавание банковских карт в браузере.

Bank of Hangzhou Consumer Finance — лицензированная организация потребительского финансирования. Столкнувшись с вызовами, связанными с быстрым ростом бизнеса, компания начала трансформацию своей инфраструктуры данных, кульминацией которой стало создание платформы GLH Lakehouse на базе Mirrorship.

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

I.Предпосылки создания платформы GLH: Инновации, продиктованные «болевыми точками» в данных

1. Требования бизнес-сценариев

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

• Актуальность данных для стратегий: стратегии управления финансовыми рисками требуют своевременных данных для принятия решений. Задержка даже в несколько минут может привести к сбою в контроле рисков.
• Консистентность данных между таблицами: синхронизация данных между различными базами и таблицами должна поддерживать консистентность на определённый момент времени. Любое расхождение могло нарушить бизнес-логику.
• Точность бизнес-данных: ежедневные отчёты для руководства должны быть точными и своевременными, так как они напрямую влияют на стратегическое направление компании.
• Потребности в сверке данных: внутридневные данные необходимы для процессов сверки, и традиционные ETL-процессы не могли обеспечить требуемую оперативность.
• Соблюдение нормативных требований: данные, предоставляемые регуляторам, должны соответствовать строгим стандартам своевременности и точности.

2. Анализ ключевых «болевых точек»

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

Проблема 1: Сложность отслеживания данных (Data Traceability)

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

Проблема 2: Отсутствие детализированных записей об изменениях

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

Проблема 3: Неточность данных на определённый момент времени (Point-in-Time Data)

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

Проблема 4: Проблемы с ежедневным закрытием операционного дня (Daily Cut-off)

В сценариях сверки транзакций по погашению платежей разные системы (например, транзакционная и бухгалтерская) обрабатывали одну и ту же операцию в разное время. Это приводило к серьёзным неточностям в данных к концу дня, что напрямую влияло на сверку.

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

II. Построение архитектуры Lakehouse с помощью Mirrorship

1. Техническая архитектура платформы GLH

Платформа GLH была спроектирована с использованием четырехуровневой архитектуры:

• Уровень приложений (Application Layer): включает узел управления (Manager Node), узлы выполнения (Execute Nodes), кастомные плагины и узел оповещений (Alerting Node).
• Уровень технических компонентов (Technical Component Layer): использует экосистему Spring Framework, MyBatis, собственный RPC-фреймворк, Log4j и др.
• Уровень промежуточного ПО (Middleware Layer): задействует ZooKeeper, Kafka и MySQL.
• Уровень эксплуатации (DevOps Layer): основан на Git, Jenkins, Docker & Kubernetes, Maven.

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

2. Почему для замены GreenPlum выбрали Mirrorship?

Выбор хранилища данных был критически важным решением. После всесторонней оценки и тестирования команда выбрала Mirrorship (корпоративную версию StarRocks) в качестве основного движка для хранения и аналитики.

Выбор было продиктован насущными проблемами — производительность существующего 26-узлового кластера GreenPlum снижалась по мере роста объёма бизнеса, а расширение требовало значительных инвестиций.

• Снижение затрат и повышение эффективности: лицензионные платежи и стоимость горизонтального масштабирования GreenPlum были высокими. Mirrorship предложила более экономически эффективное решение, соответствующее стратегической цели компании.
• Возможности ingest-а данных в реальном времени: в отличие от традиционных инструментов, таких как Hive, Mirrorship поддерживает real-time ingest и транзакционные запросы, что дает ей естественное преимущество в сценариях с данными реального времени.
• Единая платформа данных: данные были разбросаны по разным системам, создавая «острова данных». Mirrorship предоставила единую платформу для хранения и вычислений, консолидировав данные и упростив доступ к ним.
• Дизайн архитектуры Lakehouse на базе Mirrorship

В новой архитектуре платформа GLH глубоко интегрирована с Mirrorship для создания истинной Lakehouse.

• Архитектура с разделением хранения и вычислений (Shared-Storage): в качестве базового хранилища используется HDFS (с планами миграции на S3), что обеспечивает гибкость для управления ростом данных при контроле затрат и сохранении производительности.
• Использование нескольких моделей таблиц: используя возможности Mirrorship для работы с детализированными (Detail tables) и широкими таблицами (Wide tables), команда разработала кастомные структуры таблиц, поддерживающие анализ временных рядов и отслеживание данных для различных бизнес-задач.
• Унифицированная обработка данных: придерживаясь принципа «сбор один раз, обработка многократно», все данные управляются через единый конвейер обработки. Это позволило избежать дублирования разработки, значительно повысив эффективность и консистентность данных.
• Гибкое распределение данных: платформа поддерживает распределение данных в другие системы через Kafka, что обеспечивает работу сценариев, таких как Flink CDC, и создает открытую, гибкую экосистему.

III. Результаты: баланс между производительностью и экономической эффективностью

В ходе внедрения команда накопила ценный опыт:

• Оптимизировали время пакетной обработки: команда применила дифференцированную стратегию синхронизации данных, настраивая интервалы в зависимости от бизнес-потребностей — от 5 секунд для одних таблиц до нескольких минут для других.
• Оптимизировали партиционирование и бакетирование: анализ бизнес-характеристик позволил переработать стратегию партиционирования, чтобы уменьшить накладные расходы на уплотнение (compaction) мелких файлов, что привело к значительному повышению производительности.
• Рационально распределили ресурсы: оптимизировано соотношение ресурсов между вычислительными узлами и узлами хранения. Мониторинг показал, что кластер стабильно работает с загрузкой ЦП ниже 50%, легко справляясь с пиковыми нагрузками.

Бизнес-результаты

Платформа GLH достигла впечатляющих результатов:

• Полный охват данных: более 3800 таблиц из всех бизнес-систем компании подключены к real-time потоку данных.
• Синхронизация на минутном уровне: время от генерации данных до их доступности сократилось до минут, что многократно повысило скорость реакции бизнеса по сравнению с традиционной моделью T+1.
• Увеличение мощности пакетной обработки: платформа обрабатывает более 6500 заданий в день, включая более 800 задач для хранилища данных, со значительным ростом эффективности.
• Углубление интеграции с бизнесом: снято ограничение на выполнение только пакетных запросов, благодаря открытию real-time query API, что позволило бизнес-системам напрямую получать доступ к актуальным данным.

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

IV. Перспективы развития

Платформа GLH завершила разработку основного функционала. Будущее развитие будет сосредоточено на следующем:

1. Более открытые интерфейсы: поддержка интеграции с более широким спектром вычислительных и движков хранения.
2. Богатая экосистема плагинов: разработка большего количества плагинов для обработки данных.
3. Более глубокая интеграция с бизнес-процессами: дальнейшая интеграция с бизнес-системами для предоставления более точных данных.
4. Постоянное технологическое развитие: отслеживание развития технологий хранения с запланированной миграцией на объектное хранилище S3.

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

ИИ помогает программистам писать и проверять код, быстрее его понимать, тестировать идеи. Но пока он не заменяет человека — и вряд ли заменит в ближайшее время. Зато становится мощным инструментом, который меняет подход к разработке. Разбираемся, где именно он полезен, почему Python — язык номер один в ИИ-задачах и какое будущее ждет айтишников с развитием технологии.

Как ИИ влияет на разработчиков

ИИ-ассистенты уже стали стандартом в продвинутых командах. Они помогают не только быстрее писать свой код, но и лучше разбираться в чужом: объясняют сложные участки, упрощают навигацию, подсказывают решения. По данным GitHub, искусственный интеллект повышает производительность разработчика на 30%.

Что ИИ уже умеет хорошо: написать пинг-понг на JavaScript, быстро собрать функцию на Python, которая считает числа Фибоначчи через матрицы, или решить олимпиадную задачу средней сложности.

Повышение эффективности

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

В итоге техдолг сокращается, бэклог разгребается быстрее, фичи выкатываются в продакшн с меньшими задержками. Сокращается Time-to-market, а главное — на выходе получается более качественный продукт. Команды успевают не только больше делать, но и лучше думать над архитектурой.

Лифт для экспертизы

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

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

Мидлы тоже выигрывают: освобождаясь от рутины, они больше времени тратят на сложные архитектурные решения. ИИ становится ускорителем профессионального роста на всех уровнях.

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

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

…а иногда не очень изящные

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

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

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

Чтобы понять, заменит ли ИИ программистов, можно их условно разделить на два типа:

1. те, кто понимает все тонкости предметной области и может делать сложные инновационные вещи;
2. и те, кто знаком с несколькими высокоуровневыми фреймворками и делает работу, не требующую особых глубоких знаний, кроме этого.

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

Как ИИ используется в финтехе уже сейчас

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

1. Риски

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

2. Борьба с мошенничеством

Здесь есть несколько направлений: внутренний антифрод (выявление подозрительных действий сотрудников) и внешний (защита клиентов от мошенничества). Модели отслеживают аномалии в данных и предсказывают различные риски.

3. Клиентский сервис

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

4. Персонализация и продажи

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

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

5. Автоматизация

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

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

Что ИИ пока не умеет

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

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

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

Банки (и не только они) для решения внутренних задач широко используют технологию RAG (Retrieval-augmented generation): сначала модель достает нужные данные из внутренней базы знаний, а потом на их основе формирует ответ. Решения на RAG можно использовать в виде «суфлера» — модель подсказывает, человек проверяет информацию и принимает решение. Такой подход позволяет сохранить скорость и удобство, которые дает ИИ, но добавляет к ним проверку фактов.

Один из самых популярных сценариев использования RAG в банках — помощь операторам поддержки. Есть внутренние базы знаний, есть информация по продуктам и есть вопросы клиентов. Задача — быстро дать точный релевантный ответ, опираясь на всю эту информацию. Языковая модель в таком случае выступает как «общий мозг»: она понимает формулировку, подставляет нужные факты и помогает оператору.

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

Как начать разрабатывать в направлении ИИ (на волне хайпа)

Главный язык, который открывает дверь в ИИ-разработку, — Python. Почему? Во-первых, конечно, богатая экосистема — огромное количество библиотек и фреймворков для машинного обучения и ИИ созданы на Python. Во-вторых, скорость разработки — одна и та же логика может занимать одну строчку на Python и пять — на C++. В-третьих, простой и лаконичный синтаксис. Кроме того, язык имеет большое и активное сообщество разработчиков.

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

Однако Python — это только начало. Чтобы решать задачи, нужно еще:

• понимать алгоритмы: от базовых ML до обучения с подкреплением (RL);
• иметь опыт работы с данными;
• знать предметную область, в случае банков — финансы;
• уметь проектировать ИТ-системы.

Кто-то идет в разработку через Python, а кто-то — через «путь воина»: изучая Паскаль, разбираясь, как работают указатели и как работать с памятью. Это, конечно, не про ML, а про возможность по-настоящему понять, как работает компьютер.

Этот опыт тоже важен: он дает насмотренность, понимание, где под капотом происходит магия. Да, писать на Python приятно и получается быстро. Но в реальности, если у вас высоконагруженный сервис, — возможно, необходимо будет переписывать логику на C++.

Что даст нам ИИ в ближайшие годы

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

Среди ожидаемых трендов:

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

Развитие беспилотного транспорта и роботов, способных выполнять физические задачи.

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

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

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

Новички, когда сталкиваются с пет-проектами, бросаются в две крайности. Создают очередной To-Do list, который ничем не выделяется, либо пытаются сделать что-то слишком сложное, например, убийцу Notion, и забрасывают работу на полпути. Так как же выбрать идею, которую получится довести до конца?

Ключевые нюансы при выборе идеи пет-проекта

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

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

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

Как-то я пришёл на хакатон — занимался рекомендательными системами. Тогда был пик популярности Word2Vec — это модель, которая переводит слова в векторы и позволяет находить между ними смысловую близость. Я посмотрел на статистику и увидел: на одном из сайтов 25% запросов не давали результатов. Тут возникла идея, как это улучшить.

Решил собрать демку и сделал прототип: например, на запрос «кресло из крокодиловой кожи» модель показывала зелёные кожаные кресла. Не крокодиловые, но всё равно релевантные запросу.

За неделю допилил прототип до презентабельного состояния, показал коллегам и руководителю. Они дали «зелёный свет», через 2 месяца была первая MVP, которую уже начали продавать существующим клиентам. Ещё через месяц — первый клиент, интеграция, запуск.

Спустя ~5 лет количество клиентов уже измерялось сотнями :)

Подумайте, какие навыки хотите показать

Если делаете проект для портфолио, то можно выбрать несколько вакансий, на которые вы претендуете. Какие там требования к стеку, какие нужны навыки?

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

Не затягивайте со сроками

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

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

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

Не используйте учебные работы, либо используйте их правильно

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

1. У вас и ваших одногруппников эти работы одинаковые. Представьте лицо HR, когда он увидит несколько похожих проектов в разных резюме.
2. Учебные проекты не совсем ваши, ведь вы повторяли код и основные конструкции за преподавателями. Работодателю важно, как вы пишете сами, а не копируете.

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

Всё равно не могу ничего придумать, что делать?

Если самостоятельно не получается что-то придумать, то можно спросить у ИИ.

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

Пример промпта для идеи пет-проекта:

Возьмите задачу с фриланса

Зайдите на любую фриланс-биржу и полистайте разделы с небольшими заказами. Часто там попадаются простые, но жизненные — например, сделать мини-сервис для бронирования столиков или инструмент для учёта личных трат. Никто не обязывает брать заказ — достаточно посмотреть, что нужно заказчикам, и сделать что-то подобное для портфолио.

Спросите друзей или аудиторию в соцсетях

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

У меня был разработчик, уставший от хаоса в списках фильмов, которые он хочет посмотреть. Сделал пет-проект — личный медиапланировщик с нейтральным UI. Проект не стал стартапом, но в портфолио смотрелся отлично. Если сложно — можно взять существующую идею и улучшить. Например, сделать привычный To do-лист с уклоном в UX, нейросети или интеграции. Главное — показать свою силу, а не сделать ещё один клон.

Как довести пет-проект до конца и не забросить его

Вы выбрали идею для проекта, прикинули стек, сроки, пошли писать код и… забросили. Часто бывает, что вначале полны энтузиазма, а под конец либо ничего не получается, либо появляются мысли, что проект — пустая трата времени. Чтобы такого не было, лучше соблюдать следующие правила:

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

Определите для себя MVP — минимальный рабочий продукт, который точно сможете довести до релиза. Всё, что не критично для запуска, сразу откладывайте, иначе перфекционизм и погоня за новыми фичами утащат вас на дно.

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

Разбейте проект на задачи и подзадачи. Например, дизайн плеера, его вкладок, основная логика, подключение API, отладка.

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

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

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

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

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

Если очень грубо, то ориентир выглядит так: 80% кода — это знакомый нам стек, 20% — место для экспериментов и обучения. Такой подход позволяет прокачать новые навыки и довести проект до финала без выгорания.

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

Лучше постараться выработать привычку и заниматься петом, например, каждый день по 30 минут. Не можете соблюдать эту привычку по каким-то причинам? Не проблема, вместо 30 минут найдите 5. Да, за это время вы ничего не успеете, но сохраните «регулярность» — на следующий день будет проще.

Делитесь результатами. Не держите всё в столе, делитесь ходом работы и результатом. Покажите ваш MVP друзьям, обсудите его на форуме, заведите репозиторий на GitHub. Без обратной связи можно легко что-то упустить.

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

А вот ещё несколько советов от Анастасии Егоровой — фронтенд-разработчика, автора программы курса SkillBox по Vue 3 и ведущей ютуб-канала CosyFrontend.

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

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

1. Фиксировать прогресс, например, на доске Trello, чтобы самому видеть продвижение по проекту. Не забывать коммитить в гит. Некоторым разработчикам помогает отписываться о состоянии проекта в личный блог.

2. Избегать перфекционизма — сначала сделать рабочую версию, а потом постепенно ее улучшать.

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

P.S. Когда мы обсуждали тему пет-проектов и их забрасывания в одном из айтишных чатов, один из разработчиков отметил: «А никак не нужно доводить их до конца — пет-проекты для того и существуют, чтобы попробовать на них новую идею и забросить». Так что такое мнение тоже есть, но справедливо ли оно для вас — решайте сами 😀

Как оформить пет-проект

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

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

Чтобы убедиться, что пользователям удобно использовать сервис — запросите обратную связь у знакомых, коллег и родственников. Учтите их замечания.

Упакуйте проект в GitHub. Если у вас пустой репозиторий, который называется my project, то проект никто не оценит. У HR большой поток откликов, иногда они принимают решение за пару секунд, поэтому очень важно, чтобы по вашему репозиторию как можно быстрее можно было понять, что вы сделали, как это работает и какие технологии вы использовали.

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

Добавьте скриншоты, гифки, видео работы сервиса. А ещё лучше его демоверсию.

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

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

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

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

Желательно, чтобы код был чистым, с продуманной архитектурой и, по возможности, прошёл ревью опытных коллег. Будет плюсом, если в проекте видно, что разработчик следит за качеством: пишет документацию и покрывает код тестами.

Распишите проект как кейс. Подготовьте шпаргалку. Это мини-история, где вы рассказываете о проекте. Какая проблема побудила вас его сделать, какие возникли трудности на этапе разработки, как их решали, какой получили результат. У вас получится подробное описание пути разработки от идеи до финала.

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

Главное, не делайте проект ради проекта, старайтесь принести какую-то пользу и здраво оценивайте свои возможности.

Мы в Smart Engines занимаемся разработкой интеллектуальных систем для распознавания документов. Мы уже рассказывали вам, как просто и быстро интегрировать наши решения для распознавания паспорта, а также распознавания жестких и гибких форм в Android.

Сегодня речь пойдет про браузерное распознавание. Оно в последние несколько лет пользуется колоссальным спросом со стороны рынка – прежде всего у финтеха. Кроме того, развертывание PWA-приложений понадобится компаниям при интеграции функциональности в новый отечественный мессенджер MAX.

Поговорим о том, в чем плюсы распознавания в вебе и главное – как его развернуть на примере банковской карты.

Исторический экскурс

Технология WebAssembly (WASM) появилась в 2015 году и два года спустя была реализована во всех основных браузерах. Тогда же ученые Smart Engines начали проводить с WASM первые эксперименты.

Немного похвастаемся: в 2021 году мы первыми в стране представили промышленные технологии для распознавания документов в вебе. Это оказалось очень кстати, поскольку на фоне удаления мобильных приложений из магазинов к интерес к технологиям распознавания QR и банковских карт в браузере вырос.

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

Ответ нашелся быстро – WASM и Smart Engines.

В чем плюсы?

Браузерное распознавание имеет очень много преимуществ. Во-первых, это все преимущества веб приложения:

• Кроссплатформенность;
• Возможность доступа к приложению из любой точки с интернет-соединением
• Мгновенное развертывание и обновление приложения, что позволяет пользователям всегда работать с актуальной версией.

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

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

Все преимущества браузерного распознавания уже оценили наши партнёры, нацеленные на развитие своих интернет-сервисов. Среди них – Альфа-Банк, Газпромбанк и другие.

Распознавание кодифицированных объектов

Одним из самых востребованных направлений в OCR сейчас является распознавание кодифицированных объектов, таких как баркоды, номера телефонов, банковских карт и прочие машиночитаемые зоны.

В своё время мы выделили распознавание таких объектов в отдельный продукт Smart Code Engine для того, чтобы иметь возможность гибче работать с различными сценариями распознавания, а также иметь возможность пойти дальше в деле оптимизации скорости и размера библиотеки. В результате появился Smart Code Engine 2.0 – продукт получил новый интерфейс и возможность максимально гибко настраивать поведение для получения лучшего качества распознавания.

Библиотека Smart Code Engine написана на С++ и портировалась в веб с помощью инструмента Emscripten. Поскольку вся кодовая база, от низкоуровневых вычисления над изображениями до архитектуры поисковой сети, поддерживается нашим научным отделом, качественное портирование не составляло особых проблем.

Js-интерфейс библиотеки представляет собой практически зеркальный С++ интерфейс и с его помощью распознавание банковской карты реализуется вот так:

Этот код необходимо поместить в веб-воркер, чтобы не нагружать UI поток браузера лишними вычислениями.

Передача изображений в библиотеку осуществляется прямо с чтения пикселей элемента canvas, где вы выводите изображения с камеры устройства или прикрепленного файла PDF.

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

Вот как это выглядит на выходе:

Как вы можете заметить, интеграция Smart Code Engine SDK не вызывает сложностей – внедрение происходит практически мгновенно, а скорость распознавания сопоставима с нативными библиотеками.

Спрос на таких специалистов продолжает расти. Средняя зарплата проджект-менеджера в России в 2025 году составляет около 147 000 руб., при этом сеньоры могут получать до 240 тыс. Для продактов цифры еще выше — опытные специалисты в крупных IT-компаниях зарабатывают от 300 000 руб.

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

1. Академия Softline: «Управление проектами в области ИТ»

Академия Softline предлагает актуальный курс в рамках обширной обучающей программы для повышения квалификации. Программа разработана практиками из крупных IT-компаний и охватывает все аспекты работы с проектом.

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

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

Уникальность программы

Курс отличается синтезом мировых стандартов: PMBoK и ITIL интегрированы с гибкими методологиями (Agile, Scrum, Kanban). Такой подход учит адаптировать инструменты под специфику конкретных задач, а не просто следовать шаблонам.

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

Преимущества:

• практическая направленность: 70% времени посвящено работе с реальными кейсами;
• гибкие методики для ИТ-среды: от классического Waterfall до гибридных моделей;
• поддержка наставников с опытом в Сбере, Яндексе и других топовых компаниях.

Что получают выпускники

После защиты итогового проекта участники получают удостоверение повышении квалификации государственного образца и готовое портфолио с реализованным кейсом. Карьерный центр помогает с трудоустройством: студенты 2024 года получили офферы от партнеров (Сбер, МТС, VK) в течение 3 месяцев после завершения курса.

Стоимость и условия

Полная цена программы — 80 000 рублей. Доступна рассрочка на 4 месяца (20 000 руб./мес). Для корпоративных клиентов действуют скидки до 15% при обучении групп от 3 человек.

2. Компьютерная Академия ТОП: «Проджект-менеджер в IT»

Компьютерная Академия ТОП уже несколько лет готовит сильных проджектов для IT-индустрии. Курс подходит тем, кто хочет научиться управлять проектами в условиях неопределенности — именно с этим сталкивается большинство новичков.

Курс длится 10 месяцев и доступен в двух форматах: очном (в 200+ филиалах по России) или онлайн с живыми вебинарами. В отличие от многих программ, здесь нет записанных уроков — все занятия проходят в режиме реального времени с преподавателями-практиками. Каждую группу курирует действующий проджект из IT-индустрии, который дает каждому участнику обратную связь и разбирает ошибки на практике.

Уникальность программы

Живое обучение в малых группах (до 15 человек), где студенты отрабатывают навыки на 12 реальных кейсах — от запуска мобильных приложений до управления релизами SaaS. Например, один из проектов имитирует работу с заказчиком из банковского сектора, где нужно согласовать требования и сроки под жесткими ограничениями бюджета.

Программа обновляется каждые 6 месяцев с учетом запросов работодателей. В 2025 году добавлен модуль по гибридным методологиям (Agile-Waterfall) для госпроектов и FinTech.

Помимо Jira и Trello, студенты осваивают специализированные решения для IT-команд — Axure RP для прототипирования и MS Project для сложных диаграмм Ганта.

Преимущества:

• стажировка у партнеров (VK, Сбер, Тинькофф) после успешной защиты дипломного проекта;
• доступ к закрытому чату выпускников с вакансиями от 500+ компаний;
• сертификация PMI CAPM® включена в стоимость.

Что получают выпускники

По данным академии, до 80%студентов трудоустраиваются в течение нескольких месяцев после выпуска.

В портфолио входят:

• 4 завершенных учебных проекта с метриками эффективности (например, сокращение сроков на 15-20% в симуляциях);
• готовые артефакты: устав проекта, реестр рисков, отчеты по Scrum-спринтам;
• государственный диплом о профессиональной переподготовке и международный сертификат.

Стоимость и условия

• онлайн: 4 590 руб./мес (рассрочка на 10 месяцев);
• очно: 17 910 руб./мес (скидка 15% при оплате за год);
• корпоративное обучение: индивидуальный расчет для групп от 5 человек.

3. ProductStar: «Профессия Продакт-менеджер»

Курс от ProductStar подойдет как новичкам, так и тем, кто уже работает в IT, но хочет перейти в продукт.

Особенности программы:

• 8 месяцев обучения с упором на практику;
• 3 специализации на выбор: B2C, B2B или стартапы;
• работа с Figma, Miro, Amplitude, SQL;
• кейсы от партнеров: Яндекс, МТС;
• подготовка к реальным собеседованиям.

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

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

4. Академия Softline: «Управление проектами по разработке программных продуктов»

Курс от Академии Softline создан для тех, кто хочет научиться выводить проекты на финишную прямую без переработок и конфликтов.

Формат обучения и особенности курса

Курс длится 252 академических часа и реализуется в мультиформатном режиме:

• Живые вебинары с разбором кейсов и домашних заданий от экспертов-практиков.
• Самостоятельная работа на обучающей платформе с доступом к записям и шаблонам документов.
• 80% практики. Симуляции переговоров с заказчиками, разработка проектной документации (устав проекта, реестр рисков, отчеты), защита итогового проекта перед комиссией с обратной связью.

У курса Академии Softline гибкий подход к методологиям управления проектами. В отличие от стандартных программ, здесь учат не просто следовать шаблонам Waterfall или Agile, а адаптировать их под специфику российского IT-рынка.

Особое внимание уделяется работе в сложных условиях — например, управлению изменениями требований, частыми релизами и MVP. Студенты разбирают полный цикл разработки ПО: от архитектурных решений до интеграции с устаревшими системами (legacy), что особенно актуально для разработки новых программных продуктов.

Практическая направленность — еще одна особенность программы. Все теоретические знания сразу применяются в реальных кейсах от партнеров (Сбер, VK, МТС), включая разработку мобильных приложений и SaaS-платформ. Участники осваивают профессиональные инструменты: Jira для трекинга задач, MS Project для построения сложных диаграмм Ганта и Confluence для ведения проектной документации.

Преподаватели курса — действующие проджект-менеджеры с опытом в международных компаниях. Они делают акцент на технических аспектах управления: понимании жизненного цикла разработки ПО (SDLC), базовых принципах DevOps и особенностях работы с API. Это позволяет выпускникам говорить на одном языке с разработчиками и грамотно ставить технические задачи.

Результаты выпускников

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

Выпускники также получают доступ к вакансиям партнеров через карьерный центр Softline, что существенно повышает шансы на трудоустройство.

Стоимость и условия

• полная цена: 156 000 руб.;
• рассрочка: 13 000 руб./мес × 12 месяцев;
• корпоративное обучение: индивидуальный расчет для групп от 5 человек.

5. Нетология: «Продуктовый менеджер»

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

Формат обучения и особенности

Обучение длится 8 месяцев и включает 104 урока в формате видеолекций, практических заданий и живых вебинаров. Студенты работают над собственным продуктом, проходя все стадии разработки: от формирования гипотез до запуска MVP и анализа первых метрик. Каждый модуль завершается практическим заданием, которое проверяют кураторы — действующие продакт-менеджеры из Mail.ru Group, Avito и других компаний.

Основные темы:

• Анализ рынка и целевой аудитории — методы CustDev, построение CJM (Customer Journey Map), выявление Jobs To Be Done (JTBD).
• Продуктовая аналитика — работа с метриками AARRR и HEART, настройка дашбордов, проведение A/B-тестов.
• Финансовое моделирование — расчет юнит-экономики, стратегии монетизации, оценка рентабельности продукта.
• Управление продуктом — создание роадмапа, приоритизация фич, работа с бэклогом и командой разработки.

Что отличает курс:

• Практическая направленность. 70% времени посвящено работе с реальными кейсами, включая задачи от партнеров Нетологии.
• Карьерный модуль. Помощь в составлении резюме, подготовка к собеседованиям, разбор переговоров о зарплате.
• Гибкий график. Возможность изучать материалы в удобное время, совмещая обучение с работой.

Что получают выпускники

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

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

Карьерная поддержка включает доступ к вакансиям компаний-партнеров (VK, Тинькофф), персональные консультации по составлению резюме и подготовку к собеседованиям с HR-специалистами. Для лучших студентов предусмотрены стажировки с возможностью дальнейшего трудоустройства.

Стоимость

Полная цена: 158 160 руб. (доступна рассрочка — 4 393 руб./мес). В рамках корпоративного обучения площадка предлагает индивидуальный расчет для групп.

6. SkillFactory: «Проджект-менеджер в IT»

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

Курс SkillFactory предназначен для тех, кто хочет освоить управление IT-проектами с нуля или систематизировать имеющийся опыт. Программа сочетает теорию с практикой: студенты изучают методологии (Agile, Scrum, Waterfall) и сразу применяют их в реальных кейсах, таких как разработка мобильного приложения или внедрение CRM-системы.

Формат обучения

• Онлайн-вебинары с разбором кейсов от преподавателей-практиков (например, Павла Максимова, который руководил запуском eSIM в России).
• 3 проекта в портфолио: планирование приложения по Agile, внедрение софта для call-центра по Waterfall, дипломная работа — сервис для видео-найма персонала.
• Поддержка наставников, включая персональные консультации и проверку заданий.

Ключевые навыки

Курс фокусируется на практических инструментах:

• работа с Jira, Trello, MS Project для планирования;
• управление бюджетом и рисками;
• проведение ретроспектив и дэйли-митингов (коротких ежедневных собраний команды);
• подготовка документации (уставы проектов, реестры рисков).

Трудоустройство

Выпускники получают доступ к вакансиям партнеров SkillFactory и помощь в составлении резюме. По данным портала hh.ru, средняя зарплата junior-проджекта после курса составляет 95 000–120 000 руб.

Стоимость

Полная цена: 87 000 руб. (доступна рассрочка — 7 250 руб./мес). Включен бонусный курс по нейросетям.

7. GoPractice: «Профессия: Продакт-менеджер»

Программа длится 11 месяцев и предназначена для специалистов, планирующих переход в продакт-менеджмент из смежных ролей (аналитики, маркетологи, проджекты).

Обучение включает пять ступеней:

1. Анализ траекторий перехода в профессию.
2. Освоение основ продакт-менеджмента через кейсы.
3. Работа с симулятором управления продуктом.
4. Дипломный проект.
5. Подготовка к трудоустройству.

Занятия проходят онлайн с гибким графиком. Каждую группу курируют менторы из компаний (Яндекс, Avito, Ozon), которые проводят приветственные звонки и консультируют по заданиям.

Программа

Курс охватывает:

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

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

Результаты

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

Стоимость

Полная цена: 219 900 руб., рассрочка: 18 325 руб./мес × 12 мес.

Как выбрать курс и начать карьеру

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

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

Что такое скоринг

Скоринг — это автоматизированная система оценки заемщика. На основе массы параметров (кредитная история, обороты, данные о владельцах и др.) системе необходимо принять решение: выдать заем или нет, и с каким уровнем риска.

Подход JetLend — не единственный на рынке: банки традиционно опираются на классический андеррайтинг, в то время как некоторые зарубежные peer-to-peer платформы делают ставку исключительно на автоматические модели. У каждого подхода — свои сильные и слабые стороны, и выбор зависит от специфики рынка и аудитории. В случае JetLend ставка сделана на гибрид: ИИ + человек.

Почему одного ИИ оказалось недостаточно

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

При работе только с автоматическим скорингом компания столкнулась с рядом системных ошибок:

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

В результате доля дефолтов начала расти. Поэтому с 2024 года ML-модель используется совместно с андеррайтерами. В рамках реформы риск-модели было внедрено более 40 структурных изменений.

Как работает совместная модель

С 2024 года JetLend внедрил обновленную систему: теперь скоринг проводится одновременно ИИ-моделью и командой андеррайтеров. Это объединило скорость и масштаб ML с экспертной оценкой факторов, на которые автоматика пока не способна.

ML-модель (логистическая регрессия, деревья решений) оценивает вероятность дефолта, выдает рейтинг от 1 до 18. Основная метрика — коэффициент Gini, показывающий точность ранжирования.

ML-модель анализирует риски параллельно с андеррайтерам. Авто-скоринг делает первичную оценку по открытым данным. Риск-специалисты выявляют стоп-факторы, уточняют для ML-модели актуальные объемы бизнеса (по выпискам, бухгалтерско-финансовой отчетности, ответам заемщика с запрошенных внешних источников, долга по данным Бюро кредитных историй), проводят выездные проверки бизнеса и корректируют рейтинг. После этого данные проходят повторный скоринг.

Что потребовалось для реализации

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

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

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

Что изменилось после внедрения совместного подхода

С момента внедрения новой системы, в которой сочетается анализ рисков с помощью ML-модели и андеррайтинга, потребовалось улучшить такие метрики:

• Расширен список стоп-факторов: падение выручки в разные периоды времени, наличие реструктуризированных внешних займов, минимальный размер прибыли и еще свыше 50 новых риск-факторов.
• Автоматический отзыв рейтинга при просроченной задолженности по займу, блокировка траншей при расхождении отчетности и реальных показателей бизнеса.
• На регулярной основе проводится мониторинг по актуальной отчетности Заемщиков для актуализации текущего рейтинга.

Эффект оказался значительным: уровень дефолтов снизился в 2 раза ко II кварталу 2024 года, а к IV кварталу — до 0,25%. Как итог:

• Рейтинги обновлены для всех активных займов, неподходящие — исключены.
• По некоторым займам доходность может быть выше, чем по гособлигациям, но с соответствующим уровнем риска.
• Фактический XIRR по портфелю вырос, доходность по новым займам — от 30% годовых.
• Запущена программа выкупа потерь, позволяющая инвесторам очистить портфель от «токсичных» активов.

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

Вывод

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

Формат живого диалога

Формат паблик-тока для дискуссии «Ломать, пробовать, создавать: на чем строится опыт?» выбран неслучайно. Важно обсуждать вопросы опыта, ошибок и роста с молодыми людьми именно в формате живой беседы между представителями разных индустрий и молодежью. Цель — показать ребятам, что путь к успеху разбивается на маленькие шаги, которые по силам каждому. В эпоху развитых социальных сетей, где видна только красивая картинка, крайне важно показывать и говорить о том, что за этим стоит, выстраивать искренний честный диалог.

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

Газпромбанк активно поддерживает молодые инициативы и видит в новом поколении движущую силу развития. Банк не просто приходит в вузы с карьерными буклетами — мы создаем совместные курсы и проекты, где наши специалисты становятся менторами. Прошлым летом в Университете «Сириус» школьники вместе с нами делали системы биометрического доступа и автоматизированной оценки стоимости недвижимости, а уже в этом году работают над прикладным проектом в области Data Science по оценке инвестиционной привлекательности строительного проекта.

Для профессионального роста нужны не только прикладные знания, но и такие навыки как soft skills и self skills: креативность, стрессоустойчивость, эмоциональный интеллект. Эти качества невозможно получить из учебников — их формируют только опыт, ошибки и постоянное переосмысление. Именно поэтому Газпромбанк.Тех часто участвует в хакатонах и кейс-чемпионатах, дает ребятам решать практические задачи Банка. Такой подход позволяет применить теоретические знания на практике, а также познакомить с ценностями и форматом работы в финтехе.

Ключевые выводы сессии

1. Приоритетные направления для развития

Анна Лемякина, директор по национальным и стратегическим проектам Yandex Cloud, рассказала, что сегодня наибольшую поддержку получают стартапы в здравоохранении, экологии и науке. Важные критерии для успеха:

• Прикладной результат в понятном обозримом будущем, где-то в течение года;
• Масштабируемость;
• Научная база;
• Искреннее желание сделать что-то значимое.

Одним из важных критериев выбора проектов стал прикладной результат. Все проекты, которые мы сейчас поддерживаем, должны показать конкретную пользу.

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

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

Больше 61% студентов-гуманитариев активно используют инструменты на базе искусственного интеллекта для решения рутинных задач. При хорошей стыковке с технарями или при определенных навыках работы с ИИ-инструментами гуманитарии вполне могут реализовать технологические проекты.

2. Команда — это сплав, но важно оставаться людьми

Алексей Федоров, вице-президент Газпромбанка, поделился своим опытом перехода из науки в бизнес. Его история — яркий пример того, как страх может стать катализатором роста.

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

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

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

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

Он подчеркнул: «Эксперт — это человек, который совершил все возможные ошибки» (цитата Нильса Бора). Важно не бояться ошибаться и смело идти в изучение новых сфер.

3. Ищите свою уникальность

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

Свой TOPGUN я построил в 37 лет. Перед этим пробовал открывать бизнесы с 17 лет, у меня было более 30 закрытых бизнесов и накопленных долгов 12 миллионов.

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

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

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

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

4. Если есть идея — реализуй ее

Максим Яхонтов, основатель и генеральный директор «Фиджитех», основатель Hello Park, продемонстрировал более осторожный подход к смене карьеры. В прошлом инженер, а сейчас основатель международной компании по виртуальной реальности, он выбрал плавный переход из корпорации в собственный бизнес.

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

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

5. Нужно формировать смыслы

Один из главных мифов современности — творчество рождается из хаоса и вдохновения. Режиссер-постановщик Андрей Елсаков, чья команда из 200 человек создает крупнейшие мероприятия, категорически с этим не согласен.

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

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

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

Те креативщики, которые говорят о том, что боятся искусственного интеллекта, — это псевдокреативщики. Именно мы те люди, которые формируем смыслы, которые формируем проекты для этого искусственного интеллекта, мы управляем им, а не он диктует нам.

6. Человек учится через деятельность

Вячеслав Шоптенко, заместитель директора института государственной службы и управления Российской академии народного хозяйства и государственной службы при Президенте Российской Федерации (РАНХиГС), предложил альтернативу болезненному набиванию шишек: учебные симуляторы.

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

Вячеслав ссылается на пирамиду обучения, где практический опыт дает до 90% усвоения материала против 10–20% от лекций: «Человек учится через деятельность. Самый эффективный способ обучаться — это практиковаться и обучать других».

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

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

Главный вывод

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

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

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

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

Откуда началось: мой путь в финтех

До Finance.kz я работал в казахстанских финтех-проектах — bai.kz и finbee.kz. Там понял, что рынок агрегаторов в Казахстане находится в зачаточном состоянии. Пользователи мучились, сравнивая предложения банков вручную, а сами финансовые организации не умели эффективно работать с цифровыми каналами привлечения клиентов.

Finance.kz существовал уже более 3 лет, но работал как классический сайт-витрина. Когда я пришёл в проект год назад, стало ясно: нужно полностью переосмыслить подход и создать технологическое решение нового поколения.

Состояние рынка: от монополии к жёсткой конкуренции

Казахстанский рынок агрегаторов финансовых продуктов переживает бум. Ещё два года назад здесь было 2-3 локальных игрока с простейшим функционалом. Сегодня ситуация кардинально изменилась — зашли зарубежные команды: vbr.kz, fintree.kz, moneypanda.com и другие.

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

Технологические вызовы: интеграция с госсервисами и банками

Главная боль при разработке агрегатора в Казахстане — это интеграции. В отличие от рынков СНГ, здесь нельзя обойтись простым партнёрским трафиком. Пользователи хотят получить продукт онлайн, полностью, без походов в офисы.

API-интеграции с банками и МФО

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

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

Интеграция с госорганами

Finance.kz интегрируется с государственными сервисами eGov и Палаты предпринимателей (ПКБ). Это позволяет автоматически подтягивать справки о доходах, данные о трудоустройстве и другие документы, необходимые для получения кредита.

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

Архитектура продукта: ставка на микросервисы

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

Backend

Основные сервисы написаны на Node.js с использованием Express.js. Для работы с базами данных используем PostgreSQL для транзакционных данных и Redis для кэширования. Очереди сообщений реализованы через RabbitMQ — это критично для обработки заявок пользователей.

Отдельно выделили сервис интеграций, который отвечает за взаимодействие с внешними API. Он построен по принципу circuit breaker — если один из банков не отвечает, это не ломает работу всего агрегатора.

Frontend

Фронтенд построен на React с использованием Next.js для серверной отрисовки. Это важно для SEO — львиная доля трафика приходит из поисковых систем по запросам типа «кредит онлайн».

Стратегия «единого окна»: от поиска до получения

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

Для этого мы реализовали несколько ключевых функций:

• Умный подбор продуктов на основе данных пользователя и машинного обучения
• Предварительный скоринг для оценки вероятности одобрения ещё до подачи заявки
• Автоматическое заполнение анкет с подтягиванием данных из госсервисов
• Отслеживание статуса заявки в реальном времени

Монетизация: CPS как основа устойчивого бизнеса

Мы работаем по модели CPS (Cost Per Sale) — получаем комиссию только за успешно выданные продукты. Для кредитов это 2% от суммы, для микрозаймов — фиксированная сумма от 7 до 15 тысяч тенге.

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

Конкурентные преимущества: локализация против красивых интерфейсов

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

Что даёт локальный подход:

• Знание рынка: мы понимаем особенности работы казахстанских банков и МФО
• Связи с регуляторами: легче договариваться об интеграциях с госорганами
• Техническая экспертиза: наша команда уже прошла путь интеграции с местными API
• Гибкая настройка продукта под изменения законодательства и требований ЦБ

Результаты и метрики

За год активного развития мы достигли:

• 150 000 уникальных пользователей в месяц
• Интеграция с 15+ финансовыми организациями
• Конверсия заявка-выдача на уровне 35-40% (против 15-20% у конкурентов)
• Средний чек по кредитам — 1,2 млн тенге, по микрозаймам — 85 тысяч

Планы на будущее: от агрегатора к экосистеме

Ближайшие 1-2 года будут критичными для всего рынка. Мы видим несколько ключевых направлений развития:

Расширение продуктовой линейки

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

Внедрение ИИ и машинного обучения

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

Международная экспансия

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

Собственные финансовые продукты

В долгосрочной перспективе планируем получить лицензию МФО и предлагать собственные займы наиболее качественным клиентам.

Уроки и выводы

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

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

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

*Зарплаты указываем в год до уплаты налогов, в долларах США, чтобы было проще. Курс валют — по состоянию на май 2025 года.

Россия

Зарплаты в российском IT сильно зависят от региона, компании и направления. В среднем junior-разработчики получают от $9 500 в год — примерно $800 в месяц. Middle — около $22 800 в год или $1 900 в месяц, а Senior — от $40 000 в год и выше.

Отдельно стоит отметить DevOps-специалистов и аналитиков данных — их доходы на 10–20% выше, чем у разработчиков на тех же грейдах. Если у миддла-бэкендера годовая зарплата составляет $23 000, то DevOps или data scientist может зарабатывать от $25 000 до $28 000 — особенно в крупных компаниях, финтехе или инфраструктурных проектах.

Что касается трат:

• Аренда: студия в Москве обойдётся от $650–750 в месяц, не в центре и без вида на Москва-Сити. Чаще всего это обычный дом с окнами во двор или на соседний проспект.
• Транспорт: поездка в метро стоит $0.6, каршеринг — $5−7 за поездку из окраины в центр, если не стоять в пробках по часу. Шеринг удобнее и дешевле такси, когда умеешь парковаться. Расходы на бензин — примерно $0.75 за литр 95-ого.
• Питание: обед в кафе — $10-15, фастфуд — от $3.
• Хобби: спортзал — от $30 в месяц, настолки — бесплатно, если друзья не жадничают.
• Медицина: формально — бесплатно по ОМС, но с очередью на месяц к узким специалистам. В реальности многие пользуются ДМС от работодателя.
• Соцзащита: отпуск по ТК, декрет, субсидированные детсады — всё это работает, особенно в крупных городах.

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

Я, наверное, не самый типичный айтишник — не живу по полгода в тёплых странах, а рестораны уже перерос. Работаю удалённо из Красноярска, зарабатываю около 3 млн рублей в год. Этого хватает на ипотеку, хобби и дальние поездки на машине. С семьёй любим путешествовать по России — были на Байкале, в Бурятии, на Алтае. Работа стабильная, требует внимания и постоянного роста. В свободное время занимаюсь тайским боксом, собираюсь этим летом попробовать стендовую стрельбу и парусный спорт. Живём в частном доме за городом, так что дел хватает и по хозяйству, и с детьми — у нас их двое. А в прошлом году поступил в Политех на заочку.

США

В американском IT уровень дохода сильно зависит от штата, компании и направления. В среднем цифры следующие: Junior-разработчики зарабатывают от $80 000 в год, middle — около $120 000, а senior — от $150 000. Специалисты в DevOps и Data Science получают от $130 000 до $160 000, особенно если работают в крупных технологических компаниях: FAANG и аналогах.

Теперь — о жизни и расходах:

• Аренда: студия в Сан-Франциско обойдётся в $2 800–3 500 в месяц, и это без вида на мост. В Нью-Йорке — не дешевле.
• Транспорт: личная машина — почти необходимость, особенно за пределами крупных городов. Бензин стоит около $1 за литр, страховка и обслуживание — ещё пара сотен в месяц.
• Еда: чашка кофе — $5, бургер — $15, полноценный обед — $25 и выше.
• Хобби: абонемент в спортзал — от $50, подписки на Netflix и Spotify — $70+ в месяц, занятия вейкбордингом или сёрфингом — от $100 за уикенд.
• Медицина: страховка — почти обязательна, стоит $400–600 в месяц, без неё любая простуда превращается в финансовую катастрофу.
• Соцзащита: частные компании дают отпуск по 10–15 рабочих дней, не везде предусмотрены оплачиваемые больничные.

Даже на позициях сеньора жить одному в центре города — дорого. Многие арендуют жильё с соседями или уезжают в пригороды, где цены ниже, но без машины уже не обойтись. IT даёт возможность быстро расти в доходах, особенно в стартапах или FAANG, но и конкуренция — как на драфте в NBA.

Работаю в команде, которая развивает AI-сервисы для терминала Bloomberg — системы, которой пользуются финансисты и госструктуры по всему миру. Мы делаем что-то вроде встроенного голосового ассистента, способного анализировать биржевые и новостные данные. Я хожу в офис 4 дня в неделю — так проще держать ритм. День проходит между кодом, митингами и кофе. В свободное время стараюсь выжать максимум из Нью-Йорка: волейбол, теннис, пробежки в Центральном парке, театр, джаз-клубы и нескончаемый ремонт квартиры. Летом почти каждые выходные — выезды за город. Социально влиться в Нью-Йорк несложно: тут очень много мигрантов и разных культур. Хотя иногда интроверт во мне побеждает — и тогда я с радостью остаюсь дома с женихом.

Германия

IT-специалисты получают умеренные по западным меркам зарплаты, но выигрывают за счёт социальной защиты и предсказуемого качества жизни. Junior-разработчик зарабатывает около $50 000 в год, middle — около $65 000, а senior — от $90 000. Специалисты в DevOps и Data Science в крупных городах вроде Берлина или Мюнхена могут получать до $100 000–110 000 в год.

Что с расходами:

• Аренда: студия в Берлине обойдётся в среднем от $1 000 в месяц. Цены растут, но пока остаются ниже, чем в США или Великобритании.
• Транспорт: месячный проездной стоит около $65, но многие предпочитают велосипед. Бензин дорогой — почти $2 за литр.
• Еда: буханка хлеба — $2.20, обед в недорогом кафе — $15–25, ужин дома из супермаркета — ощутимо дешевле.
• Хобби: абонемент в фитнес — $35–45 в месяц, а на концерты и выставки часто можно попасть бесплатно или по символической цене.
• Медицина: государственная страховка обходится в около 7% от зарплаты, но почти полностью покрывает услуги — от стоматологии до психотерапии.
• Соцзащита: минимум 30 дней отпуска в год, оплачиваемые больничные с первого дня. Декретный отпуск — до 3 лет, с выплатами до 14 месяцев.

Жизнь в Германии структурирована: middle-разработчик уже может жить один, часто — с балконом и кладовкой. Senior — в двухкомнатной квартире с партнёром и кошкой. Овертаймы — редкость. Если кто-то продолжает переписку в Slack после 18:00, это воспринимается как тревожный звонок, признак неэффективности или выгорания.

Живу в Германии с 2017 года. За это время многое стало привычным, но до сих пор приятно удивляет. Рабочая культура устроена так, что никто не жмёт на газ: овертаймы — редкость, а 30 дней отпуска в году — норма. Люди не соревнуются, кто больше переработал. Быть просто хорошим разработчиком — это ок. Германия удобна и в быту: развитый общественный транспорт, автобаны для любителей машин, зелёные леса, замки, Альпы под боком. А ещё — комфортная среда для жизни: много IT-компаний, доступная инфраструктура, возможность работать супругам и высокий уровень безопасности. Неудивительно, что всё больше айтишников выбирают именно эту страну.

Япония

Разработчики в Японии зарабатывают в среднем:

• джуниоры — около $30 000 в год,
• миддлы — $45 000,
• сеньоры — до $70 000.

Специалисты в DevOps и Data Science могут получать $80 000–90 000, особенно в крупных корпорациях, где создают сервисы на международный рынок.

Расходы на жизнь:

• Аренда в Токио: от $800 за небольшую квартиру; чем ближе к центру — тем выше цена, но и инфраструктура удобнее.
• Транспорт: безлимитный проездной — от $100/мес, метро работает как по расписанию NASA. Бензин — примерно $1.3 за литр. Мигрантам стоит запомнить: в Японии все едут по левой стороне дороги, приоритет у помехи тоже слева.
• Еда: обед в кафе обойдётся в $6–9, ужин в раменной — около $10. Продукты в супермаркетах стоят дороже, чем в других азиатских странах.
• Хобби: повсюду геймерские клубы, общества любителей манги, тематические кафе. Расходы сильно зависят от степени увлечённости.
• Медицина: обязательная страховка равна примерно $100 в месяц и покрывает основное лечение и визиты к врачу.
• Соцзащита: формально надёжная, но важные детали могут быть в трудовом контракте — особенно у иностранцев.

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

Переезд в Японию оказался проще, чем я ожидал. Виза, жильё, оформление документов — всем занималась компания, даже трансфер из аэропорта организовали. Рабочий язык в офисе — английский, коллеги со всего мира. Квартиру нашли за две недели, на первое время предоставили временное жильё. Оборудование для домашнего офиса — за счёт компании. В быту выручают Google Translate и ChatGPT, с их помощью можно спокойно решать повседневные вопросы. Жизнь здесь удивительно комфортна, если есть поддержка и интерес к культуре.

Великобритания

Разработчики в Великобритании получают в среднем:

• джуниоры — около $45 000 в год,
• миддлы — $65 000,
• сеньоры — до $90 000.

Специалисты в DevOps и Data Science зарабатывают $90 000–110 000, особенно в Лондоне и Эдинбурге, где востребованы кадры для банков, финтеха и стартапов.

Расходы на жизнь

• Аренда в Лондоне: около $2 300 в месяц за однушку в приличном районе. Дешевле — только если снимать комнату или уехать за МКАД… простите, за M25.
• Транспорт: проездной Oyster — от $200 в месяц. Лондонское метро — как музей под землёй: готический интерьер с сюрпризами. Бензин стоит $1.8 за литр, а дорожное движение — левостороннее, как и в Японии.
• Еда: ужин в индийском кафе — $12, пинта пива в пабе — $7, а поход в супермаркет способен сильно удивить — и не всегда приятно.
• Хобби: парки, бесплатные музеи, стендап-клубы, тематические коворкинги и даже кружки настолок — скучать сложно.
• Медицина: государственная система NHS бесплатна, но нужно привыкнуть к очередям и записи к терапевту через две недели.
• Соцзащита: 25+ дней отпуска, стабильные трудовые контракты и работающие профсоюзы.

Зарплаты позволяют комфортно жить, особенно за пределами Лондона. Девопсы и дата-сайентисты — нарасхват. Английский знать нужно, но в отличие от Японии — вы его хотя бы слышали в школе. Карьерный рост возможен, особенно если знаете, чего хотите и умеете себя продать.

Я переехала в Лондон из Польши после восьми офферов и долгой проверки на визу — сам процесс занял почти восемь месяцев. Компания оплатила аренду на первый месяц, помогла с оформлением визы, а постоянное жильё мы уже искали с учётом школы для ребёнка. Сейчас мы вдвоём с мужем работаем разработчиками. На аренду и еду уходит около 30% дохода. Продукты стоят примерно как в Польше, бытовая химия даже дешевле. В быту и на работе используем английский, и это сильно упрощает адаптацию. Уровень жизни высокий, зарплаты достойные, а IT-комьюнити — очень живое и дружелюбное.

Давайте сравним

Где жить — зависит не только от зарплаты, но и от того, как вы хотите жить. Кто-то хочет в Альпы, кто-то — в аниме-рай, кто-то — чтобы мама могла приехать на выходные. И это нормально.

Но если выбирать по зарплате — вот наглядная таблица с доходами и расходами в месяц.

Заключение

Выбирать страну для релокации сложно, потому что влияет много факторов. Не стоит опираться только на принцип большей зарплаты. $5 000 в Германии и $5 000 в США — это совсем разные уровни жизни. Кто-то готов жертвовать отпуском ради денег, а кто-то предпочитает стабильность и детский сад по госпрограмме. Лавандовый раф тоже влияет.

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

Более 400 профессионалов приняли участие — разработчики, инженеры и тимлиды из ведущих компаний, таких как Сбер, Т-Банк, Яндекс, VK, Авито и другие. Посетители могли погрузиться в атмосферу работы в банке, послушав доклады на Hard- и Soft-треках, а также приняв участие в активностях в экспозоне с 16 ИТ-направлениями.

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

Как мы перестроили разработку

Первый Вице-Президент Газпромбанка Алексей Ульенков открыл конференцию и рассказал про инженерную трансформацию банка за последние несколько лет.

В 2021 году в банк пришла новая управленческая команда. Ее целью стала трансформация разработки для розничного бизнеса до уровня лучших российских банков и финтех организаций. За три года трансформации удалось достигнуть среднего срока вывода новых продуктов в 2 месяца, доля собственной разработки по ключевым системам близка к 100%, а доля клиентских жалоб на цифровые сервисы находится на историческом минимуме.

Это стало возможным благодаря нескольким ключевым принципам:

• Все производство покрыто метриками эффективности (DORA-метрик);
• Переход на собственную разработку;
• Участие всех инженеров в написании кода;
• Переход к парадигме тестирования в разработке (shift left) для раннего получения обратной связи о качестве;
• Ориентация на бизнес-результат.

Время вывода нового продукта в Газпромбанке сейчас занимает 2 месяца, для сравнения — в других банках это 3-4 месяца. Доля инхаус-разработки для ключевых систем — 95%.

Цели команды на 2025 год:

• Внедрение помощников на баз LLM для разработчиков, автоматизаторов тестирования;
• Замена OpenShift на k8s;
• Полная миграция в новое рабочее окружение;
• Основные работы по выносу бизнес-логики из АБС и импортозамещению;
• Масштабирование практик SRE;
• Тиражирование стандарта разработки.

API-First: когда контракт важнее кода

На нашем мероприятии мы уделили отдельное внимание одному из самых актуальных подходов в разработке. Об особенностях перехода на API-First рассказал Максим Морозов. Суть подхода в том, что сначала создается четкий контракт (API), который становится основой для параллельной работы команд, и только потом пишется код. Это противоположность традиционному Code-First, где сначала создаются программные компоненты, а затем решаются проблемы их интеграции.

В масштабе крупной организации, где работают сотни команд, API-First становится не просто полезной практикой, а необходимым условием эффективной работы. Когда 200 команд и 2000 инженеров должны взаимодействовать без задержек, четкие контракты между системами критически важны для сокращения Time-to-Market.

Виктор Цветков и Юлия Григорьева поделились опытом внедрения API-First. Их доклад был не столько о технических аспектах, сколько о том, как преодолевать организационное сопротивление.

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

Результат: в розничном блоке и МСБ уже более 50 команд перешли на API-First, 127 сервисов подключены к генератору кода, а из общего количества 1033 сервисов уже 450 имеют спецификацию.

Trunk-Based Development: как выжить, когда все коммитят в одну ветку

Вадим Ваганов рассказал о Trunk-Based Development (TBD) — подходе, который многим сначала кажется безумием: одна интеграционная ветка (trunk/main), куда все разработчики напрямую вносят изменения. Вадим поделился проблемами, с которыми столкнулись при внедрении, и тем, как их решали.

Для успешного внедрения TBD нужно полностью переосмыслить процесс ревью кода. Фишка в инверсии ответственности: теперь не ревьювер обязан найти время проверить ваш код, а вы, как автор MR, отвечаете за то, чтобы ваш код был проверен быстро и качественно.

Еще одно важное правило — «Общий только trunk!». Ветки создаются только для конкретных задач, ветвятся только от trunk и живут максимум несколько дней. Следующая важная мысль: «Деплой не равен релизу». Благодаря Feature Toggles можно часто деплоить в продакшн, но включать новую функциональность лишь тогда, когда это нужно бизнесу.

В результате команда получает быстрое прохождение MR через ревью, уверенность в стабильности основной ветки и возможность безопасно деплоить в любой момент.

Инженерный рост, ускорение тестирования и мониторинг

Роман Олеск затронул тему, близкую каждому технарю — «Как быть инженером». По его мнению, настоящий инженер — это тот, кто не просто пишет код по ТЗ, а понимает весь путь задачи и может влиять на процесс в любой момент.

Никакой воды и абстрактных рассуждений. Роман дал конкретные советы: как готовиться к собеседованиям (спойлер: это просто навык, который можно прокачать), как строить индивидуальный план развития и почему регулярные 1-на-1 встречи с руководителем — это не просто галочка в HR-процессах. Кстати, у него даже есть рецепт идеальной 1-на-1 встречи: 10% времени — про жизнь, 45% — про проект, остальное — про развитие. А еще мы как бы между делом рассказали про наш внутренний профиль инженера. Прокачал нужные навыки — получил «ачивку». Геймификация в действии!

На другой стороне спектра — практический доклад Кристины Клигер о том, как перестать работать ночами и начать выкатывать фичи в прод по нескольку раз в день. Ее рецепт — правильно выстроенное тестирование, особенно компонентное и API.

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

Валентин Лебедев рассказал, как в банке применяют MaaS (мониторинг как сервис) — подход, когда мониторинг превращается из головной боли в удобный инструмент самообслуживания. Суть простая: видеть проблемы раньше, чем клиенты успеют пожаловаться. Классическая проблема — мониторинг нужен всем, но настраивать его сложно, а разбираться в PromQL хочется далеко не каждому. Поэтому команда создала набор инструментов, где можно просто включить нужные функции анализа. Например, написали собственный плагин для VictoriaMetrics, чтобы инженерам не пришлось становиться экспертами по всему стеку мониторинговых решений.

Что было в экспозоне

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

На стенде тестирования мы запустили Mission: QApossible — квест, где участникам предстояло стать QA-спецагентами, собрать идеальный набор инструментов и спасти мир от багов. Ну, или хотя бы спасти релиз от откатов.

У мобильных разработчиков играли в Mobile Jenga: нужно было собрать приложение для iOS и Android, убрав лишние блоки, но так, чтобы вся конструкция не рухнула. Метафора понятна, да?

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

Интересно было и у бэкендеров. Они подготовили несколько хитрых задач на логику, которые заставляли участников как следует поразмыслить. А фронтендеры организовали две активности: «КОДетектив», где нужно было угадать язык программирования по фрагменту кода, и Bug Hunting с заданием найти в коде уязвимость. К стендам выстроились очереди из желающих проверить свои навыки.

Квартирник: как быть с токсиками в команде

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

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

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

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

Обсуждали и практические инструменты. Например, как объективно измерить токсичность (один из вариантов — оценка 360 градусов)? А также способы снижения уровня токсичности: регулярная похвала за успехи, материальное стимулирование и «радикальная прямота» — умение честно говорить о проблемах, не переходя на личности.

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

Было круто, будет еще круче

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

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

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

Узнать больше о нас и наших проектах можно в телеграм-канале и на сайте Газпромбанк.Тех.

Когда бизнес затребовал систему для обработки транзакций в реальном времени с пиковой нагрузкой в 50 тысяч операций в секунду, я понял, что серые будни enterprise инженера наконец станут весельем. Наш сервис должен был не просто работать — он должен был дышать под давлением, сохраняя отклик в пределах 10 мс. Не все проблемы в мире можно решить горизонтальным масштабированием, и одним из камней преткновения стала Java, а точнее — её «мусор».

Выбор GC: G1, Shenandoah или ZGC?

Первое, с чем столкнулась наша команда, — продолжительные STW-прерывания при нагрузке. Изначально использовали G1GC как «дефолтный» выбор для баланса между latency и throughput. Но под нагрузкой 80% CPU даже G1 не справлялся: пиковые паузы достигали 400 мс, что для платежей было неприемлемо.

Мы устроили мозговой штурм с performance-инженерами. Варианты:

1. Shenandoah — низкие паузы, но требуется больше CPU.

2. ZGC — субмиллисекундные паузы даже на терабайтных хипах, но тогда (на старте проекта) он был экспериментальным в OpenJDK 11.

3. Ручная настройка G1 — максимизировать предсказуемость через MaxGCPauseMillis и InitiatingHeapOccupancyPercen.

После недели тестов на стенде с имитацией пиковой нагрузки (JMeter + Gatling) и профилирования через async-profiler, выбор пал на ZGC. Его паузы не превышали 2 мс даже при 32 ГБ куче, а алгоритм «цветных указателей» позволял масштабироваться без блокировок. Риск? Да. ZGC был новым, но его поддержка в последних LTS-версиях и тесты убедили нас.

Тонкая настройка и проклятие «тихих» утечек

С ZGC мы выставили:

1. -Xmx48g (с запасом для избежания частых аллокаций),

2. -XX:SoftMaxHeapSize=40g (чтобы ZGC активнее возвращал память ОС),

3. -XX:+UseLargePages (снижение overhead на page faults).

Но через месяц нагрузочного тестирования обнаружили «ползучее» увеличение потребления памяти. Performance-команда, анализируя дампы через Eclipse MAT, нашла проблему: кэш данных транзакций в Apache Ignite не учитывал soft-ссылки, накапливая объекты. Вместо ConcurrentHashMap перешли на `Caffeine` с политикой expiry после 10 секунд, что снизило давление на GC.

Команда performance-инженеров: алхимики метрик

Работа с perfomance-инженерами напоминала лабораторию безумных ученых. Каждый параметр JVM, каждый HTTP-эндпоинт тестировался через JMH, а Grafana-дашборды визуализировали следующее:

1. GC pauses (ZGC собирал статистику через -Xlog:gc*),

2. Allocation rate (до 1.5 ГБ/сек в пиках),

3. CPU utilization (наши самописные RateLimiter’ы съедали 15% ресурсов).

Совместно мы написали скрипты на Python, которые автоматически подбирали -XX:ConcGCThreads и -XX:ParallelGCThreads в зависимости от нагрузки на CI/CD стендах. Это сократило время настройки на 70%.

Продакшн: огненное крещение

После релиза первые дни мы мониторили всё: New Relic для трейсинга медленных методов, Prometheus для сбора JVM-метрик. ZGC не подвел — 99-й перцентиль отклика оставался на уровне 12 мс. Но однажды ночью мы получили алерты по потреблению CPU. Оказалось, фоновый процесс генерации отчетов создавал миллионы временных объектов. Решение: выделили его в отдельный микросервис с выделенным пулом памяти и CMS (ему хватало).

Итоги

Через полгода система обрабатывала 55k операций/сек с пиковыми паузами GC в 1.8 мс. Главные уроки:

1. GC — не серебряная пуля. Даже ZGC требует понимания аллокаций в коде.

2. Performance-инженеры — ваши лучшие союзники. Их взгляд со стороны JVM спас нас десятки раз.

3. Документировать всё. Наши конфиги и скрипты настройки GC стали стандартом для других команд банка.

Теперь, когда я вижу, как сервис работает без перебоев, вспоминаю те бессонные недели с дампами и тестами… и понимаю: это того стоило. Ведь в мире highload каждая миллисекунда — это деньги. Или, как говорят у нас в банке, «миллисекунда — миллион».

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

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

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

Что случилось с рынком: цифры, которые пугают

2024 год стал точкой невозврата для IT-индустрии. Компании, зарубежные и российские, которые ещё вчера нанимали разработчиков сотнями, сегодня объявляют о сокращениях.

CNews написали, что некоторые отечественные компании хотят сократить как минимум 30% айтишников, а в отдельных случаях — до половины штата. Про ИИ в заявлениях ни слова, но люди всё равно переживают. В Твиттере, на Пикабу и Хабре всё больше обсуждают, как быстро нас всех заменит ИИ и кто будет первым: фронтендеры, копирайтеры или техподдержка?

В США ситуация тоже непростая: доля безработных айтишников выросла с 3,9 до 5,7% всего за один месяц. Но в отличие от наших компаний западный бизнес иногда признаётся, что сократил сотни человек из-за ИИ.

В начале этого года IBM начала мягкие увольнения в области финансов через требования переехать ближе к хабам компании. Параллельно компания внедряет ИИ-технологии в операционку и заменяет ими реальных людей. В PayPal уволили около 9% сотрудников, а за несколько дней до этого запустили проект с ИИ. Не выглядит как совпадение.

На фоне этого акции Meta *, Google и NVIDIA бьют рекорды — инвесторы надеются на «революцию ИИ».

Лирическое отступление: что думают люди

Мнения разделились. Некоторые очень сомневаются в том, что ИИ — соперник человека. Скорее это очень сообразительный помощник, за которым всё равно нужно следить.

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

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

Почему компании увольняют IT-специалистов

Во время ковида рынок IT-специалистов резко вырос: компании массово нанимали людей, чтобы поддерживать цифровизацию, онлайн-сервисы и удалённую работу. Сейчас спрос стабилизировался, и перенасыщение рынка привело к закономерным увольнениям. Но это одна из причин.

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

Некоторые уже заменили часть команды на искусственный интеллект:

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

Порассуждаем, какую выгоду ИИ приносит бизнесу.

Помогает с рутиной

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

Anketolog.ru и Mediacom.Expert опросили 1 100 представителей ИТ-сферы. 57% опрошенных считают, что именно автоматизация рутины — главный плюс ИИ. А 53% специалистов назвали ключевым преимуществом нейросетей увеличение продуктивности.

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

Снижает расходы

Бизнес ищет способы снизить затраты, и один из них — внедрить ИИ. По данным исследования Стэнфорда, 42% компаний подтвердили, что нейросети помогли сократить расходы.

Например, Walmart посчитал, что ИИ на 10% увеличил продажи и на 20% сократил излишки закупок. А исполнительный директор Klarna, шведской финтех-компании, заявила, что их ИИ-ассистент уже может с лёгкостью заменить труд 700 специалистов техподдержки.

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

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

Выгодно ли это на самом деле

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

(Не)дешёвый код

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

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

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

Деградация экспертности

В начале года Microsoft провёл исследование, которое показало: чем больше мы используем ИИ, тем хуже наше критическое мышление. Мы слишком сильно полагаемся на готовые решения, а иногда даже не пытаемся подумать над ними самостоятельно.

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

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

Разочарование акционеров

Искусственный интеллект — это не только тренд, развлечение и инструмент для работы, но и новое золото для акционеров.

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

На Reddit можно прочитать историю контент-мейкера, которого решили заменить с помощью ChatGPT и нескольких джуниор-копирайтеров. Через две недели его попросили вернуться, но парень отказался.

И скорее всего, это не разовая акция. Кстати, об акциях. Вопрос окупаемости ИИ волнует не только компании, но и инвесторов.

Goldman Sachs в своём отчёте задались логичным вопросом: в ИИ вложили около триллиона долларов — а что на выходе? Пока что главное достижение — разработчикам стало работать проще. Ну и в соцсетях можно посмотреть на Марка Цукерберга, неожиданно заговорившего по-русски.

Аналитик Джим Ковелло в этом отчёте предполагает, что эта сумма так никогда и не окупится: нет таких дорогих задач, которые под силу искусственному интеллекту.

Прав ли он? Время покажет.

ИИ без базы знаний — деньги на ветер

Даже самый продвинутый ИИ бесполезен, если «кормить» его устаревшими материалами. Это приведёт к ошибкам и некачественному коду. А дальше — убытки, репутационные риски и ещё раз убытки.

Именно такие риски грозили Amazon ещё в 2017 году, когда компания пыталась внедрить ИИ для подбора персонала. Нейросеть училась на данных, в которых было больше мужских кандидатур, и поэтому отдавала предпочтение именно мужчинам. По итогу Amazon от этой технологии отказался, так как получилось не очень этично.

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

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

Дыры в безопасности

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

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

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

Но не все так осторожны. В 2023 году сотрудники Samsung трижды (!) поделились с ChatGPT исходным кодом компании, из-за чего этот код добавился в базу для обучения нейросети. Это произошло случайно: работники Samsung просто не знали, как именно работает ИИ-чат. Судя по всему, к каким-то критичным последствиям это не привело. Но это скорее везение.

Чем компании могут заменить массовые увольнения

Сокращения неизбежны, потому что ИИ может выполнять простые задачи намного лучше нас. Да и рынку не нужно такое количество IT-специалистов, как раньше.

Бум диджитализации закончился, и даже Марк Цукерберг постепенно сокращает штат. К концу пандемии в Meta * было 87 000 специалистов. Но уже в 2023 году он уволил 10 тысяч человек, а в начале 2025-го — ещё 5%, примерно 3 600 сотрудников.

Тем не менее пример Цукерберга — не призыв к действию. Бизнес может обойтись без массовых сокращений, если продумает долгосрочную стратегию.

Переформатировать, а не сокращать

Компании могут сохранить команду и перераспределить ресурсы:

1. Переобучить сотрудников. Например, IBM в 2020–2023 годах инвестировала 1 млрд долларов в переподготовку своих специалистов для работы с ИИ.
2. Создать новые роли. Вместе с ИИ появились и новые профессии — промпт-инженеры и ИИ-тренеры. Это направление уже осваивают Microsoft, Google и российский «Яндекс».
3. Построить гибридные рабочие модели. Переключать членов команды на задачи, где нужен человеческий опыт: креатив, стратегия, коммуникация с клиентами. А рутину оставить искусственному интеллекту.
4. Учесть риски и преимущества ИИ. Маленьким компаниям стоит проводить «ИИфикацию» только в том случае, если искусственный интеллект действительно принесёт пользу. Потому что есть риск, что вы больше потратите, чем сэкономите. Интеграция нейросетей в бизнес-процессы может стоить недёшево.

Внедрять ИИ осмысленно

Любые изменения стоит делать не рывком, а постепенно. Например:

1. Можно начать с малого, например, автоматизировать техподдержку, и проверить, не просядет ли качество.
2. Считать расходы правильно — учитывать не только зарплаты, но и затраты на платформы, ML-инженеров и доработки, которые вносятся в сгенерированный нейросетью результат.
3. Стоит отдавать предпочтение закрытым и безопасным ИИ-моделям, чтобы не сливать данные конкурентам и не подводить своих клиентов, выдав их личную информацию злоумышленникам.
4. Обучать ИИ только на проверенных данных. Это снижает риск ошибок и «галлюцинаций» модели.

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

Чтобы решить эту проблему, бизнес внедряет системы управления знаниями, которые помогают не только команде, но и ИИ. Например, в Minerva Knowledge можно объединить знания всей компании: создать статьи и инструкции, загрузить любые документы и файлы, а потом легко найти их с помощью умного поиска.

А ассистент с генеративным ИИ сам анализирует контекст и подсказывает ответы на основе материалов из базы знаний.

Для айтишников: в какую сторону двигаться

Уже поздно делать вид, что ИИ — это несерьёзно и скоро о нём все забудут. Поэтому в такой ситуации можно приспособиться к изменениям.

• Дружба с ИИ. Можно использовать ИИ-помощников в работе, но с проверкой их ответов.
  
• Автоматизация рутины. Можно поручить ИИ тестирование, документацию, деплой, чтобы тем самым освободить время для задач, где нужна экспертность.
• Изучение промпт-инжиниринга. Очень важно точно формулировать запросы к ИИ, чтобы он смог дать качественный ответ. Советы можно посмотреть в гайдах от OpenAI.

• Анализ рынка. Можно изучить вакансии — например, AI-тренера и промпт-инженера. Вдруг вас заинтересует сфера ИИ и нужно будет начинать карьеру с джуновских вакансий.

А для тех, у кого есть опыт, зарплатная вилка будет выше. Например, для ИИ-разработчика на Python. Если уже пишете на нём, сменить профессию будет проще.

Некоторые веб-разработчики уже всерьёз задумались, не стоит ли перейти в эту область.

ML-специалисты получают больше веб-разработчиков, теперь это новый тренд в ИТ

Подытожим.

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

Что будет дальше — увидим уже очень скоро. А пока что в IT есть место и людям, и нейросетям.

*Компания Meta признана экстремистской на территории РФ

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

Hard

Наш хардовый трек — для тех, кто в проде с закрытыми глазами. API First, компонентные и контрактные тесты, мониторинг и SRE. Обсудим реальные кейсы нашего банка и как мы создаём системы, которые работают стабильно и эффективно.

Как внедрить API First в сложную финтех-инфраструктуру с учетом legacy-систем? Разберем, почему стандарт AsyncAPI не всегда подходит для крупных систем, как мы адаптировали его под наши реалии и разработали собственные инструменты.

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

Head of profession QA Кристина Клигер поделится, как через развитие команды тестирования можно быстро доставлять фичи до клиентов и радовать бизнес.

Глава центра развития ИТ-мониторинга Валентин Лебедев раскроет секреты превращения мониторинга в сервис. Живет ли OpenSource в крупных предприятиях?

Soft

В ламповой уютной атмосфере на пуфике с бутером в руке обсудим, что такое настоящий софт. Как растить инженеров, внедрять изменения и работать с сопротивлением команд и представителей бизнеса.

СТО Виктор Цветков и Head of profession SA Юлия Григорьева расскажут, какие способы внедрения изменений существуют по степени мягкости. Почему важно учитывать корпоративную культуру при работе с изменениями. Далее поговорим про неотъемлемую часть — обучение команды и работе с их сопротивлением новым практикам. Поделимся нашими лайфхаками и секретами.

Head of Profession Вадим Ваганов объяснит, зачем коммитить в main несколько раз на дню. Спойлер: чем чаще релизишься, тем меньше ошибок.

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

Экспозона

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

16 стендов объединят вместе ИТ-направления в нашем банке:

Data Science, RPA, Искусственный интеллект, Инновации, Database, Backend, QA, DevOps, Frontend, Мобильная разработка iOS и Android, Product Design, Кибербезопасность, Business Analysis, System Analysis, IT Recruitment и Agile.

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

Нетворкинг

После официальной части мероприятия приглашаем остаться и продолжить общение в неформальной обстановке. С нас космические угощения и напитки!

Как закоммититься

Вход по мультипаспорту:)

Торопись, количество мест ограничено!

До встречи на GPB CONF!

А тут можно узнать больше о наших проектах.

Visual Studio Code. Лидер среди редакторов кода

Бесплатный, универсальный IDE от Microsoft. Поддерживает все языки программирования и Git. Главная особенность — тысячи расширений. Заточен под разработку программных продуктов небольшой и средней сложности, отлично подходит для начинающих разработчиков.

JetBrains IntelliJ IDEA / WebStorm / PyCharm — лучшие IDE для Java, JS, Python

Несколько продуктов в виде профессиональных IDE для конкретных языков: Java, JavaScript, Python. Здесь есть умный анализ кода, который находит ошибки для запуска, много конкретных плюшек для Java, JavaScript, Python. Отлично подходит для больших проектов и тех, кто занимается командной разработкой.

Neovim — для любителей Vim с мощными плагинами

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

Системы контроля версий

Git + GitHub / GitLab / Bitbucket

Git — бесплатный инструмент, который помогает следить за изменениями в коде и работать над проектом вместе с командой. GitHub добавляет удобную автоматизацию (Actions) и популярен для открытых проектов. GitLab хорош для закрытых задач благодаря встроенным инструментам и приватности. Bitbucket легко дружит с JIRA для командной работы. Базовые версии бесплатны, платные — от 3 до 19$ в месяц. GitHub выбирают для опенсорса, GitLab — для секретных проектов, а Bitbucket — для тех, кто уже использует JIRA.

Git Kraken

Удобный интерфейс для работы с Git, где все изменения показаны в виде дерева. Помогает разбираться с конфликтами в коде и видеть историю. Бесплатен для личных проектов, командная версия — 5$ в месяц. Отличный выбор для новичков и тех, кто любит визуальные подсказки.

Лучшие CLI-утилиты для Git

Набор помощников, которые упрощают разработку с Git через терминал. Например, git-extras работает с рутинными задачами, tig показывает историю изменений, а git-flow помогает организовать ветки кода. Всё бесплатное и работает без интернета. Подходит тем, кто хочет ускорить работу и не боится командной строки.

Инструменты для CI/CD

GitHub Actions, GitLab CI/CD — встроенные пайплайны

GitHub Actions помогает автоматизировать сборку и запуск кода — например, чтобы тесты проходили сами после каждого изменения. Бесплатно до 2 тыс. минут для открытых проектов. GitLab CI/CD встроен в GitLab и делает то же самое с 400 бесплатными минутами, плюс больше контроля над процессом. Оба работают прямо с вашим кодом, без лишних программ. GitHub Actions проще для новичков, GitLab CI/CD — для тех, кому важна приватность. Отлично для команд, которые уже сидят на этих платформах.

Jenkins, CircleCI, Travis CI — обзор популярных решений

Jenkins — бесплатный инструмент с открытым кодом, где можно настроить всё под себя. Нужен свой сервер, зато без ограничений. CircleCI ускоряет автоматизацию, но стоит от 15$ в месяц. Travis CI дружит с GitHub: бесплатно для открытых проектов, от 69$ для закрытых. Jenkins берут для сложных задач, CircleCI — для скорости, а Travis — для простых опенсорс-проектов.

ArgoCD и FluxCD — CI/CD для Kubernetes

GitOps-инструменты для Kubernetes. ArgoCD синхронизирует код с кластерами через GUI и поддерживает откаты ошибок. FluxCD легче настраивается и автоматически обновляет образы. Оба бесплатны и работают с Helm. ArgoCD предпочтительнее для команд с опытом в Kubernetes, FluxCD — для небольших проектов с минимальными настройками.

Средства тестирования

Selenium, Cypress — тестирование фронтенда

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

JUnit, PyTest, Mocha — тестирование кода

Набор инструментов для тестирования кода. JUnit — популярный выбор для Java, особенно в больших компаниях, где используют Spring; он простой и надёжный для старта. PyTest делает тестирование на Python удобным и понятным, без лишних сложностей. Mocha (часто с Chai) подходит для JavaScript: гибкий, лёгкий, и отлично работает с проектами на фронтенде или бэкенде. Все три встраиваются в автоматизацию и хороши для новичков, которые хотят проверять код без головной боли.

Postman, Newman — API-тестирование

Postman — удобный инструмент, который начинался как способ тестировать API, а теперь помогает создавать запросы, проверять их и даже автоматизировать работу. Newman — его версия для командной строки, чтобы запускать тесты без интерфейса, например, вместе с другими автоматическими задачами. Оба бесплатны для базовых вещей, а командные функции стоят от 12$ в месяц. Postman подойдёт новичкам для ручной проверки API или создания прототипов, а Newman — для автоматического тестирования API в проекте.

DevOps и контейнеризация

Docker и Podman — контейнеры в 2025 году

Docker — стандарт контейнеризации в 2025 году. Упаковывает код с зависимостями в переносимые образы. Бесплатен для локальной работы, командная разработка обойдется в 5$ в месяц. Ограничен в РФ из-за санкций. Podman — безопасная альтернатива без центрального домена, полностью совместим с Docker-командами. Поддерживает rootless-режим и работу с systemd, но имеет меньше обучающих материалов.

Kubernetes — главный инструмент оркестрации

Платформа для оркестрации контейнеров, незаменима для микросервисной архитектуры. Бесплатная, работает локально через Minikube или в облаке (от 10$). Управляет десятками контейнеров через YAML-манифесты, обеспечивает масштабирование и обновление без простоев. Требует опыта и мощного железа, но остаётся лидером для продакшн-окружений.

Terraform и Pulumi — инфраструктура как код

Terraform — бесплатное программное обеспечение, помогает настроить инфраструктуру (серверы, сети, кластеры) через код. Работает локально без платы, а облачная версия стоит от 20$. Подходит для любых облаков и нравится тем, кто хочет держать всё под контролем. Pulumi делает то же самое, но вместо специального языка использует привычные JavaScript, TypeScript или Python. Удобнее для тех, кто уже умеет программировать, хотя сообщество поменьше. Оба хороши для новичков, которые хотят проще управлять инфраструктурой.

Базы данных и инструменты для работы с ними

PostgreSQL, MySQL, MongoDB — что выбрать?

PostgreSQL — мощная бесплатная база данных с открытым кодом, которая подходит для анализа и обработки данных в сложных проектах. Она работает с разными типами данных, вроде SQL и JSON, и не берёт денег за локальное использование (облако — от 10$). У неё есть полезные дополнения, которые помогают справляться с большими нагрузками. Отличный выбор для бэкенда или аналитики, где запросы посложнее.

MySQL — простая и быстрая база данных, которая хорошо подходит для небольших и средних проектов. Есть бесплатная версия. Легко работает с языками вроде PHP, Python и Node.js, а начать с нее может любой новичок. У MySQL огромное сообщество, где можно найти готовые ответы. По сравнению с PostgreSQL, слабее в сложных задачах, но для старта — отличный выбор.

MongoDB — бесплатная NoSQL-база данных, которая хранит данные в виде JSON-документов, а не таблиц. Облачная версия Atlas стоит от 9$. Она гибкая — не нужно перестраивать структуру, если что-то меняется и запускается одной командой. По сравнению с SQL-базами хуже справляется с транзакциями, зато идеально подходит для быстрых прототипов и стартапов, где требования часто меняются.

Prisma и TypeORM — работа с БД в коде

Prisma — удобный инструмент для работы с базами данных в JavaScript и TypeScript. Поддерживает PostgreSQL, MySQL и MongoDB, помогая быстро писать код для бэкенда. Автодополнение упрощает жизнь, но на сложных задачах может немного тормозить. Отличный выбор для небольших команд, которые делают бэкенд на Node.js.

TypeORM — бесплатный инструмент с открытым кодом для работы с базами данных в JavaScript и TypeScript. Легко дружит с NestJS и Express, помогая связать код с базой. Подходит для средних проектов, где требования могут меняться. Документация не всегда полная, а некоторые функции работают не идеально, но для гибких задач на JS/TS — хороший выбор.

DBeaver, TablePlus — удобные GUI-клиенты

DBeaver — удобный интерфейс для работы с более чем 80 базами данных. Бесплатная версия (Community) доступна всем, платная (Enterprise) — от 11$ в месяц. Есть редактор для запросов с подсказками, возможность видеть структуру базы и выгружать данные. Программа ресурсоёмкая и не работает в РФ без средств обхода. Подходит разработчикам и аналитикам, которые не хотят использовать командную строку.

TablePlus — лёгкий и удобный интерфейс для работы с более чем 10 базами данных. Бесплатная версия позволяет подключаться к двум базам, а полная стоит 59$ единоразово. Интерфейс простой, данные можно выгружать, а старт занимает пару минут. В России для покупки платной версии нужны посредники. Подходит для тех, кто хочет быстро подключиться к базам без лишних наворотов.

Фреймворки и библиотеки

React, Vue, Angular, Svelte — выбор фронтенд-разработчиков

React — бесплатная библиотека для создания динамичных интерфейсов, например, сайтов, которые быстро реагируют на действия пользователя. Она с открытым кодом и включает в себя популярные инструменты вроде Redux и Next.js. У неё огромное сообщество, что даёт гибкость, но новичкам может быть непросто разобраться. Подходит для больших проектов, где команда готова потратить время на обучение.

Angular — фронтенд-фреймворк от Google для создания продуктов со сложными интерактивными интерфейсами. Бесплатный, с открытым кодом, идёт с TypeScript из коробки, что упрощает работу с большими проектами. Встроенные инструменты вроде Angular CLI ускоряют старт, а двусторонняя привязка данных (two-way binding) экономит время на синхронизации. Сообщество большое, документация подробная, но новичкам может быть тяжело из-за обилия концепций. Подходит для тех, кто работает в команде и создает корпоративные приложения, где важны структура и масштабируемость.

Vue — фронтенд-фреймворк с простым и понятным кодом, который помогает быстро создавать интерфейсы. Он лёгкий (всего 20 КБ), включает удобные инструменты вроде Vuex, Pinia и Nuxt для разных задач. Начать с ним проще, чем с React, хотя библиотек поменьше. Отлично подходит для быстрой разработки веб-продуктов.

Svelte — современный фреймворк, который превращает код в быстрый JavaScript. Он простой, не требует лишних сложностей и работает быстрее многих других. Есть SvelteKit для дополнительных возможностей. Код получается компактным, но сообщество и экосистема пока небольшие. Подходит для стартапов и приложений, где важна скорость.

Node.js, Deno, Bun — что актуально в бэкенде

Node.js — классика серверного JavaScript. Он быстро обрабатывает запросы и имеет огромный набор готовых решений через NPM, плюс Express для создания API. С его помощью разрабатывают приложения, где всё обновляется в реальном времени, например, чаты. Экосистема большая, но для задач с высокой нагрузкой процессор может быть слабоват. Отличный выбор для API и реалтайм-проектов.

Deno — безопасная альтернатива Node.js. TypeScript из коробки, изолированный доступ, встроенный пакетный менеджер, Web API. Безопасность по умолчанию, но меньше экосистема. Для современного бэкенда с акцентом на безопасность.

Bun — сверхбыстрый JavaScript-рантайм, в 3—5 раз быстрее чем аналогичные продукты от конкурентов. Встроенные пакетный менеджер и тест-раннер, поддержка TS и NPM. Скоростной, но молодой проект с багами. Для экспериментов и микросервисов.

Spring Boot, Django, FastAPI — лучшие серверные фреймворки

Spring Boot — java-фреймворк для масштабируемых проектов. Автоконфигурация, REST API, JPA, Security, встроенный Tomcat. Spring Cloud для микросервисов. Промышленный стандарт, но требует знания Java и ресурсов. Подходит тем, кто создает enterprise-приложения.

Django — мощный Python-фреймворк, который даёт всё нужное для разработки: от работы с базами до защиты и создания API. Он ускоряет процесс и делает проекты безопасными. Подходит для сайтов и приложений на Python, но для маленьких независимых сервисов может быть сложноват. Хороший выбор для быстрого старта.

FastAPI — современный Python-фреймворк для разработки быстрых API. Он простой, автоматически генерирует документацию к коду и работает шустро. Подходит для задач, требующих высокой производительности, и поддерживает асинхронные запросы, что делает его подходящим для работы с реальным временем (real-time). Админки тут нет, а для работы с реалтайм-функциями лучше иметь небольшой опыт. Отличный выбор для лёгких API и микросервисов на Python.

Приложения с инструментами для командной работы

Slack, Discord, Mattermost — коммуникация в командах

Slack — стандарт для командного общения. Бесплатно можно чатиться с историей сообщений за 90 дней, а платная версия стоит от 7$ в месяц за пользователя. Есть каналы для разных проектов и удобная связь с GitHub, JIRA или Google Drive. Настройка лёгкая, можно даже общаться с клиентами, но в России платные функции недоступны без обхода блокировок. Подходит командам, которые любят чаты и хотят всё держать в одном месте.

Discord — платформа для общения и сообществ. Базовое использование бесплатно, Nitro от $10/месяц. Текстовые и голосовые каналы, боты для модерации, стриминг и шеринг экрана. Отличное качество звука, но мало деловых интеграций. Доступен в виде веб-версии и приложения для всех основных платформ. Подходит для удалённых команд с частыми созвонами.

Mattermost — бесплатный мессенджер с открытым кодом для безопасного общения. Можно установить на свой сервер, облачная версия — от 10$ в месяц. Похож на Slack, но данные хранятся у вас, и есть плагины для связи с другими сервисами. Настройка требует усилий, зато приватность на высоте. Для компаний, которым важно держать всё под контролем.

Notion, Confluence, Obsidian — управление документацией

Notion — гибкий инструмент для хранения документации. Бесплатно до 5 гостей, безлимит — от 8$ в месяц. Можно делать заметки, таблицы и доски задач в одном месте. Удобно для стартапов, работает на всех устройствах, но большие проекты могут тормозить. Есть версии приложения под Android, Windows и IOS. Подходит для команд, которым нужна вся информация в одном месте.

Confluence — корпоративная платформа для документации от Atlassian, стоит от 6$ в месяц за пользователя, бесплатной версии нет. Хорошо дружит с JIRA и помогает организовать записи по проектам. В России оплата через посредников. Для больших команд с чёткими процессами.

Obsidian — бесплатное ПО для заметок. Работает локально, синхронизация — от 4$ в месяц, но тратить на неё средства не обязательно, можно настроить через сторонние плагины. Данные хранятся у вас, есть плагины для допфункций. Не подходит для командной работы. Хорош для личных записей и аналитики.

JIRA, ClickUp, Trello — управление задачами

JIRA — Инструмент для управления задачами, стоит от 7$ в месяц за пользователя, бесплатной версии нет. Подходит для планирования с досками и отчётами, но новичкам может быть сложно. Для профессиональных команд, которые работают по Agile.

ClickUp — универсальный сервис для выполнения задач с бесплатной версией до 100 МБ, полная — от 7$ в месяц. Есть доски, списки и автоматизация. Прост вначале, но функций так много, что можно запутаться. Для команд, которым нужен гибкий инструмент без сложностей JIRA.

Trello — простая система для задач с досками. Бесплатно до 10 досок, дальше — от 5$ в месяц с автоматизацией. Перетаскивайте карточки от «Сделать» к «Готово». Легко и наглядно, но для больших процессов не подходит. Для маленьких команд и простых проектов.

Новые и перспективные инструменты для разработки

AI-кодогенераторы: GitHub Copilot, Codeium, ChatGPT API, Cursor AI, Claude Code, Claude API, Cloud Code от Google

GitHub Copilot — ИИ-помощник, который подсказывает код и проверяет его. Бесплатно для студентов и открытых проектов, иначе — 10$ в месяц. Работает с кучей языков в популярных редакторах, ускоряя работу. Не работает в РФ. Подходит всем, кто хочет писать код быстрее.

Codeium — бесплатная альтернатива Copilot, где безопасность на первом месте. Для бизнеса — от 15$ в месяц. Помогает с кодом и тестами, данные обрабатываются локально. Отличный выбор для команд, которым важна конфиденциальность.

ChatGPT API — инструмент от OpenAI для создания своих ИИ-помощников. Стоит недорого, доступен в России и понимает много языков. Может писать код, объяснять ошибки, но нужно уметь его подключать. Для тех, кто готов копаться в настройках.

Cursor AI — редактор кода с ИИ, похожий на VS Code, но умнее. Подсказывает код, исправляет ошибки и ускоряет работу. Под капотом разные ИИ-продукты от Open AI, Google, Antropic. Простой и быстрый, идеален для новичков, которые хотят писать код без лишней головной боли.

Claude Code — терминальный помощник от Anthropic для автоматизации кодирования. Необычный подход к разработке в сравнении с конкурентами. Работает через командную строку, ищет код, правит файлы и пушит в GitHub. Бесплатен в preview, безопасен. Подходит тем, кто хочет ускорить рутину и не боится терминала.

Claude API (3.7 Sonnet) — лучший ИИ для кодинга по мнению автора статьи. Версия 3.7 Sonnet пишет код, чинит баги и думает над задачами. Во многих сценариях превосходит Chat GPT. Стоит от 3$ за миллион токенов, не работает в России. Для тех, кто хочет мощный ИИ в своём проекте, но готов разобраться с подключением.

Cloud Code от Google — плагин для VS Code от Google, чтобы писать код для их облака. Помогает с настройкой серверов и приложений, вроде Kubernetes. Бесплатен с аккаунтом Google Cloud. Подходит новичкам, которые начинают с облачных проектов и хотят всё делать в одном месте.

Инструменты Low-Code / No-Code для ускорения разработки

Betty Blocks — Low-Code платформа для создания своего программного продукта. Всё делается через визуальный редактор с готовыми шаблонами, плюс есть упор на безопасность. Её используют большие компании вроде Clifford Chance. Подходит для сложных задач, стоит от 1050$ в месяц, не очень дружелюбна для новичков. В основном для корпораций с хорошим бюджетом.

Bubble — No-Code инструмент для разработки веб-приложений. Можно перетаскивать элементы, использовать шаблоны. Есть бесплатный тариф. Легко начать, но большие проекты могут тормозить. Отличный выбор для стартапов и одиночек, которым нужен прототип.

Zapier — No-Code для автоматизации. Соединяет 7000+ приложений через простой конструктор, стоит от 19.99$ в месяц. Удобно для экономии времени, но дополнительные настройки могут поднять цену. Для тех, кто хочет объединить разные сервисы.

Softr — No-Code платформа с привязкой к Airtable. Шаблоны простые, настройка быстрая, цена от 49$ в месяц. Дружелюбный для новичков, есть поддержка, но сложные приложения не потянет. Подходит фаундерам и менеджерам без технических навыков.

Glide — No-Code для разработки приложений из таблиц, вроде CRM или дашбордов. Стоит от 69$ в месяц, быстро собирается. Удобно для малого бизнеса, но для продвинутых задач слабоват. Хорош для простых нужд.

Caspio — Low-Code с ИИ, в котором создают облачные приложения. Большой акцент на защите данных, цена от 100$ за пользователя в месяц. Подходит для больших систем, но стартапам будет не по карману. Для профессионалов, которым важна безопасность.

UiPath RPA — Low-Code для автоматизации рутины. Упрощает разработку благодаря ИИ. Цена индивидуальная, зависит от запроса. Хорошо подходит для ниш со здравоохранением и финансами. Настройка сложная и недешёвая. Понадобится отраслям, где много повторяющихся задач.

OutSystems — Low-Code для корпоративных проектов. Поддерживает визуальную разработку ПО для крупных систем. Цена индивидуальная. Для разработчиков и больших компаний.

Лучшие новые технологии, которые могут выстрелить в 2025 году

BlueQubit

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

Блокчейн: Polkadot, Solana, Truffle

Платформы для приложений без центра управления. Polkadot и Solana делают их быстрыми и масштабируемыми, Truffle упрощает работу с кодом. Безопасно и прозрачно для финансов или логистики, но нужен опыт. Хорош для финтеха и стартапов, которые смотрят на Web3.

Edge-вычисления: Apache Edgent, Azure IoT Edge

Обработка данных прямо там, где они появляются. Edgent — лёгкий и простой, Azure IoT Edge — для умных устройств. Быстро работает, например, для беспилотных машин, но настройка требует времени. Для разработчиков IoT и небольших сервисов.

IoT: Arduino, Raspberry Pi

Популярные платформы для разработки умных устройств. Они поддерживают современные технологии для связи (например, Wi-Fi, Bluetooth) и обеспечивают базовые механизмы защиты данных. Arduino и Raspberry Pi доступны по цене, гибки в настройке и отлично подходят для проектов умного дома. Однако для сложных систем с высокой нагрузкой они могут быть недостаточно мощными. Эти платформы идеальны для энтузиастов, хоббистов и небольших IoT-проектов.

Кибербезопасность: SAST, DAST

Инструменты для защиты кода. SAST ищет ошибки до запуска, DAST — во время работы с помощью ИИ. Спасают от атак и нужны в продакшене, но требуют частых обновлений. Для всех, кто работает с данными.

Вот такой топ лучших инструментов получился, а что вы добавили бы в эту подборку? Или может быть убрали бы из неё? Давайте составим свою подборку в комментариях.

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

С чего все началось

На одном митапе по стандарту разработки нам с Head of Profession задали вопросы, которые зависли в воздухе, как нерешенный баг в коде: «А что за потребность все делать с помощью As Code? Какая от этого польза? Зачем число коммитящих в код?»

Мы, как архитекторы инженерной культуры, внедряем лучшие практики и подходы: Infrastructure as Code, API First, unit-тесты, компонентное тестирование, TBD (Trunk Based Development), GitOps, Doc As Cod. Мы дорабатываем пайплайны, как инженеры, собирающие сеть в подвале старого дата-центра. Мы создаем условия для Continuous Deployment с продуктовыми платформами, где blue-green deployment и canary deployment становятся порталами для перехода прода из одного состояния в другое.

Каждый коммит — шаг в будущее, где код становится не просто текстом, а нитью в живой ткани новой реальности. Число коммитящих — это не просто метрика, это сигнал, что система жива, дышит, развивается. И когда кто-то спрашивает «Зачем?», я отвечаю: «Потому что иначе мы останемся в прошлом, где ручные процессы, как старые провода, тянут нас назад в тишину, замедляя каждый шаг. Мы строим мир, где As Code не просто слова, код — наша новая реальность. И каждый, кто коммитит, становится частью этой вселенной».

В момент осознания вопроса я провалился на другой слой реальности, задумался об истории As Code и собрал этот текст из разбросанных по сети слепков. Эта статья — не руководство по Terraform или Kubernetes, а скорее практический взгляд на культуру As Code в масштабах крупной IT-компании.

Эволюция As Code: от истоков до современности

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

У появления этого подхода было несколько предпосылок:

1. Автоматизация и стандартизация. В 1990-х годах с развитием DevOps и agile-методологий возникла потребность в автоматизации процессов разработки и управления инфраструктурой. Новые задачи стали основой для появления подходов, где все описывается в виде кода.
2. Распространение систем контроля версий. В 2005 году появился Git, который стал инструментом для управления изменениями, что позволило хранить и версионировать не только код, но и документацию, конфигурации и архитектуры.

Корнями As Code уходит в 1970-е годы. Ранние инструменты, такие как Unix “Make” и PXE boot, заложили фундамент для автоматизации конфигураций. Позже они эволюционировали в современные подходы: Infrastructure as Code, Documentation as Code, GitOps и другие. Это подчеркивает, что As Code — не просто тренд, а естественное развитие технологий, которое упрощает управление сложными системами.

Почему все теперь в Git?

С развитием подхода As Code универсальным инструментом управления изменениями стал Git. Это произошло благодаря нескольким ключевым причинам.

• История изменений: Git хранит всю историю изменений, что позволяет отслеживать, кто, когда и что делал. Это критически важно для анализа и отката ошибок.
• Коллаборация: над проектом может работать несколько человек, и они не будут мешать друг другу.
• Прозрачность: все изменения видны, их можно обсудить, проверить и улучшить через механизмы pull/merge requests.
• Автоматизация: Git интегрируется с CI/CD — Continuous Integration / Continuous Deployment. Это позволяет автоматизировать тестирование, сборку и деплой. Работа в Git позволяет «все иметь под рукой» и упрощает создание систем поддержки и контроль стандартов ИТ-производства.
• Безопасность: Git позволяет контролировать доступ к коду и данным через ролевую модель и механизмы проверки изменений.

Как появился Git?

Git был создан в 2005 году как ответ на кризис в разработке ядра Linux. Ранее команда Linux использовала проприетарную систему контроля версий BitKeeper, но юридические споры лишили программистов этой возможности. Linux-сообщество осталось без инструмента для управления кодом. Существующие системы — например, CVS или Subversion — не подходили для масштабных проектов.

Линус Торвальдс, создатель Linux, решил разработать собственную систему, которая бы отвечала потребностям крупных проектов:

• была быстрой,
• поддерживала распределенную разработку,
• гарантировала сохранность данных (через хеши SHA-1).

Git был создан всего за 10 дней. Первая версия была настолько проста, что Торвальдс называл ее «игрушечной». При этом она уже решала ключевые задачи. Инструмент разработали с акцентом на децентрализацию: каждый разработчик имеет полную копию репозитория, что делает процесс гибким и устойчивым.

Создание Git — прекрасный пример проактивной позиции: если тебя что-то не устраивает, ты сам создаешь инструмент для решения задачи. Реагируешь на боль не нытьем, а делом, и оставляешь проблему позади. Этот инструмент родился из необходимости и стал революцией в мире разработки. Простота, скорость и распределенный подход сделали его незаменимым инструментом для команд любого масштаба.

Эволюция Git:

• 2005: первый релиз Git;
• 2008: появление GitHub, который популяризировал Git среди разработчиков;
• Сейчас: Git де-факто стал стандартом для контроля версий, который используют разработчики по всему миру.

Основные подходы As Code

Infrastructure as Code (IaC)

IaC — это описание в виде кода инфраструктуры: серверов, сети баз данных. Например, с помощью Terraform, Ansible, CloudFormation. Инструмент позволяет сделать инфраструктуру воспроизводимой, предсказуемой и легко управляемой. Вместо ручного создания серверов в облаке вы можете описать их в коде и развернуть одной командой.

Когда мы слышим термин Infrastructure as Code, то обычно думаем о современных инструментах, таких как Chef, Ansible или Terraform. Однако сама идея управления инфраструктурой и конфигурациями через код уходит корнями в 1970-е годы. Уже тогда инженеры сталкивались с необходимостью автоматизировать управление парками машин, будь то физические или виртуальные системы.

Одним из первых инструментов, позволявших автоматизировать сборку и настройку программного обеспечения, был Unix “Make” (1976). Хотя Make не стал полноценным инструментом управления инфраструктурой, он заложил основы для автоматизации задач конфигурации. Следующим важным шагом к автоматизации стал PXE boot (1981). Он позволял загружать и настраивать по сети целые машины — это стало прообразом современных подходов к управлению инфраструктурой.

Хотя эти ранние инструменты не считаются полноценными решениями для управления инфраструктурой, они создали основу для современных подходов. Unix “Make” и PXE boot показали, что автоматизация конфигураций возможна и необходима, особенно с ростом сложности систем.

Как дальше складывалась эволюция IaC:

• 1990-е: следующий этап развития начался с появлением CFEngine (1993). Это был один из первых инструментов, позволявших управлять конфигурациями на множестве машин.
• 2000-е: с развитием облачных технологий и DevOps появились более мощные инструменты, такие как Puppet (2005) и Chef (2009). Они сделали управление через код отраслевым стандартом. 2010-е: Ansible (2012) и Terraform (2014) стали лидерами в области IaC. Они предложили более гибкие и мощные решения для управления облачной инфраструктурой.
• 2013: появился Docker, который произвел революцию в контейнеризации. Он обеспечил легкость в создании, развертывании и масштабировании приложений, а также упростил процессы управления инфраструктурой.
• 2014: Kubernetes предложил автоматизацию развертывания, масштабирования и управления контейнизированными приложениями.
• 2017: создан Pulumi, который позволил управлять ресурсами облачной инфраструктуры с использованием таких языков программирования, как Go, JavaScript, TypeScript, Python, Java, C# и YAML. Благодаря этому инструменту разработчики смогли быстрее интегрировать IaC в свои процессы и создавать более сложные сценарии для автоматизации.
• 2021: появился Brainboard, который значительно упростил разработку, визуализацию и управление инфраструктурой как кодом. Он предложил графический интерфейс для создания и изменения архитектуры облаков. Это помогло сделать IaC доступным не только для разработчиков, но и для более широкого круга пользователей, в том числе для аналитиков и проектировщиков.

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

Documentation as Code (Docs as Code)

Подход Docs as Code позволяет разрабатывать техническую документацию с помощью тех же инструментов, что и код. Документы создаются в формате, который легко версионировать и хранить в Git, — например, Markdown или AsciiDoc. Это дает значительные преимущества:

• актуальность — документация API или архитектуры хранится в репозитории рядом с кодом, благодаря чему всегда остается актуальной;
• версионирование — легко отслеживать изменения и возвращаться к предыдущим версиям;
• интеграция в процесс разработки — документация становится частью DevOps-практики и развивается в Git вместе с кодом.

Подход Docs as Code начал развиваться в 2000-х годах. В это время крупные компании, такие как Microsoft, начали использовать внутренние инструменты для генерации документации из исходного кода. Например, документация .NET Framework уже создавалась с помощью автоматизированных процессов.

В 2010-х годах термин Docs as Code был популяризирован. Тогда такие инструменты, как Markdown, AsciiDoc и Sphinx, стали широко использовать для создания и управления документацией в репозиториях Git.

Architecture as Code (AaC)

AaC позволяет описывать архитектуру системы в виде кода — например, с помощью DSL. Благодаря этому она становится понятной, проверяемой и легко изменяемой. С помощью таких инструментов, как Structurizr или PlantUML, можно генерировать архитектуры программного обеспечения в коде, чтобы интегрировать их в процессы разработки.

Подход Architecture as Code начал развиваться в 2010-х годах с появлением Structurizr (2014) и других инструментов. Сегодня AaC используют для описания в формате, который можно версионировать и тестировать. Например, C4-модель помогает разработчикам и архитекторам лучше понимать сложные системы.

Хотя конкретные компании редко публично афишируют использование C4-модели или Aac, есть несколько примеров, где эти подходы активно применяются.

Крупные технологические компании

• Microsoft использует C4-модель, чтобы документировать архитектуры своих облачных сервисов, таких как, допустим, Azure. Подход AaC помогает автоматизировать создание диаграмм и поддерживать документацию в актуальном состоянии.
• Внутренние команды Amazon Web Services используют C4-модели для описания архитектуры своих сервисов, а инструменты AaC помогают интегрировать эти описания в CI/CD-процессы.

Финансовые организации

Многие банки и финтех-компании используют C4-модели, чтобы документировать сложные распределенные системы. Например, ING и Goldman Sachs применяют AaC для автоматизации создания архитектурных диаграмм и проверки соответствия стандартам.

Консалтинговые и IT-компании

• Разработчик и поставщик программного обеспечения ThoughtWorks активно продвигает использование C4-модели и подхода Architecture as Code в своих проектах. Компания создает инструменты и практики для интеграции AaC в процессы разработки.
• Производитель программного обеспечения Red Hat использует C4-модели для документирования архитектуры своих решений, таких как OpenShift, и применяет AaC для автоматизации создания диаграмм.
• Также активно использует и применяет C4-модели X5 Tech — основной цифровой партнер торговых сетей и бизнесов X5 Group.

Policy as Code

Этот подход позволяет описывать политики и управлять ими, например безопасностью или доступом. Policy as Code дает возможность автоматизировать проверку на всех этапах жизненного цикла ПО и обеспечить compliance — соответствие требованиям.

Подход Policy as Code стал популярным с появлением таких инструментов, как Open Policy Agent (OPA) и Hashicorp Sentinel. Они позволили описывать политики безопасности и compliance в виде кода, что стало особенно востребованным в облачных средах.

GitOps

GitOps — подход, в котором Git становится единым источником истины для управления инфраструктурой и приложениями. Они описываются в коде — например, с помощью Kubernetes manifests — а все изменения автоматически применяются через CI/CD.

Концепцию GitOps в 2017 году формализовала компания Weaveworks, этот подход дает несколько преимуществ:

• прозрачность — все изменения видны в Git;
• автоматизация — процессы деплоя и обновления автоматизированы;
• безопасность — изменения проходят код-ревью и тестирование.

GitSecOps

GitSecOps — расширение GitOps с акцентом на безопасность, которое стало развиваться в 2020-х годах. С помощью этого инструмента можно интегрировать безопасность в процесс разработки и эксплуатации через код, он позволяет внедрить в CI/CD инструменты статического анализа кода (SAST) и анализа зависимостей (SCA).

Преимущества этого подхода:

• раннее выявление уязвимостей;
• автоматизация проверок безопасности;
• соответствие стандартам — например, GDPR или HIPAA.

Будущее с As Code

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

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

Footnotes:

• Everything as Code Explained

• Write the Docs Guide: Docs as Code

• Understanding Docs as Code

• The Origins of Infrastructure as Code

• Canary Deployment Strategies

• AWS Whitepaper: Blue-Green Deployments

Сегодня IT-компании массово увольняют разработчиков, надеясь, что ИИ возьмёт на себя рутину.

Но, по мнению Гадалеты, это огромная ошибка, которая в ближайшие годы приведёт к хаосу, провалам продуктов и дефициту квалифицированных инженеров.

1. Новое поколение разработчиков будет слабым

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

Но теперь компании всё чаще отказываются нанимать джунов, полагаясь на автогенерацию кода. Как результат:

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

Гадалета сравнивает это с обучением вождению только на автопилоте. Пока всё идёт гладко — кажется, что проблем нет. Но когда случится сбой, человек окажется абсолютно беспомощным.

2. Компании, которые уволили программистов, скоро будут жалеть

Допустим, корпорация решает сократить IT-отдел, надеясь, что ИИ заменит программистов. Первые несколько месяцев — всё идёт хорошо.

Но затем:

• Система ломается, потому что ИИ генерировал код без понимания логики продукта.
• Выявляются дыры в безопасности, клиенты жалуются, регуляторы начинают проверки.
• Исправлять некому, потому что программистов уволили.

ИИ, который писал код, не понимает последствий и не может самостоятельно исправить ошибки.

Испуганные менеджеры начинают в срочном порядке нанимать обратно разработчиков, но сталкиваются с новой проблемой:

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

3. Опытные программисты станут редкостью и начнут диктовать условия

Пока корпорации массово увольняют разработчиков, самые ценные специалисты не сидят без дела:

• Кто-то углубляется в системное программирование, становясь экспертом в низкоуровневой оптимизации.
• Кто-то специализируется на ИИ-интерпретируемости, создавая инструменты, которые анализируют решения нейросетей.
• Кто-то уходит в финтех и хардкорную backend-разработку, где автоматизация пока бессильна.

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

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

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

Топ-5 самых высокооплачиваемых профессий в IT:

1. Разработчик на Solidity — 640 тыс рублей. Этот язык активно используется в блокчейн-проектах.
2. Продакт-менеджер — до 580 тыс рублей. Этот специалист отвечает за разработку и реализацию IT-продукта.
3. Тимлид — 550 тыс рублей. Руководитель команды разработчиков.
4. Python-разработчики в финтехе и Linux-инженеры — 520 тыс рублей. Python в данном контексте используется в финансовых технологиях, а Linux-инженеры администрируют серверы и сервисы.
5. QA-инженеры — 450 тыс рублей. Они занимаются тестированием и контролем качества продуктов.

Рынок IT в России продолжает расти

Согласно данным службы занятости и hh.ru, в России IT-сфера остаётся востребованной.

С начала 2024 года было открыто более 120 тыс вакансий для программистов и разработчиков, что на 6% больше, чем в прошлом году. Средняя зарплата программиста выросла на 10% и достигла 147.7 тыс рублей.

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

«Оплата улыбкой» от «Сбера» перепутала близнецов и сняла деньги не с той карты

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

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

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

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

«Сбер», МТС, «Мегафон», «Яндекс», VK выступили против законопроекта, который обяжет быстро передавать личные данные силовикам

Ассоциация больших данных дала комментарий Forbes, в котором выступила против законопроекта, который обяжет передавать личные данные пользователей без официального запроса не только в ФСБ или МВД России, но и региональным отделам МВД и даже ФСИН.

В Ассоциацию входят крупные российские компании, среди которых Сбербанк, Тинькофф, Яндекс, VK, QIWI, Газпромбанк, Россельхозбанк, МТС и другие.

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

В АБЦ заявили, что принятие законопроекта усложнит проверку законности запросов из силовых структур. Также он создает риски нарушения прав граждан и организаций.

Президент РФ продлил до 30 лет отсрочку от срочной службы в армии для IT-сотрудников

Президент России Владимир Путин подписал поправки в указ от 04.09.2023 № 660 «О внесении изменений в Положение о порядке рассмотрения вопросов гражданства Российской Федерации, утверждённое Указом Президента Российской Федерации от 14 ноября 2002 г. № 1325, и в Указ Президента Российской Федерации от 2 марта 2022 г. № 83 «О мерах по обеспечению ускоренного развития отрасли информационных технологий в Российской Федерации».

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

Изменения в закон были приняты потому, что с 1 января 2024 года верхний возрастной порог для призыва в армию повышается с 27 лет до 30 лет. Таким образом, отсрочку продлили в соответствии с повышением призывного возраста.

Минцифры приостановит лицензии на пейджинг в России

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

Последней компанией, которая оказывала услуги пейджинга в России, была «Телекомт», которую ликвидировали в 2021 году. Ее гендиректор рассказал, что оператор не стал продлевать лицензию. Основные компании, которые пользовались пейджингом, отказались от услуг, и бизнес стал совершенно невостребованным.

Заключение

Это — наш новый формат: еженедельная подборка новостей.

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

Также расскажите, какие новости, по вашему мнению, несправедливо не попали в подборку, почему они важны и какие последствия несут для IT-рынка.

Зачем банку танцующие человечки

Data Science Dance создали в Департаменте анализа данных и моделирования, где происходит вся ML-магия. Для решения бизнес-задач команда применяет самые разные ML-модели и технологии искусственного интеллекта. Например, методы компьютерного зрения, которые специалисты Газпромбанка решили использовать, чтобы показать, где ещё оно может быть полезно и на что в принципе способно.

В Газпромбанке занимаются не только скорингом кредитов, но и развитием компьютерного зрения и речевых технологий, графами и гео. Data Science Dance — очередное доказательство этому. Запросы от бизнеса настолько амбициозны, что приходится быть на гребне волны новых библиотек и подходов. И мы с этим справляемся. Команда Data Science в Газпромбанке не самая большая по численности, но точно в лидерах по компетенциям и их применению к интересным задачам.

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

Как оживить картинку

Определившись с идеей, начали продумывать техническую составляющую.

«Чтобы человек мог получить готовое видео за несколько минут, нужно было пройти много стадий реализации проекта. И каждая из них предполагала своё решение: где-то это ML-модель, где-то — алгоритмы. Компьютерное зрение — очень обширная область. Это 2D, 3D, распознавание объектов, детекция, сегментация и многое другое. Мы понимали, что в нашем проекте придётся совместить несколько разнородных решений и заставить их работать вместе», — говорит управляющий директор Управления алгоритмов машинного обучения Газпромбанка Алексей Найденов.

Как выглядит алгоритм работы Data Science Dance

1. Анализ видео с танцем. На каждом кадре исходного видео модель ищет определённые элементы человеческого тела: голову, кисти рук, локти, колени и так далее. При этом сохраняется вся информация о том, как человек двигался на видео: махал руками и ногами, двигал головой, подпрыгивал, приседал или делал и то и другое одновременно. Следующая модель переносит обнаруженные точки из 2D-плоскости в 3D-пространство.
2. Анализ рисунка. Человек рисует персонажа, у которого тоже нужно найти скелет и определить местоположение частей тела. За это отвечает отдельная ML-модель.
3. Анимация. Здесь в дело вступают особые алгоритмы, которые соединяют скелеты нарисованного персонажа и танцующего человека, затем анимируют его, словно оживляя. Получается видео, на котором персонаж танцует точь-в-точь как автор рисунка.

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

Все модели в Data Science Dance опенсорсные, то есть их не пришлось писать с нуля.

«В компьютерном зрении много качественных опенсорсных решений. Чтобы сделать одну хорошую модель оценки местоположения скелета по видео, нужно снять кучу видео, вручную разметить их и обучить на этих данных модель. Это гигантская работа.Поэтому для широкого круга задач целесообразнее взять предобученную модель, адаптировать под конкретные нужды и быстро получить качественный результат», — объясняет Алексей.

Какие ML-модели мы использовали

Всего в продукте использовали три группы моделей:

1. AlphaPose. Получает представление о скелете человека в 2D-плоскости.
2. MotionBERT. Переносит 2D-точки в 3D-плоскость. Это помогает понять, как человек двигается в трёхмерном пространстве. Например, прыгает назад или вперёд.
3. Animated Drawings. Отвечает за оживление персонажа.

Сложнее всего было заставить всё это работать сообща, причём быстро и без сбоев. «Например, модель Animated Drawings появилась относительно недавно, в этом году. Многие в Data Science-сообществе заинтересовались ею, начали экспериментировать и анимировать свои рисунки. Но чтобы использовать произвольное видео с танцем, авторы модели предлагали использовать платное ПО для дизайнеров и аниматоров для захвата движения на видео. Это предполагало, что для каждой анимации необходимо проводить ряд ручных манипуляций, что точно не подходило для массового применения.

В комментариях к этой модели до сих пор много вопросов, как автоматизировать анимацию рисунков без стороннего ПО. Ведь при его использовании теряется вся прелесть технологий: процесс становится долгим и неудобным. А нам нужно было найти способ получать видео быстро. Мы нашли решение, но оно не стыковалось с другими моделями. У нас как будто было несколько частей пазла, которые нужно собрать в цельную картинку. Это сложная инженерная задача», — объясняет главный аналитик-исследователь Управления алгоритмов машинного обучения Газпромбанка Игорь Дьяченко.

Ещё одно ограничение было очевидным и легко решаемым — оно касалось ресурсов. ML-модели требуют больших вычислительных затрат, а в Data Science Dance был целый набор моделей и алгоритмов, которые желательно запускать на графическом ускорителе. Чтобы посетителям не приходилось ждать видео часами, решили использовать отдельные облачные мощности.

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

Танцы по правилам

ML-модели, на которых работает Data Science Dance, могут быть весьма капризными. Например, чтобы модель корректно распознавала скелет танцующего человека, в кадре должен быть только он. Если в объектив случайно попадёт другой человек или часть его тела, например, нога или рука, это собьёт алгоритмы с толку.

«Мы много тестировали продукт в офисе, дома и на улице. Конечно, мы понимали, что в кадре не должно быть других объектов, но удивительно, что при съёмках на улице алгоритмы замечали даже людей, которые были очень далеко. Мы сами их не видели, а модель фиксировала чью-то голову вдалеке и сбивалась», — вспоминает Игорь.

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

Своих персонажей тоже нужно было рисовать определённым образом, но правила были несложными. «Чтобы всё получилось, рисунок должен быть человекоподобным. Неважно, дерево вы рисуете или милое животное — главное, чтобы у него были голова, ноги и руки. Один из посетителей, например, нарисовал Микки-Мауса, — говорит Алексей. — Цвета могут быть любые: сложности возникли только с розовым, потому что он бледный, а все другие цвета модель считывала отлично».

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

Вот таким необычным способом проект Data Science Dance показал, что с помощью компьютерного зрения можно решать разные задачи, в том числе совершенно, казалось бы, небанковские.

Как компания-работодатель мы хотим рассказывать, какие направления и задачи у нас есть. Одно из главных наших преимуществ — стремительное развитие Data Science в банке. Через научно-развлекательные активности мы демонстрируем экспертизу на широкую публику. Это помогает не только привлекать опытных специалистов, но и мотивировать юных участников VK Fest к выбору перспективной профессии.

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

Однако в 2022 году россияне внезапно испытали интерес к финансовым услугам в Казахстане: они в 16 раз чаще, оформляли ИИН, необходимый для открытия счета в казахстанском банке, а более 13 тысяч российских предпринимателей перенесли туда свой бизнес. В итоге мы задумались, не масштабироваться ли нам на Казахстан: это решение стало ситуативным, принятым внезапно и очень быстро.

В марте количество поисковых запросов «банк в Казахстане» в Яндексе выросло в 3,5 раз по сравнению с аналогичным периодом в 2021 году, а запрос «счет в Казахстане» возрос  почти в 6 раз.

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

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

Далее расскажем о нюансах, с которыми столкнулись в процессе запуска «Выберу Казахстан».

Скорость запуска

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

При планировании мы приоритизировали порядок запуска разделов. Чтобы не распылять усилия, выделили разделы первого и второго этапа. Так, первым появился раздел «Микрозаймы» — заключить партнерство с МФО было проще в плане времени, чем с банками. Спустя полтора месяца появилась полноценная зарубежная платформа.

Организация сотрудничества с зарубежными компаниями и монетизация

Финансовый маркетплейс монетизируется в основном за счет получения комиссии за оформленную заявку — по performance-модели. С российскими банками мы либо настраиваем прямые интеграции по API, либо работаем через партнерские CPA-сети.

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

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

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

Запуск первой версии на поддомене

Изначально при запуске «Выберу Казахстан» не планировалась покупка регионального домена — первая версия выкатывалась на поддомен kz.vbr.ru. Конечно, с точки зрения SEO, для успешного продвижения необходимо было купить домен в доменной зоне Казахстана .kz. Почти все сайты, которые ранжируются по основным целевым запросам, находятся именно в этой доменной зоне. Но тогда это решение не было согласовано, по итогу, сайт в доменной зоне .ru не мог занять адекватных позиций в выдаче Google, после чего команде SEO удалось согласовать покупку домена vbr.kz и в дальнейшем мы переезжали на него.

Далее возник другой вопрос — сайт использовал городские домены типа moskva.(домен).ru или tula.(домен).ru — как тогда определять страну? Чтобы научить сайт определять страну, для которой отображается страница, мы реализовали механизм определения региона при каждом запросе по двум параметрам: из URL и из cookie, — что обеспечило гибкость настроек.

Затем поняли, что локализованные параметры, в частности, значок рубля, местами вшиты в верстку. А в Казахстане нужно показывать тенге (₸). На сотнях страниц не вычислялось, какую валюту надо вывести, в инструментах выбора валют всегда присутствовал рубль: в отчетах, графиках на калькуляторах, результатах поиска, суммах «от» и «до». Чтобы это исправить, мы вынесли данные о странах в отдельный файл с определенным набором параметров. Загружая файл при старте сайта, видим нужные данные из него при выполнении запросов на сайт.

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

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

Долгое время поддомен не мог занять позиции в выдаче Google, после чего к анализу подключилась SEO-команда. Выяснили, что почти все сайты, которые ранжируются по интересующим нас запросам, размещены на доменной зоне .kz.

Переезд на домен первого уровня

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

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

Наполнение сайта

Изначально в back office не было национальной валюты — тенге. Контент-специалисты проверяли каждую страницу и инструмент на сайте, чтобы тенге отображалась в каждом банковском продукте.

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

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

Продвижение сайта

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

Потребовалось поработать над метатегами и адаптацией контента под специфику региона: так как часть контента, который предназначался для России, мы выводили на Казахстане, его тоже необходимо было подготовить к локальной специфике. Мы спарсили весь контент на домене Казахстана, который содержит российскую специфику (упоминания российских банков или особенностей законодательства), и адаптировали тексты под Казахстан.

Также понадобилась корректная настройка систем аналитики и установка счетчиков на домен нового региона: Яндекс Метрика, Google Analytics, Google Search Console, Яндекс Вебмастер.

Результаты

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

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

Российский FinTech – один из лучших в мире: на нас смотрят, на нас равняются, нам подражают. Это самая быстроразвивающаяся сфера в IT при том, что здесь одни из самых высоких требований к безопасности. Как работают айтишники в большом российском банке? Как меняют процессы, с какими проблемами сталкиваются, как реализуют себя? Отвечаем в подкасте «Техно.Логично»!

В выпуске мы поговорили о платформизации IT-разработки с нашими экспертами: Исполнительным Вице-Президентом – начальником Департамента технологий розничных некредитных продуктов Романом Китаевым и техническим директором Департамента технологий розничных некредитных продуктов, ИТ-Лидером стрима Госпроекты Максимом Моревым.

Слушать на Яндекс Музыке.

Слушать в Google Podcasts.

Слушать в Apple Podcasts.

Смотреть видеоверсию на YouTube.

О чём этот эпизод?

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

В чем особенности нового подхода? Какие у него недостатки? Как разработчики относятся к изменению рабочих процессов? Ищите ответы в нашем технологичном подкасте.

И конкурс!

Для тех, кто дослушает эпизод до конца, мы приготовили конкурс. Нужно ответить на вопрос ведущего в комментариях под этим видео. Среди предложивших самые интересные ответы мы разыграем беспроводные наушники!

Реклама АО «Газпробмбанк» LjN8K4nVg

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

Начнём с того, что и правда хорошо.

Большие и значимые проекты

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

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

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

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

К тому же очень круто говорить, что ты работаешь в таком гиганте, как Газпромбанк. У многих это вызывает вау-эффект. А у тебя — возникает чувство того самого «сына маминой подруги».

Много возможностей для роста

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

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

Есть вариант перейти в другую техническую профессию или переключиться на менеджмент, не меняя экосистему, в которой находишься. Например, мой текущий руководитель, пришёл в банк как технарь-аналитик, потом перешёл на роль Project Manager, позже — Product Owner. И это всего за несколько лет.

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

Ты — сам себе менеджер

Финтех работает по принципам Agile, и все разбиты на эффективные команды. Как правило, это один фронтенд, один бэкенд, один аналитик, один дизайнер и так далее (в зависимости от планов бизнеса и размера бэклога в Jira, специалистов может быть больше).

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

Одна из моих инициатив вылилась в сообщество фронтенд-разработчиков, в котором состоит уже больше 100 человек. Началось всё с того, что мне приходилось искать специалистов по различным вопросам. Например, тех, кто сталкивался с нашим UI Kit (тонкости было не нагуглить). Оказалось, что многие тратят на это время. В итоге мы решили создать пространство, где будем обмениваться опытом и обсуждать будни разработки.

В итоге сформировалась живая база знаний по фронтенду, которая стала занимать важную роль в нашем департаменте. За полгода жизни комьюнити мы провели несколько митапов для разработчиков: первый — онлайн, второй — офлайн. А я нашёл текущего мейнтейнера того самого внутреннего UI kit.

Корпоративные ивенты и другие бонусы

Возможности и различные айтишные плюшки, которые мне предоставил Газпромбанк, не давала и близко ни одна из шести (или уже семи) компаний, где я работал.

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

Ещё есть огромные возможности прокачивать свои навыки и учиться новому. Например, я прошёл Bootcamp для спикеров, где с утра до вечера учился выступать на сцене, питчить идеи, готовить презентации. Проводятся семинары и тренинги, которые помогают развивать не только хард, но и софт-скилы.

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

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

Наконец, здесь есть множество корпоративных плюшек, которые мало где встретишь в таком количестве. Например, приложение ГПБ Like, в котором можно ставить друг другу лайки и тратить их на мерч. И это, не говоря, про соцпакет, куда включено не только ДМС, но и психологическая, и юридическая поддержка.

И я до сих пор изучил только часть бонусов ?

К чему стоит готовиться

В банке не получится «просто писать код»

На аутсорсе или в небольшой веб-студии ты будешь ежедневно по несколько часов в день писать код, набивать руку, трекать часы в Jira и прокачивать скил разработчика. Это очень полезно в плане роста.

А в финтехе много рабочего времени уходит на встречи, заведение заявок, получение доступов, прочие нюансы. Иногда тратишь на это по 70% времени и почти не успеваешь открыть IDE.

Приведу в пример один из таких дней. С утра прошёл daily, где мы обсудили планы на день. Через час встреча на полтора часа с большой презентацией на 150 человек, далее созвон — с коллегами из другой команды, чтобы обсудить грядущую доработку. В итоге к концу дня успел позаниматься разработкой около полутора часов, и глубоко погрузиться в код не удалось.

Всё это развивает тебя в разных сферах. Например, прокачивает софт-скилы, что для многих разработчиков является проблемой. Но для человека, который мечтает просто писать код, такой ритм работы может стать проблемой и причиной выгорания.

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

Легко увязнуть в узком стеке

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

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

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

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

Безопасность и ещё раз безопасность

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

Например, недавно я работал над проектом. Отпал один из VPN, и я потерял возможность заходить в тестовый стенд мобильного приложения.

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

Но есть и плюсы

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

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

Что нужно знать про IT-карьеру банке

• Финтех — это надолго. Чтобы полностью прочувствовать сферу, нужно не меньше нескольких лет.
• Не грози менеджеру своему, попивая смузи у себя за монитором. Выстраивай хорошие отношения с коллегами, так как текучка кадров низкая по сравнению с рынком, соответственно, взаимоотношения довольно тесные.
• В банке высокий уровень ответственности, сложные проекты и задачи. И требования к хард скилам выше, чем в небольших компаниях. Перед приходом в большой энтерпрайз желательно проработать хотя бы 2–3 года в другом месте. Может быть сложно, возможно, ты будешь единственным специалистом в своей сфере внутри команды. И придётся сразу включаться в работу над сложными проектами, а не ходить по мелким задачам вместе с ментором.
• Софт-скилы решают. Я бы выделил:тайм-менеджмент — сам себе менеджер должен грамотно распределять своё время и ресурсы;многозадачность — чтобы время, которое тратится на согласования, не уходило в никуда, и ты не тонул в работе, когда появляется слишком много задач;коммуникабельность — потому что встреч действительно много;гибкость и стрессоустойчивость — в банке либо всё горит, либо всё спокойно, много людей с разными характерами, с которыми нужно пересекаться и договариваться.
• Просто писать код и трекать Jira не выйдет. Работа в банке предполагает много сторонних вещей — от презентаций продуктов до дополнительного обучения.
• С бюрократией придётся смириться и полюбить её. Бесконечная почта и массовые рассылки, подписи, согласования, ожидание — это естественные процессы.
• Финтех — это про стабильность. Банк — большая компания, которая обеспечит разработчику высокую зарплату, ДМС, приятные бонусы и гарантии на ближайшие несколько лет, даже в такое нестабильное время.
• Финтех — это onelove или выгорание. Смотри по ощущениям, ведь он очень специфичен и подойдёт не каждому.

Узнайте, как изменился Python в версии 3.11, как написать ботов в WhatsApp и Telegram для работы с финансами, как прокачать свои знания в Python с помощью пятиминутных упражнений и как написать тестовое задание на собеседовании при помощи ChatGPT.

Новости Python и дискуссии

• JEP-400 или UTF-8 РєРѕРґРёСЂРѕРІРєР° РїРѕ умоЫчанию
• Субъективные итоги 2022 года в мире Python
• Лучший язык программирования: рейтинг TIOBE 2022
• Видео «Язык года», Самые высокие зарплаты в 2022, Потрясающие увольнения в IT и другие новости
• EN Python 3.11: Improved Type Hints
• EN Allow import … from … notation

Гайды и туториалы по Python

• Сделано на Python: экспорт статистики ВКонтакте с помощью Prometeus и Grafana
• Web3: пишем небольшой фреймворк для работы со смарт-контрактами на Python
• Телеграм бот на Python, для напоминаний о реквестах на BitBucket
• Быстрый приём платежей QIWI в проекте Python
• Как правильно сделать рекурсию?
• Как сохранить данные с первого запуска, чтобы во втором запуске их можно было использовать?
• Как реализовать анимацию переливающегося текста css?
• Торговые роботы на Python
• Как отправить и скачать файл в FastAPI
• EN Electron + Django ( Part 1 ), desktop app integrate JavaScript & Python
• EN Introducing Fugue — Reducing PySpark Developer Friction
• EN Django application to automate the WhatsApp messaging
• EN Integrate Stripe Payments with Django By Building a Digital Products Selling App
• EN Building Personalised Music Recommendation System
• EN How to Generate Text with OpenAI, GPT-3, and Python
• EN Making a Game in Python with No Experience

Обучение Python: курсы, упражнения и советы

• NoNa: Алгоритм заполнения отсутствующих данных
• Советы по архитектуре кода для начинающих
• 3 принципа написания чистого кода на Python
• Видео Лучшие способы Ускорить и Оптимизировать Python код
• EN Data Science with Python: A Guide to Essential Libraries and Frameworks
• EN 5 mins LevelUp Your Python in 2023
• EN Repeated string concatenation is quadratic in PyPy (and CPython)
• EN Hexagonal architecture in Python
• EN Google’s Python Class

Развлекательный контент

• Как ChatGPT за меня тестовое задание для собеседования писал
• Воссоздаем старую компьютерную графику с помощью генеративных моделей
• EN Top 10 Python Interview Question and Answers

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

Следующие подборки можно найти здесь:

• Дайджест Python #2: чем плох Django и как создать бота на GPT-3
• Дайджест Python #3: пишем AI-плеер для сайта и боремся с лесными пожарами

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

Центробанк сообщил, что в России появится новая форма валюты — цифровой рубль. Узнали у экспертов, чем он отличается от привычного рубля и имеет ли что-то общее с криптовалютой.

Цифровой рубль — это дополнительная (третья, наряду с наличной и безналичной) форма российской национальной валюты, которая будет выпускаться Банком России в цифровом виде.

Предварительный механизм работы Центробанк предлагает такой: каждому цифровому рублю присваивается уникальный цифровой код. Он будет находиться в цифровом кошельке клиента на специальной платформе. Сначала Центробанк откроет кошельки Федеральному казначейству и банкам. Затем финансовые организации дадут доступ в кошельки своим клиентам. Каждому клиенту будет доступен только один цифровой кошелёк.

Мы, как разработчики мобильных приложений, считаем, что распространение цифрового рубля потребует комплексных изменений в логике и структуре мобильных приложений банков. Скорее всего, по аналогии с СБП, ЦБ РФ подготовит единые рекомендации по реализации платформы цифрового рубля для коммерческих банков. И каждому банку придётся под них подстраиваться даже в ущерб существующим возможностям в мобильном приложении.

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

Это не отдельная валюта, это дополнительная форма национальной валюты с равным правовым статусом. Сейчас в ходу только две: наличная и безналичная. Это не крипта. У криптовалюты нет эмитента — выпускающего органа, а у цифрового рубля он будет — и это Центральный Банк РФ. Главное отличие цифрового рубля от привычных нам денег в том, что он выпускается с помощью цифровых технологий, а от криптовалют он отличается наличием эмитента.

Можно будет намайнить цифровой рубль? Вряд ли. Официальной информации от ЦБ по этому вопросу нет, но смеем предположить, что это расходится с концепцией. Майнинг предполагает неограниченное создание платёжных единиц. В то время как выпуск цифрового рубля будет установлен Центральным Банком.

Зачем он вообще нужен? На банковских картах находится безналичная форма денег, а цифровой рубль, согласно концепции ЦБ, будет являться третьей формой. Её будет выпускать непосредственно ЦБ, без привязки к «бумажным» деньгам. К тому же, на цифровой рубль делают ставку как на валюту, способную проводить транзакции в офлайн-режиме.

Банк России берёт на себя разработку основной инфраструктуры — программного модуля, интегрированного в мобильные приложения банков. А значит и за безопасность должен отвечать главный выпускающий и регулирующий орган. Но наш 12-летний опыт работы с банковскими проектами свидетельствует, что не всё так просто. Такие проекты требуют большого внимания и много ресурсов и со стороны разработчика мобильного приложения, и со стороны конкретного банка. В этом смысле можно говорить о распределённой ответственности: главный эмитент отвечает за безопасность транзакций, разработчики и пентестеры — за кибербезопасность, банки — за реализацию.

Можем предположить, что ЦБ сделает всё, чтобы минимизировать вероятность подделок. В цифровом пространстве это, возможно, даже проще отследить, нежели с фиатной валютой.

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

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

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

Определенно коммерческие банки постепенно потеряют определяющую роль и перейдут в разряд посредников, функцией которых, станет открытие счетов клиентам в Центральном Банке России, так как именно в нём будет храниться национальная цифровая валюта.

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

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

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

На Западе для цифровых валют, выпускаемых центральными банками, уже давно придумали отдельное название (CBDC), так как они существенно отличаются от традиционных криптовалют. Основное различие — отсутствие децентрализации. Цифровым рублем будет управлять Банк России. Это значит, что ЦБ может увеличивать/снижать эмиссию e-RUB, блокировать операции с валютой для лиц из черных списков и даже манипулировать курсом цифрового рубля.

Компании хотят улучшить приложение Tap on Phone от Mastercard, которое помогает бизнесу принимать платежи через смартфон. Скорее всего, в нём появится новая технология бесконтактных платежей, основанная на 5G.

5G позволит малому и среднему бизнесу быстрее обрабатывать транзакции, считает генеральный директор Verizon.

Источник: Edngadget

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

Предыстория

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

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

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

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

Изначально для его тестирования нужно было сделать огромное количество операций:

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

И на каждом из этих этапов возможны какие-то заминки/форс-мажорные обстоятельства, затягивающие процесс.

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

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

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

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

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

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

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

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

Как проводить тесты за несколько часов

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

Популярные браузеры позволяют наладить информационный обмен с нативным приложением с помощью расширений через стандартные потоки ввода-вывода (Native messaging в Google Chrome, например). Такое приложение было реализовано, оно устанавливалось при установке соответствующего расширения, передавало команды на считыватель и ответ возвращало обратно, через расширение на страницу.

Таким образом, у бэка системы появилась возможность напрямую общаться по NFC с телефоном удаленного пользователя. И на основе этого была реализована возможность, скажем так, удаленно совершать покупки.

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

Вот именно эта возможность на порядок сократила сроки реализации ПО, существенно изменив цикл разработки.

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

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

Для этого мы предусмотрели ролевую модель, которая подразумевает разделение пользователей по организациям и включает в себя:

• роль администратора НСПК — он определяет, какой набор операций сможет проводить та или иная организация, заводит профиль организации и добавляет в нее операторов и администраторов организаций;
• администраторы организаций — могут заводить операторов только для своей организации;
• операторы — собственно тестировщики или разработчики, которые могут проводить тесты.

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

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

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

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

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

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

Для этого было написано еще одно расширение для браузера, которое теперь могло выполнять скрипты ADB по команде с сервера, которые отправлялись в нужные моменты тестирования.

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

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

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

Бесплатное обучение в школе состоит из двух этапов — теоретический курс «Финтех-тренды» и практический курс на выбор. Первую часть о том, как устроен Финтех и как создавать передовые продукты, расскажут топ-менеджеры банка. А вторую часть по дисциплинам «Управление рисками», «Системное администрирование», «Диалоговые системы», Scala, Frontend, iOS, Android и QA Automation прочтут специальные спикеры. На практике предусмотрены домашние работы, на которые может уйти 10–15 часов в неделю, и дипломный проект.

Поступление

Вступительные онлайн-экзамены в Финтех можно сдать с 12:00 3 сентября до 23:59 10 сентября. Для получения приглашения необходимо зарегистрироваться. Экзамен состоит из задач по математике и программированию. Их нужно решить за установленное время. Занятия начнутся после 17 сентября.

Подробную информацию о приемной кампании можно узнать в группе ВКонтакте или в канале Телеграм.

Обучение будет состоять из двух частей — теоретического курса «Финтех-тренды» и практического курса на выбор. Теоретический курс расскажет о том, как устроен современный финтех, о биткойне и блокчейне, соцсетях, искусственном интеллекте и других современных технологиях, применяющихся в банковской сфере. Преподавать будут топ-менеджеры банка. Выбирать практическую часть можно среди следующих направлений: Scala, Frontend, QA, Risks, Android, iOS. Список доступных направлений зависит от города, в котором планируется обучение. Проводить практические занятия будут сотрудники банка — архитекторы, техлиды, старшие разработчики.

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