Как технические решения помогают TravelTech бизнесу масштабироваться – интервью с Артемом Рудяковым
По данным, которые публикует Forbes, 70% стартапов терпят крах из–за неудачи в масштабировании. Особенно из–за преждевременного масштабирования. Артему Рудякову довелось сначала в роли разработчика, а потом тимлида принять важные технические решения на переломном этапе существования российской TravelTech–компании Aeroclub и сервиса для путешественников Time.Aero, когда масштаб деятельности вырос, количество клиентов перевалило за 2500, а кодовая база и прочие элементы IT–инфраструктуры оставались от стартапа.
Не у всех профессий и ролей есть устоявшиеся названия, и, в частности, нет слова для обозначения инженера, решающего проблемы отставания IT от расширившейся бизнес–деятельности. Но в апреле 2019, на ежегодном собрании сотрудников Aeroclub Артему вручили приз как лучшему сотруднику года. Вместе с Рудяковым, мы заглянули в «машинное отделение» превращающегося в компанию стартапа.
Aeroclub – компания, цифровизирующая бизнес–процессы оформления и организации поездок, трансферов, командировок. Более 2 тысяч бизнес–клиентов уже пользуются возможностью не проводить вручную 80% документооборота в этой сфере. Кроме того, удается сильно сэкономить. Aeroclub агрегирует данные из API сотен поставщиков транспортных услуг, безошибочно находя через их техническую инфраструктуру самые оптимальные по цене параметры обслуживания.
– Артем, какие проблемы в сфере IT создало то, что клиентов стало больше и Aeroclub превратился в компанию из стартапа?
- Проблемы, типичные для масштабируемого бизнеса. У Aeroclub несколько сервисов, каждый из которых отвечает за какой–то один аспект цифровой организации путешествий: Time.Aero (покупка билетов, бронирование отелей, заказ трансферов, сопровождающая все это статистика для руководства, генерируемая автоматом бухгалтерская отчетность), Expense (который помогает решить еще больше финансовых аспектов), Atom (аналитика по организации путешествий, командировок), ряд других сервисов. Основой был поиск подходящих пакетов услуг (авиабилетов, номеров в гостиницах), позволяющий пакетно выбрать и купить то, что вам нужно исходя из того, куда и как вы хотите ехать.
Так вот, количество клиентов начало расти. Нашей автоматизированной платформой стали пользоваться такие компании, как «Сибур», «X5 Group», «Русал», «Газпромбанк», Buyer. Возросла нагрузка на сервер и обещала вырасти еще больше, так как руководство поставило задачу создать новые услуги, а в старых – учитывать больше информации из разных источников. Для этого требовалось получать данные из API еще большего количества поставщиков туристических и транспортных данных. Нужно было добавить нагрузку на нашу систему, подгружая данные из IWay (такая система заказа трансферных бизнес услуг), «Островка» (профессиональный цифровой сервис турагентов), всего 5 новых источников.
Кстати, интеграцию для IWay в итоге писал я сам, как разработчик. Что это значило? Много новых данных и приток клиентов плюс IT–архитектуру стартапа, которая писалась второпях, иногда не самыми опытными разработчиками с «костыльными» запросами в базу данных в расчете решить проблему здесь и сейчас. Неоптимально сделали некоторые интеграции c API трэвэл поставщиков данных. Все это дало тяжелый кризис, с которым сталкиваются при масштабировании все компании. Для нас он выразился в том, что поиск с десятками фильтров стал сбоить. При сложных фильтрах результат мог задержаться на 2 минуты или вовсе дать ошибку! И при том, что нашими услугами пользуются такие клиенты! Хотя компания была создана в 1994 году и даже в 2000–х у нее не было серьезных конкурентов в России, клиенты не стали бы терпеть такое качество обслуживания. В конце концов надо было быть эффективнее, чем полуавтоматические цифровые веб–сервисы, которые все же создают сами поставщики услуг: железнодорожные и авиа–перевозчики, сети отелей. Требовались решения, причем, быстрые решения.
– Учитывая, что сейчас, как мы знаем, сервис Time.Aero и другие элементы экосистемы работают хорошо, проблема была решена. Как был достигнут этот результат? С помощью каких инструментов? Какова была ваша роль?
– Сначала я пришел в компанию как обычный разработчик, однако по мере успешного решения задач выдвинулся. Мне стали поручать решение бизнес–задач, требующих координации других разработчиков и общения с менеджментом и сотрудниками других отделов. Размах деятельности Aeroclub достиг 1,4 миллиона транзакций через наши веб–сервисы в год. Как вы понимаете – это оборот в сотни миллионов рублей. Тем не менее, технический отдел был небольшим.
Вообще сейчас «роль личности в истории» для разработки очень велика. Решая проблемы в качестве тимлида, я никогда не переставал программировать сам. Например, именно я написал модуль, собирающий в дашборде менеджмента компаний C–левела информацию о командировках, поездках и автоматически генерирующий по ним бухотчетность. Как тимлид я провел самостоятельный анализ того, почему увеличилось время получения результата в поиске и почему снизилась отказоустойчивость IT–инфраструктуры Aeroclub. Первоочередной проблемой стал довольно устаревший фронтенд системы, не поспевающий за таким объемом данных. И вкупе с этим, довольно сложные запросы для бэкенд систем, которые не были рассчитаны на такой объем данных.
Однако сложные фильтры были преимуществом сервиса Time.Aero. Потенциал рефакторинга, то есть улучшения кода скрывался в самих запросах, которые, как я уже говорил, были неоптимально написаны, когда стартап только создавался. Мы все это переписали. Жить стало лучше, жить стало веселее. Забегая вперед скажу, что этой и другими нашими мерами удалось сократить время получения результата самого сложного запроса к поиску с 2 минут до… 5 секунд!
Мы заново написали код многих интеграций с API авиакомпаний, железнодорожных перевозчиков, сетей гостиниц. Многие из них работают по совсем разным протоколам: от WCF до RPC. Разнородные данные, полученные таким образом, нужно было правильно скоординировать, чтобы они сравнивались и формировали общую услугу быстро на платформе Aeroclub, которую можно было заказать одной кнопкой. Значительного выигрыша мы добились, переписывая серверный код, а также покрывая наши приложения тестами. Мы использовали разные инструменты: nUnit, Moq, AutoFixture.
Отдельно я бы рассказал об RabbitMQ. Это брокер сообщений. В условиях высоконагруженного сервиса «с фронта» вам поступает множество разнородной информации. Если правила реагирования на них на сервере не являются гибкими и адресными, то ответы на них формируются медленно. Кому отправить SMS–уведомление? Кого проинформировать по e–mail. В архитектуре Time.Aero не было модуля, через который можно было бы тонко настроить маршрутизацию поступающих запросов. Я предложил и продвинул через руководство внедрение в архитектуру RabbitMQ как посредника, который решает все эти проблемы. И «кролик» внес большой вклад в ускорение сервиса. Наши технические решения имели бизнес–измерение: компания смогла масштабироваться, привлечь и удержать более 500 новых клиентов.
– Легко ли было заниматься кросс–разработкой – организовать сотрудничество технического отдела с другими подразделениями?
– Любые технические решения должны вытекать из стратегии компании в бизнесе. Я согласовывал наши изменения с топ–менеджментом, консультировался с отделом продаж, маркетологами и многими другими заинтересованными сторонами. Приведу в пример такую историю: в поисках решений по оптимизации кода и ускорения интерфейсов мы дошли до UI, то есть кода пользовательской части приложения, на которой написан его внешний вид. Я лично написал несколько виджетов на JS, которые помогали решать некоторые проблемы. Однако я не мог бы сделать этого успешно без понимания того, как пользователи используют продукт. Для этого мне надо было получить обратную связь от других специалистов, что я и сделал.
Добавлю, что многие проблемы с «техническим долгом», то есть неэффективными техническими решениями, которые не только приводят к ошибкам, но и заставляют разработчиков тратить время на поддержку legacy–кода, а не создание новых «фич», вытекают из менеджмента, а не разработки как таковой. Так что проблему 2–минутных результатов поиска мы решали в том числе использованием популярных в IT технологий управления проектами: Agile, Scrum. Правила спецификаций по этим стандартам взаимодействия разработчиков мы внедряли в программное окружение разработки. Чтобы деятельность на техническом уровне можно было выполнять одним единственным, правильным способом.
– Какой из своих проектов в Aeroclub вы считаете самым важным с точки зрения бизнес–целей компании?
– Сбор статистики и аналитики по поездкам клиента для предоставления ему в будущем наиболее выгодных предложений. В Time.Aero есть дашборд, позволяющий руководителям видеть все наглядно, они это очень ценят. Скоро система сможет предсказывать, когда и какие поездки клиенту могут понадобиться, выдавая соответствующие предложения. У нас уже есть наработки в этом направлении. Например, моя команда реализовала систему авто–заказа бизнес–трансферов для клиентов из числа топ–менеджмента компаний, чтобы максимально сократить действия вручную с их стороны.
Кроме того, я хотел бы подчеркнуть, что TravelTech–платформы как наша позволяют здорово экономить. Aeroclub объединяет и сравнивает на своей площадке данные более 800 авиакомпаний. А это только перелеты. Time.Aero и другие сервисы получают информацию из 1000 источников. Так как данные там представлены для разработчиков. Несложно подобрать максимально выгодные в поездке услуги. Представьте: перелет, отель, аренда автомобиля и многое другое приобретается нажатием одной кнопки и подбирается для вас автоматически. Очень перспективными являются все наши модули, которые позволяют получать скидки на приобретение нескольких разнородных услуг, которые в принципе не получится подобрать и обсудить с представителями компаний традиционным способом.
– Что планируете делать в дальнейшем для развития сервиса?
– В планах запуск мобильного приложения. Развитие собственного API. Аккумулируя на своей площадке информацию тысяч трэвэл поставщиков данных, мы стремимся сами отдавать эту информацию сторонним сервисам. Тем более, что у Aeroclub по прежнему нет эквивалентных аналогов. Также есть замысел создавать интегрированные сервисы на основе еще большего количества API. Существуют доступные по лимиту запросов открытые и закрытые данные с анонсами местных событий в дни вашей поездки, с методами, позволяющими заказывать более редкий транспорт, чем автомобили. В Европе и США такое уже используется на TravelTech–площадках. Настало время учитывать такую информацию при заказе билетов и оформлении поездок в России.
– Как становятся невидимыми героями масштабирования стартапов?
– Все начиналось банально (смеется). Я просто откликнулся на вакансию на hh. А дальше: я просто выполнял задачи так хорошо, что это заметили и оценили.
Масштабирование компаний – нерассказанная история о том, как любой IT–стартап, который уже давно работает, однажды сталкивается с суровым тестом на слаженность. Это происходит, когда количество клиентов проходит определенный порог. Если 70% организаций, согласно Forbes, не проходят этот тест на жизнеспособность, то вдвойне ценными становятся специалисты по масштабированию IT–архитектур, которые подтягивают техническую составляющую к изменениям в бизнесе. К ним принадлежит и Артем Рудяков. А Time.Aero – подтвержденный успешный кейс.
Комментарии читателей Оставить комментарий