К содержанию

Банки и финтехи

AI-native
разработка

Те же 11 человек выпускают за квартал 27 фич вместо 6. И качественнее: между замыслом и выпуском 2 передачи вместо 5.

  • 2 недели Практикалендинг вместо 3 месяцевот идеи до выпуска
  • 3 месяца Пилотприложение вместо 12с подключениями к системам банка
  • 5 париз тех же 11 человеквместо одной команды, без найма
  • 1 архитекторна все 5 парраньше — ведущий разработчик одной команды

Обычный банк11 человек одной командой: большая фича к 90‑му дню и несколько поменьше по дорогебольшая 1 · средних 3 · маленьких 26фич

AI-native банкте же 11: 5 пар «продуктолог + разработчик» и архитектор на все парыбэк-системыинтерфейс и бэкинтерфейслендингибольшая фичабольшая 1 · средних 14 · маленьких 1227фич

День 90: у обычного банка вышло 6 фич, у пар — 27: 1 большая, 14 средних и 12 маленьких.

Как считаем сроки и число фич

Для сравнения месяц условно равен 30 дням, неделя — 7 дням. Лендинг: 3 месяца — 90 дней, 2 недели — 14 дней. Приложение в пилоте: 3 месяца вместо 12.

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

Было 11 человек: продуктолог, продакт-менеджер, два аналитика, дизайнер, два веб-разработчика, два Android-разработчика и два тестировщика. В обычной схеме вся команда ведёт одну большую фичу к 90-му дню и по дороге выпускает ещё 3 средних и 2 маленьких — 6 за квартал. Те же 11 — это 5 пар по двое и архитектор. У пар разные задачи и сроки: одна пара делает ту же большую фичу, что и вся обычная команда, за 60 дней, а потом ещё одну поменьше; лендинги — по 2⁠–⁠3 недели (первый — 14 дней); доработки интерфейса — по 1⁠–⁠2 недели; бэк-систем — по 3⁠–⁠4 недели. За 90 дней пары выпускают 27 фич: 1 большую, 14 средних и 12 маленьких — против 6. Большая — от 45 дней, средняя — от 2 недель до месяца, маленькая — до 10 дней.

Внедряю этот подход в банках и финтехах. Пример на странице — лендинг РКО (расчётно-кассовое обслуживание бизнеса): продуктолог с ИИ собирает прототип, код и описание, разработчик доводит их до выпуска.

Почему одна команда выпускает так мало?

01Новая команда справляется лучше и быстрее

Продуктолог сам собирает прототип лендинга за 3 дня — замысел проходит 2 передачи вместо 5

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

Прежняя схема 6 ролей

Пара с ИИ продуктолог и разработчик, архитектор на все 5 пар

Выпуск крупной фичи
на 90‑й день
на 60‑й день
Ролей на фиче
6
3
Передач по цепочке ролей
5
2
Передач между людьми за 90 дней
36
17
Один оборот плит — 90 дней

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

Как убрать лишние круги?

02Работа продуктолога

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

Продуктолог в Cursor или Claude Code · демо

Готовы экран, код и описание переходов.

Прототип

РКО
для бизнеса

ведёт сразу в заявку на РКО
Код
product: "РКО для бизнеса"
step: "application"
Выбор передаётся в заявку
Описание
  1. Лендинг РКО
  2. Заявка на РКО
  3. Подтверждение
Передачи между участниками
Было

Шесть ролей в цепочке

С ИИ

Продуктолог → разработчик → ревью архитектора

3 рабочих дняпродуктолог собирает прототип
1 неделя всеговместе с согласованием и доработкой

Три рабочих дня продуктолог собирает прототип в Cursor или Claude Code по образцам экранов компании и сам проходит весь путь клиента: видит результат с первого дня, а не на приёмке. С согласованием и доработкой выходит неделя.

Что получает разработчик?

03Работа разработчика

Вторая неделя — выпуск: разработчик начинает с работающего прототипа, а не с задания

Нажмите «Перейти к заявке»: выбранный продукт переходит в заявку, а в коде подсвечивается строка шага.

Демо: лендинг РКОЛендинг РКО

Предприниматель

РКО для бизнеса

В заявкеРКО для бизнеса

Состояние: Лендинг РКО. Продукт: РКО для бизнеса.

1Лендинг РКО
2Заявка на РКО
3Подтверждение

Код прототипа: подсвечена строка текущего шага

Код примераTypeScript
example/rko.tsкод примера
export const RKO_PRODUCT = "РКО для бизнеса";export const BUSINESS_CUSTOMER = "Предприниматель"; export type PrototypeStep = "product" | "application" | "confirmation";export type PrototypeAction = "next" | "back" | "reset"; export type PrototypeState = {  step: PrototypeStep;  product: typeof RKO_PRODUCT;  business: typeof BUSINESS_CUSTOMER;}; export type ApplicationCheck = {  expectedProduct: string;  applicationProduct?: string;}; export function initialPrototype(): PrototypeState {  return { step: "product", product: RKO_PRODUCT, business: BUSINESS_CUSTOMER };} function openApplication(state: PrototypeState): PrototypeState {  return { ...state, step: "application" };} function confirmLocally(state: PrototypeState): PrototypeState {  return { ...state, step: "confirmation" };} export function transitionPrototype(state: PrototypeState, action: PrototypeAction): PrototypeState {  if (action === "reset") return initialPrototype();  if (action === "back") {    if (state.step === "confirmation") return openApplication(state);    return initialPrototype();  }  if (state.step === "product") return openApplication(state);  if (state.step === "application") return confirmLocally(state);  return state;} export function checkApplication({ expectedProduct, applicationProduct }: ApplicationCheck) {  const actualProduct = applicationProduct ?? "Продукт потерялся";  return { actualProduct, passed: actualProduct === expectedProduct };} export function sourceTokenForState(step: PrototypeStep) {  return { product: "initialPrototype", application: "openApplication", confirmation: "confirmLocally" }[step];}

Неделя 2 из 2 · от прототипа до выпуска · практика

1Проверитьпуть клиента
2Подключитьсистемы банка
3Закрепитьавтотестами
4Выпуститьпосле проверок

Кем стали люди из прежней команды?

04Команда

Те же 11 человек — 5 пар вместо одной команды, без найма

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

  • 5 продуктологов

    продуктолог, продакт-менеджер, два аналитика и тестировщик

  • 5 разработчиков

    веб-разработчик, два Android-разработчика, второй тестировщик и дизайнер — он собирает интерфейс с ИИ

  • 1 архитектор

    ведущий веб-разработчик — теперь держит архитектуру и ревью кода всех 5 пар

Кто что делает теперь
ФункцияРаньшеПродуктологРазработчикАрхитектор
Ценность и требованияПродуктологВыполняет··
СценарийПродакт-менеджерВыполняет··
ПрототипДизайнерВыполняет··
Системный анализАналитик·Выполняет·
Код и подключенияРазработчик·Выполняет·
ТестыТестировщик·Выполняет·
Архитектура и ревью кодаРазработчик··Выполняет

Теперь: П — продуктолог · Р — разработчик · А — архитектор

С чего начать в банке?

05Этапы внедрения

Начать можно сразу — с 6 направлений, от кредитного конвейера до CVM

Пары «продуктолог + разработчик» начинают с процессов, где банк выпускает продукты и работает с клиентами. Авторизованные зоны и ядро банка — следующие этапы.

  1. Сразу

    Этап 1Процессы вокруг продуктов

    С них пары начинают в первый же день

    • Выпуск банковских продуктовкредитный конвейер, открытие РКО, выпуск карты
    • Закрытие, обслуживание и справкив том числе консультации клиентов
    • Лидогенерацияпоиск клиентов и заявки в продажи
    • Подключение партнёровпо API и MCP
    • Актуализация данныхавтоматически, без ручных сверок и выгрузок
    • CVMработа с базой: предложения и удержание клиентов

    Системы

    • CRM
    • Фронт-офис сотрудника
    • Продуктовый каталог
    • Кредитный конвейер
    • Коммуникации с клиентами
    • НСИ и справочники
    • API-шлюз и MCP
  2. Следом

    Этап 2Авторизованные зоны

    Каналы, куда клиент входит под своей учётной записью

    Системы

    • ДБО
    • Авторизованные зоны сайта и приложения
  3. Дальше

    Этап 3Ядро банка

    Учёт счетов и операции по картам

    Системы

    • АБС
    • Процессинг
    • Связка процессинга и АБС

На каком ПО это строить?

06ИТ-ландшафт

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

Слева — обобщённая карта: 80 типов ПО, которые есть у банка в среднем, в основном вендорские комплексы. Справа — открытые системы, на которых пара строит продукт. АБС, процессинг и другие банковские системы остаются: продукт подключается к ним по API.

Что сравниваемКлассический банк80 типов ПО · обобщённая карта среднего банкаПара с ИИстек продукта на открытых системах
АрхитектураМонолит: любая правка трогает весь комплекс и ждёт его выпускаОтдельные сервисы и процессы на Temporal: меняется только нужная часть
ЛицензииВендоры берут сотни миллионов ₽ в год за лицензии и поддержку, за годы — миллиарды0 ₽ за лицензии платформы. Открытый — не значит бесплатный: банк платит за людей, серверы и подписки инструментов
ЛюдиПод каждую систему нужны редкие специалисты вендора или интегратораМассовые технологии: PostgreSQL, Kafka, Kubernetes знает рынок, а код помогает писать ИИ в IDE
ВыпускТяжёлые выкатки: окна релизов, долгие согласования, ручные откатыGitLab CI/CD и Kubernetes: выпуск маленькими порциями и откат одной командой
Требования и проектирование6 типов ПОтрекер задач, база знаний, реестр архитектуры, редактор процессов, прототипы, проектирование APIPRD и User FlowFigmaOpenAPIAsyncAPIAGENTS.md
Разработка16 типов ПОIDE, контроль версий, сборка, анализаторы, веб- и мобильные фреймворки, UI-библиотеки, CMS, ORMCursorMCPGitLabReactTypeScriptViteNode.js
Процессы и интеграция10 типов ПОBPM-движок, правила, планировщик, API-шлюз, сервисная шина, брокер, файловый обмен, low-code, RPATemporalKafka или NATSDebeziumgRPC
Данные9 типов ПОСУБД, кэш, файловые хранилища, поиск, ETL, хранилище данных, НСИ, BIPostgreSQLPgBouncerRedisElasticsearch
Тесты и выпуск7 типов ПОуправление тестами, автотесты, нагрузка, моки, тестовые данные, CI/CD, репозиторий сборокGitLab CI/CDPlaywrightMSWWireMockTestcontainersk6
Инфраструктура и эксплуатация8 типов ПООС, виртуализация, контейнеры, автоматизация, балансировщик, мониторинг, резервные копии, ITSMDockerKubernetesHelmOpenTelemetryPrometheusGrafanaLokiTempo
Безопасность9 типов ПОдоступ и роли, привилегии, секреты, криптография, сетевая защита, DLP, SIEM, AppSecKeycloakVaultSAST-сканер
Банковские системы15 типов ПОАБС, ДБО, CRM, процессинг, платежи, антифрод, AML, отчётностьОстаются: продукт подключается к ним по API

Cursor работает в режиме Privacy Mode по согласованию с ИБ, реальных данных клиентов в прототипе нет.

Как проверить это у себя?

07План пилота

Проверить у себя — 2 недели и одна пара: первый лендинг к 14-му дню

1 парапродуктолог и разработчикАрхитектор — на ревью кода
  1. Неделя 1Прототип
  2. Неделя 2Выпуск
    лендинга

Что подготовить: выберите пункт

  1. что нужно клиенту

    Один сценарий

    РКО для бизнесаЛендинг → заявка → подтверждение
    Было

    Текст требований

    С ИИ

    Прототип, по которому можно пройти

    В пилоте меряем: срок от замысла до выпуска

что нужно клиенту

Один сценарий

РКО для бизнесаЛендинг → заявка → подтверждение
Было

Текст требований

С ИИ

Прототип, по которому можно пройти

В пилоте меряем: срок от замысла до выпуска

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

Какие ещё процессы меняю с ИИ?

Экраны, код и сессия ИИ — демонстрационная копия на примере лендинга РКО. Сроки — из реальных запусков лендингов.