ТЗ (техническое задание) для советника. Все, что важно об этом сказать

[Elvis Burunduk]

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

Вот примерно такого ответа я и ждал.... Это очень сложный процесс , согласование ТЗ и что бы мы с заказчиком пришли к консенсусу ..
1) Прогеры изначально думают про заказчика = заказчик тупой и пишет ... фигню.... Да еще по пути забывает описать многие изменения... (Ну это так и есть ... Грустно...).
2) Заказчик думает = прогер это изначально тупой прогер и неторгующий, и не может понять широту моей мысли и т.д...

 

[megapont]

Допустим, открытие Buy если CCI вышел из перепроданности, при условии что цена выше EMA и выше SAR.
Все значения индикаторов и цены для сравнения берутся с сформированного бара, что бы избежать влияние перерисовки индикаторов. Сделка открывается только если нет открытой сделки советника того же направления.

Автоматизированная механика не работает.

 

[Corey Hate]

Автоматизированная механика не работает.

Можно подумать, что механизированная автоматика работает.))

 

[Ugar]

Задам тогда еще вопрос: "Что чаще всего вы, товарищи программисты, дорабатывает уже после того, как все сделали?"
О чем надо напоминать заказчику?

Все программисты пишут что запрограммировано будет только то что описано в ТЗ. Это понимают программисты, но что это значит, не всегда понимают заказчики. Иногда, трейдер даже не задумывается о нюансах торговли, о которых знает только он. Для него это само собой. Но если он не задумывается о нюансе, то и в ТЗ забудет написать. А программист не экстрасенс, не может знать то что не описано в ТЗ?
Когда то смотрел старый фильм "короткое замыкание". Я поржал от души, когда робот готовил амлет, воспринимая рецепт из кулинарной книги как алгоритм. А ведь это прекрасный пример. Написано разбить яйца в миску, но не написано что надо отделить скорлупу. В миске яйца вместе со скорлупой. Написано взболтать, но не написано как интенсивно. Половина содержимого миски разлетелось по стенам... Человеку эти нюансы, само собой понятны, а робот не мог этого знать.
Программисты прекрасно знают что трейдеры редко могут предусмотреть всё в ТЗ, так как им сложно мыслить как программист. По этому они, обычно, не отказывают в доработках заказчику.
Трейдеры, с опытом заказа программ, знают что надо постараться предусмотреть всё. Так же понимают, если что можно доработкой довести.
Некоторые сразу заказывают недоделанную систему. Основа с возможностью вручную вмешиваться в торговлю. В процессе тестирования и торговли, додумывает нюансы, заказывает дополнения.

 

[Ugar]

Автоматизированная механика не работает.

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

 

[Ugar]

Вот примерно такого ответа я и ждал.... Это очень сложный процесс , согласование ТЗ и что бы мы с заказчиком пришли к консенсусу ..
1) Прогеры изначально думают про заказчика = заказчик тупой и пишет ... фигню.... Да еще по пути забывает описать многие изменения... (Ну это так и есть ... Грустно...).
2) Заказчик думает = прогер это изначально тупой прогер и неторгующий, и не может понять широту моей мысли и т.д...

Оба пункта = мышление тождествами.
Может и есть программисты, считающие заказчиков тупыми, но точно не все. Напротив, программисты как никто знают о тупости компьютеров. Ведь он ничего нового придумать не сможет, а тупо выполняет команды в программе.
Так же много программистов MQL изучили эти языки для программирования своих идей, для собственной торговли, хотя есть и те кто с торговлей совсем не знаком.

 

[Elvis Burunduk]

Ugar , Ugar ты же видишь, я лучше промолчу, чем навредить...

Я чаще молчу..... чем вступать в прерии.... сам же знаешь = потом долго объяснять....

 

[Elvis Burunduk]

@Ugar
Я тебя, как помнишь на пяток лет младше ,
Я и потому молчу насчет отношений между заказчиком и исполнителем..
Возможно так и есть в самом деле ....

 

[megapont]

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

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

 

[Ugar]

Итогом мы все равно получаем полу-автомат.

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

 

[megapont]

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

Просто изначально вопрос был акцентирован на условиях. Сколько их по опыту. И если вы указывали условием 3 индюка (можно 4 или 5, не суть) то по идее, вы не сталкивались с ТЗ содержащим временные или количественные фильтры.

 

[Ugar]

Просто изначально вопрос был акцентирован на условиях. Сколько их по опыту. И если вы указывали условием 3 индюка (можно 4 или 5, не суть) то по идее, вы не сталкивались с ТЗ содержащим временные или количественные фильтры.

С чего Вы взяли что я не сталкивался? Наверное Вы новичок. Так как именно новичкам приходит в голову что они придумали что то уникальное, с чем никто не сталкивался. Эта мания величия со временем проходит. Сам когда то давно переболел этим.
Это я привёл пример как описывать условия. Придумал его за секунды. А вот заказчик должен подумать над тем что заказывает подольше. Условий может быть много и они могут быть разными. Но описаны они должны быть конкретно, что бы невозможно было их толковать неоднозначно. Именно так было описано эти 3 условия.

Вообще всё в ТЗ должно быть описано так же конкретно. Следует избегать сленгов, которые часто разными трейдерами понимаются по разному. Некоторые думают что написав "сетка ордеров", программист уже всё понял. Сеток много разных. Опытный программист сразу попросит описать подробно как это должно работать. А некоторые заказчики подумают что программист тупой, не знает элементарных вещей. На самом деле программист уже писал сотни разных сеток и его интересует какую именно надо заказчику.

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

 

[AlexeyVik]

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

Я бы сказал подробного не описания, а понимания его работы. Именно как заказчик это понимает. А зачастую он этого и близко не понимает.

 

[MrGreen86]

Задам тогда еще вопрос: "Что чаще всего вы, товарищи программисты, дорабатывает уже после того, как все сделали?"
О чем надо напоминать заказчику?

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

 

[megapont]

С чего Вы взяли что я не сталкивался? Наверное Вы новичок. Так как именно новичкам приходит в голову что они придумали что то уникальное, с чем никто не сталкивался. Эта мания величия со временем проходит. Сам когда то давно переболел этим.
Это я привёл пример как описывать условия. Придумал его за секунды. А вот заказчик должен подумать над тем что заказывает подольше. Условий может быть много и они могут быть разными. Но описаны они должны быть конкретно, что бы невозможно было их толковать неоднозначно. Именно так было описано эти 3 условия.

Вообще всё в ТЗ должно быть описано так же конкретно. Следует избегать сленгов, которые часто разными трейдерами понимаются по разному. Некоторые думают что написав "сетка ордеров", программист уже всё понял. Сеток много разных. Опытный программист сразу попросит описать подробно как это должно работать. А некоторые заказчики подумают что программист тупой, не знает элементарных вещей. На самом деле программист уже писал сотни разных сеток и его интересует какую именно надо заказчику.

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

Все это теория. Я спросил из практики есть что нибудь в условиях интересное, но вполне решаемое. Я не знаю как еще до вас донести мысль. Мы тут просто общаемся. Мне не интересно выяснять тут чей то профессионализм или круть. И я могу быть не просто новичком, а наглухо сопливым дрыщем. Если вам так будет комфортней.
Блин в первом посту у меня все понятно.
Практику давайте.

 

[Genry_05]

... Хотела бы, чтобы подключились программисты с опытом и поделились мнением, какое тз они предпочитают видеть? Что должно быть прописано обязательно? Что не обязательно, но желательно? Насколько важно техническое задание и прочие вопросы давайте поднимем. Упростим жизнь всем.

Увидел начало обсуждения пару-тройку дней назад и дал две ссылки на статьи по теме. Сегодня с удивлением обнаружил что сообщение потерли. Сразу стало лениво что-то обсуждать, но и пропавшего сообщения тоже жаль - может кому-то информация будет полезна.
Вот заголовки статей без ссылок:
1. Статья Andrey Khatimlianskii (Компостер) от 30 марта 2011
"Как заказать написание советника и получить желаемый результат"
2. "Как составить Техническое Задание при заказе индикатора" от 8 марта 2018
И еще … если есть желание учесть чужой опыт, то имеет смысл посмотреть разделы фриланса для программистов. Подобные разделы есть на сайтах и для mql-программистов. Люди оптимизируют свою работу, чтобы Заказчик быстрее получил результат, а Исполнитель - вознаграждение, и без ТЗ вероятность конфликта интересов возрастает.

 

[Ugar]

Я спросил из практики есть что нибудь в условиях интересное, но вполне решаемое. Я не знаю как еще до вас донести мысль.

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

 

[Юлия]

Юлия , мои соседи ...один декан физмата , другой зам информатики универа ....они бабочки в твоем животе запрограммируют....что я с ними неоднократно делал .....))))
, ....но как трейдеры они НОООЛЬ , я на спор выигрывал у них ))))))

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

Просто изначально вопрос был акцентирован на условиях. Сколько их по опыту. И если вы указывали условием 3 индюка (можно 4 или 5, не суть) то по идее, вы не сталкивались с ТЗ содержащим временные или количественные фильтры.

Когда условия временные, проще всего самому подучить MQL и не париться. Понятно, что советник не работает точно все время, что есть идеи, они меняются по отношению к рынку.

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

Ой, классно! )) посмеялись всей редакцией

Все это теория. Я спросил из практики есть что нибудь в условиях интересное, но вполне решаемое. Я не знаю как еще до вас донести мысль. Мы тут просто общаемся. Мне не интересно выяснять тут чей то профессионализм или круть. И я могу быть не просто новичком, а наглухо сопливым дрыщем. Если вам так будет комфортней.
Блин в первом посту у меня все понятно.
Практику давайте.

Вам, наверное, надо еще раз вопрос задать. Будет проще.