Несколько советов для начинающих заказчиков

Введение

Народная мудрость, авторство которой часто приписывают различным известным людям, говорит: "Тот не ошибается, кто ничего не делает". Если не считать само ничегонеделание тоже ошибкой, то с этим утверждением трудно спорить. Зато вполне возможно проанализировать ранее совершенные ошибки (свои и чужие) и свести к минимуму количество совершаемых ошибок в будущем. Сделаем попытку разобрать возможные ситуации, возникающие в процессе выполнения работ на одноименном сервисе.

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

1. А зачем вообще он нужен, этот сервис Работа?

Пользоваться сервисом Работа или не пользоваться - каждый решает самостоятельно. Мое мнение однозначно: пользоваться. Далее, несколько соображений на этот счет. Если рассматривать основные проблемы, которые могут возникнуть в процессе взаимодействия заказчик - исполнитель, то можно выделить следующие:

• Нечеткое или неоднозначное для понимания техническое задание (ТЗ) и результат этого - исполнитель делает совсем не то, что ожидает от него заказчик;
• Опасения заказчика, что его обманет исполнитель - возьмет предоплату и работу не выполнит или выполнит частично;
• Опасения исполнителя, что его обманет заказчик - получит выполненную работу и не отдаст оставшуюся часть оплаты;
• Возникновение спорных ситуаций (очень часто тупиковых) - каждый на 100% убежден в своей правоте, и искать компромиссное решение ни в коем случае не желает.

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

Итак, вы все-таки решили воспользоваться сервисом Работа и заказать разработку или модификацию индикатора, эксперта или скрипта. Предполагается, что вы начали с того, что ознакомились со следующим документом: Правила использования сервиса 'Работа'. А если вы этого еще не сделали - самое время восполнить этот небольшой пробел в знаниях.

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

2. Распространенные виды заказов

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

2.1. Форекс - это очень просто

Заказчик, который сам точно не понимает, что он хочет и как конкретно должно все это работать. Как правило, это совсем новички на форексе, нахватавшиеся поверхностных знаний и решившие, что форекс - это очень просто. Увидев удачный участок графика с двумя пересекающимися МА, и добавив, до кучи, MACD (не понимая даже, что это собственно, те же самые две линии МА) - человек решает, что торговая система найдена, и осталось только закодировать ее в виде "сова" и начинать "косить бабло".

Заявки таких заказчиков выглядят примерно так: "Простой советник", "Простой индикатор" и другие вариации со словами "простой" и "несложный". Соответственно, предлагается и плата за работу - 10-20 кредитов. Меньше поставить не дает сам сервис.

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

2.2. В дебрях индикаторов

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

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

Приведем пример такого совмещения индикаторов. Возьмем RSI с нормированным диапазоном от 0 до 100 и ATR с ненормированным диапазоном (от 0 до неизвестно какой величины, существенно меньшей единицы). Будем входить в BUY, когда ATR пересечет RSI снизу вверх на следующем баре. На картинке ниже (рис.1) серым прямоугольником показан появившийся сигнал на покупку.

Отметим его вертикальной пунктирной линий и посмотрим, что будет дальше.

Рис. 1. Есть сигнал на покупку (BUY)

На следующей картинке (рис. 2) видим, что сигнал на покупку есть, даже стал сильнее, но, почему-то слегка сдвинулся влево (положение вертикальной пунктирной линии у нас не меняется на временной оси). Получается, что надо было входить раньше. Что-то здесь не так.

Рис. 2. Сигнал на покупку (BUY) по-прежнему есть

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

Рис. 3. А вот его уже нет

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

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

2.3. Автоматизировать ручную систему

Один из наиболее сложных вариантов. Человек может торговать давно и прибыльно, но, при попытках формализовать свою систему в виде алгоритма, встает в тупик. Либо начинает описывать каждый бар графика с конкретизацией значений цен и значений индикаторов. Это происходит из-за того, что при торговле используется интуиция, т.е. скрытая на подсознательном уровне обработка торговой информации с выдачей только конечного результата. Как этот результат получился, он и сам точно не знает.

Если не получается формализовать систему, то оптимальный вариант - поэтапная автоматизация торговли. Любая система состоит из стандартных элементов (открытие/закрытие позиций/ордеров, контроль рисков, ведение позиций и т.д.). Разбейте работу на этапы и выполняйте каждый этап как отдельный. Постепенно, шаг за шагом, может получиться почти полная автоматизация торговли.

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

2.4. Чтобы советник чай готовил

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

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

2.5. Сделай то, не знаю что

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

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

3. Какое оно, идеальное ТЗ?

Если рассматривать структуру технического задания на некоторую абстрактную разработку, то идеальное ТЗ можно представить примерно следующим образом:

3.1. Среда для работы

На каком терминале (MetaTrader 4/MetaTrader 5) требуется разработка. Самое важное обычно забывают указать в ТЗ и даже в теме заказа. В теме заказа это нужно указать потому, что не все разработчики освоили язык MQL5. Или наоборот, пропустили изучение MQL4 и сразу взялись за MQL5.

3.2. У какого ДЦ/Брокера предполагается использовать разработку

Это нужно знать, в основном, при разработке экспертов (или торговых скриптов). Могут быть различные нюансы: при исполнении ордеров, размеров минимальных/максимальных лотов, переносе позиций через ночь, количество знаков в котировках, валюта счета, идут ли котировки в субботу/воскресенье и надо ли их обрабатывать, спред фиксированный или плавающий, работать по открытию нового бара или по тикам и т.д.

Лучше всего, если заказчик откроет демо-счет у своего ДЦ/Брокера с предполагаемой валютой счета и предоставит его разработчику. Это нужно потому, что процедура открытия даже демо-счета в некоторых ДЦ (например, Oanda) требует регистрации на сайте с заполнением анкет и т.д. Экономьте время разработчика. Оно может понадобиться при отладке и тестировании работы.

3.3. Предполагается использовать разработку для реального счета или только для тестирования/демо-счета

На самом деле, разница принципиальная. Если для теста важна, прежде всего, скорость работы (от этого зависит время оптимизации), то для работы на реальном счете важна обработка ошибок и восстановление корректного состояния эксперта при различных сбоях связи, перезагрузках терминала и т.п. При этом скорость тестирования эксперта для реального счета может замедлиться в несколько раз, а то и в несколько десятков раз. Опять-таки, это существенно влияет на стоимость разработки в ту или иную сторону.

Здесь нужно ответить себе на вопрос - а действительно ли мне нужен советник для реального счета? Если разработка экспериментальная и алгоритм еще не определен окончательно и будет меняться и перерабатываться, то нет никакого смысла заказывать для реального счета. Более того, это еще и вредно, так как оптимизация может идти существенно медленнее. После отработки алгоритма можно заказать доработку для реального счета. Это будет стоить не слишком дорого.

3.4. Описание алгоритма работы

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

3.5. Желаемый вид информации на экране

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

Если при пояснении алгоритма работы требуются иллюстрации, то это нужно сделать. Рисунком с соответствующими комментариями можно описать алгоритм намного проще и понятнее, чем несколькими страницами текста.

3.6. Разное

Здесь обычно пишутся общие условия и требования. Это может быть требование передачи исходного текста (кода) после завершения последнего этапа работы, расширенные комментарии в исходном тексте, срок бесплатного гарантийного исправления ошибок и другие требования.

4. Немного про отладку и проверку

На этом этапе проверяется соответствие реально выполняемых индикатором или экспертом функций и перечня функций, прописанных в ТЗ. Как известно, один из законов Мэрфи для программирования гласит: в каждой программе содержится хотя бы одна ошибка. Отсюда есть еще и следствие: каждая найденная и исправленная ошибка является предпоследней. Это, конечно, шутка, но для сложных программ (и экспертов и индикаторов) этот "закон" недалек от истины.

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

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

Понятие сложности/простоты, конечно, субъективно и во многом зависит от опыта исполнителя и понимания всех нюансов работы заказчиком. Способы и методы проверки, предоставляемые терминалами MetaTrader 4 и MetaTrader 5, весьма разнообразны. Настолько, что некоторые заказчики даже не подозревают (или забывают - было и такое в моей практике) о существовании такой возможности, как исполнение эксперта на исторических данных в тестере. А главное - наличие визуального режима работы тестера.

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

Далее, после проверки в тестере, можно убедиться окончательно в работоспособности эксперта, запустив его на демо-счете. Обычно, полутора суток работы в реальном времени на демо-счете достаточно для полной проверки. Если, конечно, не используются очень крупные таймфреймы (неделя и более).

5. Описание найденных ошибок

Отдельно хочется сказать про оптимальный вид описания найденной заказчиком ошибки. Если говорить о крайних случаях того, как не надо описывать ошибку, то это выглядит примерно так: "Ваш эксперт не работает, должно было открыться много сделок, а не было ни одной".

Исполнителю остается только догадываться о том, что же происходило в терминале у заказчика - на каком инструменте, таймфрейме, задаваемых параметрах и т.д.

На мой взгляд, лучше всего описывать найденную ошибку/неточность с использованием графической картинки. Терминалы MetaTrader 4 и MetaTrader 5 позволяют сохранять график в виде файла с картинкой. МТ4 - в формате GIF и BMP, а МТ5 - еще и в формате PNG. PNG-формат является предпочтительным, т.к. полностью сохраняется четкость картинки.

В терминале МТ4 это выглядит примерно так, как показано на рисунке ниже (рис. 4). Для этого нужно кликнуть правой кнопкой мыши на нужном графике в терминале и появится всплывающее меню.

Рис. 4. Сохранение образа графика в файле

В терминале МetaТrader 5 это делается точно также - выбирается такая же команда меню Сохранить как рисунок, только само меню несколько отличается по набору команд.

После выбора команды меню, появится дополнительное окно диалога для выбора разрешения и области сохраняемой картинки. Это показано ниже на рис. 5:

Рис. 5. Задание параметров сохраняемой картинки

Чтобы сохранить только образ окна с графиком, нужно выбрать опцию Активный график (как есть). Если выбрать опцию Активная рабочая область, то сохранится образ всего окна терминала. Иногда это бывает полезно, когда нужно показать несколько графиков одновременно.

Разрешение активного графика изменять не рекомендуется, т.к. это может ухудшить разборчивость сохраненной картинки.

Для получения картинки также можно воспользоваться сочетанием клавиш Alt+PrtScr или просто PrtScr, что позволяет сохранить графический образ текущего окна или всего экрана в буфере обмена и затем получить его в каком-либо графическом редакторе.

Далее, можно открыть получившийся графический файл в графическом редакторе и отредактировать (если нужно) - например, добавить текстовые пояснения предполагаемой ошибки в нужных местах графика. Для редактирования проще всего использовать встроенный редактор Paint, идущий в составе Windows. Впрочем, это уже дело вкуса и привычки.

6. Скрытые "ловушки" в ТЗ

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

Если обратиться к образности народного творчества, то часто заказчик при написании ТЗ рассматривает поведение "сферического коня в вакууме" вместо реального валютного или финансового рынка. То есть, идеализирует поведение ценового ряда до предела.

6.1. Дискретность изменения цены

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

Единственная "мелочь", которая здесь упущена из виду, - что цена "ходит" по графику дискретно (от точки к точке), а не непрерывно. Даже если мы включим опцию в терминале График в виде ломаной линии и увидим эту линию на экране, это не превратит ход цены в непрерывный. Все равно, реальный ценовой ряд графика будет состоять из дискретных точек.

Можно проиллюстрировать это рисунком тикового графика (примерный вид).

Рис. 6. Дискретное изменение цены

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

Итак, хотя мы видим, что вроде бы цена и достигла заданного уровня, но строго выполняя написанное в ТЗ, условие ни разу не было выполнено. Чтобы привести идеалистическое представление о цене, заложенное в ТЗ, в соответствие с реальностью, нужно сделать следующее - добавить к уровню две границы, сверху и снизу. На рисунке они показаны пунктирными линиями. Размер этих границ зависит от конкретной торговой системы. В большинстве случаев, достаточно 2-3 размера от среднего спреда.

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

Вернемся к нашему ТЗ. Исправим его таким образом: когда цена достигает заданного внешним параметром значения плюс/минус дельта, то открыть позицию на покупку. Теперь намного лучше.

Второй момент связан с тем, что в любую секунду может пропасть связь с сервером брокера. За время до восстановления связи цена может "гулять" как выше, так и ниже заданного уровня на любом расстоянии. На рисунке эта область (отсутствия связи с сервером брокера) показана розовым прямоугольником. Очевидно, что такая ситуация также должна учитываться в ТЗ.

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

6.2. Точное срабатывание в заданное время

Читаем в ТЗ: в заданное внешним параметром время установить два отложенных ордера на покупку и продажу на заданном расстоянии от цены. Здесь нужно разделять два типа терминалов - МТ4 и МТ5. Если в терминале MetaTrader 5 возможно использование таймера с минимальной дискретностью в одну секунду и с такой же точностью отсчитывать время, то в языке MQL4 терминала MetaTrader 4 таймер  отсутствует.

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

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

6.3. Использование терминов глобального масштаба

Характерный пример: когда на рынке флет, выполнить такие-то действия. При наступлении тренда, сделать то-то. При этом заказчик полагает, что уж запрограммировать понятия тренд/флет это настолько простая задача, что не стоит на ней останавливаться подробней. Думаю, комментарии здесь излишни.

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

6.4. Использование бытовых терминов

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

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

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

7. Так когда же обращаться в арбитраж?

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

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

Еще один возможный вариант - "пропадание" исполнителя или заказчика на длительное время. Не отвечает ни на личные сообщения, ни на почту и т.п. При этом деньги заказчика заблокированы на счету, работа не сделана. Или, наоборот, - работа давно сделана, но нет возможности получить оплату. Обстоятельства в жизни могут быть разные, но, тем не менее, ситуация должна и может быть разрешена с помощью арбитража.

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

Заключение

Надеюсь, что данная статья оказалась полезной для начинающих пользователей сервиса Работа. Главным образом, для начинающих заказчиков. Наверняка, в статье рассмотрены не все вопросы, но дорогу осилит идущий. Можно только пожелать быть терпимее друг к другу и поменьше выплескивать негативных эмоций в окружающий нас мир - лучше от этого не станет никому - ни заказчику, ни исполнителю.

Список излюбленных вопросов, задаваемых заказчиками

1. Почему некоторые исполнители не хотят общаться по скайпу, icq, телефону, e-mail и т.п.?

Думается, основных причин две:

Во-первых, исполнитель один, а заказчиков много, и если со всеми общаться в режиме онлайн (хорошо, если не одновременно), то непосредственно на программирование заказа времени почти не останется. Это только кажется, что по скайпу или icq можно все объяснить быстрее - один из распространенных мифов.

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

2. Почему при запуске скомпилированного эксперта/индикатора (файл с расширением ex4, ex5) терминал закрывается?

Скорей всего, ваша версия терминала устарела по сравнению с версией, использованной при компиляции. Следует обновить терминал на последнюю из доступных версий.

3. Что за ошибки возникают при компиляции файла эксперта/индикатора - Function 'xxxxxx' is not referenced and will be removed from exp-file?

Это не ошибка. Сообщение говорит о том, что функция 'xxxxxx' не используется (на месте 'xxxxxx' указывается конкретное название функции) и в скомпилированном файле ее не будет. Можно не обращать на это сообщение внимания - на работе эксперта или индикатора присутствие такой "лишней" функции никаким образом не сказывается.

4. Что за ошибка возникает при компиляции файла эксперта/индикатора - can't open "хххххх" include file?

Сообщение говорит о том, что при переносе файлов на компьютер либо файл "хххххх" не был скопирован, либо скопирован не в ту директорию. Обычно, файлы с расширением mqh следует размещать в директории include терминала.

5. Почему при работе эксперта не ставятся значки, где было закрытие позиции по тейк-профиту/стоп-лоссу?

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

6. Позиция не открылась (ордер не был установлен), хотя на историческом графике есть все условия для входа?

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

7. Как отменить работу на этапе Прототип/Макет - Демонстрация?

Отменить можно только обратившись в Арбитраж.

Список ссылок, рекомендуемых к просмотру

1. Правила использования сервиса 'Работа'
2. Как заказать написание советника и получить желаемый результат
3. Как заказать торгового робота на MQL5 и MQL4