Правила в разделе Работа - страница 5

 
Yedelkin:
А вот и концепуально иной подход к решению проблемы :)
Базара нет. )))
 
pronych:

Исходник может быть хорошо проработанным шаблоном, с кучей дополнительных возможностей, классов, и т.д. Он может состоять из кучи блоков (инклюдов, например) и только некоторые условия в нем могут различаться. Вы готовы отдать полугодовую (в простом случае) наработку, в исходниках из десятка различных файлов одной системы (системы, в смысле взаимодействия между собой), в которой отличается только сигнальный модуль(один класс(файл))?

Я понимаю, можно стандартными средствами бахнуть пересечение машек, и не жалко. А если колоссальный труд в шаблон вложен, тогда как? Нет, вот конкретно Вы готовы?

Получается, что в подобных случаях шаблон лучше отдавать в виде скомпилированного файла, а сигнальный модуль - на усмотрение Заказчика. Такая опция (о которой уже говорилось) подойдёт всем?

...Но в таком случае риск "нового билда" перекладывается на Заказчика,  а гарантия устранения такого риска - остаётся всего лишь на совести Инсполнителя. 

 
Yedelkin:

Здесь - фундаментальная ошибка. Договор - это соглашение двух или более лиц. Заявка - это лишь предложение одной стороны, которое само по себе договором считаться не может. Исходя из сути обсуждаемых Правил, о возникновении договорных отношений (о заключении договора) можно судить только после оформления ТехЗадания. Именно ТехЗадание предназначено для отражения всех согласованнных обеими сторонами деталей работы.


Я не утверждал, что в нашем случае заявка является договором, я лишь высказал пожелание в том что она должна быть приближена к нему (т.е. заявка по моему мнению должна содержать некие обязательные поля/галочки), а ТЗ более детально раскрывать особеннсоти выполняемой работы и определять определенные моменты которых исполнитель должен придерживаться.

При этом я уверен что как минимум 60% трейдеров не являющихся программистами половину из ТЗ проигнорируют.

 
Interesting:

Я не утверждал, что в нашем случае заявка является договором...

Interesting:

... я считаю, что в обычных условиях договор (читай заявка) ...

Как обычно, я комментировал то, что выделено :)
 
Interesting:

При этом я уверен что как минимум 60% трейдеров не являющихся программистами половину из ТЗ проигнорируют.

Вот поэтому я утверждал и продолжаю утверждать, что при составлении ТехЗадания (в свете конкретных Правил) Исполнитель должен смело брать на себя инициативу при согласовании деталей работы и отражении их в документе. Потому что именно Исполнителю в случае чего придётся разгребать претензии Заказчика. А коряво составленное по вине Исполнителя ТехЗадание будет только способствовать возникновению ненужных споров.
 
Yedelkin:
Получается, что в подобных случаях шаблон лучше отдавать в виде скомпилированного файла, а сигнальный модуль - на усмотрение Заказчика. Такая опция (о которой уже говорилось) подойдёт всем?
Не совсем, всем.)) Впрочем тоже, конечно, вариант...  По мне, так удобней, чтоб был один готовый файл. Это усложняет задачу (читай-'стоимость') Но разговор даже не об этом. такой подход разветвляет идею, а заказчик у нас не шарит (или шарит! они разные могут быть) в таких вещах, хоть и не дурак )) Думаю, галки "Хочу исходники" вполне хватит, и это, как раз решит большинство вопросов до согласования тз. Если с этим вопросом будет понятно, то можно дальше обсуждать задание. а там, хоть трава не расти, совсем другая стадия.
 
pronych:
Не совсем, всем.)) Впрочем тоже, конечно, вариант...  По мне, так удобней, чтоб был один готовый файл. Это усложняет задачу (читай-'стоимость') Но разговор даже не об этом. такой подход разветвляет идею, а заказчик у нас не шарит (или шарит! они разные могут быть) в таких вещах, хоть и не дурак )) Думаю, галки "Хочу исходники" вполне хватит, и это, как раз решит большинство вопросов до согласования тз. Если с этим вопросом будет понятно, то можно дальше обсуждать задание. а там, хоть трава не расти, совсем другая стадия.

Тогда что получается? Рабочий вариант для решения Вашей проблемы выглядит так:

1. С формальной стороны - новый пункт в Правилах;

2. С технической стороны - в форме для Заявки ввести опцию "Требуется исходный код" с умолчанием "Не требуется"? 

 
Yedelkin:
Вот поэтому я утверждал и продолжаю утверждать, что при составлении ТехЗадания (в свете конкретных Правил) Исполнитель должен смело брать на себя инициативу при согласовании деталей работы и отражении их в документе. Потому что именно Исполнителю в случае чего придётся разгребать претензии Заказчика. А коряво составленное по вине Исполнителя ТехЗадание будет только способствовать возникновению ненужных споров.

Да уж. Такое вероятно. Так давайте сразу еще подумаем (тихаря, пока раработчики спят))), какие добавления хочем просить в разделе 'Работа'? Но я первый!

Хачу галку! 'Исходники'

:)) 

 
Yedelkin:

Тогда что получается? Рабочий вариант для решения Вашей проблемы выглядит так:

1. С формальной стороны - новый пункт в Правилах;

2. С технической стороны - в форме для Заявки ввести опцию "Требуется исходный код" с умолчанием "Не требуется"? 

Верно
 

Есть на мой взгляд еще один, альтернативный путь - Между исполнителем и заказчиком встает некий посредник-арбитр (в нашем случае MQ), при этом исполнитель передает весь пакет материалов + исходники посреднику (который их проверяет на соответствие ТЗ), после чего  заказчик получает от посредника уведомление о завершении выполнения работы и обязан оплатить ее.

В зависимости от эксклюзивности работы и первоначальных договоренностей после оплаты заказчик получает максимально открытый исходный код или просто скомпилированные файлы.

При этом как понимаете посредник получает определенное вознаграждение.

PS

Хотя это думается мне MQ не очень по нраву...

Причина обращения: