Спасибо большое.
А теперь то, что бросилось в глаза сразу:
1. Промазали со знаком ударения :). "Техни́ческое зада́ние (ТЗ, техзада́ние)"
2. "...двусторонним актом сдачи-пpиемки". "Акт приема-передачи" как-то приятнее звучит.
П. 3.5 Стоит оговорить, на кокой хостинг. Все ли там установленно. А то как то нам дали IP адрес для SSH, логин и пароль. А все остальное - устанавливайте сами. Пришлось оговаривать, что это будет дополнительно работой с привлечением квалифицированного системного администратора.
я не знаю насколько необходимо в таком договоре забивать технические требования на хостинг. Этот вопрос можно и в ТЗ оговорить.
А лучше всего сделать ссылку в договоре на приложение(скажем №3) где и будут оговорены все технические моменты! мне кажется это наиболее оптимальным
Я согласен, что тонкости хостинга (как и многие другие тонкости) стоит указыать в приложениях или ТЗ. Может, в скобках стоит указывать - что куда ссылается - для общего понимания.
1.1. В рамках настоящего договора Исполнитель обязуется по заявке Заказчика выполнить и сдать работу по разработке программного обеспечения, предназначенного для оформления и размещения в сети Интернет материалов Заказчика, именуемое в дальнейшем Сайт.
1.2. Технические требования к разработке определены в Техническом Задании (Приложение №1) на разработку Сайта, которое является неотъемлемой частью настоящего Договора.
Я не дам, слишком долго все утрясать приходиться, чтоб на халяву его выкладывать =)
просмотрев весь договор я бы его очень сырым не назвал))) он достаточно развернуто регламентирует основные моменты...но вне сомнения над ним надо еще много работать...именно поэтому он за основу и был взят) чтобы мы совместно сделали что-то какаю-то серьезную рыбу...а каждый его адаптирует под свою специфику и нужды.
Ваш вариант положения о предмете договора более четко отражает его суть.
Единственное добавил бы сюда Опросный лист..т.к. думаю в большинстве случаев без него не обходится.
1. Предмет договора
1.1. В рамках настоящего договора Исполнитель обязуется по заявке Заказчика выполнить и сдать работу по разработке программного обеспечения, предназначенного для оформления и размещения в сети Интернет материалов Заказчика, именуемое в дальнейшем Сайт.
1.2. Технические требования к разработке определены в Техническом Задании (Приложение №1) и Опросном листе (Приложение №2)на разработку Сайта, которые являются неотъемлемой частью настоящего Договора.
Добрый день.
В свете уже на носу назойливо сидящего введения 4 части ГК, как в договоре быть с правами?
Если я верно понимаю, то в договоре должна быть оговорена передача имущественных (исключительных) прав. То есть, судя по статье 1233, должно быть оговорено либо право использования результата деятельности, либо отчуждение права.
И если речь идет об отчуждении прав, то должно быть оговорено вознаграждение.
Достаточно ли и корректно в таком разе формулировку соответствующих пунктов привести так?
5.2 Исполнитель гарантирует, что передаваемые по Договору результаты работ не нарушают интеллектуальные права других лиц.
5.3 Исполнитель передаёт Заказчику в полном объёме исключительные права результаты работ по настоящему Договору.
5.4 Исполнитель обязан известить Заказчика вместе с передачей результатов работ об использованных программных продуктах, являющихся объектами интеллектуальных прав третьих лиц и условиях их лицензирования.
5.5 Вознаграждение Исполнителя за передачу прав входит в состав оплаты за произведённые работы.
Я не знаком с ГК РФ...так как живу в Минске!(на этот вопрос пусть ответят юристы РФ)
Но у нас положения о передачи авторских прав можно прописать как в самом договоре, так и заключив отдельный.
>5.2 Исполнитель гарантирует, что передаваемые по Договору результаты работ не нарушают >интеллектуальные права других лиц.
>5.3 Исполнитель передаёт Заказчику в полном объёме исключительные права результаты работ по >настоящему Договору.
>5.4 Исполнитель обязан известить Заказчика вместе с передачей результатов работ об использованных >программных продуктах, являющихся объектами интеллектуальных прав третьих лиц и условиях их >лицензирования.
>5.5 Вознаграждение Исполнителя за передачу прав входит в состав оплаты за произведённые работы.
Написано не совсем корректно...вы можете передать только исключительные имущественные права!!!
Я не хотел бы сейчас переводить русло в тематику передачи авторских прав т.к. мы планируем через некоторое время выложить часть договора, которая как раз будет содержать такие положения.
а если я верно прочитал, оно теперь и определяется как имущественное:
"На результаты интеллектуальной деятельности и приравненные к ним средства индивидуализации (результаты интеллектуальной деятельности и средства индивидуализации) признаются интеллектуальные права, которые включают исключительное право, являющееся имущественным правом, а в случаях, предусмотренных настоящим Кодексом, также личные неимущественные права и иные права (право следования, право доступа и другие)." (ст. 1226)
Пункт
2.6. В случае приостановления по требованию Заказчика выполнения работ по настоящему Договору денежные средства, полученные Исполнителем за выполнение этапов работ, Заказчику не возвращаются.
Как-то кривоват.
Либо расторжение договора по требованию Заказчика (но в этом случае пункт должен находиться в другой главе), либо в этом пункте речь должна идти о сроках, а не о денежных средствах.
Я так понимаю по ХР никто с заказчиками еще не работал?
В большинстве своём клиент не до конца понимает, что хочет получить в результате разработки.
Жесткое ТЗ создает рамки, из которых ни одна сторона не сможет выйти – ибо договор обязывает…
Изменение ТЗ требует дополнительной работы по описанию изменений и оформлению документов, что при работе с удаленным заказчиком создает трудности.
на написание ТЗ уходит действительно много времени...но без него никак нельзя...дело в том что совершенно разные подходы работы и оплаты....в большинстве своем заказчик желает знать на какую суму ему расчитывать +-20%...ваш подход может выйти за рамки предполагаемого клиентом бюджета очень быстро.
да на ТЗ уходит время и затраты...но с его помощью ставятся четкие задачи разработчикам...а тот кто управляет проект, должен очень серьезно подойти к разработке ТЗ и взаимодействию с заказчиком в этот момент.
как можно подписывать договор, для которого нет еще ТЗ?
А ТЗ будет разработано в ходе договора.
Приблизительно:
Статья 1. ПРЕДМЕТ ДОГОВОРА
Исполнитель выполняет, а Заказчик оплачивает работы по созданию веб-сайта.
Работы по Договору выполняются в N этапов:
1. Изучение....
2. Разработка и согласование ТЗ.
N. Выполнение работ согласно ТЗ
Статья 2. СТОИМОТЬ РАБОТ И ПОРЯДОК ВЗАИМОРАСЧЕТОВ СТОРОН
Работы оплачиваются поэтапно
Статья 3. СРОКИ ВЫПОЛНЕНИЯ РАБОТ
1-й этап
2-й этап
и т.д
Странно, проекты по 3-4 месяца, до 7 JAVA программистов + пара дизайнеров у нас успешно реализуют проекты без ТЗ.
Хороший проект-менеджер решает вопросы на лету.
пример. Вчера не было ВЕБ 2.0, и позавчера не было, а договор начался позапозавчера. А сегодня Заказчик захотел, за те де деньги, что-то типа "Ой, Вась, и я такую же хочу..."
Наверное по-разному
И какой выход?
Сделать клиенту то что он уже не хочет?
Переубеждать что веб 2.0 - "так себе"?
По итогу все равно придеться переделывать, а ТЗ сделать это не позволит.
Не этично работать на "шару". Вы работу сделали? Вам, вашим детям кушать хочется? А "жуки" в голове Заказчика, не есть Ваша проблема.
1. Вы шли по графику?
2. Вы сделали часть работы?
3. Будьте добры оплатите.
Вот именно по этому я за ХР.
То есть за подход в юридическом оформлении договора с точки зрения повременной оплаты и гибкого подхода к разработке проекта.
Раз в 2 недели (или чаще в зависимости от объема проекта) корректируем направление работы и формируем план на ближайшие 1-2 итерации.
А договор с ТЗ настраивает клиента на то что он будет платить за результат, а так как определенность в проекте очень низкая (много может поменяться в процессе разработки)
Готовность платить клиента за незаконченный проект стремиться к нулю.
В повременке же клиент уже привязан к проекту заплаченными деньгами. И у сторон сохраняется мотивация закончить проект. Пусть даже с изменениями и с превышенным бюджетом. А законченный проект это всем +.
У повременки есть «слабое звено» - затягивание сроков, но это определяется репутацией – затянул пару раз сроки (покачал деньги из клиента) и привет.. с тобой никто не работает.
За что платить, если не выполнена часть работы? Если работа выполнена некачественно.
Не думаю что ХР здесь к месту.
ХР это уже принципы работы команды разработчиков.
Выход? Предугадать желание Заказчика, т.е. быть "впереди планеты всей", рассказывать Заказчику, что вот-вот грянет ВЕБ 3.0, а тут, бац, а у нас уже проект готов.
Предугадать желание заказчика? Конечно да.
Большинство заказчиков не понимают, что они хотят, многие не имеют вкуса (что уж душой кривить), часть вообще не разбирается в технологиях близких к ИТ.
Мы должны не только и не столько исполнять их текущие задачи, а предугадывать и даже формировать желания заказчиков (прививать вкус к хорошему дизайну и качественному исполнению + формировать возможности для их бизнеса в будущем).
А проекты «Сделал - Забыл» не Вам большой пользы не приносят ибо часто умирают без поддержки, ни тем более заказчику.
так все это делается на стадии разработки и написания ТЗ...+ варфрэйма(где заказчик может покликать и посмотреть как это будет работать).
непосредственное создание сайта это процесс реализации достигнутых договоренностей...в который заказчику постоянно влазить уже не надо...с ним идет согласование дизайна...а все остальное он уже не видит
Сделал-Забыл - кормят моих детей и кормили - это, ну скажем "праздничная" шоколадка.
Проект для моей пользы - это что? Заказчик будет оплачивать мою учебу?
Проект для пользы Заказчика - это уже и хлеб с маслом и ... красная икра.
>Сделал-Забыл - кормят моих детей и кормили - это, ну скажем "праздничная" шоколадка.
То есть вам не важна судьба ваших проектов в дальнейшем?
>Проект для моей пользы - это что? Заказчик будет оплачивать мою учебу?
Это новые связи и рекомендации довольного клиента.
>Проект для пользы Заказчика - это уже и хлеб с маслом и ... красная икра.
=)
Без ТЗ невозможно.
Даже если взять принцип "партнерского программирования", должны быть оговорены Права и Обязанности обеих сторон.
Т.е. Для начала работ принимается первоначальное ТЗ, с оговоренными сроками начальных работ и, наверное обязательно, с объемом этих работ.
Любой этап ТЗ, должен быть законченным продуктом (процессом), естественно если результат будет положителен. Например, прекращение работы в случае необходимости скрещивания мухи и слона, и продолжение работ в случае - собаки и волка.
ОК. Если ТЗ умещается на одной странице и является приложением к договору - я с Вами согласен. Всё остальное не является документами (в юридическом смысле), а просто рабочие записи и переписка с клиентом.
В договоре оговаривается процесс общения с клиентом и согласования, в том числе и электронным способом. ЭЦП - примените, вопросов не будет, и Заказчик в отказ уходить не будет. Даже если хотите система - "электронного документооборота"
п3.
"Сдача-приемка этапа разработки Информационной системы осуществляет Клиент в течение трех рабочих дней с даты уведомления, о готовности этапа разработки Информационной системы. "
1. СдачУ-приемкУ, наверное
2. после "с даты уведомления" запятую не надо
ТЗ VS XP и их юридическое оформление