Правила в разделе Работа - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
...А потом дополнили: "Не знаю как там по правильному но я лично считаю что ТЗ вторично и является только приложением к договору (заявке)". Что я и прокомментировал, с выделением комментируемых фраз. Суть комментария: при выполнении определённых условий ТЗ может оказаться самодостаточным (первичным по Вашей терминологии). Ну это так, к слову, предмета для спора ведь нет :)
Так в реальной жизни договор/контракт действительно первичен, не разу не встречал ТЗ без договора (при этом обычно в ТЗ только техническая информация, а в договоре основная суть юридических отношений сторон).
Лично я привык к такой последовательности:
1. договор/контракт на выполнение работ (в котором указаны заказчик, исполнитель, основная суть выполняемой работы, сроки выполнения работы, сумма которую платит заказчик исполнителю, ответственность сторон и дополнительная информация при необходимости);
2. ТЗ, в котором более детально описано само задание и приведены конкретные характеристики выполняемой работы (при этом заказчик не обязан досконально разбираться в том что содержится в ТЗ);
3. Акт выполненных работ;
4. Оплата работы или ее этапа.
Исходя из выше следующего я считаю, что в обычных условиях договор (читай заявка) имеет более высокий статус чем ТЗ (ТЗ формируется на основании договора с подробной детализацией работы или конкретного этапа).
Предположу что в нашем разработчикам (как организаторам сервиса) нужно более детально подойти к содержанию заявки, приблизив ее к реальному договору.
Также возможно стоит выделить процесс формирования ТЗ, позволив исполнителю получить определенную сумму (указанную точно или как процент от заказа), конечно в том случае если исполнитель самостоятельно подготовил ТЗ и заказчик с ним согласился.
pronych:
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
Это техническая сторона решения части проблемы. Фактически, Вы выдвигаете требование к Заказчикам "определиться с типом итогового файла", определиться на этапе заполнения Заявки. Соответственно, такое требование к Заказчикам необходимо (с формальной точки зрения) отразить и в Правилах. Чтоб Заказчики понимали, что от них требуется.
Причём Исполнителю (в его же интересах) не стоит успокаиваться при виде Заявки, а следует добиться согласования данного вопроса непосредственно в ТехЗадании.
А вообще, проще всего не мудрить с правилами, а просто, при вводе заявки добавить "снятую" галку, типа "хочу исходники" и отражать это в списке заданий. кому надо, тот отметит флажок. небольшой апдейт, а как приятно. и всем всё сразу понятно будет.
На мой взгляд саму "заявку" нужно переработать более детально. Там не только это должно быть, а еще много чего. К примеру, также можно выделить галочкой условия разрешающие/запрещающие исполнителю в дальнейшем использовать алгоритмы и программный код.
Хотя понимаю что подобные вещи очень трудно проконтролировать.
PS
Тут дело в том что как я понимаю в отличии от МАГАЗИНА заказчику никто не мешает растиражировать работу (особенно если есть исходный код), а исполнитель с легкостью может выставить ее в магазин или перепродать другому заказчику.
Это техническая сторона решения части проблемы. Фактически, Вы выдвигаете требование к Заказчикам "определиться с типом итогового файла", определиться на этапе заполнения Заявки. Соответственно, такое требование к Заказчикам необходимо (с формальной точки зрения) отразить и в Правилах. Чтоб они понимали, что от них требуется.
Причём Исполнителю (в его же интересах) не стоит успокаиваться при виде Заявки, а следует добиться согласования данного вопроса непосредственно в ТехЗадании.
Если быть точным то тут скорей нужно сделать некую условность выбора. Если заказчику обязательно нужны исходники то тут уже ничего поделать нельзя, в противном случае у исполнителя будет выбор.
При этом заказчик должен понимать что исходники и эксклюзивность работы (при наличии таковой) будут стоить дополнительных денег.
Подумав хорошенько, считаю так. Если программист пишет что-то по ТЗ заказчика, то должен передать ему и исходник. Во-первых, вряд ли разработчики когда-то скажут, что никакой новый билд никогда больше не потребует перекомпиляции. Во-вторых, это нужно для решения спорных вопросов. Возможно, что ТЗ неверно сформулировано, неверно понято или программист просто ошибся. В первом случае заказчик должен оплатить работу по новому ТЗ повторно или оставить программиста в покое. Во втором и третьем - программист должен исправить бесплатно свои косяки. Как без исходника разобраться, кто прав?
Что собственно такого есть в исходнике, что нельзя передать заказчику? Хорошая торговая идея, то есть ТЗ, стоит куда больше, чем какие-то программерские секреты.
Если же вы продаете софт, написанный по вашим собственным идеям, о передаче исходников и речи быть не может.
Исходя из выше следующего я считаю, что в обычных условиях договор (читай заявка) ...
Здесь - фундаментальная ошибка. Договор - это соглашение двух или более лиц. Заявка - это лишь предложение одной стороны, которое само по себе договором считаться не может. Исходя из сути обсуждаемых Правил, о возникновении договорных отношений (о заключении договора) можно судить только после оформления ТехЗадания. Именно ТехЗадание предназначено для отражения всех согласованнных обеими сторонами деталей работы.
...Описанный же Вами подход к связке Договор-ТЗ можно назвать классическим, который никоим образом не отменяет существованние иных равноправным форм устаканивания возникших договорных отношений. Образно говоря, глава 36 "Договор подряда" ГК РФ - это родительский класс со своими публичными и защищёнными членами, виртуальными функциями, а ТехЗадание - один из возможных классов-потомков. :)
Interesting:
Это техническая сторона решения части проблемы. Фактически, Вы выдвигаете требование к Заказчикам "определиться с типом итогового файла", определиться на этапе заполнения Заявки. Соответственно, такое требование к Заказчикам необходимо (с формальной точки зрения) отразить и в Правилах. Чтоб Заказчики понимали, что от них требуется.
Причём Исполнителю (в его же интересах) не стоит успокаиваться при виде Заявки, а следует добиться согласования данного вопроса непосредственно в ТехЗадании.
Если быть точным то тут скорей нужно сделать некую условность выбора. Если заказчику обязательно нужны исходники то тут уже ничего поделать нельзя, в противном случае у исполнителя будет выбор.
При этом заказчик должен понимать что исходники и эксклюзивность работы (при наличии таковой) будут стоить дополнительных денег.
Подумав хорошенько, считаю так. Если программист пишет что-то по ТЗ заказчика, то должен передать ему и исходник.
Что собственно такого есть в исходнике, что нельзя передать заказчику? Хорошая торговая идея, то есть ТЗ, стоит куда больше, чем какие-то программерские секреты.
Если же вы продаете софт, написанный по вашим собственным идеям, о передаче исходников и речи быть не может.
Исходник может быть хорошо проработанным шаблоном, с кучей дополнительных возможностей, классов, и т.д. Он может состоять из кучи блоков (инклюдов, например) и только некоторые условия в нем могут различаться. Вы готовы отдать полугодовую (в простом случае) наработку, в исходниках из десятка различных файлов одной системы (системы, в смысле взаимодействия между собой), в которой отличается только сигнальный модуль(один класс(файл))?
Я понимаю, можно стандартными средствами бахнуть пересечение машек, и не жалко. А если колоссальный труд в шаблон вложен, тогда как? Нет, вот конкретно Вы готовы?
Подумав хорошенько, считаю так. Если программист пишет что-то по ТЗ заказчика, то должен передать ему и исходник. Во-первых, вряд ли разработчики когда-то скажут, что никакой новый билд никогда больше не потребует перекомпиляции. Во-вторых, это нужно для решения спорных вопросов. Возможно, что ТЗ неверно сформулировано, неверно понято или программист просто ошибся. В первом случае заказчик должен оплатить работу по новому ТЗ повторно или оставить программиста в покое. Во втором и третьем - программист должен исправить бесплатно свои косяки. Как без исходника разобраться, кто прав?
Что собственно такого есть в исходнике, что нельзя передать заказчику? Хорошая торговая идея, то есть ТЗ, стоит куда больше, чем какие-то программерские секреты.
Если же вы продаете софт, написанный по вашим собственным идеям, о передаче исходников и речи быть не может.
1. Обязательная передача исходников уместна только при эксклюзивности выполняемой работы, при этом как понимаете цена будет иной (возможно в разы больше).
Вопрос с перекомпиляцией тоже можно решить в самом начале.
2. По поводу ТЗ
Ну не видел я на Forex "хороших" идей, которые бы стоили больше "хорошей" программной реализации.
На поставленный вопрос отвечу так - В исходнике есть возможность позволяющая заказчику утверждать что он правооблодатель и может делать с кодом все что угодно (к примеру продать его).
Поэтому речь идет скорей всего об эксклюзивности выполняемой работы (и тут я поддерживаю программистов не стремящихся распространяться исходный код).