Тренды 20-х в банковском и небанковском ИТ

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

Я не застал перфокарты и жесткие диски на 640 Кб, которых должно было хватить каждому, но даже для меня появление в моем доме wifi-роутера в 2006 году было чудом (Интернет по воздуху? Да ладно!). Сегодня мой автомобиль умеет проецировать скорость на лобовое стекло, а на заправке я плачу, бросив взгляд на экран смартфона. Внутри финансовой отрасли происходят точно такие же стремительные изменения. Поверьте, закрытие операционного дня в банке 10 лет назад было похоже на закат солнца вручную.

Пока старшее поколение воспринимает банки как оплот традиций и стабильности, мои ровесники уже ждут от банкинга прорывных технологий и инноваций каждую неделю. Слово «финтех» появилось не случайно, сращение финансов и технологий — это логичный вектор развития для бизнеса, ориентированного на ожидания клиентов.

Банки уходят в «диджитал». На каждой технической конференции можно встретить ребят типа меня, которые будут рассказывать, как они устали просто продавать кредитки и решили прикрутить куда-нибудь ML. Каждый понимает под словом «диджитал» что-то свое, но с нашей – айтишной – точки зрения потребитель понимает под «диджитал» компанией быструю компанию.

Обычно топ-менеджеры в банках работают на классические KPI — ROI, CIR, NTB. Если коротко — они борются за быстрый возврат инвестиций, сокращают расходы и наращивают клиентскую базу. Сегодня этого набора уже не хватает для удержания фокуса на развитии бизнеса, так в системе KPI появляется Time to market — время, за которое мы можем создавать и доставлять ценность клиенту. Причин, по которым нам нужен минимальный time to market ровно две:

C другой стороны, никому не захочется, чтобы какие-то хипстеры в погоне, добавляя в банковское мобильное приложение свои new shiny things типа чатов и роботов, сломали текущие счета или переводы. Никакие сторис и стикеры станут не важны, если я не смогу заплатить за обед в кафе. То есть time to market хорошо, но о стабильности забывать нельзя. Именно эти два вектора и определяют направление развития ИТ в цифровых банках ­— быстро, но стабильно.

В качестве примеров сильной инженерной культуры чаще всего приводят Facebook, Amazon, Apple, Netflix, Google. Эти компании действительно славятся своей инженерией: о них пишут книги, их ставят в пример другим. И совершенно неслучайно именно эти бренды находятся на первых позициях рейтинга крупнейших мировых компаний Fortune 500. Если посмотреть шире, на остальные компании из списка Fortune, то здесь тоже не будет открытий: они все похожи с точки зрения организации ИТ — все они используют Agile, DevOps, подходы Opensource и API First и так далее.

У меня нет цели писать очередную статью о том, что Agile – это здорово. Вместо этого я бы хотел подсветить несколько чуть менее мейнстримных трендов развития ИТ. Возможно, вы найдете среди них новые зоны роста для своего направления.

Здесь и далее я буду описывать опыт ОТП банка, потому что практические примеры всегда лучше голой теории.

Начну с холиварного: по моему глубокому убеждению проектный менеджмент в ИТ в целом доживает свои последние дни. Основной недостаток проектного подхода к разработке ПО – низкая скорость, и ограниченная возможность внесения изменений в процессе. Значит для достижения минимального time to market нужно что-то другое.

У себя мы сформировали кросс-функциональные команды, которые полностью автономно создают и развивают свои продукты. Методология Scrum предполагает, что такие команды должны выдавать клиентам некую ценность как минимум раз в спринт (обычно 2 недели). У нас некоторые команды релизят 2 раза в неделю. Меньше доработка – быстрее релиз – быстрее начинаем зарабатывать.

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

Есть еще один интересный нюанс. Рынок, как известно, голосует рублем – кто больше нужен, тому и платят больше. Исследование Хабр Карьеры показывает, что медианная зарплата менеджера продукта почти в полтора раза выше медианной зарплаты менеджера проекта.

И хотя на всем известном сайте по поиску работы по запросу «руководитель проектов» в категории ИТ находится 2000+ вакансий, в основном это не-ИТ и не финтех компании.

Буквально несколько лет назад использование облачных технологий в банках ограничивалось внутренними техническими нуждами. Почему? Потому что на территории РФ практически не было дата-центров провайдеров облачных сервисов. А значит любые операции с персональными данными означали владение собственным серверным парком.

Сегодня ситуация изменилась довольно радикально. Сейчас такие провайдеры не просто есть, среди них уже можно выбирать! Более того, большинство провайдеров сертифицированы ФСТЭК, PCI DSS и имеют все необходимые лицензии.

Мы используем гибридное облако в двух сценариях:

Есть такая книга «Automate the boring stuff with Python». Безотносительно плюсов и минусов самой книги (а она неплохая), в заголовке содержится очень важный посыл. Действительно, все монотонное и скучное нужно автоматизировать. Для ИТ эта мысль не очень свежая, но скажите, автоматизирована ли в вашей компании подготовка тестовых данных и подготовка тестовых стендов? Или закупки?

Так вот, в финтехе борьба идет за каждый сэкономленный человеко-час, а значит автоматизации по умолчанию подлежит вообще все. Если какая-либо операция повторяется периодически, то почему бы вам не подумать об ее автоматизации? Например, если разработчик вместо посещения отдела кадров в приемные часы с двумя экземплярами заявления на отпуск начнет оформлять отпуск нажав три кнопки, возможно, сэкономленное время можно будет направить на завоевание доли рынка.

Еще одним важным трендом, пока не очень распространенным в России, является Common platforms. Это набор инструментов, процессов и базовых правил, которые продуктовые команды потребляют как сервис.

Как это работает:

Что нам это дает:

Один из самых спорных и сложных в реализации пунктов.

В классической организации каскадирование задач сверху вниз работает по принципу «поставь задачу и проконтролируй, что она была исполнена». Так мы получаем много слоев мидл-менеджмента, каждый из которых нужен для контроля передаваемых через него вниз задач. Если посмотреть на это со стороны, выглядит это довольно забавно – много крутых менеджеров по 8 часов в день проводят на синхронизационных встречах друг с другом, а после еще по несколько часов проверяют, что задачи в их зоне ответственности выполняются в соответствии с планом. Очевидно, что это не самый эффективный способ управления корпорацией.

Многие крупные финтех (и не только) компании решая эту неэффективность перешли от принципа Command & Control к принципу Trust & Measure. Что это такое?

Возвращаясь к тезису о том, что владелец продукта – это СЕО своего продукта, задумайтесь, зачем и какого рода задачи можно ставить перед СЕО? Никакие, просто покажите ему вашу стратегию, и в рамках нее хороший СЕО приведет ваш бизнес туда, куда вы его направили, когда писали стратегию. Если не сможет – выбывает из игры, как и в любом бизнесе.

Но в процессе этого пути важно понимать, какая помощь нужна команде, где можно срезать углы, что можно не делать. Для этого рекомендуется использовать общую для всех продуктов систему метрик. Важно, что это именно метрики, а не KPI, и за их достижение или недостижение никто не будет наказан.

Например, с точки зрения ИТ для продуктовой команды такими метриками могут быть:

Аналогичный подход можно применять к чисто бизнесовым метрикам: количество клиентов онлайн, средний чек на клиента, MAU, DAU и так далее.

Смысл таких метрик в том, что пока их значения остаются «в зеленой зоне», на них не нужно смотреть. О них и помнить-то не обязательно. Но в случае, когда показатель любой что-то идет не так, команда с наивысшим приоритетом устраняет проблему, но не в ущерб остальным метрикам.

На самом деле таких принципов-трендов намного больше, и рассмотреть их в одной статье было бы сложно, да и незачем.

Вот еще небольшой список трендов, не вошедших в эту статью:

Если говорить про нас, то в ОТП Банке мы делаем все это и многое другое прямо сейчас: в первую очередь через изменение инженерной культуры, плюс разворачиваем новые инструменты и очень вкладываемся Средняя доля неуспешных внедрений в продакшн (Change failure rate);в обучение персонала. Пока мы в самом начале пути, но дорогу осилит идущий.

Мы, как и все хотим, чтобы процесс доставки ценности клиентам был максимально простым и понятным. Для этого мы одновременно унифицируем и оптимизируем наш технологический стек, и снижаем количество ручных действий в производственном конвейере. Большим вызовом для нас сейчас является повышение автономности продуктов относительно друг друга – в классических банках очень часто ИТ-системы очень плотно интегрированы друг с другом.

Что хорошо: как это обычно бывает в крупных организациях, в отдельных командах у нас уже давно успешно работают отдельные инженерные практики, решения и технологии. Этот опыт прекрасно тиражируется, а значит, мы сможем добиться целевого состояния раньше. Скорее всего, таких «агентов изменений» можно найти в любой крупной организации.

В целом, реализуя изменения, связанные с диджитализацией нашего бизнеса и улучшением клиентского опыта, мы уже накопили довольно много опыта – как позитивного, так и негативного – которым активно делимся на митапах и конференциях. В комментариях предлагаю поделиться мыслями по поводу того, какие вызовы стоят перед ИТ в финансовых организациях сегодня, а какие появятся завтра.