Когда цена и срок уже согласованы, договор на разработку сайта или приложения легко начать воспринимать как последнюю формальность перед стартом. Работать хочется начать вчера, а документ выглядит юридическим приложением к тому, о чём и так договорились.
Между тем многие важные для проекта пункты описывают вполне практические вещи: что считается готовым, как меняется объём, что происходит с кодом и доступами. К этим вопросам всё равно придётся вернуться по ходу работы. Разница только в том, когда: заранее, спокойно, за столом — или потом, в переписке, когда деньги уже уплачены, а мнения разошлись.
Чего в этой статье нет
Формулировок и советов, как составить документ. Я не юрист, и устройство договора зависит от того, кто с кем его подписывает, что именно передаётся и на каком основании — это разговор с юристом, а не со мной.
Я подписываю такие договоры с другой стороны стола и могу сказать другое: какие вопросы, на мой взгляд подрядчика, стоит решить в документе до старта. Если ответов на них нет, то, насколько складно он написан, уже неважно. Дальше — семь таких вопросов и то, что происходит, когда ответа нет.
Семь вопросов, которые стоит решить в договоре на разработку сайта или приложения
Для сайта и для приложения я проверял бы один и тот же набор вопросов, хотя конкретные ответы будут разными. Различается не рамка проверки, а то, что попадает внутрь пунктов. В договоре на разработку приложения могут появиться аккаунты магазинов, публикация, модерация и обновления операционных систем — если приложение вообще публикуется в магазинах. У сайта на тех же местах обычно стоят домен, хостинг, почта и перенос на боевой сервер. Список вопросов один, ответы разные.
1. Что считается результатом и как он принимается
Этот пункт кажется очевидным — пока у сторон не появляется разное понимание слова «готово».
Что решить. По какому признаку работа считается сданной — не «сайт готов», а «эти страницы открываются, эти сценарии проходят, вот на каких устройствах проверено». Сколько у вас дней на замечания. И как обрабатывается отсутствие замечаний в этот срок — порядок тоже должен быть понятен из документа, а не додумываться каждой стороной по-своему.
Что бывает без этого. Подрядчик считает этап сданным и ждёт оплату, заказчик считает, что «ещё не то», и обсуждение правок затягивается — потому что границу «готово / не готово» стороны понимают по-разному. Спорить тут, по сути, не о чем: просто её никто не определил.
2. Что происходит, когда объём меняется
По ходу проекта объём может измениться — появляются новые вводные, ограничения или пожелания. Ничего плохого в этом нет: часть вещей не видно на берегу.
Что решить. Как оформляется добавка: кто её оценивает, за какой срок, что происходит со сроком остальных работ и как это подтверждается — письмом, приложением, чем-то ещё.
Что бывает без этого. Возникает одна и та же неясность: входит новая задача в прежнюю цену или требует отдельной оценки. И технический вопрос превращается в спор о договорённостях. Порядок изменений нужен обеим сторонам, и это один из вопросов, которые стоит задать ещё на этапе проверки сметы — до того, как дело дойдёт до подписания.
3. Сроки — и что происходит при задержке с каждой стороны
Что решить. Из чего складывается срок и что в него входит с вашей стороны: тексты, фотографии, доступы к системам, ответы на вопросы, согласования внутри компании. И что происходит, если задерживает одна сторона или другая.
Что бывает без этого. Срок в договоре превращается в украшение. Подрядчик ждал доступов две недели, заказчик считает, что просрочка на подрядчике, — и оба по-своему правы, потому что документ про это ничего не говорит.
Отдельно скажу: пункт про задержку заказчика — не попытка подрядчика заранее оправдаться. Задержка с любой стороны может сдвинуть проект, поэтому зависимость срока от ваших материалов и решений лучше определить заранее.
4. Как связаны деньги и этапы
Что решить. Сколько платежей, к чему привязан каждый и что должно произойти, чтобы наступил следующий. Само наличие предоплаты здесь не главный вопрос — важнее понять, что вы получаете к каждому платежу.
Что бывает без этого. «Оплата по факту выполнения работ» без определения факта — это тот же спор о приёмке, только теперь с деньгами внутри.
5. Кому принадлежит результат и что именно передаётся
Тот самый вопрос про исходный код. С ним есть особенность: бывает, что обе стороны считают ответ очевидным — и понимают его по-разному.
Что решить — прямо в документе, а не по умолчанию. Что происходит с правами на созданный продукт, в каком объёме и в какой момент. Как это устроено юридически и что нужно, чтобы переход состоялся, — вопрос к юристу; моё дело сказать, что полагаться здесь на очевидность нельзя.
И отдельно — что физически передаётся. Это не одно и то же с правами, и здесь три разных слоя:
- Код самого проекта. То, что написано под вашу задачу.
- Чужие библиотеки внутри него. Почти любой современный продукт собран с использованием открытых компонентов, и на каждый действует его собственная лицензия. Поэтому права на них нельзя описывать так же, как права на код, написанный специально под вашу задачу.
- Собственные наработки подрядчика. Заготовки, внутренние инструменты, куски, которые он переносит из проекта в проект. Подрядчик может отдельно оговорить права на свои заранее существовавшие инструменты — главное, чтобы эта граница была понятна до подписания.
Помимо кода есть ещё доступы и аккаунты, которые тоже стоит перечислить заранее: серверы, магазины приложений, домен, почта, аналитика. Кто их регистрирует, на кого они оформлены и что происходит с ними при завершении работы — вопрос отдельный от кода и не менее практичный. Даже если домен оказался оформлен на подрядчика без всякого умысла, при расставании это создаёт вам лишнюю зависимость. Что именно у сайта должно быть оформлено на вас — домен, хостинг, панель управления, счётчик, почта, — перечислено в разборе разработки сайта под ключ.
6. Что происходит, если расстаёмся посреди проекта
Этот пункт легко отложить: в начале проекта обе стороны рассчитывают, что расставаться не придётся. Именно поэтому он и попадает в список.
Что решить. Как каждая сторона может выйти, что происходит с уплаченными деньгами и с уже сделанной работой, что передаётся при выходе.
Что бывает без этого. Расставание на середине — и без того неприятная ситуация; без описанного порядка она превращается в переговоры без правил, где сильнее тот, у кого на руках больше — деньги у одного, доступы и код у другого.
7. Где кончается гарантия и начинается платная работа
Что решить. Что исправляется бесплатно и в какой срок, чем это отличается от доработок, и по какой ставке идёт работа после. На практике полезно заранее развести хотя бы два случая: исправление результата, который не соответствует согласованному, и новая доработка, которой в объёме не было. Как именно это оформить — уже вопрос договора.
Как это выглядит у меня. Сроки поддержки названы прямо в тарифах: у MVP — месяц после запуска, у веб-приложения и кабинета — два, у полноценного мобильного приложения срок фиксируется в проекте, потому что там он зависит от состава. Что происходит с продуктом после этого срока и во что это обходится — разбирал отдельно, в статье про расходы после сдачи.
Кто с кем подписывает
Прежде чем читать пункты, посмотрите на первую страницу. Проверьте, кто именно указан стороной договора и совпадает ли это лицо с тем, кому вы будете платить и кто должен передать результат.
Для компании и ИП это реквизиты и подписант; для физического лица — данные, по которым сторону можно однозначно определить. Если здесь остаются сомнения, документ лучше показать юристу — это как раз тот случай, когда вопрос не в формулировках, а в том, с кем вы вообще договариваетесь.
У меня это ИП, реквизиты — в подвале любой страницы сайта, включая эту. Кто я, чем занимаюсь и как работаю — на странице обо мне.
Чего договор не сделает
Три вещи, о которых стоит помнить, чтобы не переоценить документ.
Он не сделает неподходящего подрядчика подходящим. Договор описывает, что будет, если что-то пойдёт не так. Он не влияет на то, пойдёт ли.
Он не заменяет разговор. Договор фиксирует то, о чём стороны договорились, а не решает за них. Чем больше спорных сценариев удалось спокойно обсудить заранее, тем меньше причин возвращаться к формулировкам уже во время конфликта.
Он не делает спор бесплатным. Даже хорошо составленный документ не отменяет того, что разбирательство требует времени и ресурсов. Поэтому практическая ценность договора ещё и в том, чтобы заранее убрать как можно больше поводов для спора — пока обе стороны ещё хотят работать вместе.
Отсюда и проверка при чтении: если документ подробно описывает штрафы, но не отвечает на семь вопросов выше, я бы считал его недостаточным для управления проектом — независимо от объёма.
Семь вопросов одним экраном
| Проверьте | Что должно быть понятно |
|---|---|
| Результат | что считается готовым и как принимается |
| Изменения | как пересчитываются цена и срок |
| Срок | что зависит от каждой стороны |
| Оплата | к чему привязаны платежи |
| Код и доступы | что передаётся, а что остаётся внешним |
| Выход | что происходит при досрочном завершении |
| Поддержка | где исправление, а где новая работа |
Что сделать до подписания
Прочитайте документ, держа перед собой эти семь вопросов, и отметьте, на какие из них он отвечает, а на какие нет. Дальше — не переписывать самому, а спросить: «а что будет, если…». И обратить внимание не только на сам ответ, но и на то, насколько спокойно подрядчик готов обсуждать такие сценарии заранее.
Часть вопросов лучше задать ещё раньше — на смете, пока обсуждается состав работ, а не обязательства. Для этого у меня есть рабочий лист: семнадцать вопросов подрядчику, с пояснением, зачем нужен каждый, и двумя колонками, чтобы сравнивать два предложения сразу.
Оставьте задачу в форме ниже — пришлю лист вместе с разбором. Если удобнее в мессенджере, напишите слово «смета» в Telegram или Max, контакты в подвале сайта.
А если у вас остались вопросы про то, как я работаю, — часть ответов уже собрана в разделе частых вопросов. Чего там нет — спрашивайте напрямую, отвечу.