Зачем руководителю разработки (мне) алго-трейдинг
Как показывают честные исследования (https://claude.ai/artifact/1vjGKQ4iYssefbH1Gp3R5i) - никаких корелляций и 100% рабочих моделей в дневном трейдинге нет, всё держится на интуиции и удаче трейдера.
Фондовый рынок выглядит самой хаотичной системой из всех, что я встречал.
Но это же, черт возьми, не погода, где ретроградный меркурий реально влияет. Это та самая психоистория Азимова, в ней должны быть закономерности, а значит, и возможность прогноза хотя бы на 10 дней вперёд. Погоду же научились прогнозировать.
20 лет назад завирусился термин data-mining и я прошел пару курсов на эту тему. Тогда мне это показалось очень скучным и неинтересным, а язык R - сложным даже для моего математического образования.
Когда 11 лет назад я начал управлять командами, смотреть на процессы в целом, искать способы оптимизации - вот тут, как говориться, rubber meat the road.
В работе я всегда за data-driven подход. По историческим данным я могу сказать о команде всё: какой процесс, какая культура, кто выгорит через полгода.
Из базового списка моего аудита процессов: - самоназначенные задачи, - разработчик, у которого в 3 раза больше нагрузка, чем в среднем по больнице, - диаграммы зависимостей (не только в коде), - размазанные зоны ответственности, - долгие согласования, - пики производительности в конце квартала - фокус команды на процесс, а не на результат.
Проблемы менеджмента часто похожи на проблемы разработки. Переписать с нуля и там, и там дорого.
В последствии, обретенные навыки и инструменты анализа мне обязательно пригодятся в работе.
Да и инструменты успевают за трендами - я помню как тренды и линейную регрессию считали с выгрузок в Excel, а с января 2024 в Grafana и PromQL уже можно считать линейную регрессию на лету.