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

Меня зовут Тимур Исхаков, я технический директор в Ak Bars Digital. Мы отвечаем за развитие ИТ Ак Барс Банка. 

В 2016 году, когда наша компания стартовала, мы сразу «пошли» в цифровизацию и аджайл. Начали со Scrum, которым уже тогда никого было не удивить: кросс-функциональные команды, Product Owners, пользовательские истории — выращивали продуктовую разработку. 

С 2018 года мы стали работать по SAFe: стримы, каналы, бизнес-юниты — вот это вот всё. И как результат — в 2021 году Ак Барс Банк занял 4 место в рейтинге самых инновационных банков России, а мобильное приложение Ак Барс Онлайн 3 года подряд входит в ТОП-3 лучших мобильных банков по версии Markswebb. 

В статье расскажу: зачем и как мы пришли к SAFe, как формировались стримы, о плюсах и минусах вариантов ориентации стримов на структуру бизнес-дирекций, ориентации на ИТ-продукт или на бизнес-продукт. Здесь будет достаточно много терминов, связанных с SAFe — предполагаю, что вы с ними знакомы, хотя небольшие пояснения все же оставлю.

Начнем с Agile

2016 год, Ak Bars Digital начинает свое существование. Мы понимали, что цифровизация и Agile — как раз то, что даст нам преимущество в сокращении Time-to-Market, и позволит гибко и быстро разрабатывать продукты.

Начали работать по Scrum: кросс-функциональные команды, Product Owners, пользовательские истории — всё это постарались воплотить в жизнь. Хотя сотрудников было немного, а команды небольшие, мы с самого начала старались воспитать у себя именно продуктовую разработку. 

Команд тоже было немного. Наши Product Owners синхронизировались между собой с помощью простой Kanban-доски в Miro, которую мы назвали Kanban Аk Bars Digital. 

Это было немного похоже на SAFe в плане аналога PI-планирования для учета зависимостей. Флагманским продуктом, с которым мы организовали разработку в таком подходе, был наш онлайн-банкинг — Ак Барс Онлайн.

Со Scrum всё было классно: частые публичные релизы, быстрый анализ клиентского опыта — продуктовая история во всей красе. Но бэк-офисные и миддл-офисные системы, которых в банке множество, тормозили, потому что они развивалась силами вендоров и интеграторов. 

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

Что же делать?

Переходим на SAFe

В 2018 году мы перешли на Scaled Agile Framework — фреймворк, который позволяет масштабировать Agile-подход на уровне нескольких команд и/или больших подразделений для обеспечения синхронизации и координации их между собой.

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

SAFe это слоеный пирог из различных методик Agile, в нем очень много терминов и понятий, но мы использовали не все. 

Например, мы взяли «поток» — это команда, которая стремится доставить бизнес-ценность. Поток работает по типичному Scrum: спринты по 2 недели, команды по 3-9 человек, продакты, стэндапы, ретроспективы.

Спринты объединяются в Program Increments, которые состоят из нескольких спринтов (обычно их 5, плюс-минус). Program Increments (Инкремент Программы) как раз укладывались в квартальные циклы, в которых банк и так жил. Публичные релизы и доставка ценности для энтерпрайза хотя бы в рамках квартала — это уже очень большая гибкость для крупных компаний.

Так мы запустили первые кросс-функциональные команды более высокого стека — по факту это и были Business Value Streams (Операционные Потоки Поставки Ценности) — последовательности этапов для разработки Решений.

У команд появились Business Owners.

Дальше мы организовали Agile Release Trains (ART) — долгосрочные кросс-функциональные Agile-команды, которые объединены в группу. ARTы работали в рамках того или иного продуктового направления, реализовали квартальный Program Increment с четкими целями на квартал.

Первые наши PI-планирования и Program Board (Доска Программы, на которой отображаются зависимости между командами) давали существенные преимущества в синхронизации целей и совместной работы.

В SAFe есть понятие метрик — согласованные измеряемые параметры. Нужны для оценки эффективности прогресса организации по целям, на уровне команд, ARTов и выше. 

2018 год показал, что в первых стримах мы добились улучшений ключевых метрик. Тогда мы сфокусировались на снижении Time-to-Market, и брали метрику Cycle Time — время от взятия истории в разработку до выпуска в релиз.

Метрика Cycle Time по историям (задачам), связанным с процессингом, CRM, бэк-офисными системами, значительно улучшилась. Как результат — в 2018 году наш мобильный банкинг занял второе место в рейтинге Markswebb и продолжает удерживать его в течение последних лет.

Углубляемся в стримы

И сокращаем T2M: за счет технологической гибкости Agile-команд, слияния и синхронной работы ИТ и бизнеса, роли Business Owners, включения в стримы коллег из поддерживающих подразделений — мы разработали методологию, а коллеги помогли быстро внедрить на банк и клиента.

В 2018 году первые 3 стрима были ориентированы на каналы, где мы взаимодействуем с нашими клиентами. Это был шаг в сторону клиентоцентричности: мы делаем вещи, которые реально дают профит клиенту. Это были:

• «Ak Bars Connect» — система, в которой работают операционисты банка для быстрого обслуживания клиентов.

• «Цифровой банк для людей» — развитие онлайн-банкинга Ак Барс Онлайн.

• «Цифровой банк для бизнеса» — развитие онлайн-банкинга для предпринимателей и организаций.

Выглядело это примерно так:

На картинке видно, что для всех стримов одна CRM. В теории, стримы не должны образовываться вокруг CRM. Но по факту так получилось — у нас в каждом стриме разрабатывалась своя информационная система, потому что мы ориентировались на каналы. Были и системы, которые дорабатывались всеми командами, но это уже другая история.

Какие еще результаты дали эти 3 стрима? 

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

• Целостность IT-продукта, архитектуры и дизайна. Разработка цифрового продукта совпала с тем, что это делается в одном стриме.

• Развитие как функциональности, так и удобства пользования.

• Легкость сопровождения ИТ-продукта.

Кажется, что все классно. Но без проблем тоже не обошлось:

• Организация стримов — это не омниканальный процесс. Одна команда развивает точки касания клиента с банком в отделениях, другая — онлайн-банкинг, а сквозного пути работы с клиентом нет.

• Сложность приоритизации и сопровождения.

• Непрозрачность работ по продуктам банка для бизнеса. Вроде мы развиваем каналы, клиентоориентированность, клиентоцентричность. А что с продуктами?

Организуем стримы в дирекции

Результаты неплохие, давайте теперь всё IT-производство выровняем с бизнес-юнитами и все переведем в SAFe?

Но чтобы это заработало эффективно, нужны люди, лидеры, которым не все равно на направление. Это не просто Product Owners — это должен быть ещё кто-то из бизнеса. 

В SAFe это Business Owners. 

Так мы выровняли стримы по бизнес-юнитам — на дирекции. Дирекции у нас в банке и по каналам, и по продуктам, как часто встречается в классических банках.

После этого у нас получилось 16 стримов по дирекциям. Среди них по каналам: «Омниканальность», «Цифровой банк для людей», «Развитие Контакт-центра», а по продуктам — «Продуктовая фабрика», «Кредитная фабрика».

Работало это так:

Например, в «Цифровом банке для людей» появились Agile Release Trains: 

• один ART — про ДБО Ак Барс Онлайн (канал);

• другой — про платежное ядро Единый платежный центр.

В «Продуктовой фабрике» выделились ART «Кредитование», ART «Карты, эквайринг, платежи», ART «Вклады».

На картинке «Роли в стримах» уже видны ARTы. В каждом ARTе есть Product Owner, и мы дополнительно ввели роль Chief Product Owner (CPO) — он в стриме выше.

Что получили? Много пользы в 2019–2020 годах. Например, появились кросс-продажи, когда предлагаем клиенту новый продукт в каком-то канале — это совместная «работа» и канала, и продукта.

Появились идеи нового стрима, который помог бы клиенту с ипотекой. А это опять же и привлечение, и каналы, и продукт. Это хорошо заметно на дашборде PI-планирования. Разными цветами выделены команды разных стримов и видно пересечение их инициатив.

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

Но минусы тоже есть, куда без них:

• Не всегда у бизнеса оптимальная структура, и она может транслироваться на структуру команд.

• У каждой бизнес-линии свои KPI — команды меньше коммуницируют между командами и бизнес-линиями, каждый бьет по своим KPI: кто-то за продукт, кто-то за каналы. 

• Новые инициативы, например, кросс-продажи или решение по покупке недвижимости, показали, что возникают определенные сложности в целостности бизнес-процесса. Команды работают без ориентира на сквозной процесс.

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

Новая структура стримов

Мы акцентируемся на взаимоотношениях с клиентом. Клиентоцентричность — это уже у всех на слуху, всем понятно, что мы делаем удобные для клиента вещи. Но что это такое? 

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

В рамках этой концепции мы запустили первый Agile Release Train, который называется «Решение по покупке и владению недвижимостью». В рамках процесса по покупке и владению недвижимостью мы будем работать и над привлечением клиентов, и над самим продуктом «Ипотека», и над тем, как в канале его представлять — получается такая сквозная история. 

Но ведь у нас уже есть текущие ART-ы — по кредитованию, по ипотеке, по каналам дистрибуции? В рамках эксперимента мы решили не менять структуру команд, а оставить эти ART-ы в тех же стримах — «Продуктовая фабрика», «Ak Bars Connect» — но некоторые команды из текущих ART-ов включить в новый стрим.

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

• Product Owner;

• Software Engineering Manager — СТО в том или ином ART-е или направлении;

• архитектор, который определен на этот ART;

• RTE — Release Train Engineer;

• Scrum Master. 

Если мы выделяем новый сквозной ART, и туда уходит ряд команд, то в ней должны появиться свои PO, SEM, архитектор, RTE, Scrum Master. Возможно, будет лучше продолжать синхронизировать существующие ART-ы и как-то сэкономить на ресурсах? 

Возможно. Но мы все же решили запустить новый ART, где мы все-таки выделили отдельных РО, SEM и другие роли.

Сейчас в рамках «Решения по покупке и владению недвижимостью» мы запустили ARTы привлечения, активации, сделки, владения самой недвижимостью. Команды, которые там сформировали, занимаются своей частью работы: личным кабинетом, фронт-офисом, принятием решений, партнерскими решениями, сопровождением и ипотечным продуктом.

Что мы получили?

Пока что мы пилотируем этот подход, но уже видим большое преимущество в скорости разработки. Однозначно, меньше зависимостей, лучше управляются приоритеты, и сам бэклог более управляем. И главное: сквозные процессы, сквозной Customer Journey Map (CJM), решаются в одном ART-е, в одном стриме. 

Не считая того, что это ресурсоемкий вариант, в таком подходе могут возникнуть:

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

• Сложности с релизными циклами, потому что информационных систем много, особенно в ландшафте банка. Но с этим тоже можно справляться, и мы за 5 лет научились это делать.

Самое важное: если мы хотим двигаться именно по CJM клиента, по таким стримам исходя из ценности, то крайне важна перестройка оргструктуры, в том числе самого бизнеса. Как минимум, на старте нужно создавать Discovery-команды, в которые войдут лица из бизнеса, принимающие решения. Тогда начнут появляться ценностные CJM, и вокруг них мы сможем создавать новые команды.

Метрика Cycle Time не изменилась, потому что технологическая гибкость и скорость у нас выстроена и уже была оптимизирована. Поэтому на этом этапе мы используем метрику — Lead Time. Это время от Ideation до момента, как все действительно запустилось для клиента — от идеи до релиза.

Lead Time также можно рассматривать с 2-х сторон:

• Этап Ideation — как быстро идеи сгенерировались и согласовались в Product Management Team, и дальше ушли в бэклог на реализацию. Уже первые фичи, которые мы запустили, показывают, что раньше время от идеи до релиза составляло около 6 месяцев, а сейчас это занимает два месяца. 

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

Вот такие результаты. Возможно, вам будет полезен наш опыт.