Источник
Channel -> Product -> Platform
Кейс HighLoad SPB 2022 про эволюцию мобильного банка и переход к платформенной модели.
Источник
Channel -> Product -> Platform
Кейс HighLoad SPB 2022 про эволюцию мобильного банка и переход к платформенной модели.
Это кейс о том, как мобильный банк проходит путь от локального канала к платформе на десятки команд. Важный вывод для технических лидеров: на таком росте невозможно менять только код или только оргструктуру - эволюция работает только как единая трансформация архитектуры, команд и инженерных правил.
TL;DR
- Эволюция мобильного банка проходит через три состояния: канал, продукт, платформа.
- С ростом масштаба меняются не только технологии, но и оргдизайн, роли и правила взаимодействия.
- Переход к платформе требует модульной архитектуры, платформенных команд и автоматизированного governance.
- Финальный фокус смещается на сквозной поток ценности: Mobile + API + Backends как единая система.
Ключевые вехи эволюции
- 2006: запуск модели дистанционного банка без отделений.
- 2008: запуск интернет-банка как первого digital-канала.
- 2011: запуск мобильного банка как второго digital-канала.
- 2015: мобильный банк входит в топ рынка, разработка переходит in-house.
- 2019: рост экосистемы и переход к superapp + платформенной модели.
Канал -> продукт -> платформа
2006-2011
Канал
- Небольшая команда и локальная оптимизация по экранным фичам.
- Подрядная разработка и релизное планирование с фиксированным scope.
- Главная цель: быстро получить рабочий digital-канал.
2015-2019
Продукт
- Единая in-house команда мобильного банка и быстрый рост фич.
- Кросс-функциональная работа (PM, дизайн, аналитика, mobile, QA).
- Слоеный монолит и ускорение бизнеса ценой накопления техдолга.
2019+
Платформа
- Разделение на business feature teams и platform teams.
- Общие архитектурные правила, модульность и tooling как масштабатор.
- Переход от локальной скорости к системной предсказуемости delivery.
Архитектурная эволюция
As-is: слоеный монолит
Архитектура работала на ограниченном масштабе и небольшом числе ключевых продуктовых потоков.
Virtual separation
Зоны ответственности начали появляться, но контуры владения еще оставались размытыми.
Target: модульная архитектура
Команды владеют наборами модулей, интеграция строится через публичные интерфейсы и контракты.
Операционная модель платформы
Новая структура команд
- Business feature teams отвечают за доменные сценарии superapp.
- Platform teams развивают mobile core, tooling и архитектурные guardrails.
- Роли CPO/CTO/Heads усиливают управляемость масштаба.
Release trains и delivery
- Релизы привязываются к датам, а не к фиксированному объему работ.
- Канбан и Delivery Managers управляют сквозным потоком.
- Автотесты и CI/CD quality checks становятся обязательными.
Governance и метрики
- Платформенные правила разработки и эксплуатации проверяются автоматически.
- Метрики охватывают производительность, качество и эффективность команд.
- Нарушения platform standards ограничивают вливание изменений.
Видео
Доклад на HighLoad SPB
Запись выступления с примерами командной и архитектурной трансформации.
Видео
Доклад на HighLoad SPB
Запись выступления с примерами командной и архитектурной трансформации.
Точка следующего роста
После стабилизации мобильной платформы ключевой вызов смещается на уровень сквозной поставки ценности: Mobile Bank, API и backend-сервисы должны работать как единый поток. Отсюда переход к stream-aligned связкам и пересборке межкомандного взаимодействия.
Типичные антипаттерны
Рост команды без пересборки архитектуры
Оргструктура дробится, а код остается монолитным, что резко увеличивает стоимость координации.
Фокус только на фичах
Короткая скорость высока, но системный техдолг начинает блокировать развитие на следующем масштабе.
Платформа как бюрократия
Если платформенные правила не автоматизированы и не объясняют ценность, команды обходят их.
Изолированный mobile-фокус
Без сквозной связки с API и backend delivery теряет предсказуемость на межсистемных изменениях.
Рекомендации
Синхронизируйте Conway и модульность
При изменении структуры команд сразу обновляйте границы модулей и контракты интеграции.
Вводите платформенные принципы рано
Правила должны появляться до взрывного роста, иначе стоимость миграции становится критичной.
Измеряйте поток end-to-end
Смотрите на value stream целиком, а не только на локальные метрики мобильного сегмента.
Поддерживайте эволюцию как brownfield
Переход к платформе лучше делать итеративно без остановки бизнес-поставки.
Итоговые выводы
- Масштабирование мобильного банка это всегда одновременное изменение продукта, архитектуры и организации.
- Платформенные команды и принципы становятся обязательным условием устойчивого роста, а не опцией.
- Следующий уровень зрелости начинается там, где mobile, API и backend работают как единый stream-aligned контур.