Мидзингири, Сайномэгири, Кацура-муки и просто муки выбора новой модели формирования потоков ценности.
Меня зовут Тимур Исхаков, я технический директор в 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 месяцев, а сейчас это занимает два месяца.
Этап от идеи до бэклога. Здесь результаты еще круче. Раньше процесс занимал неделю, в лучшем случае: нужно было ждать согласования разных коллег из продаж, продуктологов, методологов. Сейчас, так как они работают в одном стриме, все решается за день.
Вот такие результаты. Возможно, вам будет полезен наш опыт.
