Фриланс и арбитраж. Нужно что-то менять, иначе тупик! - страница 6

 
Artyom Trishkin:
Отдайте половину исходника :)

Я так и предложил там в ветке работы. Но меня без ответов и объяснений забанили)

С одной стороны 50% исходника это логично, но ведь понятно что абсурд - отдать каждую 2-ю строку больше на юмор похоже ))

 
Aleksey Mavrin:

Я так и предложил там в ветке работы. Но меня без ответов и объяснений забанили)

С одной стороны 50% исходника это логично, но ведь понятно что абсурд - отдать каждую 2-ю строку больше на юмор похоже ))

Так и я пошутил :)
Надо всё отдать что есть.
Дом, машину, дачу, тёщу...
Ну.., из кода - что сделано.
 
Artyom Trishkin:
Так и я пошутил :)
Надо всё отдать что есть.
Дом, машину, дачу, тёщу...
Ну.., из кода - что сделано.

Это Вы так и стали модератором?..:)

 

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

Есть две работы в арбитраже.

Первая висит уже месяц, работа выполнена в полном соответствии с ТЗ. Заказчик просто не хочет платить.

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

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

До этого работа висела в арбитраже 3 месяца, может арбитр не видит, то что работа в арбитраже. Может кто подсказать.

 
Artyom Trishkin:

Знаете как я делал иногда, когда заказчик вызывал некие неловкости...

Я передавал закрытый код - чтобы человек мог всё проверить и провести передачу денег. И писал ему, что после того, как деньги будут переданы мне, я передам ему исходник.

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

Знаете, не раз спасало.

Добрый день, коллеги.

Способ конечно хороший. Но недавно попался принципиальный заказчик, который не стал закрывать заказ пока не получит исходный код.

Возможно и такое развитие ситуации, когда заказчик протестит свой сливатор, расстроится и запьёт, т.е. забьёт на всё. Забьёт на заказ, на форекс, на сайт MQL и на исполнителя который ждёт закрытия заказа.

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

 
Andrey Kaunov:

Добрый день, коллеги.

Способ конечно хороший. Но недавно попался принципиальный заказчик, который не стал закрывать заказ пока не получит исходный код.

...

а в чём принципиальность заказчика?

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

 

Уважаемый Андрей, прочитай мой пост полностью, вместе с цитатой Артёма.

Я про это и пишу, что не со всеми заказчиками прокатит такой способ.

 
Andrey Kaunov:

Уважаемый Андрей, прочитай мой пост полностью, вместе с цитатой Артёма.

Я про это и пишу, что не со всеми заказчиками прокатит такой способ.

Да, фигня это всё -- есть риски свала заказчика на любом этапе подтверждения -- эти риски были всегда -- и от этого никак не защититься.

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

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

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

Да и потом -- какие риски свала заказчика -- 1-2% -- этим можно пренебречь.

А насчёт статистики -- мои наблюдения таковы, что минимум 90% заказчикам на эту статистику глубоко пофиг -- они равно начинают сотрудничать и с теми, у кого по 300 арбитражей при 600 выполненных работ -- и с теми, у кого вообще нет выполненных работ -- поэтому статистику надо беречь, безусловно -- но и биться в истерике из-за неё точно не стоит.

 

Андрей, согласен с тобой по всем пунктам.

Нет никаких гарантий даже если возьмёшь у него другие контакты. Он может свалить и из Телеграмма и Скайпа и т.д. Игнорить тебя и всё, как вариант.

Andrey F. Zelinsky:

...

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

...

Хорошая тема. Но её можно и на программном уровне сделать, чтобы не заморачиваться никому в плане: "А что я забыл сделать...?" Можно же сделать всплывающие подсказки в отдельных окнах или прямо в чате, уведомления на почту или телефон о следующем шаге.

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

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

 
Andrey Kaunov:

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

Ещё раз. Все расклады со свалом заказчика -- это не более 1-2% -- таким процентом можно (и нужно) пренебречь.

Мало того, любые технические или организационные ухищрения -- эти 1-2% никак не изменят.

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

Любой вариант с автоматическим завершением работы -- крайне вредный -- т.к. будет приводить к массовому завершению работ в пользу разработчика -- причём работ, по которым "конь не валялся".

Ситуаций, по которым советник выдан в работу, а по нему туча недоработок и диалог зашел в тупик и заказчик свалил -- таких ситуаций тьма -- и если сделать автоматом завершение "брошенных" работ -- то вот по таким задачам и будет идти завершение -- а это категорически недопустимо.

Поэтому -- любое завершение работы или заказчиком или через арбитраж -- никакой автоматики.

Автоматом возможно завершение только в пользу заказчика.

p.s. Как вариант -- это выбор разработчиком режима "расторгнуть в пользу заказчика" сделать без необходимости подтверждения со стороны заказчика, ну, или если заказчик не подтверждает его в течение суток, то сделать автоматом.