Доп соглашение разработка сайта

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

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

Зачем нужно дополнительное соглашение

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

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

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

Когда оформляется допсоглашение

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

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

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

Структура допсоглашения: что должно быть прописано

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

1. Вводная часть и ссылки на основной договор

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

Формулировка должна быть короткой: «Стороны, заключившие Договор №... от ..., согласовали следующее...» — и далее перечисление изменений.

2. Предмет соглашения

Здесь чётко фиксируется, какие именно работы или услуги добавляются или изменяются. Конкретика — ключ: вместо «доработки сайта» лучше писать «разработка модуля оплаты через X, включающая интеграцию API, тестирование и документацию».

Описывайте функционал через результат, а не только через набор задач. Лучше указать: «Результат — реализованный модуль оплаты, принимаемый по чек-листу в приложении №1».

3. Сроки выполнения

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

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

4. Стоимость и порядок оплаты

Раздел должен содержать точные суммы, порядок выставления актов и счетов, даты платежей и условия оплаты дополнительных расходов, например, стоимости лицензий или платных API.

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

5. Порядок приёмки работ

Опишите, как будет проходить приёмка новых функций: кто проверяет, какие критерии применяются, сколько времени выделяется на проверку и исправления, какой акт подписывается после приёмки.

Рекомендуется приложить чек-лист приёмки в качестве приложения — это убирает неоднозначности при сдаче результата.

6. Интеллектуальная собственность и передача прав

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

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

7. Гарантии и сопровождение

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

8. Ответственность сторон

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

9. Конфиденциальность

Если в процессе работ будут обмениваться доступами, паролями, закрытой информацией, закрепите обязательства по сохранению конфиденциальности и порядок возврата/удаления данных после завершения работ.

10. Форс-мажор и другие общие положения

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

11. Подписи и приложения

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

Таблица-образец: ключевые пункты и пример формулировок

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

Практические советы по формулировкам

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

Конкретность означает, что вы описываете результат, а не процесс. Измеримость — наличие критериев приёмки и метрик качества. Ответственность — чёткие сроки и последствия за их нарушение.

• Не пишите «внести доработки». Пишите «реализовать API-интеграцию по спецификации X и обеспечить прохождение трёх тестовых сценариев».
• Указывайте формат передачи материалов: Git-репозиторий, архив, документация в формате PDF/MD.
• Пропишите сроки реакции на баг-репорты в гарантийный период: например, критические ошибки — 24 часа, некритические — 5 рабочих дней.
• Если стоимость зависит от третьих лиц (платные API, лицензии), отметьте, что оплата таких услуг ложится на заказчика, если иное не согласовано.

Шаблон допсоглашения: пример, который можно адаптировать

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

Дополнительное соглашение №___ к Договору №___ от «___» _______ 20__ г.

1. Стороны: Заказчик — [название, реквизиты]; Исполнитель — [название, реквизиты].

2. На основании Договора №___ от «___» _______ 20__ г. стороны согласовали следующее:

2.1. Предмет соглашения: Исполнитель выполняет дополнительные работы по разработке: [подробное описание результатов].

2.2. Сроки выполнения: работы выполняются в период с «___» _______ 20__ г. по «___» _______ 20__ г. По завершении работ Исполнитель направляет Заказчику акт выполненных работ и уведомление о готовности.

2.3. Стоимость и порядок оплаты: общая сумма дополнительных работ составляет [сумма] руб. Оплата производится в следующем порядке: [детали платежей]. Дополнительные расходы на сервисы оплачиваются отдельно и согласовываются с Заказчиком.

2.4. Приёмка: приёмка осуществляется в соответствии с чек-листом в приложении №1. Срок проверки — [количество] рабочих дней. В случае выявления замечаний Исполнитель устраняет их в течение [количество] рабочих дней.

2.5. Переход прав: после полной оплаты все имущественные права на результаты работ переходят Заказчику; исключения: используемые сторонние библиотеки и компоненты, лицензии на которые сохраняются за правообладателями.

2.6. Гарантия: Исполнитель предоставляет гарантийный срок [количество] месяцев на выполненные работы. В рамках гарантии Исполнитель бесплатно устраняет дефекты, возникшие по его вине.

2.7. Ответственность: за нарушение сроков стороны несут ответственность в соответствии с условиями основного договора. Форс-мажорные обстоятельства освобождают от ответственности при условии надлежащего уведомления.

3. Приложения: Приложение №1 — Чек-лист приёмки; Приложение №2 — Техническое задание; Приложение №3 — Смета.

4. Прочие условия: иные условия изменяются в части, непосредственно касающейся данного соглашения. Все остальное сохраняет силу в прежнем объёме.

Подписи сторон:

Заказчик: ____________________

Исполнитель: ____________________

Процесс согласования и подписания: шаги, которые экономят время

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

1. Фиксация запроса: заказчик формулирует изменения в виде краткого запроса или тикета.
2. Оценка исполнителем: исполнитель делает техоценку и смету, указывает риски и предполагаемые сроки.
3. Подготовка допсоглашения: менеджер формирует текст допа на основе оценки, прикладывает техзадание и чек-лист.
4. Согласование: стороны проводят оперативное согласование правок, если потребуется — внутренняя проверка у юриста.
5. Подписание: вариант электронный или бумажный, в зависимости от политики. После подписания работы считаются утверждёнными в объёме и условиях допсоглашения.
6. Исполнение: осуществляется в соответствии с новыми условиями, с обязательным ведением учёта времени и изменений.

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

Управление изменениями в процессе разработки

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

• Приём заявки на изменение: создаётся новый тикет с описанием и приоритетом.
• Оценка влияния: влияет ли изменение на текущие сроки, бюджет, интеграции?
• Подготовка допсоглашения или приложения к нему: если влияние есть, формируется документ.
• Утверждение и планирование: изменение вносится в общий план проекта и распределяется по этапам.
• Тестирование: обязательный режим проверки и приёмки перед релизом.
• Документация: вносятся правки в техническую документацию и репозиторий.

Любое изменение, прошедшее без оформления, увеличивает риск перерасхода времени и затрат. Поэтому правило простое: если изменение влияет хотя бы на один параметр — оформляем допсоглашение.

Типичные ошибки и как их избежать

Ошибки чаще всего связаны с расплывчатыми формулировками и недостатком критериев приёмки. Ниже самые распространённые промахи и способы их устранения.

• Ошибка: «доработки по согласованию». Что делать: подробно опишите, что именно будет сделано, и приложите примеры сценариев использования.
• Ошибка: неопределённые сроки «в течение N дней после…». Что делать: укажите точные даты или конкретное число рабочих дней и механизм их отсчёта.
• Ошибка: отсутствие перечня работ по интеграциям. Что делать: перечислите API, версии, требования по безопасности и тесты для подтверждения работоспособности.
• Ошибка: не прописанные права на код. Что делать: заранее пропишите, какие права передаются и какие остаются у исполнителя.
• Ошибка: неучтённые внешние расходы. Что делать: отдельно укажите, какие расходы оплачивает заказчик, и механизм подтверждения затрат.

Чек-лист перед подписанием допсоглашения

Простой список пунктов, который помогут быстро проверить документ перед подписью.

• Ссылка на основной договор указана корректно.
• Точные формулировки по объёму работ и ожидаемому результату.
• Даты и этапы выполнения указаны однозначно.
• Сумма и порядок оплаты прописаны в деталях.
• Критерии приёмки и порядок устранения замечаний включены.
• Переход прав и формат передачи исходников обозначены.
• Приложения перечислены и прилагаются в окончательном варианте.
• Подписанты уполномочены и реквизиты корректны.

Особенности электронного подписания

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

Во-первых, убедитесь, что используемая ЭЦП признана в вашем регионе и соответствует требованиям контрагента. Во-вторых, сохраните копии подписанных файлов и журнал действий: кто, когда и какие правки вносил. В-третьих, если речь о крупных суммах, предусмотреть резервный способ подтверждения — например, нотариальную заверку или подпись на бумаге как резерв.

Когда стоит привлекать юриста

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

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

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

Заключение. Как сделать допсоглашение инструментом, а не бюрократией

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

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

Чётко сформулированное допсоглашение делает проект предсказуемым и помогает командам сосредоточиться на главном — создании качественного продукта.