Фрилансеры не всегда заключают договор на разработку сайта с заказчиками, полагаясь на договоренности, озвученные устно или сформулированные в переписке. Ведь сам процесс согласования и подписания документов занимает определенное время и требует усилий. Впрочем, сотрудничество на доверии достаточно рискованно для обеих сторон. Кроме того, что один из участников может безнаказанно отказаться от выполнения своих обязанностей, есть немало нюансов, которые затрудняют сотрудничество в случае отсутствия документально заверенных алгоритмов работы. Даже когда обе стороны намерены добросовестно выполнить все договоренности, их может подвести банальное недоразумение.
Договор не только гарантирует защиту как исполнителя, так и заказчика. Он представляет собой определенную дорожную карту, которая описывает каждый этап работ, каждую возможную ситуацию, действия партнеров в случае форсмажоров и алгоритм урегулирования спорных вопросов.
Даже подписание типового договора частично уменьшает риски, но мы все же рекомендуем создавать отдельный контракт для каждого заказчика.
Хостинг-провайдер и регистратор доменных имен Cityhost.ua предлагает читателям нашего блога материал, созданный совместно с IT-юристами, чтобы разобраться во всех аспектах создания договора на разработку сайта.
Этапы согласования и заключения договора
Заключение договора начинается в момент, когда заказчик и исполнитель обсуждают и согласовывают все детали проекта. Поэтому этот этап также должен быть задокументирован в виде брифа. Кроме того, нужно составить детальное ТЗ и сформировать сам договор. Давайте рассмотрим каждый шаг по этому пути.
Заполнение брифа
Заказчики очень не любят заполнять бриф и пытаются пропустить этот этап, обсудив все детали по телефону или в чате. Часто случаются ситуации, когда заказчик говорит: «Вы профессионал, посмотрите сами, что там нужно сделать и изложите свои предложения». Такая позиция нередко выливается в результат: «Нет, это не то, что нужно, предложите что-нибудь другое».
На самом же деле бриф необходим для сотрудничества, потому что в нем содержатся ответы на важные для исполнителя вопросы. Каждый разработчик заключает свой бриф, который может выглядеть подобным образом:
- Название и отрасль работы компании.
- Целевая аудитория.
- Локация (местная, всеукраинская, международная).
- Ценности, миссия.
- Корпоративный стиль — слоган, корпоративные цвета, стиль промо-материалов (желательно отправить эти материалы на почту).
- Тип сайта, который хотите заказать (визитка, интернет-магазин, корпоративный сайт, наличие/отсутствие блога и т.п.).
- Ориентировочная структура сайта, названия разделов.
- Пожелания по оформлению сайта.
- Примеры сайтов, на которые вы хотели бы ориентироваться.
Можно создать типичный бриф, но все же стоит вносить в него дополнительные вопросы, предназначенные для конкретного заказчика.
Составление технического задания
После заполнения брифа заказчик уточняет вопросы и вносит предложения, каким он видит будущий сайт — основную концепцию, количество разделов, визуальный стиль. На основе этих переговоров составляется техническое задание и одновременно начинается разработка договора.
В техзадании прописывается конкретный результат и все услуги, предоставляемые разработчиком. Это очень важно, поскольку «сделать сайт» довольно размытое понятие. Может случиться, что владельцы фирмы обратились к фрилансеру, который только пишет код, и не занимается дизайном и контентом. Он будет ждать от заказчика макет, тексты и фото. Другие фрилансеры могут сделать сайт «под ключ» и имеют разветвленную сеть субподрядчиков — дизайнеров, копирайтеров, фотографов и т.д.
Техзадание прописывается максимально подробно и включает в себя измеряемые параметры, например: «Сайт должен состоять из 5 разделов: главная страница, страница «О нас», страница контактов, страница для представления товара, раздел для блога».
Если у сайта есть блог или раздел новостей, в ТЗ также пишется, должен ли исполнитель заполнить этот раздел 2-3 новостями или делает только структуру блога.
Чем подробнее будет описан каждый аспект разработки сайта, тем меньше остается места для недоразумений.
Обсуждение и согласование текста договора
Для начала нужно определиться с типом договора. Есть два типа — договор на оказание услуги и договор подряда. Они отличаются тем, что в первом случае ключевым является сам процесс работы, а во втором — результат. К примеру, SEO-продвижение не имеет конечного результата и продолжается всегда, пока существует сайт — тогда заключается договор на сотрудничество. Для разработки сайта больше подходит договор подряда, поскольку заказчику нужен сайт, его интересует завершенная работа и его плоды.
Далее нужно поочередно прописать все главные этапы сотрудничества:
- Предоставление заказчиком материалов разработчику. Это могут быть тексты, фото, видео, логотип и т.д.
- Создание и утверждение макета.
- Создание сайта.
- Внесение поправок.
- Проверка и приём работы.
- Подписание актов о выполнении работ.
- Оплата проделанной работы.
Это ориентировочный список, потому что у каждого сайта могут быть свои этапы. Например, исполнитель не только разрабатывает сайт, но и проводит маркетинговые исследования, анализирует конкурентов и на основе полученной информации дает рекомендации заказчику насчет концепции сайта — это отдельный этап, который также требует усилий и влияет на формирование стоимости заказа.
Основные правила составления договора
Есть элементы договора, без которых он не сможет стать четким документом, дисциплинирующим стороны в процессе работы.
Сроки
Обязательно нужно прописать сроки выполнения каждого этапа. Если внимательно присмотреться к порядку действий, вы увидите, что часть работы зависит от исполнителя (создание сайта, внесение правок), а вторая часть — от заказчика (предоставление материалов, проверка, прием работы). Если в договоре прописана только финальная дата, когда разработчик должен сдать сайт, он может попасть во временную ловушку — сроки затянуты, но не по его вине.
Также следует прописать действия сторон в случае, если кто-то из партнеров выполняет свои обязанности ненадлежащим образом. К примеру, если заказчик не осуществил прием работы в течение семи дней, она автоматически считается принятой.
Прописывайте не конкретные даты, а время между этапами, например: «Разработчик обязуется предоставить начальный макет сайта в течение 4 дней с момента получения материалов».
Измеримость
Все пункты в договоре должны быть описаны таким образом, чтобы их можно было измерить каким-либо конкретным параметром — временем, действием, результатом. Например, обсуждение и внесение правок происходит в течение недели после того, как разработчик пришлет по электронной почте ссылку на готовый сайт на такой-то адрес (конкретный). Таким образом снижается вероятность путаницы, когда одна сторона ждет результата в Вайбере, другая пишет сообщение в Фейсбуке, а время истекает.
Конкретика
Очень важно прописывать четкие формулировки. К примеру, «предоставить макет сайта» — это нечеткая формулировка. А вот «предоставить макет сайта в виде проекта в Figma с доступом редактора» — это уже нечто конкретное. Также нужно прописывать, какие материалы ожидает разработчик — фотографии в формате .png с разрешением не менее 600 пикселей по ширине, тексты в формате Google Docs с открытым комментированием.
Далеко не все заказчики ориентируются в компьютерных технологиях. Если ваш клиент — небольшое строительное предприятие или ФЛП, ремонтирующий велосипеды, для него не существует никаких опций по умолчанию. Поэтому конкретное и детальное описание всех требований и этапов — это скорее необходимость, иначе клиента и разработчика может ожидать много сюрпризов.
Видео курсы по схожей тематике:
Сбалансированность
В договоре должны быть равномерно соблюдены права и обязанности обеих сторон. Не должно быть такого, что во всем виноват заказчик или вся ответственность лежит на исполнителе. Если какой-то этап работы зависит от действий определенной стороны — она несет ответственность за его реализацию или уплачивает неустойку (или подпадает под другие санкции) в случае невыполнения обязанностей по собственной вине.
Пункты договора, требующие внимания
В этот раздел вынесем те аспекты сотрудничества, о которых начинающие фрилансеры могут не знать или не уметь правильно их урегулировать.
1) Количество и порядок поправок, внесение изменений в ТЗ
Важен вопрос количества возможных правок и внесения изменений в техническое задание.
Лучший и проверенный метод — когда заказчик отправляет все правки в одном документе, а исполнитель вносит их сразу. Оптимально делать три круга правок; если у клиента появляются дополнительные правки, это должно оплачиваться. Такая политика в первую очередь защищает исполнителя от десятков переделок и дисциплинирует заказчика, который более продуманно решает, нужна ли эта правка.
Правки должны быть конкретными и аргументированными, без формулировок наподобие «сделайте как-то иначе, но не так, как есть».
Насчет ТЗ — все изменения, которые заказчик хочет внести в него уже во время работы, должны также дополнительно оплачиваться. В случае необходимости можно прописать, какие изменения и какого масштаба можно вносить, сколько стоит каждое из них. Одно дело поменять фотографию, и совсем другое, когда заказчик на финальной стадии решает заменить CMS (по факту это значит делать все заново).
2) Авторские и имущественные права
Вопрос авторских прав касается как материалов, используемых на сайте при разработке, так и использования материалов сайта после завершения работ.
Важно отслеживать, уникален ли контент, который предоставляет заказчик или предлагает исполнитель. Для обеспечения обеих сторон нужно прописать порядок действий по предотвращению ситуаций, когда могут быть нарушены авторские права третьих лиц или одного из участников проекта. К примеру, сторона, предоставляющая материалы, должна приобщить документы, подтверждающие право собственности на них — квитанции на приобретение фото- и видеоматериалов или другой контент. Или для упрощения процедуры можно просто отметить, что ответственность за нарушение авторского права несет сторона, предоставившая материалы.
К объектам авторского права относятся название сайта, тексты, фото, видео, дизайн и код. В договоре должно быть указано, кому принадлежат имущественные и авторские права на все элементы проекта после его завершения и может ли разработчик использовать какие-либо материалы для дальнейшей работы.
Для ориентира используйте Закон об авторском праве и смежных правах.
3) Сотрудничество с другими подрядчиками
Сайт состоит из многих компонентов, и не все работы подрядчик может выполнить самостоятельно. Если он обращается к субподрядчикам для создания дизайна или текстов, это также должно быть зафиксировано в договоре. Но в любом случае за качество конечного результата отвечает исполнитель.
4) Ответственные лица за коммуникацию с исполнителем
Этот момент особенно стоит внимания, если компания-заказчик большая, в ней есть много разных отделов и работников. Скорее всего, исполнитель не будет работать напрямую с директором, а будет общаться с кем-то из менеджеров. В таком случае договор должен содержать ФИО, должность и контакты лица, ответственного за коммуникацию. Не мешает указать, какие каналы общения считаются официальными — ими могут быть не только почта, но и аккаунт в Телеграме или страница в Facebook.
В случае, если разные аспекты будут согласовываться с разными людьми, это также должно быть указано. Например, за финансовые вопросы отвечает бухгалтер, за согласование макета — дизайнер компании, все остальные вопросы — к менеджеру. Но все же лучше, когда проект курирует один конкретный человек и несет ответственность за своевременную и эффективную коммуникацию.
5) Форсмажерные обстоятельства
Бывают ситуации, когда кто-то не может выполнить свои обязанности по не зависящим от него причинам. На этот случай следует вынести отдельным пунктом преодоления форсмажорных обстоятельств: что можно считать такими обстоятельствами и порядок действий в случае их возникновения (например, отсрочка для исполнителя для завершения работ или отсрочка оплаты для заказчика). Обычно в этот список входят пожары, стихийные бедствия, боевые действия, забастовки, введение карантина и другие обстоятельства, которые нельзя предусмотреть и подготовиться к ним.
6) Финансовые вопросы
В эту категорию входит не только порядок оплаты за проделанную работу (аванс, гонорар), но и сопутствующие расходы. Сюда можно отнести оплату домена и хостинга, заказы текстов, дизайна, фотосъемки и т.д. Исполнитель может эти расходы включить в сумму гонорара, но можно положить их и на заказчика. Это все обсуждается и прописывается. Также в договоре должны быть зафиксированы такие моменты, как порядок налогообложения, расчетная валюта, счета для получения средств, порядок перечисления и способ подтверждения получения средств исполнителем.
Бесплатные вебинары по схожей тематике:
7) Прием работы или отказ от него
На проверку и прием работы выделяется определенный срок, в течение которого заказчик может выдвинуть обоснованные замечания и требования по доработке сайта или отказаться принять работу, предоставив четкие аргументы. Отказаться от приема работы можно только в случае, если сайт не отвечает технической задаче, выполнен с нарушением законов или имеет другие объективные недостатки, которые делают невозможным его использование и которые можно доказать. Не могут быть учтены субъективные аргументы, когда сайт исполнен по всем договоренностям, но разработчик представлял себе его как-то иначе. Если разработчик выполнил все пункты ТЗ и договор, клиент не может отказаться от подписания акта.
В случае, если речь идет о масштабных проектах с большой суммой оплаты, советуем обратиться за консультацией к юристу, который поможет прописать договор максимально четко и избежать «лазеек» для двойной трактовки.
Статьи по схожей тематике
