Многие компании нуждаются в автоматизации своего бизнеса. Готовые решения-программы рассчитаны на среднего потребителя и зачастую не учитывают особенности функционирования конкретной компании.
Компании адаптируют уже существующие программы или заказывают разработку программ под конкретные цели и с учетом их специфики. В ходе реализации такого проекта компании сталкиваются с определенными трудностями, связанными с подготовкой технического задания, необходимого для написания программ, передачей прав на готовые программные продукты и т. д.
Для исключения неприятных ситуаций рекомендуем заранее оговорить в договоре на разработку программного продукта некоторые спорные моменты, с которыми может столкнуться конкретный заказчик на различных этапах выполнения работ.
1. Рекомендуем разработать техническое задание, на основе которого и будет разрабатываться ПО. Только при наличии сформулированного технического задания, когда разработчику заранее ясны объемы и сложность проекта, можно оценить, сколько времени займет создание ПО, а следовательно, и стоимость разработки продукта.
Техническое задание может разрабатываться в рамках общего проекта по созданию ПО либо в рамках отдельного проекта (иногда не менее длительного, чем непосредственно разработка соответствующего программного продукта), в последнем случае такое техническое задание может являться самостоятельным предметом договора с ИТ-компанией.
Рекомендуем предусмотреть в договоре с разработчиком порядок внесения изменений в техническое задание. В процессе создания ПО у заказчика часто появляются новые идеи по поводу того, как можно улучшить программу, чтобы она в максимальной степени соответствовала потребностям компании и протекающим в ней бизнес-процессам. Если в результате изменений у разработчика увеличивается объем работы, стоит определить, как будут корректироваться стоимость услуг и сроки завершения проекта.
2. В договоре необходимо указать, кто является владельцем исключительных прав на программное обеспечение — разработчик или заказчик. Объем, в котором передаются права, является предметом для переговоров между разработчиком и заказчиком и влияет на цену программы.
Разработчику можно рекомендовать предусмотреть в договоре, что права на часто используемые, повторяющиеся в разных программах элементы остаются за ним, а заказчик получает неисключительную лицензию на их использование.
3. Заказчик не может принять работу разработчика ПО, не проверив ее как следует. Результаты тестирования будут решающим фактором при принятии работы. Поэтому и заказчик, и разработчик заинтересованы в предварительном определении процедуры и сроков тестирования. Таким образом, при заключении договора необходимо подумать, как будет проходить тестирование (в частности, будет ли оно осуществляться самостоятельно заказчиком или с привлечением экспертов) и ограничить срок тестирования, в течение которого заказчик должен или принять работу, или указать на ошибки, из-за которых он не может принять продукт.
4. Также, в случае разработки сложного продукта, можно рекомендовать включить в договор условие о подготовке разработчиком инструкции пользователя (user manual).
5. Рекомендуем в договоре согласовать гарантийный срок на программу: чем сложнее программа — тем дольше должен быть срок гарантии. В этом случае, если в процессе использования заказчик обнаружит ошибки в программе, разработчик должен будет их бесплатно устранить.
6. Проект может предусматривать длящиеся обязательства разработчика по обеспечению поддержки определенного уровня и обновления программы.
Но что же происходит в ситуации, когда разработчик попадает в ситуацию банкротства и таким образом нарушает свои обязательства по сопровождению/обновлению ПО?
Это может стать большим фактором риска (операционная зависимость, стоимость и время замены), когда по условиям договора исходный код не передан. Здесь на помощь сторонам может прийти широко применяемый за рубежом институт software escrow (депонирование исходного кода).
Software escrow предусматривает передачу копии исходного кода программного продукта разработчиком третьей стороне — эскроу-агенту на хранение. Агент вправе раскрыть такой код клиенту только в строго определенных сторонами случаях.
Более подробно о депонировании кода в следующей публикации.
Авторы статьи — представители юридической фирмы LegalTec.
