Comments 47
Могу пожелать только удачи и хорошего юриста. Хорошо, что на будущее свои ошибки уже увидели.
Ситуация, когда на два юриста бывает три мнения тоже часто случается. Казус, как говорят юристы.
Немного непонятен абзац:
«Каждая из сторон по-своему трактовала предмет договора. Компания исполнитель понимала под этим доработку стандартной конфигурации 1С: Предприятие под задачи заказчика, ее настройку и внедрение. Заказчик видел то, что будет произведена установка и настройка 1С: Предприятие без какой-либо ее модификации.»
Если заказчик подразумевал под предметом исполнения договорных обязательств установку типовой конфигурации без какой-либо ее модификации, то к чему вообще были доработки? Нестыковка какая-то. Т.е. если заказчик утверждал что ему была нужная типовая конфа без доработок, то фактически она у него уже была и предмет спора как таковой не существовал.
Либо в приведенном абзаце что-то напутано, либо я чего-то не так понял.
«Каждая из сторон по-своему трактовала предмет договора. Компания исполнитель понимала под этим доработку стандартной конфигурации 1С: Предприятие под задачи заказчика, ее настройку и внедрение. Заказчик видел то, что будет произведена установка и настройка 1С: Предприятие без какой-либо ее модификации.»
Если заказчик подразумевал под предметом исполнения договорных обязательств установку типовой конфигурации без какой-либо ее модификации, то к чему вообще были доработки? Нестыковка какая-то. Т.е. если заказчик утверждал что ему была нужная типовая конфа без доработок, то фактически она у него уже была и предмет спора как таковой не существовал.
Либо в приведенном абзаце что-то напутано, либо я чего-то не так понял.
Скорее разная терминология. При работах по платформам типа 1С это не редкость. Заказчик «почему-то» уверен, что купив «коробку» он получил всё, что ему нужно, только надо что-то настроить в Конфигураторе. Что Конфигуратор — это, по сути, полноценная интегрированная среда разработки и любые очень многие действия в нём можно отнести если не к dev, то к devops, заказчик просто не в курсе.
Предмет договора звучал так: «Заказчик поручает, а Исполнитель принимает на себя работы по поставке и внедрению программного обеспечения 1С: Предприятие 8 согласно Спецификации №1 (Приложение №2 к Договору), являющейся неотъемлемой частью договора».
Спецификация содержит 5 этапов выполнения работ: Поставка ПО, Анализ и проектирование, Обучение пользователей, Настройка и адаптация системы, Опытно-промышленная эксплуатация. Этапы, соответственно кроме поставки ПО, содержали перечень работ, и не все из них можно было однозначно трактовать.
Таким образом, использованные в договоре формулировки позволили Заказчику считать, что была произведена просто настройка стандартной конфигурации 1С: Предприятие без ее модификации.
Спецификация содержит 5 этапов выполнения работ: Поставка ПО, Анализ и проектирование, Обучение пользователей, Настройка и адаптация системы, Опытно-промышленная эксплуатация. Этапы, соответственно кроме поставки ПО, содержали перечень работ, и не все из них можно было однозначно трактовать.
Таким образом, использованные в договоре формулировки позволили Заказчику считать, что была произведена просто настройка стандартной конфигурации 1С: Предприятие без ее модификации.
"… ИТ компания принимает решение начать разработку на основе еще несогласованного ТЗ на свой страх и риск..."
>>> Все остальное можно не читать. Просто кому-то никто не рассказал про ГОСТ34 и РД50. Разработку начинают на основании технического или рабочего (иногда техно-рабочего) проекта (ТП/РП), а вовсе не ТЗ. То что многие компании пытаются «сэкономить» пропуская этот этап и не затрачивая ресурсы на соответствующих специалистов разумеется приводит к идиотским решениям и ситуациям. Скупой платит дважды))
>>> Все остальное можно не читать. Просто кому-то никто не рассказал про ГОСТ34 и РД50. Разработку начинают на основании технического или рабочего (иногда техно-рабочего) проекта (ТП/РП), а вовсе не ТЗ. То что многие компании пытаются «сэкономить» пропуская этот этап и не затрачивая ресурсы на соответствующих специалистов разумеется приводит к идиотским решениям и ситуациям. Скупой платит дважды))
Полностью согласен. 1С компании им лишь бы продать, рискуют и иногда проигрывают нормальное явление.
Только в данном случае скупой не собирается платить по договорным отношениям вообще, так как стороной исполнителя не были выполнены условия договора.
Если исполнитель выступает и в роли разработчика ТЗ, то на это должен быть отдельный договор, либо данный пункт должен быть включён в основной договор. Со сроками написания, согласования со стороной заказчика.
Если исполнитель выступает и в роли разработчика ТЗ, то на это должен быть отдельный договор, либо данный пункт должен быть включён в основной договор. Со сроками написания, согласования со стороной заказчика.
Реально бред какой-то. У меня никогда договор не подписывается раньше ТЗ даде для работ с сроком испольнения в несколько месяцев. Да, бывало, что 2-3 недели тратим на ТЗ, а заказчик потом отказывается от подписания договора. Но это единичные случаи. Зато с готовым ТЗ риски минимизированы. Если уже после начала работ заказчик что-то ещё захочет, то оформляем доп. соглашение. Так ведь спокойнее обеим стлронам договора. К чему лишние риски?
Возможно, вышенаписанное кому-то и кажется бредом, ибо, как я неоднократно убеждался, IT-специфика настолько специфична, что обитает в собственном каком-то пространстве, слабо граничащим с реальной жизнью. Но в РЕАЛЬНОЙ жизни (не IT) сплошь и рядом заключаются договора с «четкими» календарными планами и «конкретными» сметами каждого этапа, первым пунктом которых (я о пунктах календарного плана и смет) следует «РАЗРАБОТКА ТЗ». То есть в договоре фигурируют конкретные сроки и суммы, а объем работ (который, к слову, определяется ТЗ) не известен. И ничего, работают люди как-то…
P.S. Я это просто в качестве ремарки сказал, для сведения. Я не оправдываю ни коим образом эту порочную практику! Но считаю нелишним «познакомить» IT-сообщество с тем, как живут остальные граждане…
P.S. Я это просто в качестве ремарки сказал, для сведения. Я не оправдываю ни коим образом эту порочную практику! Но считаю нелишним «познакомить» IT-сообщество с тем, как живут остальные граждане…
У нас, кстати, основной профиль фирмы — это разработка и производство электроники. ПО тоже делаем, но это вторично. В РЕАЛЬНОЙ жизни без ТЗ или утверждённых тех. требований договор подписывать я бы лично никому не рекомендовал. Если уж объём работ большой и ТЗ будет разрабатываться месяц или более, то лучше всего составить ОТДЕЛЬНЫЙ договор на разработку ТЗ. Да, заказчик теоретически может второй договор на выполнение работ в дальнешем заключить с другой фирмой, но нужно ли это ему? Реально вероятность этого минимальна.
Лично я всегда стараюсь страховаться по полной. К чему лишние проблемы? Это же бизнес, тут и так дел хватает. Дополнительные разбирательства никому не нужны.
Лично я всегда стараюсь страховаться по полной. К чему лишние проблемы? Это же бизнес, тут и так дел хватает. Дополнительные разбирательства никому не нужны.
Простите, конечно, но статья изобилует как орфографическими (что для юриста совершенно недопустимо), так и юридическими ошибками.
Дело для исполнителя вовсе не проигрышное, достаточно посмотреть на обширную судебную практику по аналогичным ситуациям в сфере строительства, проектирования, НИР и прочих договоров подряда.
431-я статья здесь ни при чём. «Пункт 3 статьи 75 АПК РФ» ничего подобного, на что ссылается бредовое постановление 4-летней давности, не гласит. В арбитражных судах совершенно спокойно принимаются в качестве доказательств электронные письма, переписка по скайпу и прочее. Собственно, и раньше, до изменений в законодательстве всё это принималось, только нужно было это правильно оформлять.
По сути этого дела: исполнитель договорился об определённых условиях работы, эти условия корректировались по ходу исполнения. Вопрос только в доказывании наличия корректировок и согласований, — для этого подойдёт электронная переписка, отчёты, обмен документами, комментарии представителей заказчика, телефонные звонки.
Дело для исполнителя вовсе не проигрышное, достаточно посмотреть на обширную судебную практику по аналогичным ситуациям в сфере строительства, проектирования, НИР и прочих договоров подряда.
431-я статья здесь ни при чём. «Пункт 3 статьи 75 АПК РФ» ничего подобного, на что ссылается бредовое постановление 4-летней давности, не гласит. В арбитражных судах совершенно спокойно принимаются в качестве доказательств электронные письма, переписка по скайпу и прочее. Собственно, и раньше, до изменений в законодательстве всё это принималось, только нужно было это правильно оформлять.
По сути этого дела: исполнитель договорился об определённых условиях работы, эти условия корректировались по ходу исполнения. Вопрос только в доказывании наличия корректировок и согласований, — для этого подойдёт электронная переписка, отчёты, обмен документами, комментарии представителей заказчика, телефонные звонки.
ст. 431 ГК РФ была приведена для понимания как суд будет определять предмет договора, если формулировки в договоре размыты и имеют неоднозначное понимание.
А так называемое «бредовое постановление 4-летней давности» вполне жизнеспособно и сейчас. Нам удалось с помощью доводов, изложенных в этом постановлении исключить из числа доказательств по делу всю электронную переписку, предоставленную ответчиком в огромном количестве, а также и другие документы, которые не были предусмотрены условиями договора.
А так называемое «бредовое постановление 4-летней давности» вполне жизнеспособно и сейчас. Нам удалось с помощью доводов, изложенных в этом постановлении исключить из числа доказательств по делу всю электронную переписку, предоставленную ответчиком в огромном количестве, а также и другие документы, которые не были предусмотрены условиями договора.
Работайте только с теми, кто готов выполнять свои обязательства, ну и конечно сами их выполняйте.
По практике подобных конфликтных проектов разных масштабов и с разных сторон (и подрядчика, и заказчика, и приёмщика — редкая роль, — и планируемого эксплуататора, и генподрядчика, и генсубподрядчика, и независимого технического эксперта) проблема в том, что все стороны уверены, что свои обязательства они выполнили, а вторая сторона — нет. Ну или, что не смогли выполнить свои обязательства по вине действий или бездействия другой стороны. И чаще всего это искренняя, насколько могу судить, уверенность, которую лишь пытаются обосновать другим сторонам договора, а также третьим лицам, включая суды, различными доказательствами.
Основная причина, по-моему, настаивание заказчика на фиксированной цене и сроках без чёткого определения фронта работ (или на старте чёткое, а потом вносятся уточнения, изменения, дополнения и т. д.) и согласие на то исполнителя без реалистичных оценок рисков увеличения планируемой трудоёмкости, а то и без реалистичной оценки трудоёмкости в принципе, относясь к фразам о неустойке в договоре как к формальности, «но мы же не такие, чтоб срывать сроки по субъективным причинам, а заказчик поймёт объективные трудности». С другой стороны, зачастую исполнитель настаивает на начале эксплуатации сырой разработки (субъективно исключительно в надежде, что заказчик перейдёт точку невозврата и по любому доведёт внедрение до устраивающего исполнителя этапа), причём не просто сырой, а с отсутствующей функциональностью, вместо предложения пересмотреть сроки ввода в эксплуатацию, надеясь на то, что особых проблем не будет, а они почти всегда появляются и «переключили оставшуюся часть разработчиков на тушение пожаров» вполне закономерно. То, что можно было выявить и исправить в течение нескольких итераций «попытка сдачи»-«багфиксинг», потратив лишь время нескольких людей, приходится делать в ходе уже запущенных процессов эксплуатации, зачастую срывая бизнес-процессы эксплуататора, что приводит, как минимум, к недополученной здесь и сейчас прибыли, а то и прямым расходам, не говоря о потери репутации перед клиентами, когда им вынуждены отказывать в обслуживании или безосновательно требовать с них больше чем они обязаны по договору или сложившимся обычаям в отношениях.
Для всех сторон договора на индивидуальную разработку/настройку ПО следует принять за аксиому, что на этапе заключения договора оценить сроки, трудозатраты, себестоимость для исполнителя и прочие значимые метрики процесса невозможно так, чтобы всех устроил конечный результат, кроме разве что самых тривиальных случаев, поставленных на поток. Процессы разработки, передачи в эксплуатацию и поддержки должен быть изначально построены на том, что видение заказчика о конечном результате будет понято исполнителем на старте проекта неправильно, а при сколь-нибудь значимых сроках или просто отсутствии у заказчика опыта эксплуатации подобного ПО оно будет меняться, а значит любые предварительные оценки сроков и трудоёмкости будут не реалистичными. Если заказчик настаивает на фиксированных сроках и стоимости с различными видами неустоек вплоть до отказа принимать работу в принципе и компенсации полного ущерба даже если просрочка составила один день (реальные случаи), то в сроки и стоимость нужно закладывать все типичные, практически гарантированные риски, как-то:
— задержки с чёткими формулировками требований
— изменения требований в процессе разработки
— неправильное понимание исполнителем даже вроде бы чётко сформулированных требований
— регрессии
— задержки с тестированием и приёмкой
— нетривиальные баги
— траты ресурсов на обучение и поддержку
— просьбы заказчика о жестах доброй воли в счёт дальнейшего сотрудничества
— …
Внедрение в новый год, без ТЗ, но с обязательствами…
ИМХО любому понятно, что засада.
Как любит поговаривать Мавроди: «Лох не мамонт — не вымрет.»
ИМХО любому понятно, что засада.
Как любит поговаривать Мавроди: «Лох не мамонт — не вымрет.»
Имели ли Вы практику работы по зарубежным компаниям? В частности, одна крупная узкоглазая контора повадилась не платить за выполненные работы. Притом контракт есть, работы выполнены в срок, по качеству претензий не поступало, но как только пишешь им об оплате — начинают отмазываться, говорить да-да, конечно конечно, сейчас всё будет, неделя опять молчок, GOTO 10.
Станьте ёжиками! :)
«Техническое задание или документ его заменяющий, формируйте так, чтобы у сторон договора было единое понимание о том, как должно функционировать создаваемое ПО, как должен выглядеть пользовательский интерфейс, система отчетов, какие технологии должны быть использованы при создании ПО и т.д.»
Такое ТЗ может появиться после Обследования, Анализа и Дизайна, а это 40-60% всего проекта внедрения.
Если внедрять типовую Бухгалтерию с переделкой пары печатных форм — да, можно такое ТЗ написать ДО старта проекта. Но если что-то более объемное — такое ТЗ можно написать только после выполнения большей части работ.
«Техническое задание или документ его заменяющий, формируйте так, чтобы у сторон договора было единое понимание о том, как должно функционировать создаваемое ПО, как должен выглядеть пользовательский интерфейс, система отчетов, какие технологии должны быть использованы при создании ПО и т.д.»
Такое ТЗ может появиться после Обследования, Анализа и Дизайна, а это 40-60% всего проекта внедрения.
Если внедрять типовую Бухгалтерию с переделкой пары печатных форм — да, можно такое ТЗ написать ДО старта проекта. Но если что-то более объемное — такое ТЗ можно написать только после выполнения большей части работ.
А заказчик случайно на государственное учреждение?
Проблема в том, что в сфере оказания услуг по настройке
ПО фирмы 1С имеет место систематическая подмена понятий.
Писать надо было в договоре:
Исполнитель обязуется оказать следующий перечень услуг:
1) консультационные услуги в объеме x часов
отв.: Иванов И.И. (1С: Специалист-консультант по прикладным решениям «1С: Предприятие 8» )
2) услуги в объеме y часов по настройке конфигурации такой-то
Отв.:
2.1 Петров П.П. (Специалист" по платформе «1С: Предприятие 8»)
2.2 Сидоров С.С. (1С Специалист по конфигурации такой-то)
3) информационно-технологическая поддержка, период: столько-то месяцев
Отв.:
ФИО ( профессионал по ...)
Копии сертификатов в приложении № таком-то
А то развели антимонию, понимашь: «ТЗ», «по госту».
Это же не сишечка, никакого выхлопа в виде «составного программного продукта», вам принадлежащего у вас нет.
ПО фирмы 1С имеет место систематическая подмена понятий.
Писать надо было в договоре:
Исполнитель обязуется оказать следующий перечень услуг:
1) консультационные услуги в объеме x часов
отв.: Иванов И.И. (1С: Специалист-консультант по прикладным решениям «1С: Предприятие 8» )
2) услуги в объеме y часов по настройке конфигурации такой-то
Отв.:
2.1 Петров П.П. (Специалист" по платформе «1С: Предприятие 8»)
2.2 Сидоров С.С. (1С Специалист по конфигурации такой-то)
3) информационно-технологическая поддержка, период: столько-то месяцев
Отв.:
ФИО ( профессионал по ...)
Копии сертификатов в приложении № таком-то
А то развели антимонию, понимашь: «ТЗ», «по госту».
Это же не сишечка, никакого выхлопа в виде «составного программного продукта», вам принадлежащего у вас нет.
будем рады помочь, по условиям договоримся
похоже помощь требуется Вам, по условиям договоримся ;)
Если актировать работы этапами 2-4 недели, залетов на семизначные суммы можно избежать. Если не актировали этап, следующий не начинаем. А с подписанными актами уже гораздо проще в суде
Меня жизнь уже научила не браться за работу, пока нет четкого ТЗ, в котором каждый пункт не вызывает сомнений. И я всегда делаю наценку из расчета доработок — заранее все предусмотреть нельзя, потому наверняка клиент захочет внести не оговоренные ранее правки. Психология человека устроена так, что ему гораздо приятнее заплатить сразу 400$ и заниматься только творческим процессом, пока продукт не будет доведен до совершенства, чем заплатить 300$ и затем доплачивать по 10$ за каждую дополнительную правку — так у него складывается ощущение обмана.
Еще для себя я выработал правило: не работать с мудаками. Если человек начинает со мной торговаться, я сразу отказываю ему в своих услугах. Правда я работаю только для себя и мне не приходится извращаться, чтобы прокормить бригаду разработчиков, потому имею возможность отказаться от клиента если он мне неприятен.
Тем не менее, статья для меня была полезна — я очень часто упускаю приведенные в ней нюансы, даже не задумываясь об этом. Хоть я и не терплю убытки в семизначных цифрах, но часто трачу время на то, на что можно было не тратить, если бы заранее проработал детали.
Еще для себя я выработал правило: не работать с мудаками. Если человек начинает со мной торговаться, я сразу отказываю ему в своих услугах. Правда я работаю только для себя и мне не приходится извращаться, чтобы прокормить бригаду разработчиков, потому имею возможность отказаться от клиента если он мне неприятен.
Тем не менее, статья для меня была полезна — я очень часто упускаю приведенные в ней нюансы, даже не задумываясь об этом. Хоть я и не терплю убытки в семизначных цифрах, но часто трачу время на то, на что можно было не тратить, если бы заранее проработал детали.
Хотелось бы и мне взглянуть на договор, в котором все нюансы были бы прописаны)
Собственно, ни о чем. «Читайте ТЗ внимательно, читайте договор внимательно» — вот и все.
Мне в подобной ситуации очень помогли юристы, которые в теме были ни уха не рыла. Читаем договор, они просили разъяснить каждую деталь. Вначале я их готов был придушить, потом стал серьезно уважать. Поскольку если они что-то не поняли, то суд уж точно не поймет :)
Было примерно так:
— А что такое «образец»?
— А что такое «работает в соответствии с ТЗ»? (кстати, это я им объяснить так и не смог)
— А если параметры окажутся быстрее заявленных, возможно ли отложить платеж до исправления недостатков?
— Почему не указан способ доставки в терминах Incoterms? Зачем вы здесь полстраницы лирики написали?
— Как мы докажем, что устройство работает или не работает правильно? У нас есть сертифицированные средства измерений?
И так, блин, 3 месяца каждый день
Мне в подобной ситуации очень помогли юристы, которые в теме были ни уха не рыла. Читаем договор, они просили разъяснить каждую деталь. Вначале я их готов был придушить, потом стал серьезно уважать. Поскольку если они что-то не поняли, то суд уж точно не поймет :)
Было примерно так:
— А что такое «образец»?
— А что такое «работает в соответствии с ТЗ»? (кстати, это я им объяснить так и не смог)
— А если параметры окажутся быстрее заявленных, возможно ли отложить платеж до исправления недостатков?
— Почему не указан способ доставки в терминах Incoterms? Зачем вы здесь полстраницы лирики написали?
— Как мы докажем, что устройство работает или не работает правильно? У нас есть сертифицированные средства измерений?
И так, блин, 3 месяца каждый день
Один заказчик тоже пытался придраться с вопросом: «Докажите, что разработанное устройство работает как нужно». Мы ему указали на разделы ТЗ, где были чётко прописаны требования к техническим характеристикам устройства, а также методика приёмки и проведения испытаний. Плюс у нас имелись все необходимые измерительные приборы с действующей поверкой.
Заказчик был приятно удивлён, после этого подобных вопросов больше не возникало. Кстати, он ещё и постоянным нашим клиентом стал :-)
Заказчик был приятно удивлён, после этого подобных вопросов больше не возникало. Кстати, он ещё и постоянным нашим клиентом стал :-)
Попробуйте сделать это для кастомного модуля памяти DDR3 хотя бы. Я уж не говорю про программно-аппаратные средства сложности выше среднего, типа InfiniBand свича или материнки. Да и обычный гигабитный Ethernet роутер может столько геморроя принести, если его испытывать по полной…
Вы наверное электронику никогда не разрабатывали. Поверьте, сделать можно всё. Нужны только материальные ресурсы и время. Плюс, как я уже писал выше, методика приёмки согласовывается заранее. В ней Вы можете прописать что угодно от простого включения устройства до обширного набора тестов. Вот тут и нужна конкретика, чтобы потом не было мучительно больно сдавать разработку заказчику
Да, конечно, и ПМИ тоже никогда не писал :)
Сделать можно все, вопрос, сколько это будет стоить. Не денег даже, а времени специалистов. А есть контрактные обязательства, в которых время прописано.
Для блока питания нужен один подход, для сложной электроники — совсем другой.
Я не хочу меряться, хм, интеллектами, но посмотрите на материнку и представьте себе ПМИ для нее.
Это я к тому, что иногда приходится поступаться перфекционизмом и работать с заказчиком как с партнером, на чистом доверии. Всякое бывает.
Сделать можно все, вопрос, сколько это будет стоить. Не денег даже, а времени специалистов. А есть контрактные обязательства, в которых время прописано.
Для блока питания нужен один подход, для сложной электроники — совсем другой.
Я не хочу меряться, хм, интеллектами, но посмотрите на материнку и представьте себе ПМИ для нее.
Это я к тому, что иногда приходится поступаться перфекционизмом и работать с заказчиком как с партнером, на чистом доверии. Всякое бывает.
Спасибо автору статьи и всем кто оставил комментарии с личным опытом. Было очень полезно почитать всё это.
Большое спасибо за дельные комментарии.
Хотим еще добавить. Позади уже год судебных разбирательств по описанной в статье ситуации, дело близятся к своему логическому завершению. На данный момент пройдено две судебные инстанции. Суд первой инстанции вынес положительное решение в нашу пользу в части взыскания задолженности по работам практически в полном объеме. Суд апелляционной инстанции оставил данное решение без изменения. Рассчитываем на то, что и суд кассационной инстанции оставит это решение без изменения. Но для того чтобы повернуть дело в нашу пользу пришлось приложить достаточно много усилий, особенно на стадии подготовки дела к суду.
Хотим еще добавить. Позади уже год судебных разбирательств по описанной в статье ситуации, дело близятся к своему логическому завершению. На данный момент пройдено две судебные инстанции. Суд первой инстанции вынес положительное решение в нашу пользу в части взыскания задолженности по работам практически в полном объеме. Суд апелляционной инстанции оставил данное решение без изменения. Рассчитываем на то, что и суд кассационной инстанции оставит это решение без изменения. Но для того чтобы повернуть дело в нашу пользу пришлось приложить достаточно много усилий, особенно на стадии подготовки дела к суду.
Мне интересен этот момент: «Условия договора были сформулированы таким образом, что за каждый день просрочки выполнения работ исполнитель должен был выплатить крупную неустойку. Через некоторое время размер неустойки вырос до такого уровня, что рентабельность проекта стала практически нулевой и неуклонно стремилась стать минусовой. » — неужели у вас законодательство позволяет выставить пени и штрафы, более стоимости контракта? У нас (Молдова) законодательно не разрешается указывать более 10% штрафов от стоимости контракта и пеня не может превышать 0.1% в день. Сделано специально, чтобы не маскировать займы под штрафы.
А зачем такая защита от государства?
Ты что, сам дурак, и не видишь что подписываешь?
Ты что, сам дурак, и не видишь что подписываешь?
Российское законодательство не устанавливает предельные суммы начисленных пеней (неустойки) и в некоторых случаях пени могут превысить сумму контракта. Размер пеней (неустойки) может быть снижен судом на основании статьи 333 ГК РФ, но только при наличии соответствующего заявления со стороны ответчика. Также размер ответственности должника может быть снижен, в соответствии с п.1. ст. 404 ГК РФ, если неисполнение или ненадлежащее исполнение обязательства произошло по вине обеих сторон. Суд также вправе уменьшить размер ответственности должника, если кредитор умышленно или по неосторожности содействовал увеличению размера убытков, причиненных неисполнением или ненадлежащим исполнением, либо не принял разумных мер к их уменьшению.
Это, помоему общеевросоюзное. У нас в Риге тоже самое — 0.1% в день и не более 10% в общем.
С кем не бывает в первый раз =)
Не ленитесь и дайте составить договора юристу, который занимается поддержкой ИТ компаний (т.е. специализируется или если это фирма, у них это одно из крупных направлений), опишите свою специфику, смотрите как ваши клиенты реагируют и какие ситуации возникают, и отправляйте на следующую итерацию обновлений.
Сэкономит кучу нервов, особенно если сами будете следовать условиям своего договора и вовремя нотифицировать по e-mail и/или почтой с вручением в руки о том, что клиент там, там и там то не успел, то не выполнил, тут затянул.
Ну а если проект более-менее значительный (больше месяца-двух работы), составляйте хотя-бы небольшой описание, а в идеале вообще делайте дополнение к договору с перечнем работ. Это гораздо проще, чем кажется на первый взгляд, требует час-полтора в первый раз, в последующие разы уже от 30 до 60 минут вполне укладываешься.
А про ТЗ вообще нужно вписывать пункт в договор прямо — нет ТЗ, значит ограничиваете возможность клиента выставлять претензии и закладываете 5-10-15% доплаты по контракту. В проектах по крупнее им будет дешевле оплатить разработку ТЗ, нежели платить дополнительные 15% от стоимости.
Сэкономит кучу нервов, особенно если сами будете следовать условиям своего договора и вовремя нотифицировать по e-mail и/или почтой с вручением в руки о том, что клиент там, там и там то не успел, то не выполнил, тут затянул.
Ну а если проект более-менее значительный (больше месяца-двух работы), составляйте хотя-бы небольшой описание, а в идеале вообще делайте дополнение к договору с перечнем работ. Это гораздо проще, чем кажется на первый взгляд, требует час-полтора в первый раз, в последующие разы уже от 30 до 60 минут вполне укладываешься.
А про ТЗ вообще нужно вписывать пункт в договор прямо — нет ТЗ, значит ограничиваете возможность клиента выставлять претензии и закладываете 5-10-15% доплаты по контракту. В проектах по крупнее им будет дешевле оплатить разработку ТЗ, нежели платить дополнительные 15% от стоимости.
Sign up to leave a comment.
6 типичных ошибок при заключении договоров на разработку ПО