Обсуждение статьи "Как заказать торгового робота на MQL5 и MQL4" - страница 4

 
Renat:

Пока такой возможности нет, но подумаем над реализацией.

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

Обязательно нужна такая возможность.
 
Renat:

Пока такой возможности нет, но подумаем над реализацией.

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

Понятно. Спасибо за информацию
 
Renat:

Пока такой возможности нет, но подумаем над реализацией.

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

Правильно, когда:

1) исполнитель имеет возможность отказаться от работы
2) исполнитель имеет возможность уменьшить стоимость работы
3) заказчик имеет возможность увеличить стоимость работы

В этапах выполнения работы есть недостаток:

пункт 3.2.7. Правил "После подтверждения шага "Согласование ТЗ" обеими сторонами на счете Заказчика в Платежной Системе блокируется сумма Заказа."

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

Этап "Согласование ТЗ" должен проходить в два этапа:

1. Заказчик подтверждает ТЗ - сумма блокируется.
2. Идёт обсуждение ТЗ и ДО подтверждения эатапа "Согласование ТЗ" исполнителем должна быть возможность: отказаться от ТЗ, изменить стоимость. 

Либо же возможность отказаться от ТЗ Исполнителем и изменение стоимости реализовать на этапе "Прототип/Макет". 

 
abolk:

Правильно, когда:

1) исполнитель имеет возможность отказаться от работы
2) исполнитель имеет возможность уменьшить стоимость работы
3) заказчик имеет возможность увеличить стоимость работы

В этапах выполнения работы есть недостаток:

пункт 3.2.7. Правил "После подтверждения шага "Согласование ТЗ" обеими сторонами на счете Заказчика в Платежной Системе блокируется сумма Заказа."

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

Этап "Согласование ТЗ" должен проходить в два этапа:

1. Заказчик подтверждает ТЗ - сумма блокируется.
2. Идёт обсуждение ТЗ и ДО подтверждения эатапа "Согласование ТЗ" исполнителем должна быть возможность: отказаться от ТЗ, изменить стоимость. 

Либо же возможность отказаться от ТЗ Исполнителем и изменение стоимости реализовать на этапе "Прототип/Макет". 

Подтверждаю, несколько раз на такие грабли наступал, разжевываешь заказчику его собственное ТЗ. Тратишь на это 3-4 дня. Раскладываешь ему всё по полочкам, а он линяет с этим уже раскатанным ТЗ, и заказывает его исполнение за меньшую сумму.

Составить толковое ТЗ львиная доля работы, и эта доля получается не имеет гарантированной оплаты в сервисе "Работа"!!!!

 
papaklass:

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

Вы, как впрочем и другие апологеты дармового использования квалифицированного труда программиста, постоянно и настойчиво путаете:

а) продажу уже произведённого готового товара, в цену которого уже включена неустойка в виде непродуктивной работы менеджера-консультанта, аренда магазина и прочее,

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

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

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

В реальности ни одно КБ не возьмётся даже за анализ проблемы без гарантированной оплаты. Так почему в сервисе Работа - не оплачивать (или не гарантировать) оплату за анализ/пересмотр/составление ТЗ - это должно быть нормой? 

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

papaklass:

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

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

 

papaklass все правильно говорит - закладывайте в стоимость своей работы стоимость сформулированных на шару алгоритмов.

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

 

А потом, с опытом, любой набор знаков оцениваешь сразу, и достаточно точно. По почерку, по нику, по словарному запасу... 

 
komposter:

papaklass все правильно говорит - закладывайте в стоимость своей работы стоимость сформулированных на шару алгоритмов.

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

А потом, с опытом, любой набор знаков оцениваешь сразу, и достаточно точно. По почерку, по нику, по словарному запасу... 

komposter, с Вами позвольте не согласиться... Хотя у каждого своя правда. В том смысле, что каким считать потенциального клиента - добросовестным или нет?

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

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

Абсолютно согласен с abolk'ом:

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

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

 

Эксперто-писатели, как-нибудь сядьте, посчитайте сколько времени уходит на выполнение работы по нормальным заданиям и по шаровым, сравните с сотношение дохода от нормальных заданий и шаровых. Получится что-то типа 30/70 и 70/30. Почему нормальные заказчики должны оплачивать за шаровиков?  В стомиость работы должны вкладываться затраты на обсуждение задания, но в разумном объеме (чтение и 2-3 круга с вопросами-ответами), нормальные закачики не должны платить за шаровиков.

 
denkir:

... а теперь давайте, как предлагает papaklass, посмотрим на манагера... будет ли он с потенциальным покупателем общаться хотя бы больше часа?

Больше двух  минут не будет.
 
Integer:

Эксперто-писатели, как-нибудь сядьте, посчитайте сколько времени уходит на выполнение работы по нормальным заданиям и по шаровым, сравните с сотношение дохода от нормальных заданий и шаровых. Получится что-то типа 30/70 и 70/30.

Так и есть. Чем меньше готов заказчик платить, тем чаще непонятней задание, тем больше гонора и претензионности. 

Причина обращения: