Компания CQG широко известна в узких кругах: все, кто профессионально занимается трейдингом, нас знают. Мы лидеры в поставке real time данных, технологиях графического анализа и всего с этим связанного. Головной офис в Денвере, Колорадо. Офисы по всему
миру. Компания существует
с 1980 года, уже 37 лет,
самарский офис
работает 12,5 лет.

#53 Meeting Алексей Паравин | Сергей Горелов

Ресурс-директор самарского офиса Глава департамента разработки

Компания представлена на бирже?
АП: Нет, мы частная компания.
Вы сами на бирже играете?
АП: Мы — нет, но компания предоставляет всем сотрудникам бесплатный доступ к инструментам. Есть ребята, которые торгуют...
Вы делаете это в рамках российского законодательства?
СГ: Если хочешь торговать фьючерсами, то в любом случае ещё нужен брокер, у которых, конечно, есть соответствующие лицензии локальных финансовых регуляторов. Покупается подписка на сервис CQG и организовывается выход на рынки через брокера, только потом будет доступ.
Какие у вас продукты?

АП: CQG началось с графического анализа, чартинга. Когда компания открылась в 1980 году, базовые графики рисовали от руки. Покупали лист в клеточку и рисовали, например, point & figure, крестики-нолики, пытаясь понять, куда пойдёт рынок. CQG была одной из первых компаний, которая поставила всё это на электронные рельсы. Cтандарты, которые приняты в индустрии по отображению финансовой информации на графиках, во многом были заданы CQG.

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

Также до этого мы занимались только деривативами — фьючерсами и опционами. В последние годы мы начали расширять спектр инструментов — форекс, акции, бонды, различные сложные случаи вроде UDS (user defined strategies) и так далее.

АП: Наш основной продукт — это CQG Integrated Client, где есть и торговля, и аналитика, причём очень продвинутая аналитика, с бэктестингом (back testing), где ты можешь создать алгоритм и протестировать его на исторических данных, которые у нас имеются по всем основным биржам. Ты постоянно будешь думать, что придумал что-то новое и эффективное, но бэктестинг будет тебя постоянно в этом разуверять. IC — это основной и самый полнофункциональный продукт.

Также есть CQG QTrader, облегчённый продукт без advanced трейдинга и аналитики, стоит грубо на порядок дешевле. Есть мобильные решения, которые позволяют торговать со смартфона или планшета и в тоже время иметь доступ к базовому теханализу.

СГ: И тренд последних пяти лет — наши API, программные интерфейсы. Есть люди, которым не нужны стандартные решения по теханализу, они хотят реализовать логику сами, и им нужны наши данные и выход на торговые площадки. Для этого мы предоставляем программный интерфейс. Это нужно и большим компаниям, которые делают front-end сами, и им нужны просто качественные и быстрые данные и возможность торговли, и небольшим группам людей, часто стартапам, которые пишут сами. Существует и новый HMTL5 клиент.

То есть у меня есть алгоритм, который симулирует, как будто у меня война в Сирии…
СГ: У нас нет инструмента, который предсказывает геополитические события. У нас есть инструмент для фундаментального трейдинга, в противовес техническому трейдингу (когда ты, например, принимаешь решения на основе пересечения средних с разным периодом, условно). Это реакция на какие-то новости. Мы точно так же поставляем информацию из лидирующих агентств, например, Dow Jones, и если можешь написать алгоритм, который работает с новостями, то сможешь и автоматически реагировать.
Раньше российский рынок был в основном PC Windows, сейчас сплошные пользователи на Mac. Есть платформа под Mac?
СГ: Узкие профессиональные рынки очень инертны. Для примера можно взять кассовые аппараты IBM. UI в них консервативен настолько, насколько возможно. Людям нужен просто рабочий инструмент. Mac мы пока поддерживаем в CQG IC, но есть и HTML5 клиент, доступный с любой платформы.
Про API — насколько он доступен небольшим компаниям и частным лицам?
СГ: Зависит от количества бирж, к которым нужно подключаться. Сейчас это становится всё дороже. Не мы являемся дорогим вендором, а каждая биржа несёт в себе очень много платных опций. С каждым годом все эти нагрузки ужесточаются. Принимаются законы, которые несут в себе нагрузку для поставщиков услуг. Поэтому у стартапа не будет проблем с CQG, у стартапа будет проблема, как ему эффективно подписаться на данные всех необходимых бирж. Real time данные стоят дороже, delayed данные дешевле. Стоимость зависит от пакета. Многие начинающие компании находят наше предложение интересным.
Правильно я понимаю, что основному продукту около 30 лет?
СГ: К сожалению, с точки зрения кода — да.

АП: Чтобы был понятен масштаб проблемы. Первый продукт назывался CQG, дальше был CQG NET, так как мы первые начали использовать телекоммуникационные сети. Это были самописные программно-аппаратные решения, компьютеров ещё не было в широком доступе. Данные мы посылали через спутник. Тогда ещё не было торговли. После этого System One был написан для PC. Кое-где во всей системе есть код с 90х годов, и это проблема. Всё написано на C.

Если вопрос стоит, как мы будем улучшать систему, то в CQG это, в основном, борьба с Legacy. Вы этого лишены как класс, и мы вам сильно завидуем. Взять код на C++ и просто перевести его на новую версию Visual Studio – само это иногда проблема. Многие места мы обложили boost / patterns etc. и стало полегче, но часть кода всегда будет тебя сдерживать. Поэтому мы делим продукт дальше, делаем модульным.

Разработка новых продуктов идёт одновременно в разных офисах? Расскажите о ваших релизах.

АП: Если идёт разговор в терминах продукта, то да. Но каждый продукт состоит из нескольких проектов, которые мы стараемся сосредоточить в одном офисе, правда, получается не всегда.

Проект содержит итерации, заканчивающиеся релизами, каждая итерация имеет какое-то отношение к сущности, которую мы определяем как продукт. Это может быть клиент, может быть сервер, может быть парсер.

СГ: CQG — это совокупность продуктов, довольно глубоко заходящая в разные дебри. Часть из этого co-located с биржами для обеспечения скорости передачи данных. Любое изменение в парсере, который принимает данные с биржи и транспонирует его в понятный универсальный формат, — это тоже релиз.

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

Для нас маленький проект — это до 15 человеко-недель. Средний — до 50 человеко-недель. Большой проект — 50-200 человеко-недель. Сложность самого большого проекта (Solution 3) была в том, что пока ты кардинально меняешь архитектуру, ты должен в это же время развивать проект. Поэтому у тебя всегда живёт бранч, где ты занимаешься всеми своими передовыми решениями, которые все отличные, но прямо сейчас тебе нужно выдавать новые релизы. А потом мёржить все эти решения в рамках новой архитектуры. Тем не менее проект был разбит на 3 итерации с учётом всех этих сложностей, и всё прошло успешно.

Про Solution 3 получился анекдот в рамках компании. У нас не было названий, поэтому мы просто предлагали варианты реализации. Были Solution 1, Solution 2, Solution 3. И когда выбрали третий вариант, сказали, что надо срочно придумать название, чтобы он не закрепился на годы как Solution 3. Естественно, название закрепилось как Solution 3.

Какие интерфейсы вы отдаёте наружу?

СГ: Ну, во-первых, FIX интерфейс как стандарт для биржевой торговли. Также новый API продукт Continuum Connect на основе protobuf.

Наш HTML5 продукт сам работает через Continuum Connect.

Насколько у вас большой зоопарк технологий? Как вы относитесь к интеграции новых инструментов, Rust, например?

СГ: Смотри, если ты, например, «просто» умеешь писать на Rust, это не означает, что ты можешь писать на Rust достаточно эффективно. Эффективное владение инструментом начинается с определённого уровня опыта, и для большой системы с критичными требованиями к производительности и надежности это имеет большое значение.

Поэтому мы немного более консервативны, идеи переписать вообще всё на новом языке у нас не возникает.

На самом деле, конечно, идем по пути компромисса. Мы переписывали куски на .net, когда он был популярен. Мы делаем новый продукт на базе HTML5 и новых технологий баз данных.

Мы встраиваем HTML5 компоненты из него в другие наши продукты. Но 30 лет — переписать всё вообще на новой технологии просто невозможно.

Если в компании есть энтузиаст, евангелист определённого технического подхода — мы дадим ему свободу. Если набирается критическая масса таких энтузиастов с правильной аргументацией, то мы пишем часть системы при помощи этого технического подхода. Но до Rust пока далеко, масса не накопилась.

Как у вас устроен цикл Delivery системы?

СГ: В зависимости от продукта. Большая часть стандартна: везде заведены TeamCity, всё собирается либо по коммитам, либо ночью, прогоняются тесты, осваиваем Octopus & Ansible для Continuous Delivery. Docker не используем.

Есть роадмап по развитию внутренней системы delivery, где отмечен прогресс относительно точки, где мы хотим быть. Текущий статус-кво нас ещё не устраивает, но скорость движения радует.

Если вы являетесь поставщиком данных, то у вас есть какая-то нагрузка. Можете её оценить в каких-нибудь цифрах?
СГ: Тысячи клиентов, залогиненых в один момент. Сотни серверов по всему миру. Co-location в разных городах в Штатах, в Лондоне, Сиднее, Сингапуре, Токио, Гонконге и так далее.
У вас в Самаре есть офис, а где ещё?
АП: Девелоперские офисы компании есть ещё в Москве, Зеленограде, Киеве, Ереване и Денвере . Они плюс-минус одинаковые по количеству сотрудников. Офисы продаж и поддержки расположены в Денвере, Чикаго, Нью Йорке, Гленвуд Спрингс, Лондоне, Токио, Сингапуре, Гонконге и Сиднее.
У вас есть сотрудники, которые пишут алгоритмы трейдинга?
СГ: Нет. Мы не делаем это за людей. Мы поставщик технологических услуг. Не трейдеры.
АП: Идеологи компании в этом не заинтересованы. Могли бы заниматься? Могли бы, конечно. Но тогда было бы много этических вопросов и вопросов от контролирующих органов. Ты не только сам торгуешь, у тебя есть данные пользователей в базе.
А что делать, если разработчик решил для себя использовать эти данные?

СГ: Во-первых, ты не доберёшься до данных, продакшн базы данных закрыты для доступа.

Во-вторых, у нас в договорах есть пункт, который эту ситуацию оговаривает.

Скорее, проблема нашей специфики в том, что нас постоянно абьюзят. То есть люди постоянно пытаются получить больше через наш API, чем мы им легально даём. Война идёт именно здесь, не за пароли, а за, скажем так, расширенный доступ к легальной информации.

Реально ли заработать на торгах?

СГ: Сложно. Рынок — это саморегулирующаяся сущность, она обладает функцией эффективности (насколько легко поймать какие-то простые закономерности). Например, условно, рубль падает, ЦБ РФ всегда делает интервенции в заданное время, чтобы на следующее утро в новостях было чуть поменьше драмы. Если ты знаешь, что каждый день будет в три часа вечера, то твои действия понятны. Это называется неэффективный рынок.

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

Ну в каком смысле нет... Если ты думаешь, что, в принципе, рынок будет расти, то ты сможешь всегда как частный трейдер заработать достаточно много. Но мы не берём долгие промежутки, вопрос был про эффективность в intraday торговле. Каждый день открывать торговые заявки и закрывать их. Не купить золото и продать его через пять лет, а быть эффективным, торгуя каждый месяц, каждый день. Вот это очень сложно. Для этого нужно обладать неким ноу-хау и средством его донесения.

Есть участники рынка, которые торгуют в плюс длительное время?
СГ: Да, есть, но их процент невелик. Среди частных, непрофессионалов — совсем невелик. Если хотите совет, то конкретно сейчас – используйте механизм ИИС. Тебе дают 13% в год вычета, плюс ты их ещё можешь вложить. Покупаешь на них облигации федерального займа (скажем 8%), плюс ещё 13% вычета. Это нормальный механизм повышения интереса к фондовому рынку от государства, и в данном случае доход будет выше, чем на банковском депозите.
Вам же постоянно ставят палки в колёса законодатели. Какие у вас были самые запоминающиеся моменты?

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

Или, например, приходит к тебе EU c MifiD II стандартом, какая ценовая информация должна быть зафиксирована по каждой сделке и какая точность должна быть у таймстемпов. Все эти требования мы обязаны реализовать в продукте. Плюс всё это надо хранить в полном объёме. Место стоит дёшево, но реализация, человеческий ресурс, стоит всегда дорого.

Как подтверждается чистота данных?
АП: Есть специальная аналитика таких данных. Или бывают критические моменты, например, 11 сентября под развалинами оказались некоторые биржи, и они просили данные у нас, пока не восстановились. У одной компании был бизнес в одной башне, а бэкап в другой башне.
Как у вас построена работа с распределёнными командами?

АП: Я так понимаю, что вопрос в том, как разные команды используют метрики для достижения какого-то результата. Метрики мы начали применять в 2004, когда компания начала разворачиваться в несколько офисов разработки. Мы сразу начали использовать PSP/TSP process.

СГ: Тогда была мысль, что к разработке софта можно отнестись как к классической инженерной задаче. И если ты будешь правильно проектировать порядок клёпки, то тебе это всегда даст правильный продукт. К сожалению, это не так. Люди, которые занимались разработкой процесса, сделали очень сильный акцент на повторимости результата. Для нас очевидно, что это не так, но тогда компьютерные науки только зарождались, и мы на это попали. Нам казалось, что если мы возьмём процесс от университета Карнеги, то мы точно сможем с заданной точностью предсказать и качество, и всё остальное.

АП: При этом были красивые метрики, количество дефектов на KLOC снизилось больше, чем на порядок.

СГ: И это правда, оно работает. То есть CQG, впитав в себя все эти знания, перестали следовать одному процессу и аккумулировали несколько частей разных процессов одновременно.

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

Что касается отчётности, то основное требования от разработчиков одно — чтобы они нам сказали в конце рабочего дня, над чем работали, распределив свои активности между проектами в процентах. Если хочешь что-то улучшить, ты должен это измерять. Этот принцип всегда лежал в основе нашего подхода к процессу разработки.

Вы в результате покрыли 30-летнее ядро тестами?
СГ: Нет, конечно. Это и не нужно – особенно в тех частях, где изменения не производятся. Где-то покрытие 30%, где-то 70%, где-то больше.
Сколько у вас инструментов измерения?

СГ: Если постоянно добавлять в портфель инструменты измерения, то со временем ты начнёшь только анализом и заниматься. Автоматически мы собираем сотни метрик, но смотрим и принимаем решения на основе немногих основных.

АП: У нас в дашборде инспекционные графики, но там их порядка десяти, не больше. И есть графики командной работы — качество, продуктивность, чем команда занимается. Их тоже с десяток. В сумме около 20. Смотрим раз в три недели, раз в месяц.

У нас есть небольшие командные мероприятия, когда команда собирается и обсуждает результат. Смотрим на какие-то спайки, если всё идёт как обычно, то они просто пролистываются. Люди, которые глубоко в метриках, видят, какую именно проблему нужно локализовать. А возможно, проблемы и нет, просто так звёзды сложились.

Процесс-коучи — это отдельные люди?

АП: Это дополнительная роль, дополнительная нагрузка. Чаще всего — это девелоперы, которые прошли дополнительные обучение и тратят время на помощь другим девелоперам. У процесс-коуча примерно четыре команды, и деятельность по коучингу занимает не больше 5-7% его времени. Это доведено до автоматизма, одного взгляда достаточно, чтобы понять, есть ли проблема.

СГ: У нас код-ревью делается в виде формальных инспекций, в противоположность, например, pull-request. Что может быть проблемой? Например, у нас дефекты на инспекциях делятся на функциональные и нефункциональные, я тебя инспекчу и нахожу только нефункциональные дефекты, это дефекты из разряда: «нет комментария», «код не подходит к стандарту», но после компиляции код один и тот же. А ты у меня находишь функциональные дефекты. Из разряда: «здесь работает не так, как нужно», «здесь не зелёное, а красное» и так далее. Команда ищет проблему — это «я не владею технологией» или «меня не закоучили» и т.д. Поэтому на всё это смотрим именно внутри команды вначале, менеджер не разберётся в сути.

АП: Если возникает конфликт, то в инспекции есть модератор. Если это касается инспекции как процесса, то это менеджер проекта. В целом, по ситуации.

СГ: Со временем определённые классы дефектов на инспекциях уходят, их место занимают другие. Если в инспекциях ничего не находят, то это вопрос к команде, потому что зачем вы тогда тратите деньги компании на этот процесс.

У вас свои инструменты для этого?
СГ: К сожалению, да, в свое время пришлось в них вложиться. Мы начали этим заниматься ещё тогда, когда готовых таких продуктов на рынке не было. Поэтому если компания начинает заниматься внедрением процессов разработки сейчас, ей не надо ничего писать, готовых отличных решений много.
Как строится в целом работа со всеми вашими продуктами с учётом тридцатилетней Legacy?

СГ: Мы ничего не делаем без business case. Допустим, появился новый аспект торговли, который нужно поддержать. Или аспект регуляции. Рождается идея проекта. Это некая карточка идеи — кому это нужно, зачем это нужно, почему это важно, сколько это будет стоить.

Дальше эта идея проходит арбитраж внутри компании, если понятно, что нужно делать, пишется концептуальная архитектура, составляется оценка. Если зелёный свет получен, то проект попадает в очередь на разработку. Это к нам.

Как детально работает команда?

АП: Помимо продуктового деления, у нас есть деление на большие системы. Есть клиентская: всё, что видит клиент. Есть серверная система: всё то, что клиент не видит. Есть gateway: всё, что касается прохождения сигнала между серверами, между клиентами биржи и в обратную сторону. Есть парсерная система: всё то, что стоит на выходе из биржи. Дополнительно есть инфраструктурная система, туда входят команды вроде SQA, Software Configuration Management, девелоперские системные администраторы и так далее. В каждой системе есть команды. В редких исключениях команда работает на несколько систем. Это касается не только уровня экспертизы, но и технологий. Какие-то системы пишутся на C++ под Unix, какие-то на .net, поэтому такое распределение.

Дальше уровень экспертизы. В рамках системы есть специализации: есть команды, которые специализируются на мобильных приложениях, есть команды, которые делают back end. Чаще всего получает задачу команда, чей уровень экcпертизы максимально близок.

АП: Зависит и от сложности проекта. Если придёт какая-нибудь огромная фича, задача на сервер, клиент, гейтвей. У каждой системы есть системный архитектор, у проекта есть проектный архитектор. В проекте чаще всего это умный и опытный разработчик, который часть своего рабочего времени тратит на архитектурные задачи.

СГ: Вот, для примера. Недавно мы перешли на новую версию библиотеки Boost, но оказалось, что они сделали что-то для меньшего потребления энергии на ноутбуках, в результате чего у нас в системе просела производительность (это кстати к вопросу об открытом программном обеспечении и об уровне контроля). Мы это поняли, но человек, который внедрял библиотеку, был уже в отпуске, и оба человека, которые отсматривали это изменение и были с ним знакомы, тоже были недоступны. В пятницу мы принимали решение, что нам с этим делать. Коммит был просто откачен средствами git, мы прогнали тесты и выложили на stage, впоследствии — production. Ни автор изначального изменения, ни инспекторы, ни тестировщики в этом участие не принимали. Случай простой, но показательный в плане доверия в системе, где 80% покрыто юнит тестами и есть дополнительное покрытие сценарными тестами.

Как принимаются решения на больших проектах в плане нового функционала? Как появляется идея, как оценивается?

СГ: В результате дискуссий, споров. Обычно есть продакт-менеджер, который отвечает за финансовый успех определённого направления. Например, есть продакт-менеджер, отвечающий за широту поставки данных, и он говорит, условно: «в Бразилии появился отличный Exchange. Давайте первыми начнём с ним интеграцию, тогда все пользователи, которые заходят торговать новыми бразильскими, не знаю, какао-бобами, перейдут на CQG».

Дальше собирается проектная группа, и они начинают обсуждать. Количество ресурсов ограничено, и эти ресурсы могут быть потрачены на подсоединение к Exchange, либо на новый вид аналитики, который давно нужно сделать в клиенте, либо на что-то еще. У кого больше всех аргументов, тот и получает ресурсы.

А иногда всё точно знаешь, что это надо делать. Или это must have с технической точки зрения, есть просадки производительности, и должен оптимизировать свой код. Или появился новый аспект регуляции.

АП: Есть представление о возможных доходах и потерях, без этого не начинаются новые проекты. В том числе и инфраструктурные.

СГ: У нас есть PMO (Project Management Office), который занимается процессной обвязкой всего этого дела. Они ограничивают продакт-менеджеров, которые хотят всего и сразу, тогда как у нас ограниченное количество ресурсов. Все продакт-менеджеры находятся в США как можно ближе к клиентам, к биржам. Проектные менеджеры работают в девелоперских офисах по всему миру. В том числе и в Самаре.

Есть ли у вас глобальный анализ, как влияют на трейдинг геополитические проблемы?
СГ: Каких-то вещей, аналитически учитывающих геополитическую обстановку и погодные условия, у нас нет. Другой вопрос, становится ли из-за глобальных факторов менее точна техническая аналитика. Это тема для статьи, может, даже для диссертации.
Как вы строите распределённую работу? Работаете с удалёнными командами?

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

Либо ты сначала сделаешь неправильно, и потом придётся всё переделывать. У каждого сотрудника есть телефон, в переговорках стоят интеркомы, техническая часть решена на достаточно высоком уровне. Главное — этим пользоваться.

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

АП: Также сильно влияет таймзона. Время, когда ты можешь эффективно общаться.

СГ: Человек всё-таки социальное существо. Приходят к тебе в кубик люди, говорят про технологию, с которой будете стыковаться. Вы это услышите, удалённый сотрудник не услышит. Если бы все работали удалённо, они бы к вам не подходили, использовали бы, скажем, Slack изначально, информация была бы доступна всем. Поэтому смешанные локально-удалённые команды — это отдельная сложность.

В любом случае, обязательно на каком-то этапе нужен личный контакт, посмотреть друг на друга, притереться.

Вам тоже есть, о чём рассказать?
Давайте знакомиться:

Пред. След.
comments powered by Disqus