Что важнее пункт договора или технического задания?

Договор на разработку программного обеспечения

Что важнее   пункт договора или технического задания?

Юрист по интернет-праву простым языком дает ответы на частые вопросы по договорам на разработку программного обеспечения, передаче авторских прав, авторским договорам и т.д.

Форма договора на разработку программы

Работая с программистом или фирмой по созданию программы для ЭВМ (сайта, программного обеспечения, мобильного приложения, отдельного скрипта или модуля, программы для 1С и любой другой программы), как, впрочем, и по созданию любого другого объекта авторских прав (произведения), следует оформлять такие отношения договором в письменной форме.

* Произведение и объект авторских прав – это синонимы.

Несоблюдение письменной формы договора в отношении объекта авторских прав влечет его недействительность (пункт 2 статьи 1234 и пункт 2 статьи 1235 Гражданского кодекса РФ).

Иными словами: нет письменного дoгoвoрa (в бумажной форме или в электронной) – нет прав на использование произведения. При этом договоры о передаче и предоставлении авторских прав могут заключаться и в электронной форме (например, путем обмена электронными письмами / имейл).

Исключение, которое не касается договоров на разработку программного обеспечения: договор о предоставлении права использования произведения в периодическом печатном издании (печатном СМИ) может быть заключен в устной форме (пункт 2 статьи 1286 ГК РФ).

Договор на разработку ПО – подряд, услуга или заказ?

Если по договору с разработчиками программного обеспечения вы не просто получаете права, но программа специально создается по вашему заказу, то в договоре необходимо урегулировать этап создания.

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

Сразу ответ: правовая природа договора на разработку ПО ближе к договору подряда, разработка не является услугой, она является работой. Ниже уже разберемся почему.

Однако по закону такой договор называется договором заказа.

Итак, если договор на разработку программы заключается между заказчиком и непосредственным автором (то есть лицом, которое само кодит), то это договор авторского заказа, и регулируется он статьей 1288 Гражданского кодекса РФ.

Если договор на разработку программы заключается между заказчиком и фирмой или физлицом, которое само не пишет код, а работает с авторами, руководит ими, то это уже договор заказа, и регулируется статьей 1296 Гражданского кодекса РФ.

Частая ситуация: когда в команде несколько программистов, а договор заключается с одним (“главным”), тогда в части прав главного программиста должна применяться статья 1288 Гражданского кодекса РФ, а в части прав других программистов – статья 1296, в частности это влияет на то, у кого какие авторские права.

Очень многое будет зависеть от текста договора на разработку ПО, от фактической воли сторон, от косвенных ее доказательств (например, переписки), лучше привлекать юриста по авторскому праву и интернет-праву уже на этапе составления договора, чтобы не было проблем в будущем. Ведь предприниматели несут ответственность за нарушение авторских прав и в отсутствие вины, то есть сослаться на договор с “главным” программистом в свое оправдание не получится, если кто-то из других программистов предъявит обоснованные претензии по авторским правам.

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

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

По договору подряда одна сторона (подрядчик) обязуется выполнить по заданию другой стороны (заказчика) определенную работу и сдать ее результат заказчику, а заказчик обязуется принять результат работы и оплатить его (статья 702 Гражданского кодекса РФ).

По договору возмездного оказания услуг исполнитель обязуется по заданию заказчика оказать услуги (совершить определенные действия или осуществить определенную деятельность), а заказчик обязуется оплатить эти услуги (статья 779 Гражданского кодекса РФ).

Как видно, в услугах результат не имеет правового значения, важны действия, которые могут привести или не привести к определенному результату. Договором оказания услуг может регулироваться, например, деятельность программиста по обслуживанию программы для ЭВМ, ее поддержке.

Но разработка ПО всегда подразумевает конкретный результат. Причем чем конкретнее он выражен, тем лучше для обеих сторон дoгoвoрa и проще программисту.

Более того, закон требует того, чтобы предмет договора на создание программы (договор заказа) был четко определен, то есть в договоре заказа программы должен быть описан конечный результат – программа. Если он не определен или не имеет значения, то это не договор заказа на создание произведения.

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

Техническое задание на разработку программного обеспечения

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

Нередко целесообразно подключать к работе над договором разработчика (со стороны заказчика или со стороны программиста), есть программисты, сочетающие в себе качества разработчика и программиста, тогда он поможет и с техническим заданием.

В техническом задании работы лучше разбить на этапе и согласовать сроки. Срок – это существенное (необходимое) условие договора авторского заказа. Если он не согласован в договоре, то договор авторского заказа не считается заключенным, т.е. не порождает никаких юридических последствий (статья 1299 Гражданского кодекса РФ).

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

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

Исключительные и неисключительные права на программу

Лицо, владеющее исключительным правом (аналог права собственности), называется правообладателем.

Неисключительные права корректно называть правом пользования (лицензией). Право пользования предоставляется по лицензионному договору.

Виды авторских договоров и договоров в отношении программ

С 01.01.2008 российский закон не содержит понятия “авторский договор”, оно было в утратившем силу Законе об авторском праве и смежных прав.

Сейчас обычно под авторским договором понимают гражданско-правовой договор, заключаемый с лицом, непосредственно создающим результат творческой деятельности, т.е. автором, однако существует и определение авторского договора как договора по созданию объекта авторских прав и/или передаче авторских прав на произведение.

Авторские договоры: договор отчуждения исключительного права (полная передача прав, аналог продажи) и лицензионный договор (предоставление права, разрешения, аналог аренды). По договору авторского заказа лицо обязуется создать результат творческой деятельности.

По договору отчуждения исключительного права на программу осуществляется передача исключительных прав в полном объеме: ограничить использование или “сохранить за собой” какое-то право при этом нельзя (только через конструкцию одновременной лицензии от нового правообладателя бывшему правообладателю) – такой договор вероятнее всего будет в случае спора переквалифицирован судом в лицензионный договор (который позволяет вводить практически любые ограничения и условия использования).

Служебное произведение, трудовой договор с программистом

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

Пленум Верховного Суда РФ изменил свой подход, изложенный в Постановлении от 19.06.2006 №15, согласно которому работодателю достаточно было доказать, что произведение было создано или в рамках трудовых обязанностей, или в рамках служебного задания и за счет работодателя (даже если по трудовому договору автора эта деятельность не входила в его обязанности).

Источник: http://kolosov.info/kommentarii/dogovor-razrabotka-programmy

3 шага к идеальному ТЗ

Что важнее   пункт договора или технического задания?

Курсы закончены, пробные полеты сделаны, учебные проекты написаны, и вот на горизонте появляется первый клиент с настоящим заказом на разработку сайта. Не спешите начинать работу после первого: “Ну что ж. Давайте”. Составьте техническое задание, согласуйте его с заказчиком и подпишите с двух сторон. Сэкономьте время и деньги: без подписанного задания вы рискуете поработать вхолостую.

Шаг 1. Задайте правильные вопросы

Видение задачи со стороны заказчика и со стороны исполнителя кардинально различается. Но вам нужно максимально понять пожелания к работе. Для этого узнайте как можно больше информации, которая поможет в работе. Не стоит додумывать за клиента даже мелкие детали. Может оказаться, что он как раз считает ровно наоборот.

Бизнес. Выясните модель бизнеса вашего клиента: что за компания, чем занимается, история, миссия и цели.

Узнайте, какие продукты или услуги предоставляет фирма, почему они востребованы и какое у клиента УТП.

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

Цель проекта. Узнайте, зачем заказывают разработку сайта и что именно хочет получить клиент. Есть ли или был у заказчика сайт, чем он не устраивает и что в нем нравилось. Попросите клиента говорить языком бизнеса, т.е. не “создать красивый и удобный сайт”, а “повысить продажи”, “привлечь новых клиентов” или “провести масштабную акцию”.

Проект. Постарайтесь понять, как в итоге заказчик видит вашу работу. Что конкретно он хочет получить? Определите перечень задач, стоящих перед вами как исполнителем.

Что заказчик ожидает получить в первую очередь? Выясните, по каким критериям будет решаться, что задача выполнена или проект подходит.

Также спросите, какие проекты нравятся заказчику, а какие вызывают отторжение.

Бюджет. Обсудите бюджет проекта: общую стоимость, этапы работы, порядок и сроки оплаты. Постарайтесь договориться об авансе на работу, просите не менее 30% от общей стоимости.

Так вы сможете себя обезопасить на случай неплатежеспособности заказчика или разрыва договора. Если заказчик откажется от сотрудничества, согласно ГК РФ, он должен оплатить фактически выполненные работы.

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

Ожидания. Спросите, что важно для клиента в исполнителе. Как он хочет взаимодействовать, кто будет ответственным со стороны заказчика. Определите процесс согласования и перечень вопросов в ведении ответственного лица.

Какие будут каналы связи для текущих вопросов и официальной переписки? Узнайте, что больше всего пугает клиента в будущем сотрудничестве.

Обговорите порядок действий на случай, если что-то пойдет не так или нужно будет получить срочное согласование.

Шаг 2. Запишите детально

В IT-сфере обычно оформляют два вида документов: бриф и техническое задание – ТЗ. Бриф используют на начальном этапе, прописывая в него концепцию, видение, направления работы. ТЗ более формализовано, имеет строгую форму, содержит точные формулировки и технические детали.

ТЗ – юридический документ,

в который записывают весь перечень работ и

оформляют в виде приложения к договору.

Различают ситуации, когда нужны оба документа или можно обойтись одним:

  • бриф – простая задача, быстрое выполнение.

Пример: дизайн рекламного баннера.

  • ТЗ – только техническая работа, стилистика определена заказчиком.

Пример: добавить страницу на действующий корпоративный сайт с утвержденным дизайном.

  • бриф + ТЗ – большой проект с общей стилистикой, дизайном и разработкой.

Пример: создание сайта.

Глоссарий – первый раздел, в который записываются используемые термины и их толкование. Формулировки в техзадании записывайте подробно, точно и формальным языком.

Пункты в формате “хороший сайт с веселеньким дизайном” будут трактоваться всеми участниками по-разному и приведут к отсутствию желаемого результата. Хорошее ТЗ может в несколько раз превышать объем договора.

Пусть вас это не смущает, все-таки ТЗ и есть главный документ.

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

Требования к дизайну сайта. В этом разделе указывается стилистика, цветовые решения, требования к юзабилити, сроки и порядок утверждения проекта дизайна.

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

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

Требования к программному обеспечению. Перечислите ПО для серверной и клиентской частей, которое планируете использовать в работе.

Порядок приема-сдачи проекта. Укажите, в каком виде и в каких файлах передаются заказчику результаты работы. Должен ли исполнитель размещать сайт на хостинге? Если да, на каком? Разбейте работу на этапы, укажите сроки, процесс согласования и подписания акта приема выполненных работ.

Шаг 3. Утвердите сроки

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

Дата запуска сайта. Узнайте, к какому сроку проект должен быть запущен и почему эта дата важна. Допустим, заказчик настаивает, чтобы сайт заработал через три недели, но вы не успеваете сделать большой проект за такой срок.

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

Получается, что к началу выставки на сайте должна быть информация о компании и контакты, а весь запланированный грандиозный функционал может разрабатываться дольше, еще месяц или два.

Общее время работы. Общее время может не совпадать с датой запуска сайта. Заложите дополнительное время на тестирование работы и внесение финальных корректировок.

Этапы. Разбейте весь объем на этапы. Вам будет проще планировать работу, а заказчику давать замечания.

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

Если этапы занимают много времени, три недели, месяц или больше, договоритесь об оплате каждого этапа по отдельности. Пример оформления этапов проекта:

ЭтапРезультатСрок, раб. дниСтоимостьРазмер аванса

Срок согласования этапов. Часто случается, что заказчик тянет с согласованием и замечаниями. Это тормозит работу и откладывает запуск сайта.

По итогу заказчик еще и обвиняет исполнителя в срыве сроков проекта. Чтобы этого избежать, пропишите в договоре время на согласование (3-4 дня).

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

Срок подписания актов намного важнее, чем согласования этапов. Без подписанного акта вы не сможете получить оплату за выполненную работу. Если заказчик поступит непорядочно и не переведет оставшуюся сумму, вам придется “бегать” за ним, названивать и заваливать письмами. Формально договор еще не завершен, ведь акт выполненных работ не подписан сторонами.

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

Продумайте, от какой даты считать срок для подписания: передача файлов, размещение сайта на хостинге или другое событие.

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

Можно ли работать без ТЗ?

Поклонники гибкой методологии разработки (agile, scrum и др.) вместо четкого и строгого технического задания используют концептуальные документы: скетчи, user stories и пр. По ним задается вектор направления, а детализация появляется во время разработки. Другой альтернативой свободного ТЗ выступают mindmap – диаграммы связи с древовидной структурой.

Однако если вы – фрилансер или маленькая студия, рекомендуем сотрудничать в классическом формате. При негативном развитии событий придется идти в суд, а там лучше воспримут документ с точными и понятными формулировками. Судья будет смотреть по факту: в ТЗ и на сайте есть разделы “О нас”, “Новости” и “Контакты”, значит работа выполнена.

Оформляйте техническое задание в виде приложения к договору и подписывайте одновременно с ним.

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

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

Шпаргалка

  1. Не приступайте к работе без договора.

  2. Спросите обо всем, что может относиться к проекту.

  3. Составьте бриф и ТЗ.

  4. Внесите в ТЗ точную, понятную и максимально подробною информацию.

  5. Установите и зафиксируйте сроки.

  6. Техзадание оформляйте отдельным приложением к договору.

  7. Все дополнительные пожелания и изменения добавляйте в договор как еще одно приложение.

  8. Для ускорения согласования обменивайтесь сканами документов. Но потом получите от заказчика оригинал.

  9. Пропишите в договоре все сроки: дату запуска сайта, общее время работы, этапы, сроки согласования и подписания актов.

Источник: https://geekbrains.ru/posts/project_requirements

Техническое задание как неотъемлемая часть договора на разработку сайта

Что важнее   пункт договора или технического задания?

Не так давно на одном из сайтов (не помню на каком, к сожалению) мне попалось мнение одного из разработчиков программного обеспечения, который рассказывал о том, что они давно отказались от механизма технических заданий и разрабатывают ПО «на ходу», ориентируясь на пожелания заказчиков и замечания по итогам тестирования и мол экономят кучу сил и времени. В х был вопрос: а что он делает, если заказчик, когда работа уже сделана, говорит, что «он хотел совсем другое». Выяснилось, что рассказчик, в своей практике ни разу не сталкивался с подобной ситуацией. Везучий человек.

Я не буду сейчас писать о том как правильно разработать техзадание. Оставим это на потом. Поговорим о том, какую роль играет ТЗ в процессе разработки сайта.

Если рассматривать процесс разработки сайта, как некий workflow, то можно выделить несколько ключевых этапов:

  1. Понять что хочет заказчик
  2. Описать то что хочет заказчик формальным языком
  3. Реализовать то что хочет заказчик
  4. Сдать работы заказчику и расстаться с ним, без взаимных претензий.

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

Кто должен выступить разработчиком технического задания? Казалось бы очевидный ответ — Заказчик! Ведь кроме него никто не знает чего он хочет.  Беда в том, что у заказчика в голове, как правило всего лишь набор идей, а не четкие задания Исполнителю. Я уже неоднократно сталкивался с ТЗ, которые были написаны Заказчиками.

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

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

В общем писать техзадание придется Исполнителю.  И самое лучшее включить этот процесс, как отдельный этап, в договор на разработку сайта. Разумеется за отдельную плату.   Само техническое задание нужно обязательно подписать у Заказчика в бумажном виде.

Пункты о разработке ТЗ можно вставить в договор, например в таком виде:

В разделе «Предмет договора»:

  1. Провести подготовительную работу, осуществив согласование с Заказчиком положений Технического задания, в случае необходимости провести интервьюирование лиц, указанных Заказчиком, с целью наиболее точного описания требований к создаваемому Сайту.
  2. На основании полученных данных разработать Техническое задание на разработку Сайта Заказчика в соответствии с требованиями Заказчика, в том числе:
  • Аналитическую концепцию сайта.
  • Структуру сайта.
  • Бизнес-логику сайта.
  • Структуру каталогов сайта.

Итогом настоящего этапа является подписанное Сторонами Техническое задание.

В раздел «сдача и приемка работ»:

1.1.     Сдача и приемка работ по разработке Технического задания производится в следующем порядке:

1.1.1.  Исполнитель заказным письмом с уведомлением о вручении направляет в адрес Заказчика подписанное Исполнителем Техническое задание в бумажном виде в двух равноценных экземплярах.

1.1.2.  Заказчик в течение 5(пяти) рабочих дней с момента получения Технического задания подписывает оба экземпляра Технического задания и один из них возвращает Исполнителю.

1.1.3.  В случае отказа от подписания Технического задания предоставляет Исполнителю письменный мотивированный отказ от его подписания с указанием требований, предъявляемых Заказчиком к  исправлениям, которые будет необходимо внести Исполнителю в Техническое задание.

1.1.4.  В случае невозвращения Заказчиком подписанного Технического задания по  истечении 5 (пяти) рабочих дней и не предоставления мотивированного отказа в такие же сроки, работы по разработке Технического задания считаются выполненными Исполнителем в полном соответствии с настоящим Договором, в полном объеме и принятыми Заказчиком.

Стоимость работ по разработке ТЗ как правило будет в районе 10-20% от стоимости всех работ по разработке Сайта.

Все вышеизложенное основано на личном опыте автора и является его личным мнением. Я с удовольствием отвечу на любые вопросы и комментарии. P.S. Поскольку в большей степени я программист (то бишь разработчик ПО) многие вещи могут быть изложены не совсем “обычным” языком.

P.S.S. Если вы полностью или частично копируете материалы этой статьи, обязательно указывайте автора и ставьте ссылку на источник материала – “http://38-net.ru/experience/web-tz/”.

Источник: http://38-net.ru/experience/web-tz/

Что делать, если в документах закупки разные условия?

Что важнее   пункт договора или технического задания?

Статья актуальна на 14 сентября 2019

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

Разночтения в документах закупки и извещении

Идеальный вариант — заранее внимательно прочитать все документы, которые прилагаются к закупке: извещение, техническое задание, проект контракта, инструкцию по заполнению заявки, обоснование НМЦ и т.д. Например, разночтения могут быть такими:

  • В извещении установлено, что закупка только для СМП по 30 ст. 44-ФЗ, а по документации — закупка на общих основаниях.
  • В извещении указан один срок подачи заявок, а в документах — другой.
  • В ТЗ единицы товары — штуки, а в контракте — упаковки.
  • В документах срок оплаты — 30 дней, а в проекте контракта — 240 дней.

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

Если не успели в срок, установленный для подачи запроса на разъяснения, остается обращаться в ФАС.

Разночтения в техзадании и разъяснениях заказчика

Как быть, если заказчик согласился с доводами участника в запросе на разъяснения, но ничего не изменил в документах закупки? В ФАС по этому вопросу сложилась однозначная практика: заказчик обязан внести изменения в документацию и продлить срок подачи заявок, иначе он нарушит закон. Даже если в инструкции по заполнению заявки есть фраза «В случае разночтения между данными, указанными в разъяснениях, и данными, указанными в техническом задании, участники должны руководствоваться данными, указанными в техзадании».

Вот одно из решений ФАС в пользу участника закупки.

На этапе подписания контракта

Поставщик готовит заявку на условиях из документации о закупке, а контракт заключают, дополняя эти условия информацией из заявки победителя. Заказчики не имеют права включать в контракт дополнительные пункты, которых не было в извещении о закупке. Но на практике условия в контракте иногда меняются: уменьшают сроки поставки, добавляют новые работы и т.д.

Присланный на подписание контракт не соответствует проекту контракта

Например, в проекте контракта из документов закупки срок поставки товара составляет 30 календарных дней, а в присланном на подписание документе он сократился до 20 дней. Давайте посмотрим, как могут развиваться события.

  1. Заказчик исправляет ошибку. Если это электронный аукцион, отправьте заказчику протокол разногласий. Дождитесь от него исправленный контракт, проверьте, что он соответствует проекту, и только после этого подписывайте.
  2. Заказчик отказывается вносить изменения. Заказчик говорит, что у него изменились условия и просит вас пойти на встречу. Но даже если новые условия вас устраивают, не следует соглашаться на них, так как у такого решения могут быть негативные последствия. Если вы подпишите контракт, то другие участники, обнаружив несоответствия, смогут через суд отменить сделку. Если заказчик не исправляет контракт, не соответствующий проекту, рекомендуем обратиться с жалобой в ФАС.

Условия в проекте контракта отличаются от требований в документации

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

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

Рассмотрим, какие тут могут быть варианты.

  1. Исполнить контракт на предложенных условиях. В этом случае победитель потеряет часть прибыли, выполняя работы, которые не были заложены в предложенную им цену. Убрать монтаж из контракта протоколом разногласий нельзя, так как предмет закупки — это существенное условие контракта, которое нельзя менять.
  2. . Поставщик может только поставить товар, а заказчику нужен монтаж. Тут два сценария:
    • Если победитель не планирует выполнять монтаж, а заказчик — выставлять претензии поставщику, можно расторгнуть контракт по обоюдному согласию. В этом случае победитель не попадет в РНП, а заказчику придется проводить новую закупку.
    • Заказчик настаивает на выполнении всех условий контракта, а победитель не может их исполнить. В этом случае придется отказаться от подписания контракта. Это не лучший вариант развития событий, так как победитель потеряет обеспечение заявки и право участвовать в закупках на 2 года.
  3. Заказчику нужен только товар. Посмотрите, как описан объект закупки в плане-графике, найдите обоснование НМЦ в документах. В вашу пользу сыграет то, что в плане-графике нет условия о монтаже, а на этапе запроса рыночных цен просчитывали только поставку оборудования. Задайте вопрос заказчику, действительно ли нужен монтаж? Может получиться так, что внутреннему заказчику сейчас нужна только поставка, а составитель закупочной документации просто ошибся, скопировав в контракт условие о монтаже из другого контракта на поставку оборудования. Если заказчик согласен только на поставку и вы уверены, что он не передумает после подписания контракта, подписывайте контракт и исполняйте.

После подписания контракта

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

  • По соглашению сторон, но маловероятно, что заказчик на это согласится.
  • В одностороннем порядке, если такая возможность прописана в контракте. Будьте готовы, что заказчик обжалует ваше решение в суде, и вы его проиграете.
  • По решению суда с риском попасть в РНП. Как правило суд в этой ситуации оказывается на стороне заказчика.

Выводы:

  • Проверяйте все документы закупки «на берегу».
  • Если не заметили каких-то условий в проекте контракта в момент подачи заявок, выполняйте контракт или попробуйте договориться расторгнуть его по соглашению сторон.
  • Заказчик не может менять существенные условия контракта. Незаконное включение новые условий можно оспорить в ФАС или в арбитраже.

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

Источник: https://zakupki.kontur.ru/site/articles/1177-raznue-uslovia

Техническое задание: законодательные требования и сложившаяся практика

Что важнее   пункт договора или технического задания?

Курсы повышения квалификации в Школе электронных торгов – это профессиональная переподготовка для поставщиков и заказчиков по 44-ФЗ и 223-ФЗ. Онлайн, с экспертами. 

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

Требования должны быть четкими и подробными, но количество и набор характеристик не могут быть «подогнаны» под конкретную марку или определенного производителя.

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

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

Типичные нарушения заказчика при составлении технического задания

Нарушение 1: неясные формулировки, значения

Из описания объекта закупки должно быть однозначно понятно, что заказчик собирается закупить. Требования к показателям характеристик (min, max или точные значения) следует указывать недвусмысленно, предельно понятно и доступно. Согласно ч. 1 и ч. 2 ст.

33 документация должна содержать требования, которые позволяют установить подходят ли предлагаемые товары, (работы или услуги) заказчику. Не следует использовать термины наподобие «не хуже», «не слабее» и тому подобные, это не объективное описание.

Что для заказчика лучше, а что хуже, поставщик не обязан знать или угадывать.

Характеристики объекта закупки, например, могут выглядеть так:

«Требования к товару. Товар (далее — мебель) должен соответствовать ГОСТ 16371-2014 «Мебель. Общие технические условия» (введен в действие Приказом Росстандарта от 15.06.2015 № 683-ст), ГОСТ 26800.1-86 «Мебель для административных помещений.

Функциональные размеры столов». Наименование товара — стол эргономичный. Размер, Ш x Г x В (ширина, глубина, высота): — минимальные значения — 100 x 100 x 71,5 см; — максимальные значения — 165 x 110 x 71,5 см. При этом высота не подлежит изменению. Цвет: коричневый.

Требования к столешнице: Материал — высококачественная МДФ, толщина: минимальное значение — 12 мм, максимальное значение — 35 мм. Облицовка — ПВХ-пленка. Столешница должна быть эргономичной и иметь плавные края.

В столешнице должно быть предусмотрено отверстие для проводов с заглушкой.»

Бывает, что заказчики ошибаются при указании требований диапазонными значениями. Например, «ширина более 360 мм и менее 214 мм».

Иногда при описании объекта закупки не учитываются собственные инструкции по подготовке заявок: «В случае, если присутствует слово «диапазон», «в пределах», то поставщику необходимо предоставить диапазон значений ниже установленного заказчиком». Каким образом это понимать в случае температурного диапазона непонятно.

Достаточно часто заказчики переписывают с государственных стандартов все подряд характеристики, при этом товар не может обладать всеми требуемыми характеристиками одновременно. Например, что касается подвижности и жесткости бетона ГОСТ 7473-2010.

Бетон может быть либо жестким (Ж), либо подвижным (П). Это взаимоисключающие характеристики. Однако, заказчики умудряются вписать в техзадание и то и другое: жесткость Ж1-Ж4; подвижность П1-П4. Материала с такими характеристиками не может быть.

И это является нарушением ч. 2 ст. 33 44-ФЗ.

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

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


Установление излишне детализированных требований к материалам, из которых изготавливается товар также будет нарушением закона.

Нарушение 2: ссылка на ГОСТ без какого-либо описания

Ещё одно распространённое нарушение — это перечисление в техническом задании ГОСТ, без привязки к конкретным товарам. Позиция ФАС в этой ситуации такова, что подобное описание объекта закупки не позволяет идентифицировать каждый товар, и не позволяет потенциальному поставщику подготовить заявку должным образом.


Нарушение 3: отсутствие фразы «или эквивалент»

Распространённой ошибкой также является указание в описании объекта закупки требования к товарному знаку без ссылки на возможность применения эквивалента, что может привести к ограничению конкуренции. Узнайте подробнее об этом требовании закона в видео на сайте Школы электронных торгов «Правила составления технических заданий в рамках закона 44-ФЗ и требования к их содержанию»

В общем случае при составлении закупочного ТЗ заказчик должен следить за полной безликостью описываемого объекта, то есть в нем не должно быть никаких требований и даже намеков на конкретные товарные знаки, производителей или даже страну происхождения товара.

Ещё несколько рекомендаций при составлении техзадания по 44-ФЗ

На самом деле, грамотно подготовить описание объекта закупки, техническое задание по 44-ФЗ, без наличия специальных знаний в конкретной области довольно непросто.

Некоторые заказчики даже создают закупку на оказание услуг по подготовке техзаданий.

Но и самостоятельно это сделать вполне реально, если внимательно изучить требования к объектам закупки, сопоставить со своими потребностями и точно следовать правилам описания объекта закупки по 44-ФЗ.

Нужно иметь в виду, что в маркировке изделий зашифрованы некоторые характеристики. К примеру, техническим заданием предусмотрен материал «плитка тротуарная» с маркировкой «Классико 1КО.4», техзаданием никаких требований к толщине плитки не предъявлено. Согласно расшифровке маркировки, её толщина составляет 4 см. (последняя цифра маркировки указывает на толщину в смантиметрах).

Однако, при исполнении контакта выяснилось, что требовалась плитка толщиной 6 см. От толщины плитки зависит нагрузка, которую она может выдержать. Неграмотно составленное техзадание привело к закупке материала, который не удовлетворяет необходимым требованиям.

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

Желательно не копировать описание товаров с различных сайтов. Информация в описании может не быть достоверной и окажется, что заявленным требованиям не соответствует ни один товар. Существует большая вероятность, что под данное описание подходит единственный товар. Это может расцениваться как ограничение конкуренции.

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

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

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


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

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

Несоответствие технического задания инструкции, создающее препятствие для подготовки заявки, может спровоцировать направление жалоб в УФАС потенциальными участниками закупки.


Какие ещё требования важно указать в техзадании:

  • К гарантийному сроку товара, работы, услуги и (или) объему предоставления гарантий их качества. Заказчик в техническом задании должен установить гарантийный срок не менее, гарантийного срока производителя.
  • К гарантийному обслуживанию товара.
  • К расходам на эксплуатацию товара.
  • К обязательности осуществления монтажа и наладки товара.
  • К обучению лиц, осуществляющих использование и обслуживание товара.

Главные правила

  1. При подготовке документации о закупке обратите внимание на коды Общероссийского классификатора продукции (ОКПД2), относящиеся к объекту закупки. Необходимо чтобы использованный код совпадал с конкретным объектом закупки.
  2. Помимо положений 44-ФЗ, разрабатывая техзадание следует иметь в виду также требования иных правовых актов, антимонопольных органов, технических норм и стандартов (ГОСТ, ТУ, СНиП и т.д.).
  3. Товары и материалы, запрашиваемые заказчиком в техническом задании, должны соответствовать объекту закупки и сметной документации (если такая имеется).
  4. При закупке на строительный подряд необходимо также приложить дефектную ведомость, смету, а в случае капитального строительства (реконструкции, капитального ремонта) также необходимо приложить и проектную документацию.
  5. Указывайте, что хотите закупить новые товары и материалы (т.е. они не использовались, не находились в ремонте, реставрации, не были восстановлены). Иначе, заказчик может получить б/у товары.

Распространенные вопросы

Вопрос: Можно ли прописывать на поставку запасных частей указание «оригинальных»?
Ответ: Можно, если речь идет о продукте, стоящем на гарантии, либо присутствует необходимость обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком, а также в случае закупок запасных частей и расходных материалов к машинам и оборудованию.

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

Вопрос: Нужно приобрести прибор для научных исследований к уже имеющейся системе из 3-х приборов одного производителя. Необходимо полное совмещение всего в работе. Эквивалент не желателен.

Можно не писать эквивалент и указать производителя? Система тонко настраиваемая и дорогая.

Ответ: Если Ваш случай подходит под «…за исключением случаев несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком…) – можно, в других случаях — нельзя.

Вопрос: Можно ли в техзадании по капремонту указать узкие показатели, например, цвет стен с конкретным колером, приложить пример композиции из гипсокартона на потолке, конкретную коллекцию плитку без эквивалента, ссылаясь на эстетические предпочтения?
Ответ: При формировании технического задания заказчики должны руководствоваться требованиями статьи 33 Закона № 44-ФЗ. Цвет стен — это выбор заказчика, это его потребность, не ограничивающая число поставщиков. Макет, эскиз композиции из гипсокартона на потолке — это также потребность заказчика, все исполнители смогут повторить приведённый в документации макет. Коллекция плитки без эквивалента — это нарушение пункта 1 статьи 33 Закона № 44-ФЗ: «Документация о закупке может содержать указание на товарные знаки в случае, если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент». 

Источник: https://school.kontur.ru/publications/1533

Юридический спектр
Добавить комментарий