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

План:

1)      Введение

2)Общая структура ТЗ

3)Термины

4)Требования к платформе

5)Подключение

6)Входящие данные

7)Индикаторы

8)Настройки

9)Логика входа / выхода

10)   Когда можно ТЗ не делать

11)Заключение

1. Введение

Это вторая статья на тему того как делать роботов на заказ так чтобы ни у кого не было проблем, ни у заказчика, ни у программиста. Первая здесь: http://o-s-a.net/posts/gajd-po-razrabotke-robotov-part1.html

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

Это я к тому что информация ниже очень сильно отличается от того что можно найти на просторах ынтернетов и подходит только и исключительно для случая создания торговых роботов. Но при написании роботов – действовать нужно именно так.

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

2. Общая структура ТЗ

В ТЗ должны быть следующие главы:

1)Термины

2)Требования к платформе

3)Подключение

4)Входящие данные

5)Индикаторы

6)Настройки

7)Логика входа / выхода

Что-то можно ещё конечно добавить на вкус. Но для 99% всех заказов этого хватит. Это тот минимум который ОБЯЗАН быть.

3.Термины

В трейдинге очень много всякого за более чем сто летнюю историю было написано. Тысячи книг и десятки тысяч статей. Многие термины не однозначны или имеют прямо различные значения. Поэтому – как бы это не было смешно. Нужно такой пункт в ТЗ включать.

Кроме того, большинство заказчиков роботов не обладают техническим и/или экономическим образованием и порой придумывают для каких-то явлений свои названия. Что ещё более усугубляет ситуацию. Хорошо если ты уже 100 заказов сделал и с ходу можете отделить мух от котлет. Но если бы так было, ты бы это не читал.

Поэтому – пишем раздел термины.

1)Пробой,

2)Рынок замешкал,

3)Разрыв на графике,

4)Быстрый тик,

5)Скорость рынка,

6)Дивергенция по фибо с обратной корреляцией

7)Коинтеграция фьючерса с базовым активом

Пишем всё что только можно в этот раздел. Чем больше тут будет записей – тем лучше. Это поможет программисту погрузиться в предмет и понять что нужно. Не надо думать что разработчик изначально всё знает – скорее всего нет.

4.Требования к платформе

Если заказчик понимает что ему нужно, то он может просто написать – OsEngine, MT5 или TsLab. И Всё.

Но в большинстве случаев заказчик не разбирается в нюансах торговых платформ и не отличает Quik, SmartCom, StockSharpИ OsEngine. Всё это для него просто набор букв.

Поэтому здесь он должен написать что бы он хотел видеть на экране кроме робота.

1)Нужен график

2)Отображение индикатора

3)Логирование работы робота

4)Журнал с эквити

5)Возможность тестирования

6)Наличие оптимизатора

7)Т.д…

Программисту:

Если Вы столкнулись с заказчиком который не знает на кокой именно платформе писать робота. Пусть он это напишет. Можно потом это с заказчиком обсудить и объяснить что есть в OsEngine, а чего нет. Нужно объяснить человеку что исправление платформы, если это нужно, очень долго и дорого, и приведёт к тому что роботов потом будет дорого обновлять ибо обратная совместимость исчезнет.

Но также не забудьте объяснить что делать роботов на OsEngine это:

1)Бесплатно (большинство других платформ платные)

2)С открытым кодом (это есть только в OsEngine)

3)С открытой лицензией (заказчик сможет свободно и открыто продавать и распросранять потом робота, запускать сколько захочет версий)

И всё будет хорошо. Можете дать ютуб нашего проекта.

Вот это видео например, можете выслать отдельно: https://youtu.be/RhDe3NIxv3Y

Нужно чтобы заказчик понимал как в итоге будет выглядеть робот.

5.Подключение

Также здесь нужно описать ту биржу на которой будет идти торговля. Через какой терминал будет идти торговля.

Например:

1)MOEXчерез Quik

2)MOEX через Plaza 2

3)Binance

4)Bitfinex

5)NYSE через Interactive Brokers

6)И т.д.

Нужно точно знать через какую платформу должен торговать робот.

6. Входящие данные

Здесь нужно описать какие типы данных нужны роботу для работы.

Выбор такой:

1)Свечи

2)Стакан (Стаканы)

3)Горизонтальные объёмы

4)Индекс

5)Лента сделок

Со скольки инструментов робот будет смотреть эти данные

1)С одного

2)С двух

3)С N…

Какие инструменты будут торговаться:

1)Сбербанк

2)Фьючерсы FORTS. Riи Si

3)Фьючерсы с Бинанс USDTBTC, USDTETH

Всё подряд писать не надо. Нужно описать те данные, которые роботу действительно будут нужны и взаимодействие с которыми будет описано ниже по ТЗ.

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

7. Индикаторы

Описываем то, какие индикаторы нужны для робота.

Если это что-то стандартное, так и пишем.

Нужны индикаторы:

1)RSI

2)SMA

3)EMA

4)И т.д.

Если индикатор НЕ стандартный, то нужно будет описать то как он рассчитывается. Либо дать ссылку на статью в интернете, либо натурально вписать в ТЗ логику его расчёта.

Также здесь можно описать настройки которые будут нужны для этих индикаторов

8. Настройки

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

Пример:

1)Объём входа (поле для ввода. цифра) – нужно для управление объёмом входа в позицию.

2)Вкл/выкл (переключатель) – отключаем и включаем робота

3)Проскальзывание для входа (поле для ввода. цифра) – сколько пунктов мы будем отключаться

4)Включен ли вход 1 (переключатель)

5)Включен ли вход 2 (переключатель)

6)Включен ли выход по стопу (поле для ввода. цифра)

7)Включен ли выход по профиту (поле для ввода. цифра)

8)И т.д.

9. Логика входа/выхода

Самое сложное, как может показаться. Но после описания других пунктов, здесь на самом деле уже дело за малым.

Не надо блок-схем рисовать и задуряться с формализацией какой-то этого пункта.

Пишем – своими словами. В большинстве случаев этого будет достаточно. Если что-то будет не понятно, программист спросит.

Например

Вход номер один:

Если RSI> 80, если закрытие последней свечи больше чем открытие, если в стакане покупок больше чем продаж на 30%. Входим в Лонг

Вход номер два:

…

И так далее. Просто описываем логику. Пункт за пунктом.

Самое главное – не надо здесь описывать индикаторы, платформу и прочее. Если Вы уберёте это в другие блоки, то расписать логику не составит проблем.

10.Когда можно ТЗ не делать

Причина номер один

Как мы в прошлой статье обсуждали, если Вы готовы взять программиста на оклад – можно такого подробного ТЗ не делать.

Однако – в каком-то виде его всё равно надо делать даже в таком варианте, и лучше бы всё равно научиться правильно ставить задачи.

Причина номер два

Её нет…

Вот серьёзно. Если Вы хотите проектную занятость – учитесь писать ТЗ.

У меня столько конфликтов было из-за того что люди не хотят и ленятся писать тексты, что я (и наш отдел разработки официальный) никогда в жизни не возьму заказ без ТЗ.

Учитесь.

11.Заключение

Такие вот простые правила для написания ТЗ.

Если Вы не хотите брать программиста на оклад - обязательно делайте его!

Помните, как только кто-то (программист или заказчик) настаивает на том что это делать не надо. Он либо некомпетентен, либо преследует корыстные цели. А это практически гарантирует что Вы проект до конца не доведёте.

В моей практике, сколько бы я не начинал делать проект без чёткого ТЗ – КАЖДЫЙ раз это заканчивалось факапом. Клиент может говорить что не умеет писать, ему проще видео. Клиент умоляет начать завтра ибо надо как можно быстрее. Клиенту тяжело. Ребят – просто не начинайте. Либо настаивайте в таких случаях на окладе Лучше остаться без денег чем попасть в рабство.

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

Про некомпетентность

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

Программист может игнорировать важность написания ТЗ ибо не понимает к чему это приведёт. Это говорит только о том, что он не имеет опыта создания чего-либо на заказ. И скорее всего зафакапит проект. Отказывайтесь от такого программиста.

Про корысть

Если программист настаивает на отсутствии ТЗ, у него появляется возможность в любой момент «закончить», сказав, что мы об этом не договаривались. До свиданья.

Если заказчик настаивает на отсутствии ТЗ, то у него появляется возможность увеличивать объём работ до бесконечности и настаивать на том что программист должен доделать до то момента пока он(заказчик) не будет удовлетворён. А это может наступить как через неделю, так и через два года.

Итого

Не надо друг друга обижать и ставить в уязвимое положение.

Уважайте друг друга – пишите ТЗ.

Удачных алгоритмов!