РАЗРАБОТЧИК ПРОДАВАЛ ПРИЛОЖЕНИЕ, НО НЕ ЗАРАБОТАЛ, А ПОТЕРЯЛ, потому что….
неправильно согласовал договор с Заказчиком. Делимся нашим кейсом: один крутой девелопер заказал у разработчика приложение. Первое время все шло гладко: Исполнитель спринтами сдавал работы, Заказчик — оплачивал.
Но когда дошли до выполнения работ, для которых Заказчик должен был предоставить методы API-интеграции, выяснилось, что они не были готовы.
Дальнейший сюжет больше похож на сценарий драмеди:
- Исполнитель останавливает работы в ожидании методов интеграций.
- Заказчик ждет результата, руководствуясь стойким убеждением, что работы можно продолжить и без них.
- В договоре ни слова про действия Исполнителя, в ситуации, когда Заказчик не дает методы.
После нескольких виражей переговоров Исполнителем было принято решение: сдать работы, которые можно сделать без методов интеграции, и попрощаться. Но и тут Исполнителя ожидал очередной сюжетный твист.
Чтобы не затягивать процесс, Разработчик выполнял работы, которые можно сделать без методов. В договоре же была оговорена только общая стоимость работ и стоимость каждого из спринтов (то есть без детализации). И как в таких условиях считать выполненные в ожидании методов интеграции работы, совсем непонятно.
Закончилось все хорошо: заказчик получил практически готовое приложение, исполнитель – деньги, юристы – классный кейс о том, «как не надо» составлять договор.
☹ При этом, у каждой стороны появилась копна седых волос и привычка очень глубоко вздыхать. Если не хотите также — welcome к прочтению нашей статьи о том, как правильно составить договор на заказную разработку.
ДИСКЛЕЙМЕР: мы хотим быть одинаково полезными и для Заказчиков, и для Разработчиков. Поэтому и статья будет разделена на две части: первая – для Заказчика, вторая — для Исполнителя.
Автор статьи:
I. ЗАКАЗЧИК: НА ЧТО ОБРАТИТЬ ВНИМАНИЕ В ДОГОВОРЕ?
За основу возьмем самое главное – деньги. Есть две основные модели расчета стоимости работ — Times & Materials и Fixed Price. В зависимости от модели для Заказчика меняются слепые зоны в положениях договора. О них мы и хотим рассказать, сравнение в таблице.
Вывод: если Вы заказываете разработку ПО, то необходимо:
- определиться с методикой расчета его стоимости
- обратить внимание на «слепые зоны» из таблички.
II. ИСПОЛНИТЕЛЬ: НА ЧТО ОБРАТИТЬ ВНИМАНИЕ В ДОГОВОРЕ?
Для Исполнителя red flags в договоре на заказную разработку не зависят от модели оплаты: они, в большинстве своем, универсальны.
Свели их в одну таблицу, пользуйтесь.
ВЫВОДЫ:
1. Самые распространенные варианты расчета стоимости в договорах на разработку ПО:
2. Для Заказчика слепые зоны в договоре:
3. Для Исполнителя слепые зоны универсальны:
- Сроки: устанавливаем льготный срок и возможность приостановки работ
- Автоприемка актов: не забываем включать ее в договор
- Оплата: отчуждаем право на ПО не с момента подписания акта, а с момента оплаты
- Изменение ТЗ: устанавливаем ситуации, при которых это возможно
- Перерасход бюджета: устанавливаем лимиты
Если у Вас остались вопросы или захотелось делегировать решение подобных вопросов профессионалам – мы рядом:
– тел.: +7 (969) 790-00-90
– телеграм: @aglrequest
– эл. почта: info@ag-legal.ru.
Подписывайтесь на наш телеграм канал, где мы разбираем и другие актуальные для IT юридические вопросы.