Изменения на рынке IT-специалистов – они есть? Можно ли сегодня говорить о дефиците IT-кадров? Как меняется подход к набору IT-команд в существующих реалиях? И можно ли с помощью low-code/no-code технологий решать задачи в периметре крупных финансовых организаций? На эти и многие другие вопросы в рамках программы «Финтех-Драйв» ищут ответы Владимир Залеский, управляющий партнер FIS, и его коллега Алексей Смирнов, директор по развитию FIS.
В этом выпуске своим взглядом на эти вопросы с ними и нашими зрителями поделился Алексей Клепиков, вице-президент и руководитель информационно-технологического кластера «ПАО МТС-Банк».
— Владимир Залеский, управляющий партнер FIS: Друзья, всем привет. В эфире программа «Финтех-Драйв» и с вами я, ее ведущий Владимир Залеский, и мой коллега – Алексей Смирнов.
— Алексей Смирнов, управляющий партнер FIS: Всем привет! В гостях у нас Алексей Клепиков, руководитель информационно-технологического кластера, вице-президент «ПАО МТС-Банк». Добрый день!
— Алексей Клепиков, вице-президент, руководитель информационно-технологического кластера «ПАО МТС-Банк»: Добрый.
— Владимир Залеский: Сегодня у нас будут к вам разноплановые вопросы. Но основных момента два. Первый момент: поговорим о ситуации на рынке, связанной с кадрами. Второй момент: пообщаемся по IT-технологиям, связанным с low-code/no-code.
Какие изменения вы сейчас видите на рынке IT-кадров? Обостряется ли дефицит? Или наоборот, в связи с происходящими бифуркациями, давление чуть уменьшилось, потому что многим IT-специалистам пришлось переориентироваться на решение внутренних задач?
— Алексей Клепиков: Дефицит может создаваться с двух сторон – с точки зрения количества кадров и с точки зрения потребности. То есть, если потребность резко растет, а количество кадров вообще не изменилось или тоже растет, но с недостаточной скоростью, то это тоже дефицит. Но природа этих дефицитов разная. Но сейчас дефицит есть с обеих сторон – и в плане количества специалистов, а также уровня их подготовки, и в плане растущего количества IT-задач. В том числе на государственном уровне.
Если говорить о нашей организации, а также о компаниях – в которых работают те IT-специалисты, которых я знаю – заметно снижение текучести кадров. Люди хотят стабильности, гарантий от своего работодателя, а также накопления стажа на выбранном месте работы. В связи с этим искать сотрудников стало сложнее, однако назвать драматической эту ситуацию тоже нельзя.
Сегодня у нас в целом укомплектована IT-команда. Это, прежде всего, специалисты уровня Senior, потому что именно они могут двигать бизнес вперед. Конечно, были некоторые сложности в связи с отъездом ребят за границу, но сейчас мы их вполне успешно возвращаем. Подытоживая, ситуация на рынке изменилась, но не драматически ухудшилась, нет. Большинство хочет просто стабильности, гарантий и работать.
— Алексей Смирнов: А какого профиля специалисты требуются? Сейчас многие западные игроки уходят с рынка, вместе с ними уходят и технологии. Нужны ли специалисты какого-то конкретного профиля? Или речь именно о фундаментальной разработке?
— Алексей Клепиков: У нас все стабильно. Все те, кто были нужны – нужны в тех же количествах и в той же квалификации и сейчас.
Если же посмотреть на общерыночную ситуацию, то, конечно, есть тренд на внедрение опенсорс-решений. Но на мой взгляд, спустя несколько первых месяцев после ухода вендоров из России, нервное напряжение несколько спало. Сейчас все понимают, что есть определенное время, за которое нужно спокойно, планово стать импортонезависимыми, а после уже заместить недостающие решения. И здесь всегда нужно иметь в виду бизнес-эффективность – сперва нужно обезопасить себя с точки зрения продукта от уходящих вендоров (как получать патчи и дальше, как их отлаживать, тестировать), а дальше уже целенаправленно переходить на какое-то иное решение. С точки зрения персонала: конечно, импортозамещение спровоцирует компании на поиск новых сотрудников, чаще всего это будет опенсорс. Обычные разработчики и аналитики, которые были нужны и раньше.
— Владимир Залеский: То есть при миграции специалистов с одной области разработки в другую никаких проблем не возникает? Время на адаптацию есть?
— Алексей Клепиков: Конечно. Выводить решения будем планово, спокойно. В любом случае все понимают, что от решений Siebel или SAP придется рано или поздно отказываться. Здесь самое важно – принять новую парадигму, не пытаться ей сопротивляться и спокойно двигаться вперед. Время есть.
— Алексей Смирнов: Влияет ли на выбор нового технологического стека потребность в адаптации к нему существующих специалистов?
— Алексей Клепиков: Мы не какой-то крупный итальянский банк, который держит штат старичков, не способных к освоению чего-то нового. У нас достаточно современная страна с точки зрения технологий. Я не вижу здесь никакого стоп-фактора, заставляющего нас выбирать ту или иную технологию по неким причинам. Не будет такой ситуации, в которой мы выберем систему на Golang и скажем нашим JAVA-разработчикам срочно переучиваться, в этом просто нет необходимости. Сейчас нужно просто выбрать систему с перспективной архитектурой.
Сегодняшняя ситуация для меня, как для IT-директора, вообще выглядит позитивно – у нас снизилась текучесть, сотрудники начали больше ценить стабильность. Ситуация была перегрета, сейчас она нормализуется. И нужно принять новую реальность и дальше в ней работать. Адаптивность – это очень важно, мне кажется, что сложившейся ситуации и страна в целом, и наша компания показали себя способными к адаптации. То есть первоначальные ожидания были гораздо более страшными, чем то, к чему мы пришли в итоге. Видимо, мы привыкли ждать плохого.
И вообще, есть ведь и другие задачи. Например то, что люди не хотят возвращаться с удаленки после пандемии. И это тоже своего рода вызов для IT-директоров – доказать эффективность своей команды в этих новых условиях.
— Владимир Залеский: Является ли снижение себестоимости разработки, внедрения каких-либо инноваций для вас первостепенной задачей? Какие методы вы используете для снижения этой себестоимости или по крайней мере ее удержания?
— Алексей Клепиков: Здесь точно также, как в дефицитом персонала. Объем задач тоже растет. Чтобы конкурировать банкам приходится идти на уплотнение функционала, а это всегда деньги.
Конечно, задача по оптимизации затрат есть. С одной стороны, всегда нужно искать неэффективность – смотреть, насколько эффективна и сбалансирована команда. С другой стороны, выбор инструментария тоже критичен. Простой пример: есть Siebel – монолитная система, есть ЦФТ– монолитный бэк-офис. И любая разработка, которая нужна командам в этих системах для реализации нового функционала, тормозит time-to-market. То есть микросервисы мы можем релизить в режиме онлайн практически без ограничений, но если команда не может вынести логику из монолитных приложений в микросервисный слой, то приходится либо расширять объем команды, либо обращаться за сервисной помощью. Так или иначе увеличивается time-to-market и расход на разработку.
Поэтому выбор инструментария важен. Здесь нужно понимать, насколько вы готовы рисковать плавильным развитием архитектуры, пожертвовать развитием платформы с точки зрения того, что сделано внутри платформы. Что будет, если отдать командам микросервисную платформу и дать им разрабатывать все, что они хотят? Через какое-то время мы увидим несколько десятков абсолютно одинаковых сервисов, которые по сути принесут в компанию неэффективность. Четкий архитектурный контроль, наличие solution-архитекторов, наличие tech-лидов, наличие практик разработки очень важно. У нас сейчас среди более 1500 тысяч сотрудников, задействованных в IT порядка 1000 составляют ребята из бизнес-команд. И им нужно ясное видение общей картины, чтобы работать эффективно. Здесь задача IT-руководителя – показать, как работать с платформой, каких результатов мы ждем.
— Алексей Смирнов: А видите ли вы в low-code/no-code технологиях возможность решения каких-либо задач, которые есть в периметре финансовой организации?
Алексей Клепиков: Все очень сильно зависит от того, какой у вас бизнес, какая компания. Если компания только-только заходит на какой-либо рынок, то low-code технологии выгодны, потому что сокращают time-to-market. То есть они хороши для стартапов и для бизнесов, которые постоянно меняются.
Здесь можно привести в пример RPA-технологии. Эти технологии несколько лет назад казались чуть ли не «серебряной пулей», в корне меняющей взгляд на эффективность бизнеса. Однако быстро стало ясно, что в тех компаниях, в которых и так уже высок уровень автоматизации, места для роботизации просто нет, все и так уже сделано. Или пример с автотестами – они, конечно, нужны. Но если ваша компания постоянно меняется, то затраты на постоянное изменение автотестов будут слишком велики. То есть в энтерпрайзе большого количества low-code/no-code решений не встретишь.
— Владимир Залеский: То есть говорить о полном ноукоде пока рано. А если говорить о low-code решениях: можно ли отдать 80% построения бизнес-логики специалистам без высоких технических навыков, а 20% – профессиональным разработчикам? Возможно ли это?
— Алексей Клепиков: Это возможно, но напрямую зависит от масштаба системы. Если вы большой высоконагруженный энтерпрайз, который хочет хотя бы пять лет прожить в текущей архитектуре, то low-code технологии вам не подойдут. Почему? Потому что любой непрофессиональный программист имеет свойство непрофессионально программировать. Это всегда приводит в трагичным, иногда катастрофичным, а иногда комичным последствиям. Не бывает такого, что непрофессиональный программист построил, условно, Ноев ковчег и всех спас. К сожалению, нет. То есть здесь важно понимать ключевые характеристики вашей системы – насколько велика ваша ежедневная посещаемость, ваша транзакционная нагрузка.
Простой пример. Наши непрофессиональные программисты, работая в риск-менеджменте, написали на пайтоне классный код. Который в принципе работал, всех все устраивало. Но когда появилась задача по увеличению масштаба в несколько раз, выяснилось, что эта штука вообще никак не масштабируется. Какой здесь вывод: всегда нужно смотреть на перспективу. Если компания относительно небольшая и код непрофессиональных программистов всегда можно отрефакторить при необходимости, то их можно привлекать. Но если у вас основной состав IT-команды – это не профи, то нужно понимать, что в какой-то момент вы окажетесь в ситуации, в которой вам нужно будет все это переделать. В какую цену это встанет? Какие будут последствия для компании? Вот на эти вопросы нужно ответить.
И здесь можно затронуть такую интересную тему, как time-to-market, который должен быть максимально коротким. Но он и будет максимально коротким, если бизнес-заказчик будет поминать, какое решение хочет получить в итоге. Это и увеличивает время разработки. Но секрет в том, что последовательное движение к конкретной цели будет всегда эффективнее, чем итерационное выяснение этой цели с помощью agile-подходов в ходе разработки. Поэтому очень важно профессиональное планирование развитие компании.
Вам может понравиться
Обсудить идею или проект
Ответим уже сегодня