Нужен ли Арбитраж качества кодинга? - страница 7
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Практически каждый заказчик уверен в индивидуальности собственной ТС и уверен в её граальности. Слив из-за обыденности их ТС вызовет протест в сторону исполнителя в любом случае. Желаемый продукт для них - тот, что зарабатывает. А тут слив. Кто виноват? Мля... конечно исполнитель!!! И начнётся обливание грязью исполнителя, что не прибавит ему хорошей статистики.
А если заказчика обучить делать грамотное ТЗ, тогда ему не нужен будет программист, сам сможет. Мне думается, чтобы иметь достаточно заказчиков, нужно создавать программы несливающие в любых условиях, если, конечно, возможно это! Тогда заказчик с удовольствием превратился бы в покупателя!
Я совсем не понимаю, почему у Вас такое суждение о людях? Если слив из-за того, что советник затупил при реквотах, то может и программер виноват...
Как тут уже говорили на форуме, не все программисты имеют достаточный опыт торговли, что б представлять большинство возникающих ситуаций на рынке, а трейдеры не все представляют нюансы работы программы, вот я и предлагаю навести в этом вопросе порядок...
Люди всякие бывают. Заказчики тоже. Впрочем, и исполнители...
Кстати: советник затупил при реквотах - а в ТЗ было оговорено его конкретное поведение при получении реквоты? Есть какое-то стандартное поведение при обработке ошибок. Такое, чтобы не навредить. И нужно всё же обговорить конкретно ситуацию, иначе программист сделает свою обработку. Нет, не нужно?
Мы не телепаты. Пытаемся всё же договориться о множестве ситуаций. Знаете что в ответ? В основном: Делайте на своё усмотрение. А потом не окажется, что "своё усмотрение" программиста не совпало с "усмотрением заказчика"? Ему, оказывается нужно было сервер задолбить запросами при реквотах, да ещё и всем депом, чтоб наконец открыть позицию в любом случае и раскладе. И начинаются претензии.
Заметьте, в основном открытие таких вот веток инициировано заказчиками. Всё-то им не так... А исполнители только и успевай: "Не вопрос, переделаю"...
В своём большинстве заказчики пугаются, когда начинаешь задавать уточняющие вопросы, по одной простой причине - они не имеют достаточной мотивации(знаний). Поэтому лично мне проще сделать в рамках ТЗ всё на своё усмотрение. А вот когда(если) человек получает не то, что ему хотелось видеть, резко возбуждается активность мозга и желание дать ПОНЯТНЫЕ объяснения, как всё должно работать. Точка отсчёта нормального обсуждения - готовый макет, иначе мотивация не та у заказчика...Дальше необходимые правки - и все в итоге довольны. Иногда подход даёт сбои, но в 99% случаев работает. И да, время кодирования немного увеличивается, но невероятно сокращается время, потраченное на бесполезные обсуждения ни о чём.
... нужно создавать программы несливающие в любых условиях, если, конечно, возможно это!
Легко!
Не надо открывать позиции! Всего лишь!
Люди всякие бывают. Заказчики тоже. Впрочем, и исполнители...
Кстати: советник затупил при реквотах - а в ТЗ было оговорено его конкретное поведение при получении реквоты? Есть какое-то стандартное поведение при обработке ошибок. Такое, чтобы не навредить. И нужно всё же обговорить конкретно ситуацию, иначе программист сделает свою обработку. Нет, не нужно?
Мы не телепаты. Пытаемся всё же договориться о множестве ситуаций. Знаете что в ответ? В основном: Делайте на своё усмотрение. А потом не окажется, что "своё усмотрение" программиста не совпало с "усмотрением заказчика"? Ему, оказывается нужно было сервер задолбить запросами при реквотах, да ещё и всем депом, чтоб наконец открыть позицию в любом случае и раскладе. И начинаются претензии.
Заметьте, в основном открытие таких вот веток инициировано заказчиками. Всё-то им не так... А исполнители только и успевай: "Не вопрос, переделаю"...
По поводу инициативы я придерживаюсь правила "Клиент всегда прав", ну а если он не прав, то надо ему в этом дать убедиться.
Если по существу, то я согласен с Вашими суждениями, поэтому уже в который раз говорю о том, что заказчик должен дать в ТЗ ответ на максимум возникающих ситуаций при использовании торгового робота.
Поэтому логично было бы разработать общий опросник, где и указывалось бы какие моменты должен проработать заказчик и дать четкий ответ на них, а если не понятно, то спросить. Более того, ответы на эти вопросы позволили бы более трезво формировать стоимость работ, в итоге получился бы стандартный объем работ (по данным опросника) и работа логики советника в части исполнения самого ТЗ (но отвечающая заданными критериями заказчика). Тут по первой части работ можно и прайс открытый размещать и скидки делать - рекламировать себя, да и риски будут снижены как для заказчика, так и для исполнителя.
Если по существу, то я согласен с Вашими суждениями, поэтому уже в который раз говорю о том, что заказчик должен дать в ТЗ ответ на максимум возникающих ситуаций при использовании торгового робота.
Вот хорошая статья -- https://www.mql5.com/ru/articles/235. Считаете в ней чего-то не хватает? Тогда напишите, чего. Или скажите автору.
Опередил :)
Причем она прибита на довольно видном месте, вот только все считают себя гуру составления ТЗ и никогда ее не читают.
ЗЫ. блин, исправил ошибку в названии темы - слетели результаты голосования. сорри :(
Вот хорошая статья -- https://www.mql5.com/ru/articles/235. Считаете в ней чего-то не хватает? Тогда напишите, чего. Или скажите автору.
Спасибо за ссылку, я конечно знакомился с данной статьей, но она не отвечает на вопросы поднятые в этой ветке:
1. Качество кода
2. Особенности торговли при использовании советника.
Опередил :)
Причем она прибита на довольно видном месте, вот только все считают себя гуру составления ТЗ и никогда ее не читают.
ЗЫ. блин, исправил ошибку в названии темы - слетели результаты голосования. сорри :(
1/3 была за.
Можно тогда Вас попросить добавить ответы:
"
Да, я чаще Исполнитель работ
Нет, я чаще Исполнитель работ
Да, я чаще Заказчик работ
Нет, я чаще Заказчик работ
"
Спасибо.
Спасибо за ссылку, я конечно знакомился с данной статьей, но она не отвечает на вопросы поднятые в этой ветке:
1. Качество кода
2. Особенности торговли при использовании советника.
1/3 была за.
Можно тогда Вас попросить добавить ответы:
"
Да, я чаще Исполнитель работ
Нет, я чаще Исполнитель работ
Да, я чаще Заказчик работ
Нет, я чаще Заказчик работ
"
Спасибо.
Сейчас 1/4 за (1 из 4 заново проголосовавших).
От себя лично: Нет, я не Заказчик и, тем более, не Исполнитель. И не чаще ни реже! ;)