Обсуждение статьи "Как заказать написание советника и получить желаемый результат" - страница 5

 
TheXpert:

От автора "к размышлению перед заказом 14" и "к размышлению перед заказом 15" ))

Гыгы, а я и не заметил )

 

abolk:

Андрей, вы действительно хотите обсудить статью, или "как всегда"?

  1. Составление алгоритма было несколькими разделами раньше, и именно там рекомендовалось нумеровать пункты для легкого к ним доступа.
  2. Если читают "тэ-три", не сокращайте.
  3. Логи совсем не обязательно слать все, поэтому информация об условиях проверки актуальна.
  4. Адрес сервера часто обязателен для проверки, т.к. у разных брокеров разные торговые условия и проблема может не воспроизвестись на MQ-Demo.
  5. Версия терминала тоже важна, новую функциональность вносят в оба МТ до сих пор. А некоторые заказчики могут сидеть на 509 или еще каком-то билде, нет смысла гадать, нужно просто это знать.
  6. Если заказчик обламывается дать данные для решения его проблемы, ему ничего не поможет. Вы 3 раза угадаете, в чем у него проблема, а на 4-й не сможете, и будете "плохим программистом".

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

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

TheXpert:
А напиши лучше. или предложи альтернативу.

 

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

 
denkir:

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

Недавно еще раз обсуждали эту тему в похожей ветке.

Я считаю, что достойный исполнитель своего заказчика найдет. Но высказывались разные мнения )

 

ps: тю, так вместе и обсуждали

 
Добрый вечер. Скажите, если я включу непосредственно в файл технического задания информацию об оговоренном между мной и программистом сроке выполнения работы (сроком считаю момент получения мной готового советника, а не макета, разумеется), то могу ли я использовать эту информацию как способ аннулировать заказ через арбитраж в случае невыполнения работы в срок? Также в ТЗ могу внести информацию о том, что буду, например, ежедневно (минимум раз в день) выходить на связь для ответов на все вопросы программиста и т. д. и т. п. То есть, короче говоря, если я создам свой маленький регламент непосредственно в ТЗ, защищающий как мои права, так и права программиста, естественно, оговорив это с программистом (логично, он ведь должен прочесть файл ТЗ), может ли это стать правовой основой для моей защиты? Ну вот честно, устал от тех, кто говорит одно, а делает другое... Ведь по сути программист обязан внимательно изучить ТЗ, перед тем как соглашаться на условия заказчика, и если ему что-то не понятно или кажется невозможным, то он обязан говорить об этом сразу, в процессе изучения ТЗ, а не в процессе выполнения. Опять же я могу это тоже включить в свой регламент. Вопрос лишь в том, не будет ли создание своего регламента расцениваться сервисом как нечто неправомерное? Как показывает практика, большинство программистов соглашаются выполнить работу на любых условиях, просто чтобы сказать заказчику то, что он хочет услышать, и получить согласие на выполнение работы. Я устал сливать деньги на таких программистов. Жду ответа на вопрос. Спасибо. 
 
Eduard Minosian:
Достаточно в одной ветке задавать вопрос.
 
Andrey Khatimlianskii:
Помните! Программист не отвечает за прибыльность вашей стратегии, его задача - написать программу, которая будет работать по утвержденному вами алгоритму.
100%
 
Eduard Minosian:
Добрый вечер. Скажите, если я включу непосредственно в файл технического задания информацию об оговоренном между мной и программистом сроке выполнения работы (сроком считаю момент получения мной готового советника, а не макета, разумеется), то могу ли я использовать эту информацию как способ аннулировать заказ через арбитраж в случае невыполнения работы в срок? Также в ТЗ могу внести информацию о том, что буду, например, ежедневно (минимум раз в день) выходить на связь для ответов на все вопросы программиста и т. д. и т. п. То есть, короче говоря, если я создам свой маленький регламент непосредственно в ТЗ, защищающий как мои права, так и права программиста, естественно, оговорив это с программистом (логично, он ведь должен прочесть файл ТЗ), может ли это стать правовой основой для моей защиты? Ну вот честно, устал от тех, кто говорит одно, а делает другое... Ведь по сути программист обязан внимательно изучить ТЗ, перед тем как соглашаться на условия заказчика, и если ему что-то не понятно или кажется невозможным, то он обязан говорить об этом сразу, в процессе изучения ТЗ, а не в процессе выполнения. Опять же я могу это тоже включить в свой регламент. Вопрос лишь в том, не будет ли создание своего регламента расцениваться сервисом как нечто неправомерное? Как показывает практика, большинство программистов соглашаются выполнить работу на любых условиях, просто чтобы сказать заказчику то, что он хочет услышать, и получить согласие на выполнение работы. Я устал сливать деньги на таких программистов. Жду ответа на вопрос. Спасибо. 

Вот ведь какой парадокс:

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

1. Вас не устраивает, что я выбираю программиста из нескольких программистов.

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

3. Вы хотите с кем-нибудь о чем-нибудь поболтать.

4. Вы не умеете укладываться в сроки, которые называете. 

https://www.mql5.com/ru/job/38355 

А выбора-то ведь и нет.
 
Eduard Minosian:
Добрый вечер. Скажите, если я включу непосредственно в файл технического задания информацию об оговоренном между мной и программистом сроке выполнения работы (сроком считаю момент получения мной готового советника, а не макета, разумеется), то могу ли я использовать эту информацию как способ аннулировать заказ через арбитраж в случае невыполнения работы в срок? Также в ТЗ могу внести информацию о том, что буду, например, ежедневно (минимум раз в день) выходить на связь для ответов на все вопросы программиста и т. д. и т. п. То есть, короче говоря, если я создам свой маленький регламент непосредственно в ТЗ, защищающий как мои права, так и права программиста, естественно, оговорив это с программистом (логично, он ведь должен прочесть файл ТЗ), может ли это стать правовой основой для моей защиты? Ну вот честно, устал от тех, кто говорит одно, а делает другое... Ведь по сути программист обязан внимательно изучить ТЗ, перед тем как соглашаться на условия заказчика, и если ему что-то не понятно или кажется невозможным, то он обязан говорить об этом сразу, в процессе изучения ТЗ, а не в процессе выполнения. Опять же я могу это тоже включить в свой регламент. Вопрос лишь в том, не будет ли создание своего регламента расцениваться сервисом как нечто неправомерное? Как показывает практика, большинство программистов соглашаются выполнить работу на любых условиях, просто чтобы сказать заказчику то, что он хочет услышать, и получить согласие на выполнение работы. Я устал сливать деньги на таких программистов. Жду ответа на вопрос. Спасибо. 

100% можете, я бы включал обязательно

Вот я очень принципиально и внимательно отношусь к времени исполнения задачи

и хоть у меня всего 4 задачи исполнены я ни разу не влетал на просрочку и не собираюсь влетать

- по крайней мере по своей вине не должен попасть


--

есть  обратная сторона луны

сразу оговорюсь лично  у меня такой ситуации не случилось еще

1 заказчик выбрал исполнителя

2 Оговорили  ТЗ  - сумму и срок оговорили  - допустим срок поставили 1 день

3 Программист начала работу - и завершил ее через час - и через сервис оповестил заказчика

4 Далее происходит любой из сценариев , заказчик занят , уехал на дачу , ушел в отпуск.

   Не важна причина ,  он не ответил к вечеру не ответил утром и вечером  второго дня и вообще на 3 дня пропал.

итог программист попадает на просрочку работы

--

Кстати обратная сторона луны  - заказчик попадает на программиста который не исполняет работу вовремя

---

и такие случаи нередки судя по  профилям фрилансеров

--

Правильно будет разделить учет времени ЗАКАЗЧИКА и ИСПОЛНИТЕЛЯ

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

 
Eduard Minosian:
Добрый вечер. Скажите, если я включу непосредственно в файл технического задания информацию об оговоренном между мной и программистом сроке выполнения работы (сроком считаю момент получения мной готового советника, а не макета, разумеется), то могу ли я использовать эту информацию как способ аннулировать заказ через арбитраж в случае невыполнения работы в срок? Также в ТЗ могу внести информацию о том, что буду, например, ежедневно (минимум раз в день) выходить на связь для ответов на все вопросы программиста и т. д. и т. п. То есть, короче говоря, если я создам свой маленький регламент непосредственно в ТЗ, защищающий как мои права, так и права программиста, естественно, оговорив это с программистом (логично, он ведь должен прочесть файл ТЗ), может ли это стать правовой основой для моей защиты? Ну вот честно, устал от тех, кто говорит одно, а делает другое... Ведь по сути программист обязан внимательно изучить ТЗ, перед тем как соглашаться на условия заказчика, и если ему что-то не понятно или кажется невозможным, то он обязан говорить об этом сразу, в процессе изучения ТЗ, а не в процессе выполнения. Опять же я могу это тоже включить в свой регламент. Вопрос лишь в том, не будет ли создание своего регламента расцениваться сервисом как нечто неправомерное? Как показывает практика, большинство программистов соглашаются выполнить работу на любых условиях, просто чтобы сказать заказчику то, что он хочет услышать, и получить согласие на выполнение работы. Я устал сливать деньги на таких программистов. Жду ответа на вопрос. Спасибо. 

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

 

Здравствуйте. 

Порядок рассмотрения обращений в Арбитраж

-----

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

_________________________________

Прошу помочь и понять. Срок 10 дней с какого момента начинается данный срок

 

Доброго времени суток!

Думаю для новичка Визуализационный чек -лист сделать и в некоторых подпунктах как говориться по народному объяснить,выделить основные пункты потому как не все читают,а Британские ученые довели что визуально лучи к восприятию чем само чтение!!!

(То что сразу пришло на ум для улучшения вашей миссий между трейдером и программистом)