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

Заказчик считает, что сделали не в срок, совсем не так, как договаривались. Хочет, чтобы бесплатно переделали, раз сделали так плохо, — ну или вернули деньги. А исполнитель уверен, что все сделал как надо, что заказчик вовремя не давал доступы, не принимал промежуточный результат и всячески мешал. В итоге понесли лишние неоплаченные трудозатраты. Хочет оплату и компенсацию переработок. Знакомая ситуация? Кажется, тогда эта статья будет вам полезна.

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

Перечислю тезисно, что может хороший договор:

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

Тип договора в данном случае не так важен. Ниже речь пойдет о более-менее универсальных вопросах, которые органично можно вписать в любой договор: T&M, аутстаффинг или аналоги, обычный или рамочный договор выполнения работ и/или оказания услуг.

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

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

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

Цепочка будет выглядеть так:

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

Важно обратить внимание на момент передачи права. Например, одна компания подписала договор, в котором моментом перехода исключительного права было подписание акта приемки. Работу исполнитель выполнил некачественно, поэтому заказчик был не готов подписать акт. Получилось, что у заказчика есть код, который он не может использовать, поскольку правообладатель (исполнитель) не давал разрешения и не передал права.

Также проблема может возникнуть при поэтапной сдаче. Если вы принимаете результат в несколько итераций, в случае спора может быть сложно доказать, что к вам перешли права на конкретную часть кода.

Можно рассматривать несколько вариантов, например:

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

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

Постановка ТЗ

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

Очень банальная фраза, что “Без ТЗ результат ХЗ” все еще работает. Именно так и происходит. Если не получается зафиксировать точные критерии на старте, можно протоколировать встречи. Такие протоколы можно будет подписать сторонам и использовать как критерии приемки, если заранее это прописать в договоре.

Возможность использования Open Source

Open Sourse или открытое программное обеспечение может быть коварным. Такие лицензии могут накладывать ограничения на использование программы в целом.

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

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

Оплата доработок и нового функционала

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

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

Универсальных договорных решений два:

• почасовая ставка (или договор T&M, как вам привычнее);
• неустанно подписывать допники на новую доработку.

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

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

Последствия просрочки и приостановка работы

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

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

Наверное, вы обратили внимание, что я рассказывала несколько небольших историй. Это опыт и ошибки моих клиентов: заказчиков и исполнителей. Сложности, с которыми они сталкивались, и обращались за помощью в их решении.

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

Давайте сделаем полезно? Расскажите в комментариях, с какими сложностями и спорами вы сталкивались при работе с заказчиками или исполнителями? Может быть, дело уже доходило до суда или в результате решили мирно, но было уже немного тревожно?

Спасибо, что прочитали! Буду очень рада услышать ваш опыт в комментариях.
---
Больше интересного и полезного в моем канале, буду вам рада