Семь пунктов, обязательных в договоре на разработку ПО

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

Вот семь пунктов, которые это предотвращают.

Короткий ответ

Семь пунктов, и конкретные формулировки в каждом важнее, чем само наличие пункта с таким названием.

Право на IP и код с датой перехода

Самый важный пункт и тот, который чаще всего пишут расплывчато - намеренно или случайно.

«Клиент владеет всем результатом работ» звучит защищающе. Без триггера это не так: владеет с какого момента? В некоторых договорах право переходит только «по завершении сотрудничества» - и это становится реальной проблемой, если отношения заканчиваются на втором месяце четырёхмесячной разработки, потому что формально ничего не завершилось.

Что искать вместо этого: право переходит с каждым этапным платежом или сразу при создании с обратной лицензией разработчику для портфолио. Оба варианта работают. Расплывчатые сроки - нет.

Явные исключения из скоупа

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

«Разработка MVP согласно приложенному скоупу» слабее, чем кажется, если сам приложенный скоуп не перечисляет исключения - расходы на сторонние API, контент, миграцию данных, поддержку сверх оговорённого окна. Без этого списка обе стороны опираются на собственные допущения, а допущения редко совпадают.

Оплата по этапам, а не по календарю

График оплаты, привязанный к датам - net 30, потом через 30 дней, потом ещё через 30 - платит независимо от того, что-либо сдано или нет. Это лишает вас единственного реального рычага, если проект отстаёт.

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

Определённая процедура запроса на изменение

Скоуп изменится. Договор, который не говорит как, неявно говорит «разберёмся, когда это случится», а это выгодно тому, у кого в тот момент больше рычагов - обычно не вам, в середине проекта, когда смена подрядчика дорога.

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

Определённое, явно ограниченное окно поддержки

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

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

Условия расторжения и выхода

Каждый договор должен отвечать письменно, до того как это понадобится: что произойдёт, если одна из сторон захочет выйти до завершения проекта?

Минимум: срок уведомления, что причитается за выполненную к тому моменту работу, и подтверждение, что условия собственности (см. первый пункт) чисто применимы и при досрочном расторжении, а не только при успешном финале. Договор, описывающий только чистое завершение, не предусмотрел сценарий, наиболее вероятно ведущий к спору.

Конфиденциальность и запрет переиспользования

Стандарт для большинства профессиональных договоров, но стоит проверить конкретную вещь, которую основатели считают покрытой, а она часто нет: пункт, запрещающий разработчику переиспользовать вашу конкретную бизнес-логику, данные или проприетарный подход в проекте другого клиента, а не просто общая конфиденциальность о неразглашении вашего бизнеса.

Обычные NDA покрывают секретность. Этот пункт покрывает переиспользование - и именно эта версия имеет значение, если ценность вашего продукта в том, как что-то работает, а не просто в том, что оно существует.

Что делать, если этих пунктов в договоре нет

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

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

Изучаете договор на разработку MVP и хотите второе мнение по условиям? Пришлите детали - мы скажем, чего не хватает. Наша собственная структура договора, включая условия по IP и этапы оплаты, объяснена в разделе цены.