Как составить договор на оказания услуг по разработке программного обеспечения

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

Вот чтобы таких кошмаров не случалось, и нужен договор оказания услуг по разработке программного обеспечения. Это не формальность или бумажка – это страховка и ваш путеводитель в мире IT-проектов. Без него вы рискуете потерять деньги, время, нервы и даже права на то, что заказали. Например, представьте: разработали вам сайт, а потом выясняется, что права на него остались у разработчика, и вы не можете его нигде использовать без его разрешения!

Важно понимать, что для разных форм сотрудничества (будете вы нанимать человека для разовой задачи, или для полноценного создания уникального продукта) подходят разные типы договоров. И разобраться в них – это уже полдела!

Когда и кому нужен договор?

Кажется, очевидно, но давайте закрепим: договор на разработку ПО нужен всегда! И, как правило, его заключает:

• Бизнес. Любая компания, стартап или индивидуальный предприниматель, которым нужно новое ПО, сайт, приложение, доработка существующего продукта или его техническая поддержка.
• Разработчики. Будь то фрилансеры, небольшие студии или крупные IT-компании. Договор будет для них гарантией оплаты. Также он нужен для четкой формулировки задач.

Договор нужен, если:

• Создается ПО с нуля. Вы придумали гениальное приложение – договор защитит ваши права.
• Выполняется доработка существующего продукта. Нужно добавить новый функционал или улучшить старый.
• Требуется сопровождение и поддержка, чтобы ваш сайт или приложение работали без сбоев.

А почему устные договоренности недопустимы? Тут все просто. Слова – это не документ. Сегодня договорились так, завтра кто-то что-то забыл, не так понял, или вовсе сделал вид, что не помнит. В суде устные договоренности – это «слова против слов». А вот письменный договор – это четкий документ, который защищает интересы обеих сторон. Он убирает двусмысленность и фиксирует правила игры. При заключении договора со специалистами по IT системам убедитесь, что все копии документа заверены подписями с печатью организации, иначе они не будут иметь юридической силы по нормам ГК РФ.

Какой тип договора выбрать? Не ошибитесь!

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

Договор возмездного оказания услуг (ДОУ)

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

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

Пример 1: Вам нужен ИТ-консультант, который проверит вашу систему безопасности и даст рекомендации. Вы платите за его время и экспертизу, за его «услугу» по аудиту. Он не создает для вас новое ПО.

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

Пример 3: Вы хотите, чтобы программист провел аудит вашего кода и нашел в нем ошибки или потенциальные уязвимости. Вы платите за его работу, за «услугу» по анализу кода, но не за исправление этих ошибок или написание нового функционала.

Если по ДОУ вам напишут код, то права на этот код останутся у исполнителя, а вы получите только «услугу по написанию». Эта ошибка может стоить вам всех прав на ваш продукт!

Абонентский договор на разработку ПО также относится к этому типу договоров.

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

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

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

Договор ГПХ, или договор гражданско-правового характера, – это соглашение между заказчиком и исполнителем, регулирующее выполнение работ или оказание услуг, не являющееся трудовым договором. В отличие от трудового договора, договор ГПХ не предполагает трудоустройства в штат и заключается на определенный срок или для выполнения конкретной задачи.

Договор подряда подходит для создания конкретного ПО с четким техническим заданием. Например, если вы заказываете разработку мобильного приложения с прописанным функционалом. Результат – это то, что можно пощупать или увидеть: построенный дом, отремонтированная машина, или в нашем случае – готовое ПО. Если заключается договор ГПХ на разработку программного обеспечения, то исполнитель обязуется выполнить определенную работу и передать результат этой работы заказчику.

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

Пример 2: Вам нужно создать корпоративный сайт-визитку или интернет-магазин с заранее утвержденным дизайном и набором функций.

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

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

Договор на создание произведения по заказу (договор авторского заказа)

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

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

Пример 1: Вы заказываете разработку новой ОС специально для ЭВМ, для ноутбука или сложной, инновационной платформы, которая является вашим «ноу-хау». Здесь нужна передача всех прав на интеллектуальную собственность.

Пример 2: Вы заказываете разработку сложной CRM-системы или ERP-системы, которая будет полностью кастомизирована под ваши бизнес-процессы и станет вашей интеллектуальной собственностью.

Если вам нужно готовое ПО, которое будет принадлежать вам, выбирайте договор подряда или договор авторского заказа!

Рамочный договор на разработку программного обеспечения с этапами

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

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

Он выручает, когда нужно запустить большой и сложный IT-проект! Рамочный договор задает все базовые правила игры на будущее: кто что делает, как соблюдается конфиденциальность, кому принадлежат права на созданный код, как будут проходить платежи и как решаются возможные споры. Он не описывает каждую мелочь конкретного проекта, но создает надежную «рамку» для долговременного и гибкого взаимодействия.

А когда мы добавляем фразу: «на разработку программного обеспечения с этапами», это значит, что весь проект разбивается на маленькие, понятные и управляемые части. Каждый этап оформляется отдельным документом, где прописаны задачи только для этой конкретной фазы. Это удобно, ведь легче контролировать ход работ. Вы можете вносить изменения после каждого этапа, менять приоритеты или добавлять новые идеи, не переписывая большой договор. Это подходящее решение для динамичной сферы разработки ПО, где предсказать все на год вперед невозможно.

Основные разделы договора. Что должно быть в нем?

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

Предмет договора

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

• Четкое описание создаваемого ПО. Например, «Разработка мобильного приложения для iOS и Android под названием «Мой ЗОЖ-трекер»».
• Функции ПО. «Приложение должно помогать пользователям отслеживать калории, записывать тренировки, ставить цели и получать рекомендации по питанию».
• Технологии. «Разработка ведется на React Native, база данных – PostgreSQL».
• Совместимость, платформы. «Совместимость с iOS 15+ и Android 10+».

Техническое задание (ТЗ)

Это ваш детальный план выполнения проекта! В нем прописаны все требования к будущему ПО.

Пример характеристик: «Язык программирования: Python 3.9. Операционные системы: Windows 10, macOS Ventura. Формат передачи данных: JSON. Функционал: личный кабинет пользователя, каталог товаров, корзина, онлайн-оплата, система отзывов».

Чем подробнее ТЗ, тем меньше споров возникнет при выполнении задания.

Сроки и этапы разработки

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

Примерная формулировка: «Проект делится на 3 этапа: 1. Дизайн и UX-прототип (срок до 15.08.2025). 2. Разработка бэкенда и базы данных (срок до 15.09.2025). 3. Разработка фронтенда и интеграции, итоговая сборка и тестирование (срок до 15.10.2025)».

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

Права и обязанности сторон

Здесь нужно указать: что должен заказчик, что должен исполнитель.

Обязанности заказчика: своевременная оплата, предоставление необходимой информации и доступов, оперативное тестирование и приемка работ, предоставление обратной связи.

Обязанности исполнителя: соблюдение сроков, выполнение работ по ТЗ, обеспечение качества, предоставление отчетности, передача исключительных прав.

Оплата и ответственность

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

Варианты оплаты могут быть такими:

• Фиксированная цена (Fixed Price). Вы заранее договариваетесь на конкретную сумму за весь проект. Идеально, если ТЗ – детальное и не будет меняться.
• Почасовая ставка (Time & Materials). Вы платите за фактически отработанные часы и потраченные материалы. Подходит, когда проект гибкий, и ТЗ может меняться в процессе. Обязательно указывайте ставку часа и периодичность оплаты.

Штрафы и неустойки: обязательно пропишите, что будет, если одна из сторон нарушит свои обязательства. Например: «В случае просрочки сдачи этапа исполнитель уплачивает неустойку в размере 0.1% от суммы этапа за каждый день просрочки» или «За некачественную работу исполнитель обязуется устранить недостатки за свой счет в течение N дней». Это стимулирует обе стороны быть ответственными.

Передача исключительных прав

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

Альтернатива – лицензирование. Иногда вместо полной передачи прав исполнитель может предоставить вам лицензию на использование ПО. Это как аренда, а не покупка. В таком случае в договоре прописываются условия лицензии: срок, территория использования, возможность модификации и т.д. Но для большинства бизнесов лучше стремиться к полной передаче исключительных прав.

Гарантийное обслуживание и поддержка

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

Примеры формулировок: «Исполнитель обязуется устранять баги и критические ошибки, выявленные при использовании ПО, в течение 3 месяцев с даты его передачи заказчику, без доплаты». Или: «Исполнитель оказывает техническую поддержку ПО по тарифу X в течение Y месяцев после завершения проекта». Это обеспечит вам спокойствие после релиза.

Конфиденциальность и коммерческая тайна

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

Четко определите, какие данные (коммерческие тайны, ноу-хау, клиентские базы) считаются конфиденциальными. Укажите, как исполнитель обязуется их защищать, не разглашать третьим лицам и что будет в случае нарушения. Пропишите, как передаются такие данные (только по защищенным каналам). Это поможет избежать утечек ценной информации.

Особенности международных контрактов

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

Учитывайте:

• Валютные риски. Надо прописать курс на момент оплаты или привязаться к курсу ЦБ.
• Юрисдикцию и применимое право. Если возникнет спор, где его будут решать? В суде какой страны? По законам какой страны? Это должно быть четко прописано. Например: «Споры разрешаются в Лондонском арбитражном суде по законам Англии и Уэльса».
• Защиту интеллектуальной собственности в разных странах. Законы об авторских правах отличаются! Убедитесь, что передача исключительных прав действительна в юрисдикции вашей страны и страны исполнителя. Возможно, потребуется двойная регистрация.
• Разницу часовых поясов и локализацию. Это не юридические, но практические моменты. Договоритесь о времени созвонов. Обсудите, кто отвечает за перевод и адаптацию ПО для разных языков и культур (локализацию).

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

Ошибки и риски при заключении договора

Вот самые частые «грабли», на которые наступают новички и даже опытные игроки:

• Отсутствие формулировки об исключительных правах. Мы уже говорили, но повторю – это страшная ошибка! Если нет четкого пункта о передаче прав, ПО остается собственностью разработчика.Всегда включайте в договор отдельный, подробный пункт о передаче исключительных прав.
• Непрописанные этапы разработки..Проект без четких этапов – это «болото». Непонятно, что делается, когда ждать результат, за что платить. Делите проект на логические, измеримые этапы с четкими сроками и критериями приемки.
• Устные договоренности. «Да ладно, мы же договорились!» – это путь к разочарованию. Все, что касается проекта, должно быть зафиксировано на бумаге (или в электронном документе с подписями). Изменения вносятся только через дополнительные соглашения.
• Отсутствие гарантий. Что делать, если ПО «глючит» после запуска? Включите в соглашение раздел о гарантийном обслуживании и поддержке, где прописаны сроки и условия бесплатного исправления ошибок.

Заключение

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

Лучше потратить время на грамотную проработку условий договора с юристом по IT-праву. Это окупится сторицей! Чем потом тратить гораздо больше сил, времени и денег на решение проблем через суд, выяснение отношений и переделки.

Помните: четкий, понятный и всеобъемлющий договор оказания услуг по разработке программного обеспечения – это половина успеха вашего IT-проекта.