1. Договор на разработку ПО — договор подряда.
По «духу» разработка ПО ближе всего к договору строительного подряда. Современное программное обеспечение разрабатывается по итеративной модели, то есть делается часть работ, потом другая, третья итерация и т.д. Это можно сравнить со строительством дома: фундамент, стены, проводка, отделка и т.д.
Иногда выдвигается мнение, что разработка ПО — договор возмездного оказания услуг, но эта позиция скорее ошибочна. Возмездное оказание услуг — процесс, тогда как сторонам нужен результат в виде некоего продукта.
2. Всегда нужно четко делить работы на этапы.
Так же как и поэтапные пуски комплексов в строительстве, по договору на разработку ПО всегда необходимо четко делить этапы разработки на части (они же итерации) и в актах приема-передачи прописывать, что принимается. После этого можно переходить к следующей итерации, подписывать акт и т.д.
Это позволит, во-первых, четко понять, к чему идет разработка, то есть разрабатывается ли то, что нужно, а во-вторых, в случае спора упростит заказчику доказывание необходимости оплаты фактических затрат подрядчика.
3. Договор подряда + передача исключительных прав.
Возникает вопрос: как передать права на разработанное ПО? Все-таки в нем может быть много элементов: музыка, изображения, интерфейс и т.п. В договоре на разработку желательно оговаривать передачу заказчику исключительных прав на разработанный продукт.
Сделать это можно и отдельным договором уступки исключительных прав, но лучше предусмотреть в договоре на разработку, так как исполнитель (он же разработчик) после сдачи выполненных работ уже может быть не заинтересован в передаче исключительных прав и просто отложить этот вопрос «в долгий ящик».
4. Акт приема-передачи НЕ на 300 страниц.
Как уже было сказано, ПО — комплексный продукт, включающий различные элементы, которые как-то нужно указать в акте приема-передачи. В акте в общих случаях указывается товар или передаваемое имущество. И чтобы этот акт не был на 300 страниц, перечисляя каждый элемент от кода до кнопок и элементов дизайна, в акте можно указывать реализованные задачи, отраженные в техническом задании на разработку.
Точно так же заказчику следует внимательно читать договор на предмет оговорок вроде «работы считаются принятыми заказчиком, если от него не последует ответа в течение N дней после получения акта». Есть судебные прецеденты, когда по этой причине суд отказывает заказчику в защите прав.
5. Привлекайте бухгалтерию.
На старте разработки и на поэтапной приемке работ необходимо привлекать бухгалтерию, чтобы в последующем не было трудностей с приемкой к учету ПО.
6. Гарантия на ПО.
В привычном понимании нет гарантийного срока, в течение которого заказчик может предъявить к исполнителю претензию по качеству или другим недостаткам разработанного продукта. При разработке ПО чаще всего разработчик безвозмездно дорабатывает продукт. Баги и ошибки выявляются в ходе приемочного тестирования или непосредственного использования продукта.
Однако не следует забывать, что срок исковой давности по договору подряда довольно короткий — год (ст. 678 ГК). Поэтому заказчику не стоит затягивать с предъявлением претензий хотя бы формально, если разработчик не хочет исправлять ошибки в продукте.
