Разработка и план внедрения Self Cube

Cube — Разработка

Типовой план разработки

Стандартный план внедрения платформы Self Cube

Пошаговый график запуска: архитектура и UX/UI, 15 двухнедельных спринтов, 3 релиза, пилот на сотрудниках и выход в промышленную эксплуатацию за 10–12 месяцев.

спринтов разработки (по 2 недели)

промежуточных релиза

месяцев до Go Live

4 ключевых этапа внедрения

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

Архитектура, аналитика и UX/UI

Месяцы 1–3 • Проектирование и согласование

Подготовительный фундамент:
• Совместное проектирование архитектурного контура и спецификаций API.
• Описание интеграций с АБС, картами, KYC/AML и шинами данных.
• Разработка дизайн-системы, UI Kit и кликабельных прототипов для Web, iOS и Android.
• Фиксация скоупа, критериев приёмки MVP и подписание детального соглашения (Scope & Commercials).

15 спринтов разработки

Месяцы 2–10 • Двухнедельные спринты с регулярными демо

Итеративная поставка функционала (демо каждые 2 недели):
• Спринты 1–2: Бэклог, архитектурный каркас и CI/CD стенды.
• Спринты 3–4 (Core Domain): Профили клиентов, счета, базовые транзакции, лимиты.
• Спринты 5–6 (Channels): Интерфейсы Web, iOS и Android как тонкие клиенты к API.
• Спринт 7 (MVP ★): Первый рабочий контур платформы, готовый к сквозному тестированию.
• Спринты 8–11 (Features & Expansion): Кредиты, депозиты, платежи, МСБ, AI-ассистенты.
• Спринт 12 (Mid-Demo ★): Комплексная демонстрация всех модулей стейкхолдерам.
• Спринты 13–15: Стабилизация, нагрузочное тестирование и миграция данных.

Тестирование, 3 релиза и безопасность

Месяцы 4–11 • Интеграционный регресс и ИБ аудит

Непрерывный контроль качества:
• На каждом из 3 релизов проводится полное интеграционное тестирование и автоматизированный регресс.
• Выделенный контур проверки производительности и отказоустойчивости.
• Комплексный аудит информационной безопасности (Security Review), пентесты и проверка соответствия требованиям регулятора.

Пилот на сотрудниках и Go Live

Месяцы 9–12 • Внутренний пилот и промышленный запуск

Безопасный вывод в эксплуатацию:
• Запуск закрытого пилота на сотрудниках банка для проверки боевых сценариев в реальных условиях.
• Доработка и полировка интерфейсов на основе реальной обратной связи.
• Настройка сквозного мониторинга, алертов и логирования.
• Бесшовный перевод в промышленную эксплуатацию (Go Live).

Принципы реализации Self Cube

Сначала контур и интерфейс, затем код каналов. Регулярные демо исключают сюрпризы в конце проекта.

Демо каждые 2 недели

Каждый спринт завершается работающим инкрементом и демонстрацией стейкхолдерам.

Тонкие клиенты к API

Web, iOS и Android работают через единый документированный слой API микросервисов.

3 промежуточных релиза

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

Пилот на сотрудниках

Откатка всех пользовательских путей на внутренней фокус-группе до клиентского трафика.

Audit-by-Design & ИБ

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

Фиксированные сроки

Стандартный 10–12 месячный цикл внедрения с прозрачным графиком вех и контрольных точек.

Сколько длится внедрение платформы ДБО по типовому плану?

Типовой каркас Self Cube — архитектура и UX, 15 спринтов по две недели, три релиза, пилот на сотрудниках и промышленный запуск за 10–12 месяцев. Это ориентир плана, а не дата «под ключ» для любого банка. Срок двигают готовность АБС, число интеграций и глубина уникального UX. Имеет смысл отдельно оценить миграцию данных и контур безопасности: они часто сидят вне диаграммы спринтов. Если ландшафт тяжёлый, каркас вех тот же, календарь длиннее 10–12 месяцев. Обещать дату без этого разбора нельзя.

Это жёсткие 10–12 месяцев или план можно сжать?

10–12 месяцев — стандартный каркас типового плана, не приговор. Сжать можно, если режете сегменты и не рисуете уникальный набор экранов с нуля на каждый канал. Ядро, интеграции и ИБ своё время всё равно занимают: их не схлопнуть лозунгом «давайте Agile». Имеет смысл ускорять за счёт готовых модулей и тонких клиентов к API, а не за счёт отмены пилота на сотрудниках. Без пилота промышленный запуск обычно дороже сэкономленных недель. План обсуждают на ландшафте банка, а не как универсальный Gantt.

Когда появляется рабочий MVP цифрового банка?

На типовом плане — седьмой спринт: уже не прототип экранов, а рабочий контур домена и каналов, который можно гонять сквозными сценариями. До этого идут каркас, CI/CD, профили, счета, базовые транзакции и тонкие клиенты веб/iOS/Android. Имеет смысл не называть MVP макетом в Figma. Если к седьмому спринту нет сквозного пути «клиент — канал — домен — ядро», это ещё не платформа. Дальше на Mid-Demo показывают расширение: кредиты, платежи, МСБ, ассистенты.

Зачем нужен пилот на сотрудниках до запуска для клиентов?

Чтобы словить права, лимиты, дыры интеграций и странные маршруты UX до клиентского трафика. Сотрудники бьют контур так, как не бьёт счастливый путь в презентации: чужие роли, чужие лимиты, обрывы шины. Имеет смысл не пропускать этот этап ради даты питча. Ошибки идентификации и лимитов в проде стоят дороже двух спринтов пилота. Self Cube ставит пилот после трёх релизов и до промышленной эксплуатации. Это часть плана внедрения ДБО, а не опция «если успеем».

Сколько релизов и как часто заказчик видит демо?

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

Нужно ли отдельно заказывать разработку мобильного банка?

Интернет-банк, iOS и Android в плане Self Cube — тонкие клиенты к API, а не толстые приложения со своей бизнес-логикой. Отдельный «проект мобильного банка» как вторая платформа обычно не нужен, если каналы ходят в тот же шлюз. Имеет смысл не закладывать уникальный UX на каждый экран: это главный раздуватель срока. Если канал тащит правила продуктов в себе, вы снова получите три разных банка. Тонкий клиент как раз это предотвращает.

Что входит в этапы архитектуры, разработки, тестирования и запуска?

Сначала архитектура, аналитика и UX/UI: границы доменов, интеграции, каркас. Затем 15 спринтов разработки с демо раз в две недели. Потом тестирование, три релиза и контур ИБ — audit-by-design, а не проверка в конце. Финал — пилот на сотрудниках и Go Live. Имеет смысл не схлопывать ИБ в «последнюю неделю». Если безопасность и нагрузочные тесты оставляют на хвост, промышленный запуск сдвигается. Каркас этапов как раз против этой ошибки.

От чего зависит срок внедрения на конкретном банке?

От готовности АБС и шины, числа продуктов в первом контуре, глубины кастомизации интерфейсов, миграции данных и того, сколько исключений банк хочет оставить ручными. Типовой план даёт вехи, календарь собирают на ландшафте. Имеет смысл прикидывать не «сколько стоит спринт», а какие интеграции обязаны работать к MVP. Если ядро не отдаёт стабильный API, срок живёт там. Self Cube ускоряет за счёт готовых модулей и тонких клиентов, но не отменяет эту зависимость.

Прикинуть план на ваш банк

Разберём 15 спринтов и 3 релиза на вашем ландшафте, оценим интеграции и согласуем график запуска.

Запросить демо