
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Правильно, когда:
1) исполнитель имеет возможность отказаться от работы
2) исполнитель имеет возможность уменьшить стоимость работы
3) заказчик имеет возможность увеличить стоимость работы
В этапах выполнения работы есть недостаток:
пункт 3.2.7. Правил "После подтверждения шага "Согласование ТЗ" обеими сторонами на счете Заказчика в Платежной Системе блокируется сумма Заказа."
Получается, что стороны обсуждают ТЗ - а именно - Исполнитель вникает в ТЗ, тратит своё время, правит Заказчику ТЗ, фактически консультирует Заказчика - а в результате Заказчик имеет возможность по итогам обсуждения "слинять" и/или выбрать другого. В итоге часто приходится принимать поверхностно изученное ТЗ со всеми вытекающими в виде "недооценил сложность/стоимость/реализуемость работы".
Этап "Согласование ТЗ" должен проходить в два этапа:
1. Заказчик подтверждает ТЗ - сумма блокируется.
2. Идёт обсуждение ТЗ и ДО подтверждения эатапа "Согласование ТЗ" исполнителем должна быть возможность: отказаться от ТЗ, изменить стоимость.
Либо же возможность отказаться от ТЗ Исполнителем и изменение стоимости реализовать на этапе "Прототип/Макет".
Правильно, когда:
1) исполнитель имеет возможность отказаться от работы
2) исполнитель имеет возможность уменьшить стоимость работы
3) заказчик имеет возможность увеличить стоимость работы
В этапах выполнения работы есть недостаток:
пункт 3.2.7. Правил "После подтверждения шага "Согласование ТЗ" обеими сторонами на счете Заказчика в Платежной Системе блокируется сумма Заказа."
Получается, что стороны обсуждают ТЗ - а именно - Исполнитель вникает в ТЗ, тратит своё время, правит Заказчику ТЗ, фактически консультирует Заказчика - а в результате Заказчик имеет возможность по итогам обсуждения "слинять" и/или выбрать другого. В итоге часто приходится принимать поверхностно изученное ТЗ со всеми вытекающими в виде "недооценил сложность/стоимость/реализуемость работы".
Этап "Согласование ТЗ" должен проходить в два этапа:
1. Заказчик подтверждает ТЗ - сумма блокируется.
2. Идёт обсуждение ТЗ и ДО подтверждения эатапа "Согласование ТЗ" исполнителем должна быть возможность: отказаться от ТЗ, изменить стоимость.
Либо же возможность отказаться от ТЗ Исполнителем и изменение стоимости реализовать на этапе "Прототип/Макет".
Подтверждаю, несколько раз на такие грабли наступал, разжевываешь заказчику его собственное ТЗ. Тратишь на это 3-4 дня. Раскладываешь ему всё по полочкам, а он линяет с этим уже раскатанным ТЗ, и заказывает его исполнение за меньшую сумму.
Составить толковое ТЗ львиная доля работы, и эта доля получается не имеет гарантированной оплаты в сервисе "Работа"!!!!
Это Ваши риски в качестве испонителя. Ведь, выбирая холодильник, Вы не покупаете тот, который очень хорошо описал менеджер. Вы возмете на заметку рассказ менеджера и можете пойти в другой магазин и купить холодильник дешевле. И менеджер ничего не получит за свой качественный рассказ. Но не рассказывать совсем нельзя. Менеджер это понимает и каждый раз рискует.
Вы, как впрочем и другие апологеты дармового использования квалифицированного труда программиста, постоянно и настойчиво путаете:
а) продажу уже произведённого готового товара, в цену которого уже включена неустойка в виде непродуктивной работы менеджера-консультанта, аренда магазина и прочее,
б) с проведением научно-исследовательских, опытно-конструкторских и технических работ - в этом случае цель этапа "Согласование" - разобраться с тем, что хочет Заказчик, формализовать его изначально нечёткую задачу и т.д. и т.п. - это стоит затрат профессионального труда, который безусловно должен быть оплачен.
Если в первом случае менеджер-консультант не создаёт новой стоимости - товар уже произведен и готов к продаже, то во втором случае программист что обсуждает с заказчиком его же ТЗ создаёт для заказчика новое ТЗ - и этот труд должен быть оплачен.
Если менеджеру в Вашем случае безусловно платится заработная плата, то во втором случае - на каком основании, Вы считаете, что программист должен остаться без оплаты? Пересмотренное, разобранное ТЗ стоит не меньше стоимости написания программы - и уход заказчика к другому программисту естественный и оправданный желанием платить меньше.
В реальности ни одно КБ не возьмётся даже за анализ проблемы без гарантированной оплаты. Так почему в сервисе Работа - не оплачивать (или не гарантировать) оплату за анализ/пересмотр/составление ТЗ - это должно быть нормой?
Большинство арбитражных ситуаций в сервисе Работа - это "нечёткое ТЗ", "недооцененная по сложности работа". И причины в том, что разработчик на этапе "Согласование ТЗ" совершенно незащищён от недобросовестного заказчика.
papaklass:
Тоже самое и в Вашем случае. Если Вы откажитесь от работы над ТЗ с заказчиком, Вы его точно потеряете. А если Вы грамотно поможете заказчику составить ТЗ, то очень велика вероятность того, что эта работа достанется Вам и в будущем заказчик к Вам вернется. Воспринимайте это как издержки работы с людьми.
Пора бы прекратить смотреть на программиста, как на некоего безработного, которому нечем заняться, который сидит и ждёт и радуется каждому заказчику и каждому заказу. У программиста есть основная работа, есть свои интересы, есть свободное время. И вряд ли программист с радостью будет тратить своё свободное время на заказ, который может состояться лишь с некоторой вероятностью.
papaklass все правильно говорит - закладывайте в стоимость своей работы стоимость сформулированных на шару алгоритмов.
Или, в самых сложных случаях, оговаривайте стоимость формализации задания. Хотя, на это соглашаются редко.
А потом, с опытом, любой набор знаков оцениваешь сразу, и достаточно точно. По почерку, по нику, по словарному запасу...
papaklass все правильно говорит - закладывайте в стоимость своей работы стоимость сформулированных на шару алгоритмов.
Или, в самых сложных случаях, оговаривайте стоимость формализации задания. Хотя, на это соглашаются редко.
А потом, с опытом, любой набор знаков оцениваешь сразу, и достаточно точно. По почерку, по нику, по словарному запасу...
komposter, с Вами позвольте не согласиться... Хотя у каждого своя правда. В том смысле, что каким считать потенциального клиента - добросовестным или нет?
Если закладывать в стоимость своей работы стоимость сформулированных на шару алгоритмов, то по определению уже клиент считается не добросовестным, т.к. платит за "риск незаказа". Так поступают, например, розничные сети в плане воровства. Все мы переплачиваем за товары ровно настолько, насколько много у магазина своровали...
Имея механизм построения отношений между заказчиком и исполнителем через сайт MQ, можно более или менее справедливо его сконструировать...или попробовать это сделать...
Абсолютно согласен с abolk'ом:
Например, представьте, что Вы исполнитель. Вы обсуждаете и формируете корректное ТЗ для заказчика примерно дня 3-4... а теперь давайте, как предлагает papaklass, посмотрим на манагера... будет ли он с потенциальным покупателем общаться хотя бы больше часа?
Эксперто-писатели, как-нибудь сядьте, посчитайте сколько времени уходит на выполнение работы по нормальным заданиям и по шаровым, сравните с сотношение дохода от нормальных заданий и шаровых. Получится что-то типа 30/70 и 70/30. Почему нормальные заказчики должны оплачивать за шаровиков? В стомиость работы должны вкладываться затраты на обсуждение задания, но в разумном объеме (чтение и 2-3 круга с вопросами-ответами), нормальные закачики не должны платить за шаровиков.
... а теперь давайте, как предлагает papaklass, посмотрим на манагера... будет ли он с потенциальным покупателем общаться хотя бы больше часа?
Эксперто-писатели, как-нибудь сядьте, посчитайте сколько времени уходит на выполнение работы по нормальным заданиям и по шаровым, сравните с сотношение дохода от нормальных заданий и шаровых. Получится что-то типа 30/70 и 70/30.
Так и есть. Чем меньше готов заказчик платить, тем чаще непонятней задание, тем больше гонора и претензионности.