За каждым релизом 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 и расписание «поезда». Если команда успела подготовить фичу к определенной дате, то через неделю – после релиза – она гарантированно окажется у клиента. Это ценнее любых процессных деталей.