Как правильно поставить задачу MQL-программисту: чек-лист для заказчика

Заказывая советника или индикатор на MQL, многие трейдеры получают не то, что представляли: робот открывает сделки не по тем правилам, закрывает позиции не вовремя, а доработки превращаются в бесконечные переписки и доплаты. Причина почти всегда одна — нет чёткого технического задания.

Советник реализует ровно то, что прописано в ТЗ: неописанные правила разработчик не додумает. Разберём, из чего состоит грамотное техническое задание, и составим чек-лист, который поможет поставить задачу MQL-программисту ясно и с первого раза.

Почему советник получился не таким, как вы хотели

Торговый советник для MT4 или MT5 — это не воплощение вашей идеи, а буквальная реализация текста технического задания. Программист не «додумывает» правила, которые в нём не описаны: если в ТЗ не указаны стоп-лосс, момент входа или фильтр новостей, в код попадёт только то, что записано. Робот честно выполнит задание, но торговать будет не так, как вы представляли. Кажущаяся «очевидность» и есть главный источник расхождений между задуманной и написанной логикой.

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

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

Цена недосказанности: переделки, сроки и споры

Недосказанность в ТЗ не проходит бесследно — она превращается в доплаты и сдвиг сроков. Пока идёт разработка, каждое «добавьте ещё одно условие» — это новая итерация кода, тестирования и согласования, которую исполнитель справедливо считает отдельной работой. А на приёмке выясняется, что робот «работает не так, как я думал», и начинается спор: кто должен оплачивать правки, которые существовали в вашей голове, но не в тексте задания, а значит, формально вне оговорённого объёма работ.

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

Детальное ТЗ экономит деньги ещё до начала разработки. Чем полнее задание, тем точнее исполнитель оценивает стоимость и сроки: ему не нужно закладывать в смету запас на догадки и будущие уточнения. Чем больше неопределённости в постановке, тем выше такая «страховка» — и тем заметнее итоговая цена может разойтись с названной.

Что даёт грамотное ТЗ: предсказуемый результат

Грамотное ТЗ превращает хаос переписки в один документ. Вместо десятков сообщений «а ещё нужно…» — структурированный текст: логика торговли (инструмент, таймфрейм, условия входа и выхода), параметры со значениями по умолчанию, правила риск-менеджмента и критерии приёмки. Такой документ одинаково читают и вы, и исполнитель. Вопрос «что именно мы делаем» больше не требует отдельного обсуждения и не зависит от памяти участников.

Второе преимущество — база для сравнения предложений. Когда несколько разработчиков получают одну и ту же постановку, их сметы и сроки можно сопоставлять напрямую. Разница в цене отражает подход и квалификацию, а не разное понимание задачи. Документ становится и основой формальной приёмки: каждый пункт ТЗ закрывается результатом, а спорные моменты решаются ссылкой на конкретный раздел, а не на воспоминания о договорённостях.

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

Логика и параметры: ядро технического задания

Ядро ТЗ — формализованная логика сигналов. Укажите инструмент и таймфрейм, на котором работает советник. Зафиксируйте бар, на котором сигнал считается подтверждённым, — обычно на закрытии сформировавшейся свечи, чтобы исключить перерисовку индикаторов. Затем по шагам пропишите условия входа и выхода: что открывает позицию, что её закрывает. Укажите тип ордеров — рыночный market или отложенный pending. Каждое условие формулируйте проверяемо: «появляется стрелка индикатора» — плохо, «быстрая скользящая средняя пересекает медленную снизу вверх на закрытии бара» — хорошо.

Параметры выносите в настройки: каждому — имя, единицу измерения и значение по умолчанию. Так поведение меняется без перекомпиляции, а исполнитель получает однозначную спецификацию. Период индикатора указывайте в барах, стоп-лосс — в пунктах, объём — в лотах. В итоге должна получиться таблица параметров, по которой программист пишет код без уточняющих вопросов. Пример условного блока настроек на MQL5 (показанные объявления input подходят и для MQL4):

input double LotSize       = 0.1;   // объём позиции, лот
input int    FastMAPeriod  = 10;    // период быстрой скользящей средней
input int    SlowMAPeriod  = 30;    // период медленной скользящей средней
input bool   UseNewsFilter = true;  // учитывать новости

Схема условна: реальный набор input-переменных зависит от стратегии, имена и значения вымышлены. Отдельно зафиксируйте терминал — MT4 или MT5. Языки не идентичны, поэтому платформу и совместимость версий прописывают явно. А если новости влияют на вход, добавьте в логику новостной фильтр в советнике: как он прописывается в ТЗ.

Риск-менеджмент и приёмочные тесты: два раздела, которые забывают

Риск-менеджмент — самый важный, но чаще всего забытый раздел ТЗ. Пропишите максимальный риск на сделку в процентах от депозита — например, 1–2 %. Укажите авторасчёт лота исходя из этого процента и уровня стоп-лосса. Задайте значения стоп-лосса и тейк-профита в пунктах, поведение трейлинг-стопа и фильтры: время работы советника и пропуск сделок в моменты новостей. Чем точнее эти значения, тем проще проверять советник на истории и не бояться за депозит в реальной торговле. Схематичный пример условных настроек на MQL5 (показанные объявления input подходят и для MQL4):

input double RiskPercent    = 1.0;   // риск на сделку, % от депозита
input double StopLossPts    = 300;   // стоп-лосс, пунктов
input double TakeProfitPts  = 600;   // тейк-профит, пунктов
input bool   UseNewsFilter  = true;  // не входить в моменты новостей

Схема условна: имена и значения вымышлены, реальный набор зависит от стратегии и брокерских условий. Затем опишите критерии приёмки — без них работу не с чем сверять. Укажите тест на истории: период, модель тиков, учёт спреда и комиссий, список проверяемых ситуаций. Пропишите обработку ошибок: потерю соединения, отказ торгового сервера, нехватку маржи. Включите в тесты проверку проскальзывания и реквотов — частых источников расхождения ожиданий на приёмке. Каждый пункт ТЗ должен закрываться результатом теста. Чтобы одиночный бэктест не обманул, добавьте в ТЗ и walk-forward анализ в MT4 и MT5 — он покажет, устойчивы ли параметры вне периода оптимизации. Итогом приёмки становится отчёт: журнал теста, сверка по пунктам, список замечаний.

Поставка, поддержка и итоговый чек-лист

В финале ТЗ зафиксируйте условия поставки: формат — собранные ex4/ex5 или исходный код, этапы оплаты, сроки и объём гарантийных правок. Например, исправления по пунктам ТЗ в течение месяца. Если рассматриваете готовый код, а не разработку с нуля, подсказка — как найти исходный код советника на MQL-Files.

Перед отправкой ТЗ пройдитесь по чек-листу: от названия до места запуска.

• название советника и терминал: MT4 или MT5;
• идея и логика: инструмент, таймфрейм, привязка сигнала к бару;
• параметры с именами, единицами и значениями по умолчанию;
• риск на сделку, стоп-лосс, тейк-профит, лот, время работы;
• проскальзывание, реквоты и поведение при ошибках исполнения;
• каналы оповещений (push/e-mail) и интерфейс, если нужны;
• критерии приёмки и тест на истории;
• формат поставки, этапы оплаты, гарантийные правки;
• место запуска робота — VPS для бесперебойной работы советника.

Если ТЗ получилось большим и дорогим, сравните разработку с нуля с альтернативой — готовые советники для MT5: иногда дешевле адаптировать готовое решение под свою стратегию. Планируете работу в обоих терминалах — заранее заложите в документ это требование, изучив совместимость и перенос MQL4 ↔ MQL5. Итог: один документ, по которому исполнитель сдаёт работу, а вы принимаете её без споров.