Что думают о сервисе Фриланс разработчики на MQL5 - страница 5

 
Aleksey Vyazmikin #:

Заказчик давно получил готовый продукт. 

А какая тогда претензия с его стороны? Почему он не подтверждает, что работа выполнена?

 
Ivan Titov #:

Как это не ущемляет? Заказчик затягивает оплату, о сроке которой предварительно договорились, и портит статистику исполнителю (средний срок исполнения увеличивается). Поддерживаю предложение обязательного согласования с исполнителем увеличения срока.

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

Вопрос... Как увеличение срока со стороны заказчика вам навредит? Наоборот, просрочка пропадет, и основание расторгнуть работу пропадет..

 
Nikolay Ivanov #:

А какая тогда претензия с его стороны? Потому он не подтверждает, что работа выполнена?

Официально заявлял - ему нужно время, что бы разобраться.

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

По факту вне периода обучения статистические характеристики улучшились, но он их все скрывает на рисунке - не дает статистик.

 
Nikolay Ivanov #:

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

Вопрос... Как увеличение срока со стороны заказчика вам навредит? Наоборот, просрочка пропадет, и основание расторгнуть работу пропадет..

В чём проблема сделать двухстороннее согласование? Разве Ваш пример как то мешает этому?

 
Nikolay Ivanov #:

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

Вопрос... Как увеличение срока со стороны заказчика вам навредит? Наоборот, просрочка пропадет, и основание расторгнуть работу пропадет..

Читайте внимательно: я предлагаю не отменить возможность увеличения срока, а добавить подтверждение этого действия исполнителем.

 
Nikolay Ivanov #:

А какая тогда претензия с его стороны? Почему он не подтверждает, что работа выполнена?

Часто бывает, что нет никаких претензий: после получения кода заказчик просто исчезает (благо ему не требуется подтверждать свою личность в ЛК, по крайней мере ники допускаются вместо имени и фамилии). Для таких случаев предлагаю сделать автоматическое подтверждение шага передачи работы со стороны заказчика, если заказчик не ответил в течение 3-х дней после передачи исполнителем кода.

 
Aleksey Vyazmikin #:

По факту вне периода обучения статистические характеристики улучшились, но он их все скрывает на рисунке - не дает статистик.

Проще говоря, его не устраивает прибыльность готового продукта?


Ivan Titov #:

Читайте внимательно: я предлагаю не отменить возможность увеличения срока, а добавить подтверждение этого действия исполнителем.

 Суть в том, что если вам в100% случаев выгодно когда дедлайн отдаляется, то зачем это согласовывать? Чем это нарушит ваши права? Сервис развивается и идет в сторону практичности и оптимальности, поэтому какой смысл в лишней бюрократии? Вот раньше, чтобы аннулировать работу был нужен арбитраж, а сейчас это согласование с админами пропало и достаточно только согласия заказчика и исполнителя. 

Часто бывает, что нет никаких претензий: после получения кода заказчик просто исчезает (благо ему не требуется подтверждать свою личность в ЛК, по крайней мере ники допускаются вместо имени и фамилии). Для таких случаев предлагаю сделать автоматическое подтверждение шага передачи работы со стороны заказчика, если заказчик не ответил в течение 3-х дней после передачи исполнителем код

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

 
Nikolay Ivanov #:

 Суть в том, что если вам в100% случаев выгодно когда дедлайн отдаляется

Как посчитали 100%? Как минимум 2 исполнителя вам здесь привели примеры, когда не выгодно.

Nikolay Ivanov #:

 Но автопринятие никто делать не будет.. Это слишком опасно.

Вы передаете решение администрации? Чем именно опасно?

 
Ivan Titov #:

Как посчитали 100%? Как минимум 2 исполнителя вам здесь привели примеры, когда не выгодно.

 Я вам привел 2 примера когда это выгодно. Других примеров выгодности и невыгодности нету. Другие исполнители связывают свои проблемы с увеличением сроков, хотя там дело не в сроках, вот уже выяснилось что дело в том, что продукт не прибыльный, поэтому его не принимают.. Заказчик думал что получит грааль. И причем тут срок исполнения? Он может и без увеличения сроков просто не принимать работу бесконечно долго.

Ivan Titov #:

Вы озвучиваете решение администрации? Чем именно опасно?

Я озвучиваю свое мнение, на мой взгляд оно логично.

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


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

Это все я за 10 минут придумал. А умельцы за длительное время кучу уловок выдумают. 

 
Nikolay Ivanov #:

 Я вам привел 2 примера когда это выгодно. Других примеров выгодности и невыгодности нету. 

Если признавать только свои "правильные" примеры и отрицать остальные, то согласен - получится 100%.

Nikolay Ivanov #:

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

Это точно "простой" пример и точно реальный? Как заказчик может не знать, что надо заходить на сайт, если он уже подтвердил все шаги вплоть до демонстрации? Как проект после демонстрации может быть полунерабочим?

Мой пример для сравнения укладывается в одно предложение: после передачи исходников заказчик получил все, что хотел, и исчез.

Ну и в правила само собой надо добавить про автоматическое закрытие, чтобы заказчик был в курсе.

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