Разделы

Бизнес Цифровизация Аутсорсинг ИТ в банках Финансовые результаты

Банк "Хоум Кредит": Мы банкиры, для нас главное – цифры

Внутренняя разработка информационных систем или аутсорсинг? По степени популярности и актуальности этот вопрос вполне может сравниться с бессмертным "быть или не быть". Каждая компания решает его по-своему. В банке "Хоум Кредит", где степень влияния информационных технологий на успешность бизнеса трудно переоценить, к поиску ответа подошли как и положено банкирам – на основе цифр и рационального расчета. Как выстроить оптимальную схему распределения обязанностей внутри ИТ банка и когда имеет смысл организовать выделенный центр разработки на базе аутсорсера? Об этом в интервью CNews рассказывает Кирилл Кибалко, директор департамента развития ИТ банка "Хоум Кредит".

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

CNews: Начать работать с удаленной командой аутсорсера было сложно?

Кирилл Кибалко: Я бы не сказал, что у нас были какие-либо серьезные проблемы. Наш партнер имеет положительно зарекомендовавшие себя технологии, и это сыграло свою роль. Что не сразу сложилось – это коммуникации. Когда сотрудники сидят рядом друг с другом, ходят вместе в курилку или на обед - это способствует появлению неформальных положительных эмоций и связей. Становится проще общаться по рабочим вопросам, лучше понимать друг друга. Когда появляется удаленный центр, то на первом этапе у членов команды возникает своего рода культурный шок: как общаться, как работать? Есть единый коллектив программистов, но, к примеру, условные Михаил и Алексей сидят в офисе в Москве, а изображение Ивана только иногда появляется на мониторе в окошке Skype. И есть еще какой-то программный код, который он пишет.


Кирилл Кибалко: Мы были заинтересованы в том, чтобы внешний подрядчик полностью взял на себя всю организацию инфраструктуры, постановку процессов, подбор персонала и его мотивацию.

Сначала некоторые менеджеры проектов психологически не могли привыкнуть к распределенной работе. Как можно доверить разработку не тому программисту, к которому всегда можно подбежать и посмотреть, чем он занят, а тому, кто находится за сотни километров от тебя в Самаре и работает в другой компании? Но преодолеть этот барьер несложно: когда с обеих сторон работают специалисты высокого класса, они постепенно находят общий язык и выстраивают эффективные рабочие взаимоотношения. Тем более что современные средства коммуникаций - Go2Meeting, Skype, Spark или их аналоги – позволяют уменьшить дистанцию.

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

CNews: Какие задачи и проекты вы поручаете удаленному центру разработки, а какие оставляете себе?

Кирилл Кибалко: Здесь действует тот же принцип: ключевая экспертиза – в банке, разработка – в удаленном центре. Мы рассматриваем возможность привлечения аутсорсинговых специалистов в качестве аналитиков, но в целом 90% аналитиков на проектах были и будут наши штатные специалисты. Это логично, поскольку они досконально знают и понимают наш бизнес. У наших партнеров, в свою очередь, компетентные разработчики, которые хорошо разбираются в наших ИТ. Такая модель разделения обязанностей полностью оправдывает себя, и мы собираемся развивать ее и дальше.


Кирилл Кибалко: В банке введено табу на слова "много", "долго" и другие неконкретные оценки.

Численность сотрудников самарского центра несопоставима с числом специалистов в головном офисе (сейчас это почти два десятка специалистов), но они задействованы в достаточно большом количестве проектов. Информационные системы банка, за исключением одной, построены на основе готовых промышленных платформ, которые были существенно кастомизированы под специфику нашего бизнеса.

Одно решение – систему поддержки розничного кредитования Homer – мы полностью разрабатывали с нуля: это единый продукт для всей группы Home Credit. Проекты самарской команды связаны с развитием как собственной системы банка, так и других решений (в частности, системы для поддержки фронт-офиса).

CNews: Разработка информационных систем построена таким образом, что в производственных процессах участвуют несколько команд – внутренних и внешних. Как вы оцениваете качество и эффективность их работы?

Кирилл Кибалко: Мы очень практичны в подходах к оценке качества и эффективности работы. В банке введено табу на слова "много", "долго" и другие неконкретные оценки. Если кто-то из моих подчиненных, например, говорит "ошибок в программе много и исправляются они долго", он сразу теряет в моих глазах значительную долю уважения. Производственный менеджер не должен оперировать словами "много", "долго", "мало", "плохо", "хорошо". Он должен оперировать количественными показателями: "ошибки исправляются долго: это занимает столько-то часов".

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

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