Канал. Продукт. Платформа

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

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

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

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

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

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