Содержание слайдов

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

   Эволюция подходов к развитию мобильного банка Тинькофф

2. 2. Александр Поломодов

   CTO мобильного банка, онлайн-привлечения и не только

   Курирую наши интервью по System Design и Troubleshooting

3. 3. Для тех, кто задавался этими вопросами

   Для кого доклад

   Зачем масштабировать разработку?

   Как сделать это эволюционно, не проседая по бизнес-задачам?

   Какую целевую топологию выбрать для ваших команд?

   Как сбалансировать платформенную и продуктовую разработку?

4. 4. Шестнадцать лет в шести вехах

   Мобильный банк: канал, продукт, платформа

   2006 — основание компании, 2008 — интернет-банк

   2011 — появление мобильного банка

   2015 — мобильный банк как топовый продукт

   2019 — платформа, 2022 — что дальше

5. 5. 01. Мобильный банк как канал

   2006–2011: от почты до первого приложения

6. 6. Дистанционный банк по модели Capital One

   Как всё начиналось (2006)

   На старте только кредитные карты

   Прямые продажи почтой

   Взаимодействие с клиентами через call centers

7. 7. Первую версию приложения сделали подрядчики

   Появление мобильного банка как дополнительного канала

   Для старта были выбраны базовые услуги

   Первую версию сделали подрядчики на заказ

   Требования к приложению писались поэкранно

   Планирование шло версиями с заранее определённой функциональностью

8. 8. 02. Мобильный банк как продукт

   2015: разработку перенесли внутрь

9. 9. Одна команда из двадцати на трёх заказчиков

   Мобильный банк как продукт

   Заказчики: банк для физлиц, для юрлиц, страховая

   Общая IT-команда ~20 человек с общей приоритизацией

   Крупные релизы примерно раз в квартал

   Монолитное приложение и Mother API

10. 10. Это работало — и вот почему

    Пока продуктов немного, а команда небольшая

    Было несколько основных продуктов, ресурсы шли им

    Команда была небольшой — ~50 человек к 2019 году

    Приоритетами получалось управлять вручную

    Основной фокус — на расширении функциональности

11. 11. 03. Мобильный банк как платформа

    2019: вертикали, команды и архитектура

12. 12. Банк-монолайнер вырос в набор вертикалей

    Развитие группы и IT-ландшафт

    2006–2019: от монолайнера до SuperApp

    Вертикали: физлица, SME, инвестиции, страховая

    …мобильный оператор и нефинансовые сервисы

    И платформы: data, ML, origination, инфраструктура

13. 13. Приложений стало несколько, а core-команда одна

    Разные приложения и общая core-команда

    SuperApp, приложение банка для юрлиц

    Приложения инвестиций и мобильного оператора

    Мобильная core-команда обслуживает всех

    Она и становится платформенной командой

14. 14. Шесть бизнесовых команд и шесть платформенных

    Новая структура команды

    Banking products, Payments, Insurance products

    SME products, Invest products, NonFinancial Services

    Платформенные: Release, Platform, Design

    …Excellence, Performance, Reliability

15. 15. Меняются команды — меняем архитектуру системы

    Три состояния одной и той же схемы

    Организации проектируют системы по своим коммуникациям

    Было: общая команда над слоистой архитектурой

    Стало: автономные команды со своими доменами

    Цель: свои модули и модульная архитектура

16. 16. Релизы привязаны к датам, а не к функциональности

    Release trains и инженерная культура

    Команды должны работать автономно

    Kanban-процессы внедряют delivery managers

    Автотесты обязательны для новых фич

    Fitness functions через Danger в CI/CD

17. 17. Большие релизы раз в четыре недели

    Промежуточные результаты

    Плюс релизы меньшего размера в промежутке

    Процессы описаны, ответственность на команде и DM

    Платформенные команды внедрили модуляризацию

    Наладили mobile SRE и оптимизировали производительность

18. 18. 04. А что дальше?

    2022: сквозная поставка и governance

19. 19. Три триггера, что пора менять команды

    Бизнес хочет улучшений в сквозной поставке ценности

    Софт стал слишком большим для одной команды

    Темпы поставки устойчиво замедлились

    Бизнес-сервисы опираются на разрозненные нижележащие

    У каждого триггера свой набор симптомов

20. 20. Сквозной процесс строим через delivery manager

    Команды поверх SuperApp, APIs и Backends

    Метрики сквозного процесса: TTM, lead time, cycle time

    Работа и с downstream, и с upstream

    От API «собери данные сам» к BFF для мобильных

    И к сборке read-моделей на потоке событий

21. 21. Правила проверяются автоматически

    Платформенный technical governance

    Что такое команда и какие у неё атрибуты

    Процессы development, deployment и эксплуатации

    Правила показывают уровень здоровья команд

    Метрики: производительность, качество, поток

22. 22. 05. Итоги

    Вопросы, на которые я обещал ответить

23. 23. От стартапа до команды SuperApp на ~400 инженеров

    Вопросы, на которые я обещал ответить

    Своей мобильной разработки на старте не было вообще

    Приложение стало преимуществом — разработку внесли внутрь

    Продуктов стало много — понадобилась платформа

    Сквозные команды потребовали technical governance

    Возьмите этот опыт и примерьте на свою ситуацию

    Зачем, как эволюционно, какая топология и как сбалансировать платформу с продуктом

24. 24. Материалы для дальнейшего изучения

    С финального слайда доклада

    Текстовая версия выступления — bit.ly/mobileBankEvolution

    В конце статьи приведены все рекомендованные материалы

25. 25. Спасибо!

    polomodov.tech

    Все слайды и ссылки — в Telegram-канале

    Александр Поломодов, Technical Director & Fellow, Т-Технологии

    @book_cube