Масштабирование финтеха: учитесь на чужих ошибках

Какие технические сложности возникают у владельцев и руководителей бизнеса, когда обороты резко растут и начинают измеряться сотнями миллионов и миллиардами рублей, а число сотрудников — десятками и сотнями, а также как их решать, «Деньгам» рассказал CEO компании IT Monsters Виталий Колготин.

Выйти из полноэкранного режима

Развернуть на весь экран

— Какие ключевые вызовы стоят перед финтех-компаниями в России сегодня?

— Мы видим стремительный рост рынка. Россия входит в топ-5 стран по уровню проникновения финтех-услуг. Более 80% российских граждан пользуются различными финансовыми услугами в режиме онлайн, будь то онлайн-кредиты, страхование, инвестиции или просто денежные переводы. Значит, за реализацию финансовых услуг сегодня отвечают IT-специалисты. Развитие информационных технологий, в свою очередь, позволяет резко расти тем сегментам рынка, где они усиленно внедряются.

— Как меняются задачи IT-команд, когда компания стремительно растет?

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

Если у вас масштабы бизнеса ежегодно удваиваются, то каждый год увеличивать в два раза количество линейных сотрудников — архисложная задача. Чтобы автоматизация шла эффективно, многие компании, и мы в частности, выбирают путь продуктовых команд, то есть разделяют IT-персонал на направления, отвечающие за разные участки работы. В нашем случае такими участками являются, например, выдача кредитов, погашение кредитов, клиентский сервис и т. д. За каждый из них отвечают разные продуктовые команды, между которыми распределяется вся IT-разработка. И для каждой команды вводится свой KPI.

— Какие могут быть KPI у разработчиков?

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

— Количественный рост IT-персонала тоже, вероятно, порождает проблемы?

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

Сейчас появилось много бизнес-процессов, которые успешно работают без участия людей. Мы запускаем инициативу, и после этого десять задач создаются автоматически, людям ставятся задачи, возникает чек-лист. Когда ты, условно говоря, общаешься с десятью разработчиками или с двадцатью, это опять же две большие разницы, у живого общения есть естественный предел. И по мере масштабирования описывать процессы все сложнее: одно дело — распределять какой-то новый процесс на 10 человек, а другое дело — на 100. Все становится очень дорого, и об этом лучше подумать сразу: как фича проходит путь от описания до выкладки на продакшен, кто за что отвечает. И лучше, если процесс будет автоматизирован, и ты не сможешь залить фичу на продакшен, если у нее нет, к примеру, документации, описанной по определенным критериям. И проверкой полноты описания занимается не человек, а сама система.

— Какие могут быть ошибки при масштабировании онлайн-бизнеса?

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

— А как масштабирование влияет на IT-архитектуру?

— То, с чем многие столкнутся и сталкиваются,— это переход к микросервисной архитектуре. Микросервисы имеют смысл, когда есть хотя бы один-два разработчика, чтобы сопровождать каждый из них. Мы делали все изначально на монолите, но со временем поняли, что у нас какой-то процесс сбоит, скажем, потому, что он слишком тяжелый. Тогда мы принимаем решение написать для него отдельную программу. У нас появляется отдельное веб-приложение, помогающее решать задачи распределения персонала по микросервисам, которым занимается отдельный человек. И такая структура показала хороший результат, мы смогли эффективно работать даже в период резкого роста компании, когда задач становится все больше и больше. А растем мы как минимум в два раза ежегодно, а в отдельные периоды — до трех. Это создает постоянное давление на IT-инфраструктуру, процессы и команду, требуя высокой гибкости и быстрой адаптации.

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

Михаил Щедрин