Что должно быть в договоре на разработку сайта?

В договоре стоит закрепить:

• состав работ и результат каждого этапа

• техническое задание или порядок его подготовки

• стоимость, график платежей и отдельные расходы

• сроки, зависимости от заказчика и порядок изменения планов

• критерии приёмки и устранения замечаний

• права на дизайн, код, контент и результаты разработки

• доступы, домен, лицензии, хостинг и передачу проекта

• условия поддержки, гарантийных исправлений и дальнейших доработок

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

Мы в Ameton переходим к договору после того, как с заказчиком согласованы задачи и состав первого этапа работ. Иначе за формулировкой «разработать сайт на 1С-Битрикс» может скрываться что угодно: простой каталог, интернет-магазин с оплатой и доставкой, личный кабинет или B2B-портал. У этих проектов разный объём работ, поэтому сначала важно договориться о содержании будущего сайта, а затем фиксировать условия разработки

В договоре должен быть понятен результат разработки

Главный вопрос договора — какой результат обязан передать подрядчик. Не достаточно указать название проекта: нужно определить, какие функции, материалы и документы получит заказчик

Если сайт должен принимать заказы, то в договоре или приложении нужно описать не только наличие корзины. Важно зафиксировать правила оплаты, доставки, уведомлений, интеграции с учётной системой и критерии проверки заказа

Чем сложнее проект, тем важнее разделять его на этапы. Аналитика определяет сценарии и ограничения, дизайн — интерфейс, разработка — функции, а запуск — порядок переноса и проверки результата

Техническое задание должно описывать сценарии, а не только страницы

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

Для интернет-магазина полезно зафиксировать:

• откуда поступают товары, цены и остатки

• как пользователь выбирает товар и оформляет заказ

• какие способы оплаты и доставки должны работать

• куда передаются заказы и статусы

• кто редактирует каталог и контент

• какие ситуации считаются ошибкой и как их проверяют

Для B2B-портала дополнительно важны роли пользователей, персональные цены, документы, согласования и границы доступа. Для корпоративного сайта — структура, формы заявок, обработка обращений и интеграция с CRM

Сроки должны учитывать действия обеих сторон

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

В договоре полезно указать:

• дату начала и завершения каждого этапа

• срок, в который заказчик предоставляет материалы и обратную связь

• порядок согласования промежуточных результатов

• основания для переноса сроков

• последствия изменения состава работ

• порядок уведомления о риске задержки

Хороший договор прямо фиксирует обязанности сторон и как принимаются решения по ходу проекта

Стоимость должна быть связана с составом работ

Стоимость разработки нужно фиксировать вместе с объёмом работ, а не отдельной строкой без расшифровки. В противном случае сложно понять, что именно меняется при добавлении новой функции

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

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

Порядок приёмки защищает обе стороны

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

В договоре стоит определить:

• кто принимает результат

• в какой срок заказчик направляет замечания

• в каком виде фиксируются замечания

• какие замечания относятся к несоответствию договорённости, а какие считаются новой задачей

• в какой срок подрядчик исправляет подтверждённые недостатки

• как оформляется приёмка этапа или всего проекта

Сайт стоит принимать по конкретным действиям, которые должен выполнить пользователь. Для формы заявки важно, чтобы обращение отправлялось и приходило ответственному сотруднику. Для интернет-магазина — чтобы пользователь мог оформить заказ, оплатить его и получить корректное уведомление. Для личного кабинета — чтобы каждая роль видела только доступные ей данные

Приёмка по конкретным сценариям снижает риск спора о том, «нравится» ли сайт. Она переводит обсуждение в проверяемый результат

Права на результаты и доступы нужно описать отдельно

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

Стоит закрепить:

• какие права передаются на дизайн, код, документацию и иные результаты

• что относится к индивидуальной разработке, а что к сторонним продуктам или библиотекам

• на кого регистрируются домен, лицензия 1С-Битрикс и учётные записи внешних сервисов

• как заказчик получает доступ к репозиторию, хостингу и резервным копиям

• какие материалы подрядчик передаёт после завершения этапа

• какие ограничения могут действовать на использование сторонних модулей и контента

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

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

Поддержку и гарантийные исправления нельзя смешивать

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

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

Порядок дальнейшей работы с сайтом полезно обсудить ещё до запуска. О принципах сопровождения проекта можно подробнее прочитать в статье Что входит в техническую поддержку сайта на 1С-Битрикс?

В договоре нужно предусмотреть изменение и завершение проекта

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

Подрядчику и заказчику стоит согласовать:

• как оформляется новая задача

• кто оценивает её влияние на стоимость и срок

• когда изменение считается согласованным

• можно ли приостановить отдельный этап

• что передаётся при досрочном завершении работ

• как стороны передают доступы, материалы и уже созданные результаты

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

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