Denis Nikolaev #: Договоритесь с заказчиком на отмену работы через арбитраж с последующим удалением работы заказчиком с фриланса.
Иногда это не вариант:
Возможностей о чем-то договориться и гарантий исполнения договоренностей в дальнейшем - никаких. ТЗ в процессе работы уточнялось и изменялось многократно, но заказчик не собирался в этом останавливаться. Процесс уточнения выглядел так: заказчик предлагал "уточнение", бездумно взятое из ChatGPT или из интернета. После моего указания на ошибки в нем и невозможность реализации, заказчик тут же его отметал и предлагал совершенно другое. И так до тех пор, пока реализация не становилась возможной. А арбитраж заказчик начал, требуя нарушить собственное ТЗ. При этом менять ТЗ, чтобы это можно было реализовать, категорически отказывается.
В результате исполнитель "имеет" убыток в виде потраченного времени, ухудшение статистики по арбитражам и просрочке (сколько висят такие арбитражи, всем известно), понижение рейтинга и истеричный отзыв.
А заказчик, протестировав очередную свою "идею", и поняв, что она не работает, остается при деньгах. При этом ему даже не обязательно верифицировать аккаунт, насколько я знаю. И он всегда может завести новый якобы с незапятнанной репутацией.
При этом заказчик начал арбитраж, требуя нарушить собственное ТЗ (кстати, ТЗ в процессе работы уточнялось и изменялось многократно, но заказчик не собирался в этом останавливаться). Возможностей о чем-то договориться и гарантий исполнения договоренностей в дальнейшем - никаких.
В результате исполнитель имеет убыток в виде потраченного времени, ухудшение статистики по арбитражам и просрочке (сколько висят такие арбитражи, всем известно), понижение рейтинга и истеричный отзыв.
А заказчик, протестировав очередную свою "идею", и поняв, что она не работает, остается при деньгах. При этом ему даже не обязательно верифицировать аккаунт, насколько я знаю. И всегда может завести новый с незапятнанной репутацией.
Это риски фриланса, они были, есть и будут всегда.
До заключения контракта следует добиться от заказчика максимально чёткого ТЗ, иначе не браться за заказ.
Это риски фриланса, они были, есть и будут всегда.
До заключения контракта следует добиться от заказчика максимально чёткого ТЗ, иначе не браться за заказ.
Так и делаю, только в процессе неожиданно выяснилось, что заказчик в максимально четкое ТЗ в общепринятом смысле, вложил оказывается другой смысл. Риски и неравенство понятны: заказчик платит деньги. Удивляет то, что арбитраж с явным нарушением заказчиком п.III.2.5 правил тянется столько времени.
без всестороннего изучения -- в проблеме не разобраться.
в данном случае можно привести только цитату из известного произведения:
"Запомни, Шарапов -- наказания без вины не бывает. Ему надо было просто вовремя со своими женщинами разбираться и пистолеты не разбрасывать где попало. Ясно?"
другими словами: разработчик всегда сам виноват.
p.s.
вариаций здесь не так много:
1я и наиболее частая -- претензии заказчика обоснованы и он прав
2я -- разработчик принял в работу нечёткое и/или несогласованное ТЗ и потерял контроль над раскладом
Не стремится помочь заказчику сделать как лучше. Пишет только по ТЗ, причем как его поймет. Делаешь замечания по заданию, он всегда прав, приходится долго убеждать. Тяжелый на общение.
-- заказчики у вас разные -- но проблемы у всех одинаковые.
Договоритесь с заказчиком на отмену работы через арбитраж с последующим удалением работы заказчиком с фриланса.
Иногда это не вариант:
Возможностей о чем-то договориться и гарантий исполнения договоренностей в дальнейшем - никаких. ТЗ в процессе работы уточнялось и изменялось многократно, но заказчик не собирался в этом останавливаться. Процесс уточнения выглядел так: заказчик предлагал "уточнение", бездумно взятое из ChatGPT или из интернета. После моего указания на ошибки в нем и невозможность реализации, заказчик тут же его отметал и предлагал совершенно другое. И так до тех пор, пока реализация не становилась возможной. А арбитраж заказчик начал, требуя нарушить собственное ТЗ. При этом менять ТЗ, чтобы это можно было реализовать, категорически отказывается.
В результате исполнитель "имеет" убыток в виде потраченного времени, ухудшение статистики по арбитражам и просрочке (сколько висят такие арбитражи, всем известно), понижение рейтинга и истеричный отзыв.
А заказчик, протестировав очередную свою "идею", и поняв, что она не работает, остается при деньгах. При этом ему даже не обязательно верифицировать аккаунт, насколько я знаю. И он всегда может завести новый якобы с незапятнанной репутацией.
Иногда это не вариант:
При этом заказчик начал арбитраж, требуя нарушить собственное ТЗ (кстати, ТЗ в процессе работы уточнялось и изменялось многократно, но заказчик не собирался в этом останавливаться). Возможностей о чем-то договориться и гарантий исполнения договоренностей в дальнейшем - никаких.
В результате исполнитель имеет убыток в виде потраченного времени, ухудшение статистики по арбитражам и просрочке (сколько висят такие арбитражи, всем известно), понижение рейтинга и истеричный отзыв.
А заказчик, протестировав очередную свою "идею", и поняв, что она не работает, остается при деньгах. При этом ему даже не обязательно верифицировать аккаунт, насколько я знаю. И всегда может завести новый с незапятнанной репутацией.
Denis Nikolaev #:
Это риски фриланса, они были, есть и будут всегда.
До заключения контракта следует добиться от заказчика максимально чёткого ТЗ, иначе не браться за заказ.
Так и делаю, только в процессе неожиданно выяснилось, что заказчик в максимально четкое ТЗ в общепринятом смысле, вложил оказывается другой смысл. Риски и неравенство понятны: заказчик платит деньги. Удивляет то, что арбитраж с явным нарушением заказчиком п.III.2.5 правил тянется столько времени.
согласитесь, вы сейчас ноете.
без всестороннего изучения -- в проблеме не разобраться.
в данном случае можно привести только цитату из известного произведения:
"Запомни, Шарапов -- наказания без вины не бывает. Ему надо было просто вовремя со своими женщинами разбираться и пистолеты не разбрасывать где попало. Ясно?"
другими словами: разработчик всегда сам виноват.
p.s.
вариаций здесь не так много:
1я и наиболее частая -- претензии заказчика обоснованы и он прав
2я -- разработчик принял в работу нечёткое и/или несогласованное ТЗ и потерял контроль над раскладом
согласитесь, вы сейчас ноете.
без всестороннего изучения -- в проблеме не разобраться.
Согласен с последним. Поэтому сначала изучите, потом требуйте согласия с первым. Этот случай не относится ни к одной вашей вариации.
p.s.
С женщинами и пистолетами у меня все в порядке.
Согласен с последним. ...
ваше согласие или несогласие не требовалось и не играет никакой роли.
в вашем случае с огромной вероятностью -- заказчик прав.
это следует из сопоставления двух тезисов:
1) вы написали выше:
арбитраж заказчик начал, требуя нарушить собственное ТЗ
2) читаем последний вам негативный отзыв:
Не стремится помочь заказчику сделать как лучше. Пишет только по ТЗ, причем как его поймет. Делаешь замечания по заданию, он всегда прав, приходится долго убеждать. Тяжелый на общение.
... Риски и неравенство понятны: заказчик платит деньги. ...
Если вам постноянно не везет на заказчиков, то есть вариант фильтрации: например, выбирать работы от заказчиков с высоким рейтингом.
Типа такой:
ваше согласие или несогласие не требовалось и не играет никакой роли.
Т.е. сами требовали согласиться, а если с вами не согласились, то сразу роли не играет? Тогда ваш пост в моем вопросе тоже роли не играет.
2) читаем последний вам негативный отзыв:
)) Больше 3-х лет назад. Слишком глубоко копаете, чтобы делать вывод обо всех. Раз в 3 года при 40 работах в год - далеко "не только лишь все".
-- заказчики у вас разные -- но проблемы у всех одинаковые.
Проблема резинового ТЗ в понимании заказчика - общая для всех исполнителей. Поэтому и введен п.III.2.5 правил
Если вам постноянно не везет на заказчиков
Отнюдь, случаи единичные. Но портят всю картину. Когда нарушение заказчиком п.III.2.5 правил очевидно, хотелось бы большей оперативности от арбитража.