Денис Сарипов: «В чем разница оптимизации процессов в корпорациях и стартапах»

И в крупных компаниях, и в стартапах важно вовремя оптимизировать IT-процессы, чтобы быстрее масштабироваться и не выпасть из конкурентной борьбы. Но в зависимости от стадии зрелости компаний, оптимизация проходит в них по-разному. Денис Сарипов, Frontend Engineer в VK, выполнял ключевую роль в таких проектах и в стартапах, и в корпорациях. Он рассказал IT-World, в чем состоят основные отличия, какие решения будут наиболее оптимальными, и на что обращать внимание на ранних этапах проектирования архитектуры.

Денис, вы успели поработать и в крупной экосистеме VK, и в небольшом стартапе 6tamp. В чем для вас ключевые различия в подходе к работе фронтенд-инженера в таких разных условиях?

Я бы сказал, что в небольших компаниях и стартапах более важную роль играет скорость выполнения задач. Например, бывают моменты, когда компания не может взять новых клиентов, потому что ей не хватает каких-либо функций — и для получения прибыли нужно быстро их реализовать. Также в стартапе нет подробной документации, аналитики и других вспомогательных материалов по продукту. Нужно самостоятельно разбираться с клиентскими потребностями и даже самостоятельно общаться с потенциальными потребителями, чтобы быстрее понять, что для них важно. А в крупной корпорации решения принимаются, исходя из общей стратегии. Условно, мы должны понимать, в какую сторону движемся и где будем через несколько лет — чтобы определить, действительно ли нам необходима та или иная функция. Например, мы хотим развиваться в определенной стране, но там есть особые требования законодательства, и нужно понять, сможем ли мы переработать под них наш продукт. Для этого необходимо прочитать документацию, собрать аналитику, пообщаться с другими участниками команды. Если подытожить, то в стартапе мы думаем, в основном, как сделать задачу быстрее, чтобы привлечь больше клиентов — и некоторые аналитические моменты опускаем. А в корпорации сначала анализируем ситуацию, чтобы снизить риски возможных проблем в будущем. Со стороны технологий в стартапах обычно используются новые инструменты, и нет никаких комплаенсов. В больших компаниях разработка может зависеть от внутренних технологий, легаси и требований третьих лиц — то есть перед реализацией какой-либо функции нужно всё это согласовать. Таким образом, сроки проекта могут быть больше, чем в стартапе. По моему опыту, в корпорациях удобно использовать low-code платформы — с их помощью можно имплементировать определенные функции без участия специалистов, и это сокращает цикл разработки. Например, в VK мы реализовали на основе low-code конструктор для рассылок, который помогает бизнесам автоматизировать коммуникацию.

Расскажите подробнее о email-конструкторе и инструментах автоматизации коммуникаций — как эти решения повлияли на бизнес, и почему такие low-code платформы важны?

Нашей идеей было создать для B2B-клиентов инструмент, который поможет неспециалистам легко настраивать автоматизированную систему коммуникации — через чат-бот в мессенджерах, SMS или email. Это значительно экономит время и средства — не нужно вручную составлять десятки сообщений и нанимать сотрудников, которые разработают решение для рассылки. Этот сервис могла бы использовать и сама платформа VK — например, в качестве техподдержки. В результате сервис повысил привлекательность платформы для бизнеса и вовлеченность аудитории. Предприниматели видели автоматическую рассылку, например, от самой платформы или других сообществ, и понимали, что тоже могут воспользоваться ей. Также сам VK смог снизить затраты на разработку решений для рассылок — теперь все оповещения для пользователей можно автоматически запускать через конструктор. Это решение сейчас доступно не только в VK — любой бизнес может его подключить. Так мы внесли свой вклад в развитие российского предпринимательства в целом — компании могут использовать конструктор для коммуникации с клиентами и повышать количество продаж.

Учитывая, что в VK вы занимались оптимизацией архитектуры для сценариев взаимодействия пользователей, с какими основными вызовами вы столкнулись при переходе на новую архитектуру, и как этот процесс повлиял на скорость вывода фич и стабильность системы?

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

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

Если говорить о проектах в 6tamp — дэшборды и аналитика для разных типов пользователей — на что приходилось делать упор при проектировании таких интерфейсов, чтобы продукт был понятен и бизнесу, и конечным клиентам?

Компания 6tamp занимается разработкой цифровых карт для программ лояльности. Задача таких программ — максимальное удержание пользователей. Но при этом потребители не всегда готовы тратить время на регистрацию в системе — и поэтому она должна быть удобной и прозрачной. Мы сделали так, что получить карту можно с помощью QR-кода — после сканирования пользователь переходит в удобный интерфейс, где указывает информацию о себе, а карта добавляется в электронный кошелек на смартфоне. То есть весь пользовательский путь интуитивно понятен. При визите клиента QR-код карты можно быстро отсканировать, а информация попадет в дашборд. Для бизнеса важна максимально детальная и наглядная статистика, которую можно использовать для коммуникации с клиентами. Например, отправлять push-уведомления для клиентов, которые проходят мимо офиса, или предлагать бонусы на день рождения. Поэтому в дашбордах должна быть по максимуму отражена информация о потребителях — их пол и возраст, геолокация, статистика по покупкам и т.д.

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

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

Какие подходы к архитектуре фронтенда позволяют изначально заложить устойчивость к росту нагрузки — будь то стартап с десятками тысяч пользователей или платформа уровня VK с миллионами?

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

В каких компаниях вам самому комфортнее работать?

Мне комфортнее всего работать в средних компаниях. В них достаточно ресурсов делать интересные, технически сложные проекты, и при этом двигаться быстро. Также в них довольно легко продвинуться по карьерной лестнице, в отличие от корпораций. Но в принципе, это относится и к стартапным проектам крупных компаний.