SavePearlHarbor

Программист в банковском проекте: пять мифов и круглый стол

—

от автора

admin

Что только не говорят про разработку в банковском секторе: программисты там не нужны, уйти из банка невозможно, менеджмент с разработчиками разговаривать не умеет. И многое другое. Мы на Хабр Карьере решили обсудить разработку в банках со знающими людьми, позовем на круглый стол несколько тимлидов из крупных банков и узнаем, как оно там на самом деле все устроено. Приходите послушать (онлайн, конечно) 22 декабря в 17:00, регистрация тут. 

А пока мы попросили наших друзей, которые занимаются ИТ-поддержкой банков в ЛАНИТ, рассказать про то, с какими мифами они сталкиваются на практике. Статья получилась «по верхам» — задавайте вопросы в комментариях (или докидывайте ещё «мифов»), в деталях все обсудим, подтвердим или опровергнем на круглом столе!

Миф 1: Банк — это не про айти

С одной стороны, так и есть. Банки, вообще, довольно сложные структуры в организационном плане. Но жизнь меняется, мы все уже привыкли пользоваться мобильными приложениями: пополнять карты, переводить деньги, оплачивать счета — всё одним кликом.

Сегодня банки в старой парадигме будут лишаться клиентов. Они стоят перед выбором: трансформироваться или потерять бизнес. Клиенты требуют сервисы и удобство. А для того, чтобы предоставлять классные услуги, нужны классные специалисты. Это люди, которые могут предложить идею, решение и доказать её пользу не только для банка, но для его клиентов. Из таких специалистов, например, состоит большинство банковских команд Сбербанка, Тинькофф и ВТБ, к продуктам которых мы все привыкли. Сбербанк так уже давно выделил свою ИТ-службу в Сбертех, отдельную компанию. 

Почитать по теме: 

Миф 2: Стабильность важнее инноваций

Тоже отчасти правда. Банки долго были очень инертными. Какие-то остались такими и сейчас. Но, например, те же Сбербанк, Тинькофф и ВТБ, о которых мы уже говорили, пытаются уйти от образа консервативной компании, они стремятся работать по-другому.

У тех, кто сейчас приходит в банковские проекты, есть шанс поучаствовать в создании новой культуры работы на этом рынке. Теперь если банк будет выводить продукт на рынок в течение полугода, он потеряет и рынок и клиентов, в его продукте вообще не будет смысла. Time-to-market — одна из основных характеристик в банковских проектах. Её пытаются сократить всеми возможными способами. Если кредитная организация будет работать в старом стиле, добавляя в разработку множество согласований и регламентов, то time-to-market будет очень и очень длинным.

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

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

По теме: 

Миф 3: Из банковской сферы сложно уйти

За время работы в банке разработчик обрастает огромным количеством специфических, отраслевых знаний. Когда человек тратит 3–5 лет на то, чтобы разобраться в какой-то сфере, впитать её, ему становится сложно расстаться с этим опытом. Так что этот миф тоже отчасти правда. Но это связано не только с банковской спецификой, так же можно сказать практически про любой другой рынок. 

Миф 4: Менеджерам из банковского бизнеса сложно найти общий язык с ИТ-специалистами

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

Ребята из проектных команд общаются с банком не только через ТЗ и документы, разработчики напрямую коммуницируют с продакт-оунерами, обсуждая задачи и ход работы. И, как минимум, из-за того, что современные методологии разработки подразумевают настолько плотную коммуникацию между заказчиком и исполнителем, талантливый руководитель со стороны клиента быстро осваивается в особенностях работы подрядчика. 

Есть ещё один вариант коммуникации — когда разработчик не общается напрямую с бизнес-заказчиком и между ними стоит, как минимум, аналитик от банка. Получается, что программист вряд ли почувствует сильную разницу в общении, работая с банком. Либо они вовсе не будут пересекаться, либо будут работать, например, в небольшой agile-команде, где каждый специалист точно глубоко погружен в ИТ-процессы. 

Ещё можно заглянуть сюда: 

Миф 5: Меня ждут однообразные проекты

Чем больше банк, тем больше выбор между проектами.

Есть проекты первого класса. Это масштабные продукты, которые решают сложнейшие задачи внутри организации. Такие проекты запускаются, идут, и работают очень долго. Бывают и краткосрочные проекты. Например, отдел маркетинга в банке провёл исследование и сделал вывод, что для конкретной группы клиентов нужно сделать микросервис, который поможет банку, во-первых, улучшить сервис для потребителей и, во-вторых, быстро заработать. Такие проекты запускаются мгновенно и так же быстро выводятся на рынок. В такой работе есть драйв, овертайм и, да, порой очень сильные нагрузки, но это важный и редкий опыт для сотрудника. 

Почитать ещё: 

Встречаемся 22 декабря в 17:00 на круглом столе про разработку в банках, регистрация тут. Вопросы спикерам кидайте в комментарии. 

ЛАНИТ собрали нам для статьи свои вакансии на банковские проекты, мы разбавили их актуальными позициями в Сбере, Тинькофф и банке «Открытие»:

ссылка на оригинал статьи https://habr.com/ru/company/habr_career/blog/532984/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *