Все статьи
Эксперимент с красивой нарезкой оргструктуры
Дата: 22.08.2022
Опыт Ак Барс Цифровые Технологии (Ак Барс Банк) в формировании стримов, плюсы и минусы вариантов ориентации стримов на структуру бизнес-дирекций, ориентации на ИТ-продукт или на бизнес-продукт.
Доклад на конференции Enterprise Agile Russia 29 ноября 2021 года.
Меня зовут Александр Киверин, я работаю техническим директором в компании «Ак Барс Цифровые Технологии». Это подразделение, которое отвечает за развитие IT «Ак Барс Банка». Почему я сегодня могу говорить о SAFe: я являюсь Certified SAFe® Agilist (прим. ред. — сертифицированный практик фреймворка Scaled Agile Framework®), и у меня есть достаточно большой управленческий опыт в разных секторах — от финтеха до медицины, в которых удалось создать разные комплексные продукты.
«Ак Барс Банк», несомненно, благодаря «Ак Барс Цифровые Технологии» в 2021 году занял четвертое место в рейтинге самых инновационных банков России, а ещё мы три года подряд входим в топ-3 лучших мобильных банков по версии Markswebb.
Всё началось в 2016 году, когда была основана компания. Уже тогда было понятно, что надо двигаться по Agile, потому что это как раз то, что даёт нам преимущества в сокращении Time-to-Market (прим. ред. — время поставки на рынок) . В цифровизацию банк пошел именно для того, чтобы сократить этот пресловутый Time-to-Market и гибко, быстро разрабатывать продукты. Мы уже тогда начали работать по фреймворку Scrum, так как уже тогда им никого было не удивить. Кросс-функциональные команды, Product Owners, пользовательские истории — всё это мы постарались воплотить в жизнь. Сотрудников было немного, команды маленькие, но отдельно я бы заострил внимание на том, что мы с самого начала старались воспитать у себя именно продуктовую разработку. Команд было немного и наши Product Owners синхронизировались между собой с помощью Miro на Kanban-доске, назвали ее Kanban АБЦТ (прим. ред. — Ак Барс Цифровые Технологии). Это было немного похоже на SAFe в плане аналога PI-планирования для учета зависимостей.
Флагманским продуктом, с которым мы организовали разработку в таком подходе, был наш онлайн-банкинг, Ak Bars Online. Со Scrum всё было классно: частые публичные релизы, быстрый анализ клиентского опыта — продуктовая история во всей красе. Но бэк-офисные и миддл-офисные системы, которых в банке множество, тормозили, потому что они развивалась силами вендоров и интеграторов. Тогда в следующем 2017 году мы решили, что с процессами по Scrum всё понятно, но настоящую гибкость на самом деле даёт не только фреймворк Scrum, но и технологическая гибкость компании. Это один из моих поинтов сегодняшней презентации — обращайте внимание и на это — если хотите гибко и быстро развиваться, то практики DevOps и платформы тоже нужно внедрять своевременно.
Время шло и продуктов становилось всё больше: помимо Ak Bars Online у нас появились другие очень крупные цифровые решения, направленные на клиента. Соответственно, в фокусе были максимальная эффективность и быстрая доставка, но всё оставалось по-прежнему: бэк-офисные и мидл-офисные системы тормозили нас ещё сильнее, потому что фронт-офисных систем мы разрабатывали всё больше.
Также мы начали замечать, что задержки возникают при взаимодействии с разными корпоративными блоками, бизнес-блоками банка. Тогда в 2018 году мы с высоты нашего опыта — прежде я уже работал с этим фреймворком — посмотрели на Scaled Agile Framework и решили: это то, что нам нужно. Но мы решили не использовать термины именно фреймворка и внедрять его не только на уровне нашего подразделения «Ак Барс Цифровые Технологии», а на уровне всего банка.
Мы использовали такие термины, как «поток» — команда, которая стремится доставить бизнес-ценность, те же Program Increments (прим. ред. — Инкремент Программы) по факту как раз укладывались в квартальные циклы, в которых банк итак жил, и мы понимали, что публичные релизы и доставка ценности для энтерпрайза хотя бы в рамках квартала — это уже очень большая гибкость для крупных компаний.
Так мы запустили первые кросс-функциональные команды более высокого стека — по факту это и были Business Value Streams (прим. ред. — Операционные Потоки Поставки Ценности), у которых появились Business Owners (прим. ред. — Представители Бизнеса). Тогда ещё про Agile Release Trains (ART) явным образом не говорили, но «потоки» включали в себя несколько кросс-функциональных Agile-команд, которые работали в рамках того или иного продуктового направления, реализуя квартальный Program Increment с четкими целями на квартал. Первые наши PI-планирования и Program Board (прим. ред — Доска Программы, на которой отображаются зависимости между командами) давали существенные преимущества в синхронизации целей и совместной работы.
2018 год показал, что в первых стримах мы добились улучшений ключевых метрик. Тогда мы фокусировались на снижении Time-to-Market, брали метрику Cycle Time — это время от взятия истории в разработку до выпуска в релиз. Метрика Cycle Time по историям (задачам), связанным с процессингом, CRM, бэк-офисными системами, значительно улучшилась. Как результат — в 2018 году наш мобильный банкинг занял второе место в рейтинге Markswebb и продолжает удерживать его в течение последних лет.
SAFe, на мой взгляд, — это про тот же Time-to-Market, но достигается сокращение T2M уже не только за счет технологической гибкости Agile-команд, а за счет слияния и синхронной работы ИТ и бизнеса, роли Business Owners, включения в стримы коллег из поддерживающих подразделений — про быстрое внедрение того, что мы разработали, непосредственно в методологию банка и на клиента. В 2018 году первые три стрима были ориентированы на каналы, где мы взаимодействуем с нашими клиентами. Это был шаг в сторону клиентоцентричности: мы делаем вещи, которые реально дают профит клиенту. Это были:
- «Ak Bars Connect» — развитие фронта, где работают операционисты банка для быстрого обслуживания клиентов;
- «Цифровой банк для людей» — развитие нашего онлайн-банкинга Ak Bars Online;
- «Цифровой банк для бизнеса» — развитие онлайн-банкинга для предпринимателей и организаций.
Также по факту в каждом из стримов разрабатывалась та или иная информационная система. В теории стримы не должны образовываться вокруг информационной системы, но на практике у нас так и получилось, несмотря на то, что мы ориентировались на каналы. Были и системы, которые дорабатывались всеми командами, но это уже другая история, о которой я рассказывал на Enterprise Agile Russia 2020 (прим. ред. — конференция предыдущего года).
Какие ещё результаты дали эти три стрима? Очень большую вовлеченность бизнеса, потому что по факту мы согласовались с определенными дирекциями, которые отвечали за эти направления. Мы сразу получили профит по коммуникации с бизнесом. Как я отметил, у нас совпала разработка цифрового продукта с тем, что это делается в одном стриме. Тут мы получили еще и профит в виде целостности IT-продукта, целостности архитектуры и дизайна. Кажется, что все классно. Но какие проблемы в такой нарезке или в такой организации стримов? По факту это не омниканальный процесс. Одна команда развивает точки касания клиента с банком в отделениях, другая — онлайн-банкинг. Нет сквозного пути работы с клиентом.
Следующее — сложность приоритизации и непрозрачность для бизнеса работ по продуктам банка. То есть мы развиваем каналы, клиентоориентированность, клиентоцентричность. А что с продуктами? Тогда мы решили, всё IT-производство выровнять с бизнес-юнитами и всё перевести в SAFe. Так и сделали. Но для того, чтобы это заработало эффективно, нужны люди, лидеры, которым не все равно на направление, и это не просто Product Owners — это должен быть ещё кто-то из бизнеса. В SAFe это Business Owners. Таким образом, мы выровняли стримы по бизнес-юнитам, на дирекции. Дирекции у нас в банке и по каналам, и по продуктам, как часто встречается в классических банках.
Соответственно, вот такие стримы у нас получились — по каналам: «Омниканальность», «Цифровой банк для людей», «Развитие Контакт-центра» и другие, и по продуктам: «Продуктовая фабрика», «Кредитная фабрика» и другие.
В целом, тоже классная структура. В «Цифровом банке для людей» уже появились Agile Release Trains: один ART — про ДБО Ak Bars Online, другой — про платежное ядро Единый платежный центр. В «Продуктовой фабрике» выделились ART «Кредитование», ART «Карты, эквайринг, платежи», ART «Вклады».
За 2019–2020 гг. мы получили очень классный профит. Здесь произошел перенос большой ответственности на сторону бизнеса. Некоторые компании боятся этого, потому что бизнес может диктовать немного не то, что лучше знает IT (та же архитектура). Но с большей вовлеченностью бизнеса проще управлять бэклогом, бюджетом и ресурсами.
Когда мы режем отдельно по каналам и по продуктам, есть и минусы. Не факт, что бизнес сейчас живет в оптимальной структуре, и как раз такая структура бизнеса может транслироваться на структуру команд. Так как у каждой бизнес-линии свои KPI, команды меньше коммуницируют, каждый бьет по своим KPI: кто-то за продукт, кто-то за каналы. Новые инициативы, которые у нас начали рождаться, например, кросс-продажи (это когда мы предлагаем нашему текущему клиенту новый продукт, но в каком-то канале — то есть по факту затрагивает и каналы, и продукты) или решение по покупке недвижимости (где предполагается работа и по привлечению, и развитие каналов дистрибуции, и сам ипотечный продукт), показали, что возникают определенные сложности в целостности бизнес-процесса. Команды работают без ориентира на сквозной процесс, поэтому и нет бизнес-метрик, которые измеряют именно процесс клиентского пути — измеряют продажу продукта и посещаемость канала. Такие сквозные инициативы показали нам, что нужно что-то менять.
Так совпало (и мы к этому пришли эволюционно), что банк сейчас вступает в новый стратегический цикл, где мы работаем с консультантами, которые смещают фокус на взаимоотношения с клиентами. Клиентоцентричность — это уже у всех на слуху, всем понятно, что мы делаем удобные для клиента вещи. Сейчас мы делаем акцент именно на взаимоотношениях с клиентом. Что это такое? Это решения конкретных проблем клиента, улучшение качества его жизни и реализация его целей и желаний, а также долгосрочное удержание клиента в банке. Мы запустили первый Agile Release Train, который называется «Решение по покупке и владению недвижимостью». Здесь мы увидели, что в рамках процесса по покупке и владению недвижимостью мы будем работать и над привлечением клиентов, и над самим продуктом «Ипотека», и над тем, как в канале его представлять — получается такая сквозная история. Но у нас же уже есть текущие ART-ы — по кредитованию, по ипотеке, по каналам дистрибуции. В качестве эксперимента мы решили не менять полноценно заново структуру команд, а оставить эти ART-ы в тех стримах, которые были, — «Продуктовая фабрика», «Ak Bars Connect» — но некоторые команды из текущих ART-ов включить в новый стрим.
Подумали: классно, но что тогда делать с ключевыми ролями, которые управляют этими поездами? Надо понимать, что у нас есть Product Owner, Software Engineering Manager (SEM — это СТО в том или ином ART-е или направлении), архитектор, который определен на этот ART, RTE (Release Train Engineer) и Scrum-мастеры. Если мы выделяем новый сквозной ART, и туда уходит ряд команд, то в ней должны появиться свои PO, SEM, архитектор, RTE, Scrum-мастер. То есть, может быть, лучше продолжать синхронизировать существующие ART-ы и как-то сэкономить на ресурсах? Но решили запустить все равно такой новый ART. Сейчас в рамках «Решения по покупке и владению недвижимостью», где мы все-таки выделили отдельных РО, SEM и другие роли, запустили поезд, который и про привлечение, и про активацию, и про сделку, и владение самой недвижимостью. Команды, которые там сформировали, — про личный кабинет, фронт-офис, принятие решения, партнерские решения, сопровождение и про сам ипотечный продукт.
Что мы получили? Пока что мы пилотируем такой подход, но уже видим большое преимущество в скорости разработки. Однозначно, меньше зависимостей, лучше управляются приоритеты, и сам бэклог более управляем. И главное: эти сквозные процессы, сквозной Customer Journey Map (CJM), как раз решаются в одном ART, в одном стриме. Надо понимать, что все-таки это ресурсоемкий вариант, но оно того стоит, на наш взгляд.
В таком подходе может возникнуть сложность с целостностью IT-продуктов, IT-систем, но выше я отметил, что ориентироваться на IT-системы — неправильно, там возникает множество других проблем. Помочь в этом вопросе нам могут единые инженерные практики, общие подходы к работе во всех направлениях, контроль архитектурной целостности на уровне компании.
Есть сложность с релизными циклами, потому что информационных систем много, особенно в ландшафте банка, но с этим тоже можно справляться, и мы за пять лет научились это делать. Самое важное: если мы хотим двигаться именно по CJM клиента, по таким стримам исходя из ценности, то здесь крайне важна перестройка оргструктуры, в том числе самого бизнеса. Как минимум нужно создавать на старте Discovery-команды, в которые войдут лица, принимающие решения из бизнеса, — тогда начнут появляться ценностные CJM, и вокруг них мы сможем создавать новые команды.
Важной метрикой является Lead Time. Метрика Cycle Time в принципе не изменилась, потому что технологическая гибкость и скорость у нас выстроена и оптимизирована была ранее.
Lead Time — это время от Ideation до момента, как все действительно запустилось для клиента — от идеи до релиза. Важен также сам этап Ideation — как быстро идеи сгенерировались и согласовались в Product Management Team, и дальше ушли в бэклог на реализацию. Уже первые фичи, которые мы запустили, показывают, что раньше время от идеи до релиза составляло около шести месяцев, а сейчас это занимает два месяца. От идеи до бэклога — еще более колоссальные результаты. Раньше процесс занимал неделю в лучшем случае — нужно было ждать согласования разных коллег из продаж, продуктологов, методологов и др., а сейчас, так как они работают в одном стриме, все решается за день.
Видео и слайды
