По сути, мы все (и Администрация, и Разработчик, и Заказчик) находимся по разные стороны сервиса. И каждый видит свои ньюансы и сложности. То диалоговое окошко, что Вы привели я как раз видел - это существенный и важный шаг вперёд по донесению до Заказчика всей необходимой информации. Я же перечислил те вопросы, которые задают 99% Заказчиков, что первый раз пришли на сервис. И каждому заказчику приходится с завидным постоянством и настойчивостью давать ссылку на Пошаговое руководство и на раздел аккаунта Расчёты. Такое положение дел говорит о том, что информативности в ключевых вопросах - Пошаговое руководство и Расчёты - явно недостаточно.
Похоже, что заказчики просто не читают то, что написано в диалоговом окне"Создание новой работы" и сразу нажимают кнопку Принять. И с этим, наверное, к сожалению, ничего не поделаешь, даже, если окружить их со всех сторон ссылками. Они будут идти напролом и спрашивать у исполнителя тот или иной интересующий их момент. Если исполнитель ответит, то им это проще, так как это будет краткая форма ответа. Ну, а если исполнитель не ответит, то даст ссылку, вот тогда ничего не поделаешь, нужно читать. Вот как выйти из этого "тонко" психологического замкнутого круга? :) Принудительное чтение что-ли организовывать. :)
Здравствуйте, я новичок на mt5.com .Я заказал советника из раздела заданий и при прохождении пошагового процесса работы я столкнулся с трудностями на шаге'Переговоры о требованиях'. Мы оба, я и разработчик, подтверждаем этот шаг, но я не могу получить доступ к следующему шагу Prototype/Model. Колонка "Переговоры о требованиях" все еще в зеленом цвете, и я не могу перейти к следующему разделу. Кто-нибудь из опытных, пожалуйста, помогите мне...
Здравствуйте, я новичок на mt5.com .Я заказал советника из раздела заданий и при прохождении пошагового процесса работы я столкнулся с трудностями на шаге'Переговоры о требованиях'. Мы оба, я и разработчик, подтверждаем этот шаг, но я не могу получить доступ к следующему шагу Prototype/Model. Колонка "Переговоры о требованиях" все еще в зеленом цвете, и я не могу перейти к следующему разделу. Кто-нибудь из опытных, пожалуйста, помогите мне...
У МЕНЯ ТА ЖЕ ПРОБЛЕМА, СМ. ПРИКРЕПЛЕННЫЕ ИЗОБРАЖЕНИЯ
У вас есть идеи о том, что происходит, как мы можем решить эту ситуацию?
День добрый всем. А у меня вот назрел такой вопрос по данной тематике. Частенько повторяется ситуация, что работа взята, начинаешь делать и тут выясняется что или индикатор, предоставленный заказчиком в качестве источника сигналов на открытие сделок не корректен и его нужно дорабатывать, или хотелки заказчика уже после прохождения этапа согласования ТЗ возросли, что приводит к возрастанию стоимости работы. Заказчик с этим согласен и готов доплатить, но цена проекта зафиксирована и на сколько я понимаю изменить даже при обоюдном согласии ее нельзя. В результате доплату приходится прогонять либо мимо сайта либо оформлять еще какую то работу, что не всегда удобно. Вопрос соответственно в следующем - а нет ли все же способа изменить стоимость работы после подписания ТЗ. В реальной жизни все просто - выпускаешь дополнение к договору, в кот. прописываешь изменения в ТЗ и цены договора - хлоп печати и подписи с двух сторон и погнали дальше. А тут я что-то такого не нашел. Ну или может плохо искал? )))
vadimpl: День добрый всем. А у меня вот назрел такой вопрос по данной тематике. Частенько повторяется ситуация, что работа взята, начинаешь делать и тут выясняется что или индикатор, предоставленный заказчиком в качестве источника сигналов на открытие сделок не корректен и его нужно дорабатывать, или хотелки заказчика уже после прохождения этапа согласования ТЗ возросли, что приводит к возрастанию стоимости работы. Заказчик с этим согласен и готов доплатить, но цена проекта зафиксирована и на сколько я понимаю изменить даже при обоюдном согласии ее нельзя. В результате доплату приходится прогонять либо мимо сайта либо оформлять еще какую то работу, что не всегда удобно. Вопрос соответственно в следующем - а нет ли все же способа изменить стоимость работы после подписания ТЗ. В реальной жизни все просто - выпускаешь дополнение к договору, в кот. прописываешь изменения в ТЗ и цены договора - хлоп печати и подписи с двух сторон и погнали дальше. А тут я что-то такого не нашел. Ну или может плохо искал? )))
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Правильно, когда:
1) исполнитель имеет возможность отказаться от работы 2) исполнитель имеет возможность уменьшить стоимость работы 3) заказчик имеет возможность увеличить стоимость работы
пункт 3.2.7. Правил "После подтверждения шага "Согласование ТЗ" обеими сторонами на счете Заказчика в Платежной Системе блокируется сумма Заказа."
Получается, что стороны обсуждают ТЗ - а именно - Исполнитель вникает в ТЗ, тратит своё время, правит Заказчику ТЗ, фактически консультирует Заказчика - а в результате Заказчик имеет возможность по итогам обсуждения "слинять" и/или выбрать другого. В итоге часто приходится принимать поверхностно изученное ТЗ со всеми вытекающими в виде "недооценил сложность/стоимость/реализуемость работы".
Этап "Согласование ТЗ" должен проходить в два этапа:
1. Заказчик подтверждает ТЗ - сумма блокируется. 2. Идёт обсуждение ТЗ и ДО подтверждения эатапа "Согласование ТЗ" исполнителем должна быть возможность: отказаться от ТЗ, изменить стоимость.
Либо же возможность отказаться от ТЗ Исполнителем и изменение стоимости реализовать на этапе "Прототип/Макет".
1) исполнитель имеет возможность отказаться от работы 2) исполнитель имеет возможность уменьшить стоимость работы 3) заказчик имеет возможность увеличить стоимость работы
В этапах выполнения работы есть недостаток:
пункт 3.2.7. Правил "После подтверждения шага "Согласование ТЗ" обеими сторонами на счете Заказчика в Платежной Системе блокируется сумма Заказа."
Получается, что стороны обсуждают ТЗ - а именно - Исполнитель вникает в ТЗ, тратит своё время, правит Заказчику ТЗ, фактически консультирует Заказчика - а в результате Заказчик имеет возможность по итогам обсуждения "слинять" и/или выбрать другого. В итоге часто приходится принимать поверхностно изученное ТЗ со всеми вытекающими в виде "недооценил сложность/стоимость/реализуемость работы".
Этап "Согласование ТЗ" должен проходить в два этапа:
1. Заказчик подтверждает ТЗ - сумма блокируется. 2. Идёт обсуждение ТЗ и ДО подтверждения эатапа "Согласование ТЗ" исполнителем должна быть возможность: отказаться от ТЗ, изменить стоимость.
Либо же возможность отказаться от ТЗ Исполнителем и изменение стоимости реализовать на этапе "Прототип/Макет".
Подтверждаю, несколько раз на такие грабли наступал, разжевываешь заказчику его собственное ТЗ. Тратишь на это 3-4 дня. Раскладываешь ему всё по полочкам, а он линяет с этим уже раскатанным ТЗ, и заказывает его исполнение за меньшую сумму.
Составить толковое ТЗ львиная доля работы, и эта доля получается не имеет гарантированной оплаты в сервисе "Работа"!!!!
Это Ваши риски в качестве испонителя. Ведь, выбирая холодильник, Вы не покупаете тот, который очень хорошо описал менеджер. Вы возмете на заметку рассказ менеджера и можете пойти в другой магазин и купить холодильник дешевле. И менеджер ничего не получит за свой качественный рассказ. Но не рассказывать совсем нельзя. Менеджер это понимает и каждый раз рискует.
Вы, как впрочем и другие апологеты дармового использования квалифицированного труда программиста, постоянно и настойчиво путаете:
а) продажу уже произведённого готового товара, в цену которого уже включена неустойка в виде непродуктивной работы менеджера-консультанта, аренда магазина и прочее,
б) с проведением научно-исследовательских, опытно-конструкторских и технических работ - в этом случае цель этапа "Согласование" - разобраться с тем, что хочет Заказчик, формализовать его изначально нечёткую задачу и т.д. и т.п. - это стоит затрат профессионального труда, который безусловно должен быть оплачен.
Если в первом случае менеджер-консультант не создаёт новой стоимости - товар уже произведен и готов к продаже, то во втором случае программист что обсуждает с заказчиком его же ТЗ создаёт для заказчика новое ТЗ - и этот труд должен быть оплачен.
Если менеджеру в Вашем случае безусловно платится заработная плата, то во втором случае - на каком основании, Вы считаете, что программист должен остаться без оплаты? Пересмотренное, разобранное ТЗ стоит не меньше стоимости написания программы - и уход заказчика к другому программисту естественный и оправданный желанием платить меньше.
В реальности ни одно КБ не возьмётся даже за анализ проблемы без гарантированной оплаты. Так почему в сервисе Работа - не оплачивать (или не гарантировать) оплату за анализ/пересмотр/составление ТЗ - это должно быть нормой?
Большинство арбитражных ситуаций в сервисе Работа - это "нечёткое ТЗ", "недооцененная по сложности работа". И причины в том, что разработчик на этапе "Согласование ТЗ" совершенно незащищён от недобросовестного заказчика.
papaklass:
Тоже самое и в Вашем случае. Если Вы откажитесь от работы над ТЗ с заказчиком, Вы его точно потеряете. А если Вы грамотно поможете заказчику составить ТЗ, то очень велика вероятность того, что эта работа достанется Вам и в будущем заказчик к Вам вернется. Воспринимайте это как издержки работы с людьми.
Пора бы прекратить смотреть на программиста, как на некоего безработного, которому нечем заняться, который сидит и ждёт и радуется каждому заказчику и каждому заказу. У программиста есть основная работа, есть свои интересы, есть свободное время. И вряд ли программист с радостью будет тратить своё свободное время на заказ, который может состояться лишь с некоторой вероятностью.
По сути, мы все (и Администрация, и Разработчик, и Заказчик) находимся по разные стороны сервиса. И каждый видит свои ньюансы и сложности. То диалоговое окошко, что Вы привели я как раз видел - это существенный и важный шаг вперёд по донесению до Заказчика всей необходимой информации. Я же перечислил те вопросы, которые задают 99% Заказчиков, что первый раз пришли на сервис. И каждому заказчику приходится с завидным постоянством и настойчивостью давать ссылку на Пошаговое руководство и на раздел аккаунта Расчёты. Такое положение дел говорит о том, что информативности в ключевых вопросах - Пошаговое руководство и Расчёты - явно недостаточно.
Здравствуйте, я новичок на mt5.com .Я заказал советника из раздела заданий и при прохождении пошагового процесса работы я столкнулся с трудностями на шаге'Переговоры о требованиях'. Мы оба, я и разработчик, подтверждаем этот шаг, но я не могу получить доступ к следующему шагу Prototype/Model. Колонка "Переговоры о требованиях" все еще в зеленом цвете, и я не могу перейти к следующему разделу. Кто-нибудь из опытных, пожалуйста, помогите мне...
У МЕНЯ ТА ЖЕ ПРОБЛЕМА, СМ. ПРИКРЕПЛЕННЫЕ ИЗОБРАЖЕНИЯ
У вас есть идеи о том, что происходит, как мы можем решить эту ситуацию?
День добрый всем. А у меня вот назрел такой вопрос по данной тематике. Частенько повторяется ситуация, что работа взята, начинаешь делать и тут выясняется что или индикатор, предоставленный заказчиком в качестве источника сигналов на открытие сделок не корректен и его нужно дорабатывать, или хотелки заказчика уже после прохождения этапа согласования ТЗ возросли, что приводит к возрастанию стоимости работы. Заказчик с этим согласен и готов доплатить, но цена проекта зафиксирована и на сколько я понимаю изменить даже при обоюдном согласии ее нельзя. В результате доплату приходится прогонять либо мимо сайта либо оформлять еще какую то работу, что не всегда удобно. Вопрос соответственно в следующем - а нет ли все же способа изменить стоимость работы после подписания ТЗ. В реальной жизни все просто - выпускаешь дополнение к договору, в кот. прописываешь изменения в ТЗ и цены договора - хлоп печати и подписи с двух сторон и погнали дальше. А тут я что-то такого не нашел. Ну или может плохо искал? )))
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Пока такой возможности нет, но подумаем над реализацией.
Причем только в сторону увеличения и только если у заказчика есть достаточно денег.
Правильно, когда:
1) исполнитель имеет возможность отказаться от работы
2) исполнитель имеет возможность уменьшить стоимость работы
3) заказчик имеет возможность увеличить стоимость работы
В этапах выполнения работы есть недостаток:
пункт 3.2.7. Правил "После подтверждения шага "Согласование ТЗ" обеими сторонами на счете Заказчика в Платежной Системе блокируется сумма Заказа."
Получается, что стороны обсуждают ТЗ - а именно - Исполнитель вникает в ТЗ, тратит своё время, правит Заказчику ТЗ, фактически консультирует Заказчика - а в результате Заказчик имеет возможность по итогам обсуждения "слинять" и/или выбрать другого. В итоге часто приходится принимать поверхностно изученное ТЗ со всеми вытекающими в виде "недооценил сложность/стоимость/реализуемость работы".
Этап "Согласование ТЗ" должен проходить в два этапа:
1. Заказчик подтверждает ТЗ - сумма блокируется.
2. Идёт обсуждение ТЗ и ДО подтверждения эатапа "Согласование ТЗ" исполнителем должна быть возможность: отказаться от ТЗ, изменить стоимость.
Либо же возможность отказаться от ТЗ Исполнителем и изменение стоимости реализовать на этапе "Прототип/Макет".
Правильно, когда:
1) исполнитель имеет возможность отказаться от работы
2) исполнитель имеет возможность уменьшить стоимость работы
3) заказчик имеет возможность увеличить стоимость работы
В этапах выполнения работы есть недостаток:
пункт 3.2.7. Правил "После подтверждения шага "Согласование ТЗ" обеими сторонами на счете Заказчика в Платежной Системе блокируется сумма Заказа."
Получается, что стороны обсуждают ТЗ - а именно - Исполнитель вникает в ТЗ, тратит своё время, правит Заказчику ТЗ, фактически консультирует Заказчика - а в результате Заказчик имеет возможность по итогам обсуждения "слинять" и/или выбрать другого. В итоге часто приходится принимать поверхностно изученное ТЗ со всеми вытекающими в виде "недооценил сложность/стоимость/реализуемость работы".
Этап "Согласование ТЗ" должен проходить в два этапа:
1. Заказчик подтверждает ТЗ - сумма блокируется.
2. Идёт обсуждение ТЗ и ДО подтверждения эатапа "Согласование ТЗ" исполнителем должна быть возможность: отказаться от ТЗ, изменить стоимость.
Либо же возможность отказаться от ТЗ Исполнителем и изменение стоимости реализовать на этапе "Прототип/Макет".
Подтверждаю, несколько раз на такие грабли наступал, разжевываешь заказчику его собственное ТЗ. Тратишь на это 3-4 дня. Раскладываешь ему всё по полочкам, а он линяет с этим уже раскатанным ТЗ, и заказывает его исполнение за меньшую сумму.
Составить толковое ТЗ львиная доля работы, и эта доля получается не имеет гарантированной оплаты в сервисе "Работа"!!!!
Это Ваши риски в качестве испонителя. Ведь, выбирая холодильник, Вы не покупаете тот, который очень хорошо описал менеджер. Вы возмете на заметку рассказ менеджера и можете пойти в другой магазин и купить холодильник дешевле. И менеджер ничего не получит за свой качественный рассказ. Но не рассказывать совсем нельзя. Менеджер это понимает и каждый раз рискует.
Вы, как впрочем и другие апологеты дармового использования квалифицированного труда программиста, постоянно и настойчиво путаете:
а) продажу уже произведённого готового товара, в цену которого уже включена неустойка в виде непродуктивной работы менеджера-консультанта, аренда магазина и прочее,
б) с проведением научно-исследовательских, опытно-конструкторских и технических работ - в этом случае цель этапа "Согласование" - разобраться с тем, что хочет Заказчик, формализовать его изначально нечёткую задачу и т.д. и т.п. - это стоит затрат профессионального труда, который безусловно должен быть оплачен.
Если в первом случае менеджер-консультант не создаёт новой стоимости - товар уже произведен и готов к продаже, то во втором случае программист что обсуждает с заказчиком его же ТЗ создаёт для заказчика новое ТЗ - и этот труд должен быть оплачен.
Если менеджеру в Вашем случае безусловно платится заработная плата, то во втором случае - на каком основании, Вы считаете, что программист должен остаться без оплаты? Пересмотренное, разобранное ТЗ стоит не меньше стоимости написания программы - и уход заказчика к другому программисту естественный и оправданный желанием платить меньше.
В реальности ни одно КБ не возьмётся даже за анализ проблемы без гарантированной оплаты. Так почему в сервисе Работа - не оплачивать (или не гарантировать) оплату за анализ/пересмотр/составление ТЗ - это должно быть нормой?
Большинство арбитражных ситуаций в сервисе Работа - это "нечёткое ТЗ", "недооцененная по сложности работа". И причины в том, что разработчик на этапе "Согласование ТЗ" совершенно незащищён от недобросовестного заказчика.
papaklass:
Тоже самое и в Вашем случае. Если Вы откажитесь от работы над ТЗ с заказчиком, Вы его точно потеряете. А если Вы грамотно поможете заказчику составить ТЗ, то очень велика вероятность того, что эта работа достанется Вам и в будущем заказчик к Вам вернется. Воспринимайте это как издержки работы с людьми.
Пора бы прекратить смотреть на программиста, как на некоего безработного, которому нечем заняться, который сидит и ждёт и радуется каждому заказчику и каждому заказу. У программиста есть основная работа, есть свои интересы, есть свободное время. И вряд ли программист с радостью будет тратить своё свободное время на заказ, который может состояться лишь с некоторой вероятностью.