После запуска продукта первоначальное техническое задание редко остается неизменным. Пользователи просят новые функции, появляется необходимость подключить платежную систему, изменить интерфейс или добавить новый модуль.
Рассмотрим типичную ситуацию. Компания заказала разработку CRM, а через два месяца решила добавить личный кабинет и интеграцию с сервисом оплаты. Разработчик готов приступить к работе сразу, но возникает вопрос: нужно ли подписывать новый договор?
В большинстве случаев ‒ нет. Если проект продолжается, достаточно правильно оформить изменения.
Именно поэтому договор на разработку программного обеспечения должен содержать не только описание первоначальных работ, но и понятный механизм дальнейшего развития и сопровождения продукта.
Когда новый договор не требуется
Для украинских договоров общий принцип закреплен в статьях 651 и 654 Гражданского кодекса Украины: стороны могут изменить договор по взаимному согласию, а изменения обычно оформляются в той же форме, что и основной договор.
Иными словами, при каждой новой задаче не требуется заключать отдельный договор ‒ достаточно оформить изменения в рамках уже действующего соглашения.
Поэтому ещё на этапе подготовки договора стоит заранее определить:
- кто вправе согласовывать изменения;
- каким документом они оформляются;
- когда исполнитель может приступать к работе;
- как новые задачи влияют на стоимость и сроки проекта.
Такие положения экономят гораздо больше времени, чем последующее согласование каждого изменения с нуля.
Что использовать вместо нового договора
Выбор документа зависит от того, что именно меняется.
- Дополнительное соглашение ‒ если изменяются стоимость проекта, сроки выполнения или порядок оплаты.
- Change Request ‒ если появляется новая задача или меняется ранее согласованный объем работ.
- Спецификация ‒ если необходимо подробно описать новый функционал, требования к системе, порядок тестирования и критерии приемки.
Пример: если внедрение новой CRM требует переработки архитектуры и изменения базы данных (изменение объема работ), а также переноса даты запуска (изменение сроков), эти последствия должны быть согласованы до начала разработки в соответствующих документах. Иначе после завершения работ заказчик может считать их частью первоначального проекта, а исполнитель ‒ дополнительной услугой.
Кейс: почему изменения должны оформляться письменно
Во время проекта по созданию новой системы управления воздушным движением для британской National Air Traffic Services (NATS), который реализовывался при участии IBM, часть требований продолжала уточняться уже после подписания контракта. Позже парламент Великобритании отметил, что незавершённые спецификации и изменение требований в ходе разработки стали одной из причин задержек проекта и роста его стоимости.
Для стартапа масштаб другой, но проблема остается той же. Каждая новая функция или изменение алгоритма работы продукта кажется небольшой доработкой, однако со временем первоначальный объем работ меняется настолько, что стороны начинают по-разному понимать, что входило в проект, а за что исполнитель вправе требовать отдельную оплату.
Вывод: Change Request нужен не ради документов. Он позволяет зафиксировать изменение до начала разработки, оценить его влияние на стоимость и сроки и избежать споров о том, что именно было заказано.
Кому принадлежат права на доработки
Новая функция ‒ это не только дополнительные расходы, но и вопрос интеллектуальной собственности.
Новый модуль, оригинальный программный код или иное творческое решение могут охраняться авторским правом как часть компьютерной программы или самостоятельный результат разработки.
В Украине распределение прав на произведения, созданные по заказу, регулирует Закон Украины «Об авторском праве и смежных правах». При этом конкретный объем передаваемых прав, момент их перехода и возможность повторного использования кода лучше прямо закрепить в договоре.
В Европейском союзе компьютерные программы охраняются авторским правом в соответствии с Директивой 2009/24/EC. В свою очередь, конкретные правила распределения прав между заказчиком и разработчиком определяются не только законодательством соответствующей страны, но и условиями договора.
В США оплата работы независимого разработчика сама по себе не означает автоматического перехода авторских прав. Доктрина work made for hire применяется только при соблюдении установленных законом условий, поэтому договор обычно дополняют письменной уступкой прав на код и другие результаты разработки.
Поэтому перед согласованием новой задачи стоит убедиться, что договор определяет:
- кому принадлежат права на каждую доработку;
- когда они переходят заказчику;
- может ли исполнитель повторно использовать созданный код;
- входят ли в передачу исходный код, документация и доступы.
Именно эти вопросы инвесторы проверяют во время due diligence.
Вывод
Развитие IT-продукта невозможно заранее описать в одном техническом задании. Поэтому задача договора ‒ не запретить изменения, а установить понятный порядок их оформления.
Если в договоре на разработку программного обеспечения компании заранее предусмотреть механизм согласования новых задач, использовать Change Request, дополнительные соглашения и спецификации, каждая доработка станет продолжением проекта, а не причиной спора о стоимости, сроках или правах на результат.
В результате команда сохраняет темп разработки, контролирует бюджет и не сталкивается с ситуацией, когда спустя несколько месяцев стороны по-разному понимают объем выполненных работ.
Автор: Валерий Сталиров, CEO компании IT-юристов Stalirov&Co
