1. Начало

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

В начале 2019г. МТС принимает стратегию трансформации компании в продуктовую экосистему. Что это и зачем?

В последние годы активно набирает обороты гипотеза или даже мнение, что в в скором времени "монопродукты" перестанут существовать, а будущее пользовательского поведения - это не выбор каким продуктом он будет пользоваться для решение конкретных задач, а пользователем какой продуктовой экосистемы он будет. Вместо отдельного сервиса для вызова такси, отдельного оператора для покупки билетов, отдельного провайдера для банковских услуг - одна экосистема, которая будет комплексно закрывать большинство его потребностей. One ring to rule them all, если угодно.

Если посмотреть на рынок сегодня, то мы уже видим несколько успешных прецедентов этой гипотезы.

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

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

Третьим, и наиболее вероятным игроком этого рынка может стать МТС. Посудите сами:

1. Огромная пользовательская база. Более 70 млн платящих клиентов.

2. Наличие обширного продуктового предложения в разных сферах:

   • Телеком.

   • Банк.

   • Покупка билетов (Ticketland).

   • Медиа и развлечения - KION, eSports, MTC Music и тд.

   • Медтех - Медси и SmartMed.

   • Инвестиции и управление капиталом - МТС Инвестиции и Система Капитал.

   • и тд.

3. Огромная накопленная Big Data по пользовательской базе оператора, позволяющая очень точечно сегментировать клиентов и предлагать им наиболее релевантные продукты.

То есть, если "связать" все продукты в единый клиентский опыт, мы можем прийти в состояние когда:

Пользователь МТС с помощью карты МТС Банка оплачивает покупку билетов в MTC Ticketland, получает бонусные баллы в MTC Cashback, и тратит их на оплату подписки в MTC Kion и MTC Music.

Вообщем-то, этот сценарий и есть цель трансформации группы. Это ее вижн, цель и стратегия развития на ближайшую перспективу.

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

1. Изменение орг. структуры всей группы из Core-based модели, где одна из бизнес-вертикалей (Телеком) - это ядро бизнеса, и вся компания строится вокруг нее, в "плоскую" структуру независимых бизнес-вертикалей без явного центра. Что собственно и было сделано в начале 2019г. Телеком стал одной из вертикалей группы, а само слово "МТС" перестало означать мобильную связь, а стало префиксом ко всем продуктам группы - MTC Mobile, МТС Банк, МТС Ticketland, МТС Kion и тд.

2. Трансформации организационной и ролевой структуры, IT и бизнес процессов каждой отдельно взятой бизнес-вертикали МТС в сторону продуктовой модели управления, end-to-end команд, применения Agile и продуктовых подходов.

3. Создание сквозного бесшовного клиентского опыта между продуктам группы. И как следствие, изменение взаимодействия бизнес-вертикалей компании друг с другом.

В этой статье мы подробно поговорим о втором пункте - трансформация МТС Банка в продуктовую модель, на примере создания мобильного приложения банка.

2. Образ результата трансформации

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

1. Структура сформирована на базе независимых бизнес-юнитов (далее - Стримы), несущих end-to-end ответственность за свой продукт и его P&L.

2. Все стримы и команды живут в едином операционном ритме банка. Что позволяет нам связать top-down/bottom-up стратегические цели банка с ежедневными задачами разработчика в команде.

3. Высокий уровень Agile-зрелости команд.

Для оценки зрелости используем адаптированную под наши реалии матрицу зрелости команды - ссылка. Целевой показатель > 2.7 (из 4).

4. Быстрая скорость разработки функционала в продуктах. От взятия задачи в работу до вывода в прод менее 50 дней.

5. Создание качественных продуктов для пользователя (подробно об этом позже).

3. Стартовая позиция

Отлично, с предпосылками и терминологией разобрались. Можем переходить к сути. Давайте разбираться с чего мы начинали трансформацию:

1. Отрисовываем текущую структуру Департамента разработки мобильного банка.

Что характерно, ни продуктовых команд, ни определения зон ответственности, ни понятной ролевой модели в тот момент не было. Что ж, будем исправлять.

2. Проводим аудит внутренних процессов команды. Видим, что операционный ритм работы команд как таковой отсутствует. Эпизодически проводятся митинги в командах (напр. планирование), но без какой-то выстроенной системной логики и взаимосвязи друг с другом. Отсутствует как класс планирование разработки в целом, нет инструментов релиз-менеджмента, слабо построены процессы Контроля качества, и тд.

3. Замеряем уровень Agile-зрелости команды. Получаем оценку в 1.2 (из 4.0). На секундочку, уровень ниже 2.0 - это считай полное отсутствие любых элементов Agile и продуктового подхода. Да уж, материала для работы нам будет предостаточно.

4. Проводим сессии по отрисовки Value Stream Map продукта, чтобы узнать реальную скорость разработки.

И тут мы натыкаемся на первый по-настоящему шок. Средняя скоростью вывода функционала в прод. более 300 дней, и с частотой релизов около 1 раза в 6 мес.

Вдумайтесь, с момента "давайте сделаем эту фичу" до момента когда пользователь получил ее в приложении проходит чуть меньше года!

Надо отметить, что понимания этой цифры в тот момент ни у кого в банке не было. После ее первичного замера и опрозрачивания начался настоящий шторм, и мы как организация, проходили все 5 стадий принятия неизбежного. Были и крики, и возмущения, и пересчеты метрики, и попытки "сторговаться" на хотя бы 150 дней. Но в целом, эффект от появления этой цифры был потрясающе полезным, и дал крайне важный уровень поддержки трансформации со стороны топ-менеджмента. Все осознали и приняли, что с такими показателями жить нельзя и классный мобильный банк никогда не сделаем. Надо меняться!

5. Собираем любые метрики качества продукта, которые можем найти. Вот они:

• На 40+ месте в рейтинге мобильных банков Markswebb.

• Оценки в AppStor'ах на уровне 1.3 звезды.

• Сразу 5 финансовых мобильных приложений, доступных для скачивания пользователям экосистемы - МТС Банк, Новый МТС Банк, МТС Деньги, МТС Кошелек и MTS Payments.

6. Итого, из 5 пунктов нашего образа результата, мы не проходим ни по-одному.

Хорошее начало для изменений, не правда ли? :)

4. Шаг первый. Строим продуктовый* стрим

Структура формирует процессы. Процессы формируют культуру.

Помня эту мантру, нам становится вполне очевидно с чего нужно начинать изменения - Редизайн орг. структуры в продуктовую модель.

* Но подождите, какой к черту продуктовый стрим? Это неправильно, скажете вы. Ведь Мобильный банк - это не продукт, а канал, или даже витрина продуктов компании. То есть, априори продуктового стрима Цифрового банкинга быть не должно. Мобильный банк - это важная часть клиентского пути множества продуктов банка - Кредиты, Карты, Страховки и тд. И получается, что нужно строить не отдельный стрим канала, а формировать продуктовые стримы по бизнес-направлениям, и включать тут мобильную разработку как компетенцию в end-to-end команды.

И будете правы. Забегая вперед скажу, что спустя почти год мы именно к такой модели мы и придем. Продуктовые e2e стримы по всем бизнес-направлениям.

Но на данном этапе трансформации, при текущем уровне зрелости команд и компании в целом, при текущим уровне ИТ и бизнес процессов, понимания продуктового подхода и того факта, что в целом в банке нет ни одной end-to-end или хотя бы близкому к этой команде. С уверенностью вам скажу, что формирование Канального стрима - хороший и правильный первый шаг трансформации.

Это и quick win в плане достижения результатов и улучшения текущих процессов разработки здесь и сейчас; и хорошая заявка на подтверждение гипотезы о том что продуктовая модель работает (Proof of Concept если угодно). Ведь не забываем, что мы в самом начале пути и нам еще предстоит завоевать поддержку и одобрение трансформации.

1. Итак, первый редизайн структуры Цифрового банкинга:

Из текущего состояния дизайним 5 небольших продуктовых end-to-end команд, каждая меньше 12 человек, с обозначенной зоной ответственности.

Конечно, настоящего e2e тут еще нет. Во-первых, команды работают по сути "по заказу" продуктовых стримов и получают приоритеты от Бизнес-оунеров соответствующих бизнес линий. Во-вторых, в составе команд еще нет компетенций по backend-разработке. Но об этой теме поговорим дальше в этой статье.

Здесь хочется сделать важную ремарку с ответом на вопрос "А почему меньше 12 чел? Что за ограничение такое странное?". Отвечаем:

Закон Меткалфа:

Правило 2 пицц:

2. Строим операционный ритм стрима

Запускаем ритм по которому живут команды, с одним важным условием - пока что это общий бэклог с едиными приоритетом, которым по сути управляют бизнес-линии, а не стрим Цифрового банкинга.

• Внедряем скоринг бэклога по RICE. Оцениваем влияние каждой задачи а наши 3 стратегически цели банка - Опер.доход, База активных клиентов, NPS.

• Запускаем "суперспринты" (LeSS), в котором планируем сразу все 5 команд.

• Запускаем синхронизации между командами с помощью PO Sync и Scrum of Scrums.

• Запускаем базовые события скрама в каждой команде.

3. Определяем подход к измерению метрик команд.

Из этого фокусируемся только на следующем:

• Lead Time

• Cycle Time

• Dev Time

• Release Frequency

Для того чтобы посчитать метрики команд становится понятно что в текущей организации ведения проектов в Jira это сделать невозможно.

Проводим перенастройку Jira, и уходим от множества проектов по направлениям (напр. Тестирование и заведение багов) к единому проекта стрима. То есть, от базового типа задачи "Протестировать фичу" к задачам типа User Story, включающим в себя все необходимые этапы ее разработки

4. Определяем зоны роста команд по матрице Agile-зрелости.

5. Защищаем и вводим в структуру новый класс сотрудников для банка - Продуктовый аналитик. Цель - покрытие приложения инструментами продуктовой аналитики, формирование линейки метрик, построение и анализ воронок и тд.

6. Результаты этапа:

• Структура и процессы сильно улучшились. Появилась прозрачность в работе и первые попытки прогнозировать сроки разработки (хоть и неточные).

• Lead Time сократился до 120 дней. Что все еще много, но уже хороший прогресс.

• Proof of concept продуктовой модели случился.

5. Шаг второй. Масштабирование

Жизнеспособность продуктовой модели подтвердилась. Теперь можем брать на себя новый вызов и риски по росту и масштабированию разработки на принципиально новый для банка уровень.

Тем более что у нас появляется амбициозная цель от акционера - попасть в ТОП-10 рейтинга мобильных банков Markswebb. А я напомню, что на тот момент времени, банк не попал даже в ТОП-40 этого рейтинга.

По предварительным оценкам, чтобы эту цель выполнить в течении года, нам нужно увеличить объемы разработки в 3 раза!

Что ж, благо дизайн структуры, сделанный на предыдущем этапе предполагает некую модульность и позволяет нам практически линейно и без значительных доп. издержек увеличивать число команд, работающих над мобильным банком. Новые команды можно добавлять в построенную структуру практически как кубики Lego. Они легко встраиваются в уже налаженные процессы.

1. Вырастаем с 5 до 16(!) продуктовых команд в Цифровом банкинге.

Из доп. издержек на масштабирование структуру появляются дополнительные команды поддержки (RUN-команды):

• Release

• DevOps

Результаты этапа:

• Markswebb - 9 место.

• Средний Lead Time < 80 дней.

6. Шаг третий. Переходим в структуру продуктовых стримов

Ок. Упражнение с одним стримом цифрового банкинга мы сделали, но это еще далеко от картины, которые мы хотим получить. Как вы наверное уже себе представили представили, изголодавшиеся бизнес заказчики были не очень рады выстроенной перед ними узким горлышком в виде модели приоритезации бэклога и дело вовсе не в выбранном инструменте (RICE).

- Где наши задачи?

• Когда будет следующий релиз?

• Мы это не согласовывали!

  Знакомые слова? На получение ответов и выяснение причин уходило времени больше чем на создание ценности, а степень неопределённости увеличивалась, напомним, что команд у нас уже 16. Что бы выйти из этой замкнутой цепи мы начинаем передавать/выделять команды для наших заказчиков, упрощая коммуникации и их скорость.

  11 из 16 команд отдаются в прямое управление в стримы. Все еще как независимые команды, но уже живущие в операционных ритмов продуктовых стримов, а не в ритме канального стрима Цифрового банкинга.

  5 команд оставляем в канальном стриме. Их фокусом будут "общебанковские задачи", которые вроде нужны всем (как например Авторизация или навигация в приложении), но ни один из бизнесов не хочет брать за нее ответственность. А также управление релизным процессом и контроль качества.

Хм... всего абзац на процесс передачи команд, который длился несколько месяцев.
Что бы вы не повторяли наших ошибок, вот вам наш итоговый список вопросов, который мы проговаривали в момент передачи команд.
В нем есть:

• Разделение зон ответственности.

• Найм и онбординг.

• Мотивация.

• Развитие.

• Релизный процесс.

• Ответы про инструменты.

• Правила работы.

• Правила Релизов.

• Правила для правил (шутка, но и до этого могло дойти).

Ссылка на Гугл док

Результат этапа:

• В бизнес стримах (дада, скоро мы назовем их продуктовыми) помимо основной бизнес функции появились разработчики. Выделенные, настоящие, которые могут давать результат и мы знаем скорость с которой они это делают. Для реализации задач больше не нужно выбивать ресурсы, контролировать их, заключать сложные договорные отношения. У вас в стримеры Есть квалифицированные люди, которые могут дать результатное тат!

• Средний Lead Time ±60 дней.

• Объем релизов вырос с ~10-12 задач уровня Story до 60-80 аналогичных задач.

Подводные камни этого этапа:

• Не всем разработчикам понравилось находиться ближе к бизнесу. У нас увеличился отток, но мы его ожидали. Кого то переводили в платформенные команды, с кем то приходилось прощаться, но нам нужны были продуктовые разработчики, готовые погружаться в контекст происходящего.

• Бизнес стримы были не не готовы/ не обучены работе с командой.

• Устранение одного узкого места сразу подсветило множество других опасных участков в других местах.

7. Шаг четвертый. Строим полноценные end-to-end команды в стримах

1. Спустя почти год трансформации мы наконец можем прийти к финальной цели трансформации - end-to-end продуктовые команды.

В структуре каждого стрима проводим редизайн и объединяем старые бэкенд команды стрима с новыми фронтенд командами (переданными им из Цифрового банкинга), в одну настоящую e2e команду.

Например, стрим Кредитование:

На выходе, спустя 1.5 года трансформации мы получаем организацию, в которой все ключевые направления развития бизнеса имеют собственные команды и возможности развиваться в рамках цифрового продукта (мобайл), не мешая друг другу. И суммарно количество таких команд в банке исчисляется десятками.

9. Key Takeaways

1. Без поддержки Топ-менеджмента трансформация такого уровня не едет.

2. Communication is never enough. О целях и задачах трансформации придется повторять часто и одно и тоже.

3. Обосновывать изменения легче на цифрах и метриках. С данными сложно спорить.

4. End-to-end команды и продуктовая модель - работают!

5. Это дорого. Бюджет такого мероприятия исчисляется в сотнях миллионов рублей в год.

6. Консультанты из Big-3 дают хороший старт проекта, но не стоит ожидать от них полного внедрения новой модели. Для этого нужна своя команда трансформации внутри организации.

Авторы статьи: Денис Теплов (ex-Head of Transformation, МТС Банк), Михаил Красавин (ex-Agile Coach, МТС).