«Принцип CTO — быть готовым к черному дню». Техдиректор ProsperPay о нюансах работы
Нуркен Адилбаев еще в школе понял, что программирование — это его. Так парень начал карьеру разработчика и получил опыт во многих ИТ-корпорациях Казахстана, постоянно развиваясь в профессии. Недавно Нуркен стал техническим директором (CTO) финтех-проекта ProsperPay. Сервис позволяет работникам партнерских компаний отслеживать суммы заработанных на текущий момент денег и переводить их себе на карту в любое время.
В рамках конкурса лучших СТО стартапов, который Digital Business проводит совместно с Yandex Cloud, мы пообщались с Нуркеном и узнали подробности о специфике позиции техдиректора, необходимости подготовки к черному дню и диверсификации провайдеров.
«В стартапах все в первый раз»
— Нуркен, расскажите о своем опыте до ProsperPay.
— Начинал карьеру в «Народном банке», затем была «Цесна», «Билайн», «Сбер», еще несколько организаций. В других компаниях был близок к должности CTO: тимлид, руководитель направления, техлид. И в итоге я перешел в ProsperPay на эту позицию.
— Как опишете разницу между работой в больших компаниях и стартапе?
— В корпорациях много бюрократии, выстроенные процессы — любая ситуация уже была, и есть четкое решение под нее. А здесь — все в первый раз, и приходится по-новому создавать инструкции. В ProsperPay пришел первым и начал набирать людей, разрабатывал гайдлайны на определенные ситуации. Когда команда маленькая — бюрократия не нужна, тикеты описывать не требуется. А теперь приходим к более классическому корпоративному стандарту работы.
«Трудных задач не бывает: это просто совокупность простых»
— Расскажите о технически сложных решениях в ProsperPay, и в чем была их необходимость.
— По сути, все решения уже придуманы в мировой практике. И любая проблема, с которой сталкиваются разработчики, в большинстве случаев известна — задача лишь в нахождении этого кейса. Нужно просто постоянно сидеть на «Хабре» и читать материалы.
Я бы сказал, что у нас сложные решения не в плане реализации, а в плане совершенства. Мы переписали архитектуру, опираясь на опыт банков, плюс при переходе на микросервисы были свои нюансы. Трудных задач не бывает: это просто совокупность простых. И достаточно декомпозировать, чтобы понять — ничего экстремального нет.
— ProsperPay ушел с монолита на микросервисную архитектуру. Почему?
— Да, но не из-за того, что мы только сейчас научились это делать, а потому что лишь теперь возникла потребность. Команда разрослась, и она начала в один и тот же репозиторий заливать идентичные исходники, что привело к конфликту кода.
Микросервисы — не самая большая наша заслуга. Есть другие «подкапотные» дела, которые пользователи не чувствуют. Например, ускорение обработки запросов, улучшение оптимизации. Мы перешли с одного стека на другой: весь код переписан с PHP на Java, мобильное приложение перевели с WebView на Flutter. Фронтенд полностью другой, начали использовать большие языковые модели для автоматизации. Все это было за год. Проделана очень серьезная работа.
— Зачем переходили на Flutter?
— WebView сильно зависит от интернета, а у пользователей мобильная скорость не всегда высокая. Большая часть логики находилась на облаке, и устройству постоянно нужно обращаться к нему для вычислений. Приложение в такой архитектуре становится, по сути, браузером для открытия определенных страниц. Flutter же хорош тем, что требует меньше разработчиков, и мы пишем сразу на все платформы. И при этом частично работа идет на самом девайсе, а не сервере.
— Каким решением больше всего гордитесь в ProsperPay?
— Наверное, главная красота — у нас под капотом, которую пользователи не видят. Речь о надежности системы в плане архитектуры. Если какой-то микросервис ломается или в нем обнаруживаются ошибки, то система может саморегулироваться и понять, что некорректные данные нужно исключить из обработки. Наш основной принцип — чувствительность проверок. Мы стараемся строить систему так, чтобы при малейшем нарушении целостности данных проверки срабатывали и блокировали подозрительные действия.
Также мы разработали собственное антифрод-решение, о тонкостях которого не могу рассказать. Интеграция готовых продуктов заняла бы сопоставимое время, при этом чужое решение менее гибко и хуже учитывает специфику проекта.
«Выстроен баланс между техническим требованием и запросом со стороны бизнеса»
— Как найти баланс между скоростью, надежностью и производительностью? Что за чем идет в вашем случае?
— Думаю, каждый СТО задается этим вопросом. Начинающие обычно хотят сделать софт идеальным в техническом плане. А бизнес-ориентированные хотят побыстрее сделать фичу и не особо зацикливаются на качестве. У нас выстроен баланс между техническим требованием и запросом со стороны бизнеса.
Есть правило получения 80% результата при 20% усилий. Не могу сказать, что существует оптимальная формула — каждая задача требует индивидуального подхода. Мы смотрим на бизнес-фичу: какое изменение понадобится, насколько оно серьезное. Если решение задачи начинает приносить прибыль, то мы за 1-2 спринта закрываем все долги.
К примеру, реализовали функционал интеграции компании. Для львиной доли клиентов процесс работал как часы — они могли быстро подключиться и начать пользоваться сервисом. Но были кейсы с нестандартными форматами, и для них на первых порах требовалось ручное вмешательство нашей команды.
В дальнейших итерациях расширили форматы и тем самым убрали мануальную работу. В итоге клиенты начали пользоваться сервисом раньше. Они дали оперативный фидбек, отталкиваясь от реальных проблем, а мы смогли улучшить фичу так, чтобы их решить. Тем самым не стали пилить сферического коня в вакууме, но закрыли реальную боль конечного юзера.
«Я провожу не столько собеседования, сколько интервью»
— Что представляет собой техническая организация в ProsperPay?
— Есть три команды: две занимаются только бизнес-фичами, третья приводит в порядок код и доделывает оставшиеся задачи. У нас изначально была такая задумка по командам. Я пришел к ней после общения с СТО, изучения практик в других компаниях — были хорошие отзывы по такой структуре, и мы решили взять ее за основу.
— Вы подбираете людей в команды. Как выглядит собеседование? На что обращаете внимание?
— У каждой команды и человека есть свое позиционирование и видение мира. Если привести специалиста, который по образу мышления сильно конфликтует с остальными разработчиками, то они просто не сработаются.
Я провожу не столько собеседования, сколько интервью. Анкетные вопросы «как это работает», «как это называется» не задаю. Скорее говорим на более абстрактные темы, и по ответам становится понятно, насколько человек увлечен программированием. Если отвечает развернуто, с интересом, сам у тебя что-то спрашивает и уточняет, начинает на ходу размышлять, предлагать идеи — то понятно, что разработчик пришел в эту сферу не только за деньгами и жизнью в зоне комфорта. Программирование нужно любить, изучать, постоянно развиваться в нем.
— Какие вы выработали принципы при найме людей?
Первый: не перегружать кандидата слишком сложными вопросами и терминами, с которыми он мог не сталкиваться ранее. Если человек не знает какое-то понятие, это не обязательно означает, что он слабый специалист — возможно, просто не было необходимости работать с такой задачей ранее. Важно подбирать уровень вопросов и кейсов под конкретный уровень позиции.
Второй: не соглашаться на меньшее. После серии неудачных собеседований есть риск «замылить глаз» и снизить планку. Главное — не поддаваться этому. Команда заслуживает лучших специалистов, а слабое звено может замедлить развитие.
Третий: искать созидателей, а не потребителей. Последние ищут комфорт, следуют только инструкциям и не стремятся брать на себя ответственность. Созидатели же бросают вызовы, стремятся улучшать процессы, находят и исправляют ошибки, двигают продукт и команду вперед. Именно такие люди обеспечивают рост компании.
— Вы впервые стали СТО. Было ли несоответствие между ожиданиями и реальностью? В плане зоны ответственности, специфики работы.
— Понимание было, и как раз поэтому пришел в стартап — имелся некий внутренний вызов, который и двигает вперед. Поначалу, хоть и будучи СТО, кодил руками сам, потому что людей было мало. А затем, по мере роста числа сотрудников и появления нескольких команд, уже приблизился к менеджерской роли.
Разработчик мыслит кодом, тимлид оперирует людьми, техлид думает над архитектурой приложения, техдир управляет процессами. В моем случае, хоть я и руковожу процессами, но мне по-прежнему нравится писать код.
«Первая задача программиста — убить в себе перфекционизм»
— Какой у вас главный принцип работы как СТО?
— Их много. Основной — если что-то плохое может произойти, оно случится. Это позволяет предусмотреть как можно больше потенциальных проблем, и в итоге быть готовым к ним. Мы не размещаемся на одном сервере, работаем с несколькими провайдерами (и по SMS, и по оплате) — наша инфраструктура максимально диверсифицирована. И такой метод уже не раз выручал нас. Есть протоколы на определенные чрезвычайные ситуации. Мы подготовлены к черному дню, но надеюсь, что он никогда не наступит.
Также могут произойти и изменения в командах: кто-то заболеет, решит покинуть компанию. Поэтому у нас никогда нет одного человека на модуле — всегда несколько. И есть дежурства: независимо от своей должности человек выступает вместе с первой линией техподдержки. Это позволяет хорошо узнать всю систему изнутри, хоть выдержать две недели в режиме почти 24/7 и непросто.
— Дайте совет CTO-коллегам либо тем, кто готовится занять эту позицию.
— Начинающим посоветую искать компромисс. Однажды услышал фразу, которая очень понравилась: первая задача программиста — убить в себе перфекционизм. Если гнаться за идеалом, то можно в нем утонуть. Нужно искать оптимальное решение, которое удовлетворит и техническую команду, и запрос со стороны бизнеса.
— Что появится в ProsperPay в ближайший год?
— По технической части постоянно идет много улучшений, особый акцент сделаем на повышение скорости работы и стабильности системы.
Вам будет интересно:
