Все статьи
Повышаем прозрачность и эффективность — новый бизнес-ритм в Сбер Банке Беларуси
Дата: 20.02.2023
История Сбер Банка Беларуси — одного из крупнейших банков Беларуси с 2 тысячами сотрудников.
Доклад с конференции Enterprise Agile Russia 2022.
В белорусском Сбербанке я вместе с командой занимаюсь трансформацией процессного, проектного и продуктового подходов. Я поделюсь нашим опытом внедрения нового бизнес-ритма, который позволил повысить прозрачность и эффективность работы нашего IT-периметра.
Пару слов о нас: мы являемся дочерним банком Сбера в Беларуси. Мы действительно схожи: культурой, продуктами, технологиями и даже красивыми современными офисами, но глобально мы разные как по размеру, так и по используемым гибким практикам.
Наш банк — это 2000 сотрудников, и мы являемся одним из крупнейших банков в Беларуси. По различным рейтингам мы занимаем либо первые строчки, либо входим в топ. Мы задаем определенные тенденции на рынке банкинга, в том числе в теме развития Agile.
Несколько фактов про наш Agile-периметр. Во-первых, фактически все наше IT-производство работает в Agile. Мы используем IT-ресурсы по принципу аутстаффинга дочерней компании. Это 22 Agile-команды, в которых 150+ человек разработки по всем нашим продуктам и решениям. При таком размере мы в IT-банкинге финансируем больше всех на рынке.
Наш кейс полезен тем, кто находится на старте либо в процессе масштабирования Agile и думает или экспериментирует с темой целеполагания и эффективности.
Содержание статьи
Появление Agile в нашем банке
Серьезно об Agile заговорили в нашем банке в декабре 2018 года, когда приняли решение о полном переходе в Agile с 1 января 2019 года. Мы в это не верили, но исторически и документально так и произошло. В реальности весь 2019 год мы передавали проекты в команды, дизайнили их состав, настраивали базовый процесс, распределяли функции и роли.
В 2020 году осознания и опыта у нас стало гораздо больше. В большинстве команд прижился скрамоподобный фреймворк. И когда работа каждой команды у нас в целом настроилась, мы задумались о теме масштабирования. Главный фокус при масштабировании у нас был на синхронизацию работы команд. На этом этапе нам помогли некоторые подходы в SAFe® (прим. ред. Scaled Agile Framework®).
Изначальный контекст внедрения практик масштабирования
Наши команды работали в условиях формализма: ежеквартально выносили планы, затем отчеты их выполнения на комитет. При этом общая картина мира по работе change-периметра у нас в компании не складывалась, так как синхронизация этих планов на уровне фичей и продуктов не осуществлялась. Часто возникала критика, в первую очередь от топов: «А что делает это ваше дорогое большое IT?»
Никакие зависимости не выявлялись и не согласовывались. Это приводило к постоянным переносам дорожных карт. Естественно, это происходило через комитет, туда же с обоснованием нужно было идти, если терялась актуальность либо менялись приоритеты.
Какой-либо системной работы с рисками или проблемами на уровне всего IT-производства мы не проводили. На уровне команды проблемы выявлялись, настраивались, но системно такой работы не было.
Понимание всех этих проблем у нас внутри было, но для каких-то глобальных изменений нам не хватало, во-первых, сильной внутренней экспертизы — что и как делать, а с другой стороны, нужен был волшебный толчок сверху, чтобы топы эти изменения приняли и двигали ими сверху.
Выявление проблем и поиск решений
Мы поступили мудро и одновременно очень просто: в начале прошлого года мы пригласили в компанию внешнего провайдера для проведения диагностики зрелости нашей компании. Это был ScrumTrek. Мы вместе, топ-менеджмент, лидеры команд, продуктов, лидеры экспертиз, в формате нескольких сессий провели оценку гибкости нашей компании по ряду доменов.
По итогам общей оценки самыми западающими зонами у нас оказались процессы и структура. И те проблемы, о которых я упомянула, теперь явно сформулировались и поднялись на поверхность.
В качестве возможного решения провайдер предложил нам посмотреть в сторону SAFe®. А так как это происходило в момент бурного обсуждения на сессии: и проблемы, и решения вместе с топами, то предложение автоматом трансформировалось для нас в решение внедрять. Мы начали дизайн нового производственного процесса внутри банка — PI-цикла (прим. ред. Program Increment).
Здесь нам помогал внешний провайдер. Мы вместе отдизайнили все события, определили роли и провели серию воркшопов для всех участников и для ролей по их функциям, настроили все пространства и доски. Параллельно до запуска нового цикла мы отменили все прежние понятия: дорожные карты, комитеты, связь выполнения вех с мотивацией. Мы продавали историю: давайте дадим свободу командам, но с аккуратным нашим наблюдением, если вдруг что пойдет не так, мы откатим все назад. И так как это решение было уже одобрено наверху, нас услышали и дали добро на реализацию.
Так мы ушли в пилотирования этого подхода. На всю подготовку и на дизайн у нас ушло где-то 1,5-2 месяца. Со 2 квартала прошлого года мы начали работать по новым подходам, сразу на всем периметре наших команд.
Фасилитацию первых 3 циклов весь прошлый год у нас осуществлял провайдер. Внешний эксперт снимал все вопросы, комментарии, критику наших команд и помогал нам. С этого года полную подготовку, фасилитацию и последующее сопровождение забрал на себя офис трансформации банка.
Новый производственный процесс
Новый процесс состоит из трех последовательных этапов:
- Каждый квартал мы начинаем с события планирования, на котором каждая команда презентует свои приоритетные цели, затем честно формируются планы с учетом емкости, выявляются и согласовываются зависимости с построением в конце общей синхронизированной доски инициатив на предстоящий квартал. Также обязательно обсуждаются риски по полюбившейся нам модели ROAM (прим. ред. Resolved, Owned, Accepted, Mitigated).
- Далее каждые 2 недели проходит регулярный PO Sync, на котором продакты снимают статусы реализации фич, синхронизируют зависимости, риски. И при важных отклонениях или нарушениях информируют заинтересованных лиц.
- Завершающим этапом является событие Inspect & Adapt, где по итогам каждого квартала в нашем дизайне мы проводим ревью плановых и внеплановых фич, демонстрацию нового функционала и завершаем определением, выявлением и решением проблем. Темы ценностей у нас в нашем дизайне сегодня нет. Почему — об этом далее.
Во всех этих событиях, кроме PO Sync, у нас участвуют все команды разработки, борд, заказчики, продакты, необходимые эксперты типа юристов, безов и так далее. И с момента внедрения PI-цикла, в течении уже почти 2 лет, мы все эти события проводим в онлайне с использованием Zoom, Miro, Confluence.
Что мы добавили
- Подготовка к событиям PI-цикла.
Конечно, в процессе движения по этому циклу мы вносили определенные изменения. Подготовка к PI не является нашим новшеством — это классика, нас этому научил ScrumTrek. Но в чем особенность? Мы этот этап в нашем дизайне выделили не сразу. Было слишком много изменений, она не заходила. Мы пришли к этому позже, когда команды стали сами выделять время и последние итерации на подготовку, а нас, офис трансформации, просить подготовить необходимые доски.
- Вовлечение заказчиков в Change-деятельность.
Акцентировали внимание на работу с нашим заказчиком, то есть мы настаиваем на том, что в событиях важно участвовать — и в планировании, и в инспекции. Про планирование говорим, что, кто не успел, тот опоздал со своей историей или фичей. И детально работаем с системой требований — в части своевременности и поступления до PI, и глубины проработки для качества планирования.
- Включение новых ролей в процесс планирования.
Также мы в процессе планирования включили ряд новых ролей со своими отдельными досками, где теперь выстраиваются все зависимости с командами. Я говорю про безопасность, юристов, сопровождение и, из нового, — наша CX-лаборатория (прим. ред. Customer eXperience), которая также синхронизирует все исследовательские механизмы.
- Регулярные встречи с Board.
По итогам каждого цикла мы организуем отдельную встречу с нашим бордом, где проводим оценку итогов планирования, инспекции, в том числе на языке цифр производства, подсвечиваем все системные риски, проблемы, обсуждаем их.
Что нам это дало
Свобода команд в планировании дала нам амбициозные планы. Планы у нас не остались планами, а с небольшим отклонением все они реализовываются по последним данным. При этом фокус на выполнение в срок у наших команд не только сохранился, но даже усилился.
Нам кажется, что это все стало благодаря процессу выявления и управления зависимостями. На первом срезе в прошлом году это были 56% зависимых фич между собой и по количеству, и по ресурсам. Сейчас это 30%, но это остается одной из существенных проблем нашего масштабирования.
Мы обеспечили обещанную гибкость в планах, любое изменение не требует выход на комитет. На инспекции команда может просто сообщить, что поменяла свои цели и задачи.
Мы системно выстроили работу с рисками и проблемами. Мы очень много изменений проводим от контуров до требований.
Также мы обеспечили открытость коммуникации, где любой желающий в компании может подключиться к событиям, послушать команду и задать любой вопрос по интересующей его фиче.
Это нам дало рост вовлеченности всех уровней, и теперь вопросов от топ-менеджмента, других участников, чем занимается наше большое дорогое IT — не возникает от слова совсем.
Новые точки роста
Казалось бы, все прекрасно и работаем слаженно, прозрачно. Но в конце прошлого года, когда данный цикл стал уже восприниматься как база, все чаще в первую очередь у топов начал возникать вопрос: а для чего мы это делаем и что нам это все приносит?
Для общего понимания: у нас вся эта работа была без единой цифры с точки зрения бизнеса. Ни KPI, ни метрик у команд не было, бюджеты раздавались, работу работали, а все остальное было за кадром. Такая предпосылка была.
Так в конце прошлого года появляется задача по внедрению метрического целеполагания в Agile. И в решении этой задачи мы стали использовать некоторые подходы OKR (прим. ред. Objectives and Key Results). Когда в конце прошлого года мы взяли эту задачу в работу, мы начали с изучения опыта различных компаний, Сбера в том числе. В ходе целой сессии обсуждений внутри сформулировали концепцию, детально обсудили с внутренним периметром, как мы будем работать на языке цифр, а затем вынесли на правление банка для принятия. Приняли и начали работать.
Начинаем говорить о ценности мы в рамках бюджетной кампании, где по итогам защиты бюджета каждая команда уходит с так называемым годовым коммитментом. На год фиксируется EBITDA (прим. ред. Earnings Before Interest, Taxes, Depreciation and Amortization) и метрики-драйверы, которые позволят ее достичь. Если команда финрез не генерит, она уходит только с метриками-драйверами конечной ценности. Поквартально они не разбиваются на цифры — это годовое обязательство.
Далее ежеквартально каждая команда, глядя на свое годовое обязательство и исходя из своих текущих приоритетов и вызовов, определяет квартальные цели, Q-цель и K-result: то, чего мы хотим достичь и как мы это будем мерить по итогам квартала.
И наконец по итогам каждого квартала мы мониторим динамику как коммитмента, так и статус Q-цели и K-results. Это происходит на BVD, о которому расскажу далее.
Эти подходы мы приняли в начале года и со 2 квартала начали пилотировать опять на всем периметре.
Business Value Day
Со второго квартала в нашем календаре agile-событий появился Business Value Day (BVD). Это событие мы проводим по итогам каждого квартала, и оно посвящено ценности, результативности и эффективности деятельности наших IT-команд.
На этом событии у нас в основном присутствует бизнес.
Участвуют наши инвесторы, топы, лидеры команд и продуктов, заказчики, офис трансформации, в том числе мы его фасилитируем. Мы проводим в текущем формате 2 дня очно, никакого онлайна. Первый день бизнес-команды полдня, второй день те же полдня — сервисные, инфраструктурные. Выступает каждая команда коротко 5-7 минут, дискуссионная сессия — минут 10.
Что говорят команды? Буквально два фокуса в их выступления, четыре пейджера четкие по формату, которые выдаем мы. Сначала показывают результаты квартала только в цифрах, никакой инспекции. Команды показывают на цифрах по итогам квартала, сколько потратили, глобально на какие типы инициатив деньги ушли: бизнес, не бизнес, legal, техдолг и так далее. Оценивают квартальные цели прошедшего квартала: Q-цель и K-result и показывают статус коммитмента, которым посчитали финансы. Завершается целеполаганием в цифрах на следующий квартал.
В ходе этого мероприятия обсуждается и принимается ряд решений, уточняются метрики, формулируются задачи по актуализации коммитмента. Как правило, у команд усиливается ресурс. К сожалению, кардинальных решений об остановке каких-то продуктов, переброса ресурсов пока нет. Это зона нашего развития. Хотя эти три диалога, которые были в этом году, открыли много классных инсайтов, в том в том числе, что где-то крутятся бантики, которые можно резать при бюджетировании.
Что мы получаем
По итогам бюджетирования теперь все 100% команд у нас выходят с коммитментом, чего раньше не было. И при итерациях рассмотрения внутри, мы видим, что количество команд, которые берут на себя финансовую EBITDA, растет. В 2021 году было 60% команд. Сейчас в 2022 году на новой бюджетной компании цифра стремится к 80%.
На планировании все 100% команд без исключения начинают планирование от целей и метрик, а затем под это планируют бэклог, а не от обратного, как раньше — под задачи натягивали цели.
И наконец у нас появилась система мониторинга результатов команд — это наш BVD. Раньше метрик не было, и мониторить нечего было. Сейчас сквозь призму трех показателей: EBITDA, Run Rate, покрытия бюджета идет этот диалог и принимаются решения.
Куда мы растем
В случае с первой темой масштабирования нам практически все понятно, кроме проблемы зависимостей, а с системой целеполагания мы даже спустя год фиксируем большое количество точек роста на разных уровнях.
На уровне команд:
- Нам нужно продолжить прокачивать умение формировать метрики от ценности, а не от действия, а также растить наших заказчиков не передавать в производство ни одной задачи без цели и метрики.
- Мы хотим научиться управлять метриками продукта, понимать их, считать и выстраивать все взаимосвязи между всеми продуктами и командами. И, конечно же, научиться делать более частый замер этих метрик в периоде. Не раз в квартал, а на более коротких отрезках времени.
На уровне компании:
- Мы начали эксперимент с подходом: «Деньги в долг. Это когда инвестиции выдаются как кредит под проценты, и при его возврате команда может рассчитывать на дополнительный фонд развития в свой бюджет или же на мотивацию.
- Мы понимаем, что нам нужно научиться принимать кардинальные управленческие решения, если команда из квартала в квартал на BVD демонстрирует невыполнение и низкие Run Rate.
- Нам нужно научиться связывать цели и метрики команд со стратегическим уровнем, так как стратегия и цели топов пока в разрыве.
Наше будущее
Сейчас мы работаем в новом бизнес-ритме, получаем определенные преимущества, удовольствие от положительных изменений, работаем над новыми точками роста. Мы как офис трансформации чувствуем, что в компании происходят глобальные изменения, которые поддерживаются всеми участниками, от топов до команд.
Видео и слайды
