«Хотим релизить даже в час пик без рисков». Как в ИТ-блоке Bereke Bank строят новую инженерную культуру

За каждым релизом Bereke Bank стоит работа десятков ИТ-специалистов. Чтобы их усилия складывались в единую систему, Software Engineering Manager банка Павел Лукьянов развивает инженерную культуру и помогает командам расти. Здесь важны не только технические навыки, но и способность принимать решения на основе данных. Именно поэтому в банке появился чек-лист для оценки зрелости и визуальный «радар», который показывает картину процессов целиком. Такой инструмент помогает руководителям управлять развитием без бюрократии и лишнего контроля.

Как внедряли эти практики и какой результат они дали, Павел Лукьянов рассказал в интервью Digital Business.

«Есть соблазн работать по принципу "где горит, там и тушим"»

— Как бы вы описали свою работу?

— С лета 2023 года работаю Software Engineering Manager в направлении daily banking — это все некредитные операции для физических лиц: переводы, платежи, инвестиции, депозиты, подключение новых клиентов. По сути, все то, чем все мы пользуемся каждый день через мобильное приложение.

В управлении находится 42 человека, 7 команд: одна узкоспециализированная, остальные продуктовые. Моя ключевая задача – развитие инженерной культуры и зрелости. Проще говоря, отвечаю за то, чтобы разные специалисты – разработчики, QA, системные аналитики, DevOps-инженеры – работали как единое целое. Чтобы их совместная работа действительно помогала достигать бизнес-целей, а не превращалась в формальные «галочки».

Кроме инженерной зрелости, есть еще 2 направления.

• Первое – people management: найм, онбординг, поддержка новых сотрудников, их карьерное развитие и, в некоторых случаях, увольнение.
• Второе – архитектурные и бизнесовые задачи. Когда у бизнеса есть идея, нужно помочь правильно ее разложить, выбрать архитектурное решение, встроить в нашу экосистему.

— Что вы вкладываете в понятия «инженерная культура» и «инженерная зрелость»?

— Регламент и инструкции важны, особенно в банке, но охватить ими все процессы невозможно. ​​Инженерная культура – это то, как мы принимаем решения, работаем с ошибками, делимся знаниями и заботимся о качестве. Она задает общий стиль работы команды, когда строгих правил нет. А инженерная зрелость – это уже то, что можно оцифровать.

В Bereke Bank создали специальный чек-лист: примерно 150–170 вопросов, которые касаются разных аспектов работы моих подопечных. Ответы оцениваются. Отдельные баллы команда получает, если решения принимаются на основе метрик, а не интуиции. Потом собираем так называемый «радар зрелости» – визуализацию, которая демонстрирует, в чем команда сильна, а где нужно приложить усилия. Чем ровнее и шире круг, тем ближе команда к идеалу.

— Зачем это нужно? 

— Когда у тебя десятки команд и ограниченные ресурсы, есть соблазн работать по принципу «где горит, там и тушим». В итоге гасишь пожар, но не меняешь систему. «Радар» же позволяет быстро понять, в чем системная проблема, и у кого из коллег можно «подсмотреть» решение. По сути, это инструмент аудита, который Центр компетенций проводит примерно раз в квартал. Мы с коллегами самостоятельно разработали этот подход.

«Хотим релизить даже в час пик без риска что-то сломать»

— Что подтолкнуло вас по-новому взглянуть на рутинные процессы?

— Когда присоединился к команде Bereke Bank, в компании начинался новый этап развития, активно менялись процессы и подходы. В банке внедрили холакратию (система, при которой решения не спускаются «сверху вниз», а принимаются командами – здесь и далее прим. Digital Business) и SAFe (Scaled Agile Framework). Все это помогло избавиться от лишней бюрократии и усложненных процессов без потери качества и не в ущерб безопасности.

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

— К каким показателям вы стремитесь?

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

• Во-первых, фич-тоглы (feature toggling): возможность включать и выключать отдельные функции прямо в продакшене, без релиза новой версии приложения.
• Во-вторых, «скрытый прод» – версию приложения, которая доступна только сотрудникам банка. Благодаря этому можно найти ошибки, прежде чем запускать обновление для клиентов.
• В-третьих, «канареечные» релизы: предлагаем новую функцию небольшому проценту пользователей и смотрим на метрики. Если все стабильно, расширяем охват.

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

Helicopter View: почему руководителю полезно витать в облаках

— Какие практики используете для оптимизации процессов?

— Во многом помог так называемый helicopter view. Это умение отойти и посмотреть на ситуацию сверху. Есть любимая аналогия: один и тот же предмет с разных точек выглядит по-разному. Но только если отдалиться, он становится виден целиком. С процессами то же самое. Когда «закапываешься» в детали, видишь только свой фронт работы. Но, если подняться выше, становятся заметны недочеты. Наш чек-лист и «радар зрелости» – хороший пример применения этой практики.

— Есть ли у этого метода недостатки? 

— Всего один: опасно все время «витать в облаках» и не спускаться на землю. Можно не заметить проблему. Поэтому в Bereke Bank регулярно проводим гембы. Это практика из системы, принятой в Toyota – руководители, включая  топ-менеджмент, погружаются на уровень исполнителей, чтобы понять, как все работает изнутри.

По личному мнению, еще помогает регулярная ретроспектива: открыть календарь и честно оценить, на что тратится время – на рутину или на изменения? Если календарь начинает «управлять тобой», а не ты календарем, это сигнал, что пора перестроить процессы.

— Что порекомендуете middle-менеджеру, который хочет внедрить helicopter view?

— Два простых совета. Первый – воспитывать в себе любознательность и насмотренность. Полезно ходить к коллегам, чтобы посмотреть, над чем они работают – вдруг решение ваших проблем рядом, и не надо изобретать велосипед?

Пример из практики: нужно было поддержать контрактный подход к изменениям API, то есть совместить обновление со старой версией приложения. Заглянул к другой команде, которая с этим уже справилась, запросил инженерное решение и передал своим ребятам.

Отсюда следует второй совет: не считайте свою проблему уникальной. В 99% случаев это не так. Отойдите на шаг назад, посмотрите свежим взглядом, оцифруйте и двигайтесь по узким местам. Это скучно звучит, но именно так и растет инженерная зрелость.

— Как превратить процессы в результат, который оценит и клиент, и бизнес?

— Важно смотреть на результат глазами клиента. Ему неинтересно, что у нас внутри. Главное, чтобы все было максимально просто и эффективно в использовании.

Для бизнеса другой приоритет – предсказуемость. В Bereke Bank есть трехмесячный roadmap и расписание «поезда». Если команда успела подготовить фичу к определенной дате, то через неделю – после релиза – она гарантированно окажется у клиента. Это ценнее любых процессных деталей.