Как меняли разработку мобильного банка под бизнес

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

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

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

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

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

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