Стоит ли менять правила во фрилансе,чтобы они были четко прописаны - страница 4

 
Арбитраж разбирает споры между сторонами на остовании написанного ТЗ в прикрепленном файле и итогу работы. Если же написано "обо всём договорились или договоримся в скайпе", чью сторону должен будет принять арбитраж ?
 
Vladimir Zubov:
Арбитраж разбирает споры между сторонами на остовании написанного ТЗ в прикрепленном файле и итогу работы. Если же написано "обо всём договорились или договоримся в скайпе", чью сторону должен будет принять арбитраж ?
Сторону исполнителя, если он хоть что-то сделал (и это отражено в исходнике передаваемом заказчику). 
 
Vladimir Zubov:
Арбитраж разбирает споры между сторонами на остовании написанного ТЗ в прикрепленном файле и итогу работы. Если же написано "обо всём договорились или договоримся в скайпе", чью сторону должен будет принять арбитраж ?

Должен расторгнуть контракт но выплатить половину исполнителю. 

 
-Aleks-:

Должен расторгнуть контракт но выплатить половину исполнителю. 

Получается способ получить работу за пол цены
 
Vladimir Zubov:
Арбитраж разбирает споры между сторонами на остовании написанного ТЗ в прикрепленном файле и итогу работы. Если же написано "обо всём договорились или договоримся в скайпе", чью сторону должен будет принять арбитраж ?
Рассмотреть претензию по существу, а комбатанты будут собачиться без ссылок на ТЗ. Это если захочет разбираться, не захочет - пополам
 
-Aleks-:
Как минимум, об этом надо предупредить Заказчика, мол я не хочу отдавать свои наработки... речь о том, что по умолчанию код должен отдаваться, если не оговорено сторонами иное.

Верно! совершенно

Потому все эти тонкости  надо оговаривать на берегу до того как проект запущен.

И если заказчик знает о том что ему нужны исходники он должен предупредить программиста

И если программист не желает расставаться с библиотеками своими, то тоже должен  пояснить это заказчику и оговорить заранее.

Если не использовать наработки - это по логике  затормозит время на создание проекта.

Т к коды свеже - написанные всегда требуют больше проверок  , тестов более тщательных и  время на их писанину.

В общем если заказчик  хочет исходники - пусть готовится к большему сроку по реализации и к большей цене за работу.

 
Ihor Herasko:
Продукт - это программа, которая должна выполнять алгоритм, прописанный в ТЗ. Если программа его выполняет, то продукт считается произведенным. Исходный код программы - это оборудование, на котором выполнялась разработка продукта. Когда приходит заказчик к мебельщику, то он получает вместе с мебелью оборудование, на котором была произведена эта мебель? Нет. Точно также и с программами - исходный код исполнитель предоставлять не обязан. Хотя в большинстве случаев такое и делается. Но это вовсе не значит, что подобное обязательство является умолчательным. При составлении ТЗ все это можно было бы обговорить. Раз не оговорено, то и предмета обсуждения нет - по желанию исполнителя.

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

Когда человек заказывает код - то он покупает код высокого уровня.

Если ему продают компилированную версию - это уже не покупка - это аренда с правом пользования, но без права распоряжения. Т.е. другой вид сделки.

 Т.е. кодеры, продающие машинную адаптацию кода вместо самого кода - мошенники.

 
Dmitry Fedoseev:
Получается способ получить работу за пол цены

Не совсем, каждый виноват - оставили договоренность по деталям на потом, за это и заплатили столько и получили...

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

А из моего опыта очень много программистов бросают проекты и уходят, часто вообще с ресурса. 

 
-Aleks-:

Не совсем, каждый виноват - оставили договоренность по деталям на потом, за это и заплатили столько и получили...

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

А из моего опыта очень много программистов бросают проекты и уходят, часто вообще с ресурса. 

Часто после доработки чужого кода заказчик потом обращается по поводу любых проблем с советником. Получается, что на последнего дорабатывающего сваливается вся ответственность. Даже если объяснишь, что отвечаешь только за свою доработку, все равно потом будет пара вопросов, надо будет выяснить, что это проблема точно не в доработке, еще объяснить доходчиво. 

Часто заказчики из принципа убегают к другому программисту после конфликта, тут полезно выяснит, почему же заказчик пришел с чужим кодом, если что, вернуть его назад. От себя не убежишь. Если там был конфликт и что-то не поделили, очень вероятно что и здесь будет так же. Заказчик тоже должен активно думать, не всем это нравится.

Сама доработка чужого кода требует досконально разобраться в коде. Получается дорого.  

 
Dmitry Fedoseev:

Часто после доработки чужого кода заказчик потом обращается по поводу любых проблем с советником. Получается, что на последнего дорабатывающего сваливается вся ответственность. Даже если объяснишь, что отвечаешь только за свою доработку, все равно потом будет пара вопросов, надо будет выяснить, что это проблема точно не в доработке, еще объяснить доходчиво. 

Часто заказчики из принципа убегают к другому программисту после конфликта, тут полезно выяснит, почему же заказчик пришел с чужим кодом, если что, вернуть его назад. От себя не убежишь. Если там был конфликт и что-то не поделили, очень вероятно что и здесь будет так же. Заказчик тоже должен активно думать, не всем это нравится.

Сама доработка чужого кода требует досконально разобраться в коде. Получается дорого.  

В том то и дело, что разборка чужого кода, получается, задача сложней, чем написание нового с нуля. Поэтому и встал вопрос о культуре программирования, организации кода, читабебельности кода, комментариях в коде.

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

Может мне так везет, но я часто теряю исполнителя по причинам его ухода с ресурса... 
Причина обращения: