Новые сервисы MQL5.community: Расчеты и Работа - страница 33
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Добрый вечер. Только что задал данный вопрос в обсуждение статьи https://www.mql5.com/ru/forum/3537/page5. Решил продублировать сюда, чтобы по возможности получить больше информации. Скажите. если я включу непосредственно в файл технического задания информацию об оговоренном между мной и программистом сроке выполнения работы (сроком считаю момент получения мной готового советника, а не макета, разумеется), то могу ли я использовать эту информацию как способ аннулировать заказ через арбитраж в случае невыполнения работы в срок? Также в ТЗ могу внести информацию о том, что буду, например, ежедневно (минимум раз в день) выходить на связь для ответов на все вопросы программиста и т. д. и т. п. То есть, короче говоря, если я создам свой маленький регламент непосредственно в ТЗ, защищающий как мои права, так и права программиста, естественно, оговорив это с программистом (логично, он ведь должен прочесть файл ТЗ), может ли это стать правовой основой для моей защиты? Ну вот честно, устал от тех, кто говорит одно, а делает другое... Ведь по сути программист обязан внимательно изучить ТЗ, перед тем как соглашаться на условия заказчика, и если ему что-то не понятно или кажется невозможным, то он обязан говорить об этом сразу, в процессе изучения ТЗ, а не в процессе выполнения. Опять же я могу это тоже включить в свой регламент. Вопрос лишь в том, не будет ли создание своего регламента расцениваться сервисом как нечто неправомерное? Как показывает практика, большинство программистов соглашаются выполнить работу на любых условиях, просто чтобы сказать заказчику то, что он хочет услышать, и получить согласие на выполнение работы. Я устал сливать деньги на таких программистов. Жду ответа на вопрос. Спасибо.
Сроки и цену можно указать непосредственно в работе. Остальное можно в задании.
Хотите получить нормального исполнителя - не гонитесь за 10-долларовыми заявками.
Арбитраж на стороне заказчика обычно.
Сроки и цену можно указать непосредственно в работе. Остальное можно в задании.
Хотите получить нормального исполнителя - не гонитесь за 10-долларовыми заявками.
Арбитраж на стороне заказчика обычно.
То есть, дополнительно описать некоторые свои условия (не упомянутые в регламенте сервиса) я не могу? И если так, то как арбитр расценит невыполнение задания в срок, если это будет одной из главных причин для арбитража с моей стороны? Еще раз повторюсь на всякий случай, что под выполнением в срок подразумеваю готового советника, а не макет. Обычно программисты к сроку готовят только макет. Поэтому я и сделал вывод, что арбитраж по данному вопросу на стороне исполнителя... раз программисты так относятся к понятию "срок". Пока что арбитражем ни разу не пользовался.
Все мои задания сам оцениваю не менее, чем 100 долларов обычно. Поэтому и задался вопросом, как могу себя защитить. Я слил уже более 1000 долларов на не вполне ответственных или не вполне грамотных программистов. И теперь хочу продумать все досконально. Так что про 10-долларовые заявки это не ко мне. И суть тут не в том, какая заявка у исполнителя, на 10 долларов или на 500, а в том, могу ли я защитить свои права. Кто угодно может попросить 500 долларов за свою работу. Это еще не значит, что он хороший программист.
Попробую быть более конкретным и описать пару условий, которые для меня важны:
1. Срок это срок готовности советника, а не макета. Так? И является ли невыполнение в срок уважительной причиной для арбитража? Если так, то при каких условиях с моей стороны я могу не оплачивать заказ и разморозить деньги?
2. Мне необходимо, чтобы программист не предлагал мне альтернативы моим функциям в процессе выполнения ТЗ. Если какая-то функция на его взгляд невозможна или неправильна (и т. п.), то он должен об этом меня поставить в известность перед началом выполнения ТЗ. Могу ли я вписать это требование непосредственно в файл ТЗ, чтобы можно было потом доказать, что программисту это условие было выдвинуто, если вдруг он его нарушит? И может ли это быть 100%-ным доводом для решения в мою пользу в арбитраже?
Попробую быть более конкретным и описать пару условий, которые для меня важны:
1. Срок это срок готовности советника, а не макета. Так? И является ли невыполнение в срок уважительной причиной для арбитража? Если так, то при каких условиях с моей стороны я могу не оплачивать заказ и разморозить деньги?
2. Мне необходимо, чтобы программист не предлагал мне альтернативы моим функциям в процессе выполнения ТЗ. Если какая-то функция на его взгляд невозможна или неправильна (и т. п.), то он должен об этом меня поставить в известность перед началом выполнения ТЗ. Могу ли я вписать это требование непосредственно в файл ТЗ, чтобы можно было потом доказать, что программисту это условие было выдвинуто, если вдруг он его нарушит? И может ли это быть 100%-ным доводом для решения в мою пользу в арбитраже?
к п.1. "не является". Срок готовности зависит не только от разработчика, но и от заказчика. И неизвестно, после предоставления макета, от кого больше. Макет надо проверить, выверить на баги, внести правки, отладить. Т.е. установить точный срок получения итогового решения весьма проблематичная задача.
к п.2. чтобы программист не предлагал вам альтернативы в процессе выполнения -- пишите ТЗ. Вы понимаете что такое ТЗ? Это до мелочей, до функций, до алгоритмов функций проработанный ваш будущий советник. Проработанный вами. Проработанный настолько полно и подробно, что разработчик уже выступает простым кодировщиком и не более того. Вы способны написать такое ТЗ?
p.s. Вам проще найти вменяемого разработчика. Задача не простая, но выполнимая. Чтобы не терять средства на разработки, пишите ТЗ, проверяйте макет, требуйте неукоснительное выполнение ваших требований. Арбитраж в местном Фрилансе преимущественно на стороне заказчика. Если заказчик, конечно, адекватен.
к п.1. "не является". Срок готовности зависит не только от разработчика, но и от заказчика. И неизвестно, после предоставления макета, от кого больше. Макет надо проверить, выверить на баги, внести правки, отладить. Т.е. установить точный срок получения итогового решения весьма проблематичная задача.
к п.2. чтобы программист не предлагал вам альтернативы в процессе выполнения -- пишите ТЗ. Вы понимаете что такое ТЗ? Это до мелочей, до функций, до алгоритмов функций проработанный ваш будущий советник. Проработанный вами. Проработанный настолько полно и подробно, что разработчик уже выступает простым кодировщиком и не более того. Вы способны написать такое ТЗ?
p.s. Вам проще найти вменяемого разработчика. Задача не простая, но выполнимая. Чтобы не терять средства на разработки, пишите ТЗ, проверяйте макет, требуйте неукоснительное выполнение ваших требований. Арбитраж в местном Фрилансе преимущественно на стороне заказчика. Если заказчик, конечно, адекватен.
По пункту 1 я выше писал, что со своей стороны могу обеспечить ежедневную связь с программистом. Опять же, как показывает практика, большинство программистов почти не задают вопросы до наступления оговоренного срока и к сроку скидывают лишь макет. И вот тут в мешке я нахожу кота... Я уже готов к тому, чтобы программист сам назвал мне свой ГАРАНТИЙНЫЙ срок, то есть такой срок, когда советник будет полностью готов с учетом всех возможных исправлений. Его задача изучить ТЗ и решить, насколько оно сложное (то есть осталось ли ему только выложить стратегию в коде или еще надо придумывать, как это сделать). Общаясь со мной, если он адекватен, он поймет, насколько я способен ему помочь в решение его задачи, и соответственно сможет определить реальные сроки.
По пункту 2 да, я способен писать такие ТЗ, хотя и не по всем функциям, но честно скажу, что как правило, не делаю этого по той причине, что мне, конечно, проще выложить лишь информацию о том, что я хочу увидеть в конечном результате. Опять же это вопрос времени и денег. И как я уже написал выше, программист должен определить, насколько сложна задача, сколько она потребует времени и денег. Но альтернативы моим функциям мне не нужны. Зачастую под такими предложениями альтернатив скрывается желание программиста найти более легкий для него путь либо вообще неспособность выполнить мою задачу (с таким я тоже сталкивался). Я уже принял решение не ставить программистам слишком жесткие условия по срокам. Пусть срок называет исполнитель, лишь бы он меня устроил и был сроком получения мной готового советника. Иначе срок это пустой звук. Программирование это не отдельная республика. Это такой же труд, как и любой другой. И должен подчиняться единым трудовым законам...
И еще к вопросу по срокам... Срок важен как юридическая величина еще и по той причине, что меня, например, естественно мучает, если программист очень долго не может решить тот или иной вопрос. И мне приходится делать проверки одной (порой довольно простой) функции по многу раз. В этом случае для меня становится очевидным низкий уровень профессиональной грамотности исполнителя. В частности поэтому мне хочется всегда услышать адекватный срок от программиста. На мой взгляд это единственная объективная величина, которая сможет показать, насколько грамотен и ответственен исполнитель. Все остальное мне лично кажется демагогией.
Да что тут говорить, срок либо есть, либо его нет... Срок изготовления макета это ничто. Под макетом может скрываться какая угодно степень нереализованности задач... И я этого отследить никак не могу. Так что, то, что вы говорите по поводу сроков, это лишь защита для вашего комфорта, но не для комфорта заказчика.
Попробую быть более конкретным и описать пару условий, которые для меня важны:
1. Срок это срок готовности советника, а не макета. Так? И является ли невыполнение в срок уважительной причиной для арбитража? Если так, то при каких условиях с моей стороны я могу не оплачивать заказ и разморозить деньги?
2. Мне необходимо, чтобы программист не предлагал мне альтернативы моим функциям в процессе выполнения ТЗ. Если какая-то функция на его взгляд невозможна или неправильна (и т. п.), то он должен об этом меня поставить в известность перед началом выполнения ТЗ. Могу ли я вписать это требование непосредственно в файл ТЗ, чтобы можно было потом доказать, что программисту это условие было выдвинуто, если вдруг он его нарушит? И может ли это быть 100%-ным доводом для решения в мою пользу в арбитраже?
Заложите запас в срок самостоятельно.
Если макет будет готов за 5 дней, добавьте еще 5 (а лучше 10) на проверку и косметические правки.
Прописать в задании вы можете все что угодно, но не думаю, что арбитраж моментально вернет вам деньги только потому что "программист не ответил на вопрос в течении 12 часов, а это было указано в ТЗ". Нужно самому найти грань адекватности.
По несоответствиям с реализацией функций проблем быть не должно. Если вы сказали, что нужно так, то так и должно быть реализовано (если вы в обсуждении не приняли предложение программиста по переделке).
Где я могу узнать мнение третьей стороны? То есть непосредственно арбитра. Я написал в сервис-деск вчера, мне пока не ответили.
Видимо, не можете. Ренат вон заходил, но вам решил не отвечать.
Статистика по арбитражу: