+7-953-535-22-46
Ape-email@yandex.ru
Ape-email@yandex.ru
Как составить договор на разработку ПО: инструкция для подрядчика
(с примерами рабочих формулировок)
Грамотно составленный договор на разработку программного обеспечения (ПО) — залог защиты интересов подрядчика. Разберём, как его составить, какие риски предусмотреть и как подкрепить позиции отсылками к судебной практике.
#1. Нечёткое ТЗ - споры о объёме выполненных работ
На практике данный риск связан с тем, что заказчик в процессе работы меняет требования, добавляет новые функции или меняет приоритеты, что ведёт к увеличению сроков и затрат без дополнительной оплаты.
Что это может повлечь:
Решение:
прикрепите к договору детальное техническое задание (ТЗ) с функционалом, интерфейсами, интеграциями. Разделите общий проект на спринты и актируйте их после каждого.
Альтернативный вариант – предусмотреть аутстаффинговую модель при которой для выполнения ТЗ вы наделяете Заказчика командой с почасовой оплатой. Тогда вне зависимости от количества правок стоимость работ будет измеряться количеством привлеченных специалистов и их временем.
- срыв графика работ;
- перерасход бюджета;
- конфликтные ситуации с заказчиком.
Решение:
прикрепите к договору детальное техническое задание (ТЗ) с функционалом, интерфейсами, интеграциями. Разделите общий проект на спринты и актируйте их после каждого.
Альтернативный вариант – предусмотреть аутстаффинговую модель при которой для выполнения ТЗ вы наделяете Заказчика командой с почасовой оплатой. Тогда вне зависимости от количества правок стоимость работ будет измеряться количеством привлеченных специалистов и их временем.
ВАЖНО: при разработке контракта не стоит включать в него условие об обязательном направлении оригиналов в письменной форме, поскольку при наличии подобного условия юридически значимые сроки (например, сроки рассмотрения заявки и др.) будут считаться судом с даты направления или получения оригинала документа, а не отправки сообщения по электронной почте.
#2. Изменение требований в ходе разработки
Решение:
Предусмотрите процедуру внесения изменений в формате «под себя»:
пропишите процедуру внесения изменений: форма запроса (например, через Jira, Trello), согласование сроков и стоимости;
укажите, что любые изменения оформляются дополнительным соглашением;
установите плату за анализ запроса на изменение (например, 5 процентов от предполагаемой стоимости доработки).
В таком случае Заказчик не сможет сослаться на несогласованные в установленном порядке изменения.
Предусмотрите процедуру внесения изменений в формате «под себя»:
пропишите процедуру внесения изменений: форма запроса (например, через Jira, Trello), согласование сроков и стоимости;
укажите, что любые изменения оформляются дополнительным соглашением;
установите плату за анализ запроса на изменение (например, 5 процентов от предполагаемой стоимости доработки).
В таком случае Заказчик не сможет сослаться на несогласованные в установленном порядке изменения.
#3. Просрочка из‑за несвоевременного предоставления данных
Чтобы минимизировать риски, связанные с несвоевременным предоставлением данных заказчиком, в договоре можно включить следующие формулировки и условия:
Пример №1 (общее указание)
Заказчик обязуется предоставить Исполнителю все необходимые для выполнения работ данные, включая доступы к системам, API-документацию, тестовые данные и иную информацию, в сроки, согласованные Сторонами в Приложении № [номер] к настоящему Договору. В случае отсутствия в Приложении конкретных сроков Заказчик обязан предоставить данные в течение [указать срок, например, 5 рабочих дней] с момента подписания Договора либо с момента письменного запроса Исполнителя».
Дополнительные уточнения:
Дополнительные уточнения:
- Формат предоставления данных: «данные предоставляются в электронном виде через [указать канал связи, например, корпоративную почту, облачный сервис] в структурированном виде, удобном для обработки Исполнителем».
- Ответственность за достоверность данных: «Заказчик гарантирует достоверность и полноту предоставляемых данных. В случае выявления Исполнителем ошибок или неполноты данных Заказчик обязан устранить их в течение [указать срок] с момента уведомления».
Пример № 2 (последствия нарушения сроков предоставления)
«При нарушении Заказчиком сроков предоставления данных, предусмотренных п. [номер пункта договора] настоящего Договора, сроки выполнения работ автоматически продлеваются на период просрочки. Исполнитель не несёт ответственности за задержку в выполнении работ, вызванную несвоевременным предоставлением данных со стороны Заказчика».
Дополнительные условия:
Дополнительные условия:
- Уведомление исполнителя: «Исполнитель обязан уведомить Заказчика о задержке в выполнении работ в связи с несвоевременным предоставлением данных в течение [указать срок, например, 3 рабочих дней] с момента выявления просрочки».
- Компенсация затрат: «Если задержка в предоставлении данных привела к дополнительным затратам Исполнителя (например, оплате простоя сотрудников), Заказчик обязан компенсировать эти затраты в размере, согласованном Сторонами или определённом на основании фактически понесённых расходов».
Дополнительные меры ответственности
- Расторжение договора: «При неоднократном нарушении сроков предоставления данных (более [указать количество, например, 2 раз] в течение срока действия Договора) Исполнитель вправе расторгнуть Договор в одностороннем порядке с возмещением понесённых расходов».
- Возмещение убытков: «Заказчик возмещает Исполнителю все документально подтверждённые убытки, возникшие из-за несвоевременного предоставления данных, включая упущенную выгоду, если она доказана».
#4. Претензии по качеству из‑за сторонних библиотек
Решение: укажите, что ПО может использовать open‑source‑компоненты (например, React, Spring), и ответственность за их стабильность лежит на сообществах разработчиков.
Чтобы минимизировать риски, связанные со сторонними библиотеками, в договоре можно включить положение с явным указанием на использование open source-компонентов.
Общая формулировка:
«Исполнитель вправе использовать в рамках разработки ПО открытые компоненты (библиотеки, фреймворки и т.п.), распространяемые под открытыми лицензиями (например, React, Spring и др.). Заказчик осведомлён о таком использовании и согласен с этим».
Дополнительно следует обратить внимание на следующие 3 варианта основных формулировок, защищающих интересы подрядчика, при использовании открытых компонентов:
Чтобы минимизировать риски, связанные со сторонними библиотеками, в договоре можно включить положение с явным указанием на использование open source-компонентов.
Общая формулировка:
«Исполнитель вправе использовать в рамках разработки ПО открытые компоненты (библиотеки, фреймворки и т.п.), распространяемые под открытыми лицензиями (например, React, Spring и др.). Заказчик осведомлён о таком использовании и согласен с этим».
Дополнительно следует обратить внимание на следующие 3 варианта основных формулировок, защищающих интересы подрядчика, при использовании открытых компонентов:
Ограничение ответственности подрядчика
Пример формулировки:
«Исполнитель не несёт ответственности за невозможность использования ПО или его части из-за прекращения поддержки, устаревания или изменения условий лицензирования сторонних компонентов».
«Исполнитель не несёт ответственности за невозможность использования ПО или его части из-за прекращения поддержки, устаревания или изменения условий лицензирования сторонних компонентов».
Порядок действий при возникновении проблем
Пример формулировки:
«При выявлении недостатков, связанных со сторонними компонентами, Заказчик обязан самостоятельно обратиться к их разработчикам или правообладателям. Исполнитель оказывает содействие в предоставлении необходимой информации, но не обязан устранять такие недостатки за свой счёт».
«При выявлении недостатков, связанных со сторонними компонентами, Заказчик обязан самостоятельно обратиться к их разработчикам или правообладателям. Исполнитель оказывает содействие в предоставлении необходимой информации, но не обязан устранять такие недостатки за свой счёт».
Согласие заказчика с принципом «как есть» (as is)
Пример формулировки:
«Заказчик принимает ПО в том состоянии, в котором оно передано, включая возможные недостатки, связанные со сторонними компонентами. Все риски, связанные с их использованием, несёт Заказчик».
Указанный принцип "как есть" допустим в договорах между субъектами предпринимательской деятельности и снижает ответственность подрядчика.
«Заказчик принимает ПО в том состоянии, в котором оно передано, включая возможные недостатки, связанные со сторонними компонентами. Все риски, связанные с их использованием, несёт Заказчик».
Указанный принцип "как есть" допустим в договорах между субъектами предпринимательской деятельности и снижает ответственность подрядчика.
#5. Споры о доработках после приемки
- Решение: разделите:
- гарантийную поддержку (устранение ошибок в течение установленного договором срока);
- новые требования (оформляются отдельным договором).
Учтите, что подобного рода услуги можно считать оконченными с момента получения заказчиком авторизационных данных и при условии, что исполнитель обеспечил работоспособность (см. Постановление Арбитражного суда Западно-Сибирского округа от 03.08.2022 № Ф04-3523/2022 по делу № А46-18647/2021).
Пример формулировки о гарантийных обязательствах:
Гарантийное обслуживание включает в себя устранение ошибок, допущенных по вине Исполнителя при исполнении настоящего Договора. Все Услуги в рамках гарантийного обслуживания оказываются силами и за счет Исполнителя с максимальным приоритетом.
Гарантийный срок на Услуги, оказанные по настоящему Договору, составляет 3 (три) месяца, начиная с момента подписания Акта об оказании услуг.
Гарантийное обслуживание не включает в себя создание новых настроек программного продукта.
Гарантии, указанные в настоящем разделе, не распространяются на ошибки в функционировании результатов оказанных Услуг, возникшие вследствие неправильного использования результатов или действиям Заказчика, противоречащим пользовательским (информационным) материалам, переданным Исполнителем.
Гарантийное обслуживание включает в себя устранение ошибок, допущенных по вине Исполнителя при исполнении настоящего Договора. Все Услуги в рамках гарантийного обслуживания оказываются силами и за счет Исполнителя с максимальным приоритетом.
Гарантийный срок на Услуги, оказанные по настоящему Договору, составляет 3 (три) месяца, начиная с момента подписания Акта об оказании услуг.
Гарантийное обслуживание не включает в себя создание новых настроек программного продукта.
Гарантии, указанные в настоящем разделе, не распространяются на ошибки в функционировании результатов оказанных Услуг, возникшие вследствие неправильного использования результатов или действиям Заказчика, противоречащим пользовательским (информационным) материалам, переданным Исполнителем.
#6. Споры о правах на интеллектуальную собственность
Рекомендуется четко указать в договоре следующее:
- подрядчик сохраняет права на используемые фреймворки и утилиты;
- заказчик получает исключительные права только на конечный продукт.
#7. Неоплата из‑за «незавершённости» проекта
- Решение: предусмотрите поэтапную оплату с авансом за каждый спринт. При расторжении договора подрядчик проще сможет доказать выполненный объем.
Такое условие будет означать, что заказчику нужно организовать проверку результатов в указанный период или дату. Конкретный срок на приемку работ по договору подряда и отказ от нее помогут взыскать долг, даже если заказчик не подписывает акты.
Чтобы процесс сдачи не превратился в бесконечное ожидание и переделку, подрядчику нужно: прописать срок на приемку работ и подписание направленного заказчику акта и не забыть направить уведомление заказчику о необходимости проведения приемки (определение СКЭС ВС РФ от 21.11.2023 № 305-ЭС21-24521 № А40-178725/2020).
#8. Утечка исходного кода
Утечка исходного кода — ситуация, когда исходный код программного обеспечения становится доступным третьим лицам без разрешения правообладателя.
Заказчик, получивший исходный код, может передать его сторонним разработчикам для доработки или поддержки, опубликовать его в открытом доступе или использовать в других сторонних проектах.
Чтобы минимизировать риск утечки, включите в договор следующие положения:
Заказчик, получивший исходный код, может передать его сторонним разработчикам для доработки или поддержки, опубликовать его в открытом доступе или использовать в других сторонних проектах.
Чтобы минимизировать риск утечки, включите в договор следующие положения:
А) Вариант прямого запрета:
«Заказчик обязуется не передавать исходный код ПО, созданный Исполнителем по настоящему Договору, третьим лицам без письменного согласия Исполнителя. Запрет распространяется на любые формы передачи: продажу, аренду, безвозмездную передачу, публикацию в открытом доступе и т. д.».
Детализация:
«Заказчик обязуется не передавать исходный код ПО, созданный Исполнителем по настоящему Договору, третьим лицам без письменного согласия Исполнителя. Запрет распространяется на любые формы передачи: продажу, аренду, безвозмездную передачу, публикацию в открытом доступе и т. д.».
Детализация:
- укажите, что запрет действует как в период действия договора, так и после его завершения;
- определите срок действия запрета (например, 5 лет после окончания договора или бессрочно);
- предусмотрите штраф за нарушение (например, фиксированная сумма или процент от стоимости договора).
Б) Вариант оформления лицензионного соглашения с ограничениями использования:
Исполнителем предоставляется Заказчику неисключительная лицензия на использование ПО в пределах, установленных Договором. Такая лицензия может быть установлена на ограниченной территории, ограничена количеством машин / пользователей / учетных записей или предназначенной исключительно для внутренних бизнес‑процессов Заказчика.
Исполнителем предоставляется Заказчику неисключительная лицензия на использование ПО в пределах, установленных Договором. Такая лицензия может быть установлена на ограниченной территории, ограничена количеством машин / пользователей / учетных записей или предназначенной исключительно для внутренних бизнес‑процессов Заказчика.
- В) Вариант использования систем контроля версий (GitHub/GitLab)
- Пример формулировки:
В случае предоставления Заказчику доступа к репозиторию:
доступ предоставляется только уполномоченным сотрудникам Заказчика;
- настройки доступа ограничиваются правами „только для чтения“;
- Заказчик обязуется не копировать код из репозитория без письменного согласия Исполнителя».
В качестве дополнительных мер, которые можно предусмотреть в договоре под данный риск, могут выступать обязанность заказчика настроить двухфакторную аутентификацию или регулярный аудит прав доступа.
- В качестве дополнения:
Рекомендуется уделить внимание и форс-мажору, в т.ч. хакерским / DoS-атакам / временным отключениям Сети «Интернет» (ИТ-сбои относятся к предпринимательскому риску, если компания не предприняла базовых мер защиты и не зафиксировала порядок действий в договоре см. постановление Арбитражного суда Московского округа от 08.12.2023 по делу № А40-293189/2022); мобилизации, в т.ч. частичной (см. Определение Второго кассационного суда общей юрисдикции от 22.04.2025 по делу № 88-6550/2025).
Требуется аудит или составление договора на разработку ПО? Оставьте заявку и с Вами свяжутся любым удобным для Вас способом.
Телефон: +7-953-535-22-46
Почта: info@pehterev-pro.ru
Почта: info@pehterev-pro.ru
Telegram/WhatsApp: +7-953-535-22-46
Нажимая на кнопку, вы даете согласие на обработку персональных данных и соглашаетесь c Политикой конфиденциальности.
Смотрите также:
