Регламент внесения изменений в ТЗ (Change Request)

Приложение №4 к Договору-оферте на оказание услуг по разработке

Назначение: настоящий Регламент детализирует п. 16 Договора-оферты и устанавливает процедуру внесения изменений в утверждённое Техническое задание (далее — «ТЗ»). Любое изменение объёма работ после утверждения ТЗ оформляется в порядке настоящего Регламента.

Зачем это нужно (для Заказчика): избежать «недоразумений» о том, что входит в проект, а что нет. Каждое изменение прозрачно: вы знаете цену и срок до начала работ.

Зачем это нужно (для Исполнителя): защита от бесконечных «небольших правок», которые на деле съедают рентабельность и сроки. Каждое изменение — отдельная единица работы с отдельной оплатой.

---

1. Основные принципы

1.1. Утверждённое ТЗ — основной документ проекта. Любая работа, не предусмотренная ТЗ, по умолчанию не входит в проект и оплачивается отдельно.

1.2. Без письменного согласования в порядке настоящего Регламента изменения не вносятся. Устные просьбы, согласования в личных встречах, переписки в мессенджерах без явного подтверждения стоимости и сроков не являются основанием для выполнения работ.

1.3. Презумпция: если Заказчик заявляет «но мы же это обсуждали» / «в прошлый раз вы делали бесплатно» — но соответствующий Change Request не оформлен, такое заявление не порождает обязательств Исполнителя.

1.4. Юридическая сила email распространяется на согласование Change Request (п. 10.3 Договора-оферты).

---

2. Что считается изменением ТЗ

К изменениям, требующим оформления Change Request, относятся (но не ограничиваются):

• Добавление новых функций в Продукт;
• Изменение существующих функций (логики, поведения, состава полей формы и т.п.);
• Изменение дизайна после его утверждения (правки макетов, перерисовка, новые экраны);
• Изменение технических требований (другой стек, другие интеграции, другие платформы);
• Изменение состава контента (добавление новых разделов, изменение структуры);
• Изменение целевых устройств (поддержка дополнительных браузеров, ОС);
• Дополнительные итерации правок сверх предусмотренных ТЗ (например 3-я и последующие итерации дизайна, если в ТЗ заложены 2);
• Изменение сроков по инициативе Заказчика (отсрочка, ускорение);
• Изменение стека или подхода к разработке.

Не требуют Change Request:

• Устранение критических ошибок в коде Исполнителя в рамках гарантии (п. 15.1 Договора-оферты);
• Незначительные правки текстов / изображений, согласованные в рабочем порядке без влияния на сроки и стоимость (на усмотрение Исполнителя);
• Работы, явно предусмотренные ТЗ.

---

3. Процедура согласования Change Request

Шаг 1. Запрос Заказчика

Заказчик направляет Исполнителю email с описанием изменения. Запрос должен содержать:

• Тема письма: [Проект Название] CR-N: <краткое описание> (например: [Бот Иллюзия] CR-1: добавить оплату через СБП).
• Описание: что именно нужно добавить / изменить / удалить, желательно с примерами или скриншотами.
• Контекст: зачем изменение нужно, какую задачу решает.
• Приоритет / срочность (если важно).

Шаг 2. Оценка Исполнителем

Исполнитель в течение 3 рабочих дней с момента получения запроса направляет Заказчику ответ с оценкой:

• Возможность реализации: возможно / возможно с оговорками / невозможно (с причинами);
• Влияние на стоимость: дополнительная сумма;
• Влияние на сроки: дополнительное количество рабочих дней либо новая итоговая дата сдачи;
• Срок действия предложения: до какой даты Заказчик может принять оценку (обычно 5–7 рабочих дней);
• Условия оплаты: аванс / по факту / в составе финального платежа.

Если для оценки требуется больше 3 рабочих дней (сложное изменение, требующее исследования) — Исполнитель уведомляет об этом в указанный срок и указывает разумный срок предоставления оценки.

Шаг 3. Решение Заказчика

Заказчик в установленный Исполнителем срок направляет email с одним из ответов:

• ✅ «Согласовано» — с подтверждением стоимости и сроков → Change Request утверждён, переходит в работу.
• ❌ «Не согласовано» — изменение не вносится, проект продолжается по исходному ТЗ.
• 🔄 «Прошу пересмотреть» — обсуждение, новая итерация оценки.

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

Шаг 4. Фиксация

После согласования Change Request:

• Получает порядковый номер (CR-1, CR-2 и т.д.);
• Заносится в журнал Change Request по проекту (ведёт Исполнитель);
• Учитывается в финальном Акте приёмки (п. 3 Акта);
• Стоимость и сроки добавляются к итоговым.

---

4. Шаблоны email-сообщений

4.1. Шаблон запроса от Заказчика

Тема: [Проект Иллюзия — сайт] CR-1: добавить онлайн-оплату через СБП

Привет!

Хочу добавить на сайт онлайн-оплату занятий через СБП.

Контекст: сейчас принимаем оплату только наличными в студии,
теряем клиентов которые хотят забронировать сразу.

Подробности:
— на странице каждого занятия — кнопка «Оплатить онлайн»;
— переход на форму оплаты (СБП);
— после оплаты — уведомление в Telegram администратору;
— чек клиенту на email.

Срочность: хотелось бы запустить до 1 числа следующего месяца.

Жду оценку.

4.2. Шаблон оценки Исполнителя

Тема: Re: [Проект Иллюзия — сайт] CR-1: добавить онлайн-оплату через СБП

Привет!

Оценка по запросу:

Возможность: возможно реализовать.
Стек: подключим ЮKassa (СБП работает через них). Аккаунт ЮKassa регистрирует Заказчик.

Стоимость: 25 000 ₽
Сроки: +5 рабочих дней к текущему графику.
Новая дата сдачи: вместо 25.07 → 01.08.

Условия оплаты: предоплата 50% перед стартом, 50% по завершении.

Что нужно от Заказчика:
1) Зарегистрировать аккаунт ЮKassa и передать доступы.
2) Подготовить юр.документы (договор-оферта на услуги) — это
   зона ответственности Заказчика (см. п. 8.1.4 Договора-оферты),
   рекомендую привлечь юриста.

Предложение действительно до 28.06. После этой даты — пересмотр условий.

Жду решение по email.

4.3. Шаблон согласования от Заказчика

Тема: Re: [Проект Иллюзия — сайт] CR-1: добавить онлайн-оплату через СБП

Согласовано.

Стоимость 25 000 ₽, +5 рабочих дней к графику, новая дата сдачи 01.08.

Аванс пришлю сегодня. С юристом по оферте — свяжусь, передам тексты в течение 3 дней.

---

5. Особые случаи

5.1. Срочные изменения (hot-fix)

5.1.1. Если изменение требуется немедленно (например критическая ошибка в боевой версии Продукта, не относящаяся к гарантии) — Заказчик вправе запросить hot-fix.

5.1.2. Hot-fix-тариф: стоимость работы в режиме срочности × 2 к обычной оценке. Срок реакции — 1 рабочий день.

5.1.3. Оценка hot-fix направляется в упрощённом формате (без детальной разбивки), согласование — по email в течение 2 часов с момента отправки оценки.

5.2. Серия мелких изменений

5.2.1. Если в ходе проекта возникает много мелких изменений, Стороны вправе договориться об абонементной модели оплаты: фиксированное количество часов работы Исполнителя в месяц по согласованной ставке.

5.2.2. Абонементная модель оформляется отдельным соглашением; настоящий Регламент применяется к каждому изменению в составе абонемента в упрощённом порядке (только описание + согласование по email, без детальной оценки каждого).

5.3. Изменения, фактически отменяющие проект

5.3.1. Если запрашиваемые изменения по объёму и сути превышают исходный объём работ (например запрос на полную переделку, на смену стека, на разработку дополнительного отдельного продукта) — Исполнитель вправе предложить заключение нового Договора / нового ТЗ вместо оформления Change Request.

5.3.2. В этом случае текущий проект завершается в части выполненных работ (с подписанием Акта), и новые работы оформляются отдельным проектом.

---

6. Журнал Change Request

Исполнитель ведёт по каждому проекту журнал согласованных Change Request в табличной форме:

Журнал ведётся в произвольной форме (Notion, Google Sheets, отдельный документ). При сдаче проекта журнал прикладывается к Акту приёмки (п. 3 Акта).

---

7. Ответственность

7.1. При выполнении Change Request Исполнитель несёт ответственность за их качество в пределах, установленных Договором-офертой (раздел 11).

7.2. При невыполнении не согласованных изменений Исполнитель ответственности не несёт. Если Заказчик утверждает, что какое-то изменение «должно было быть выполнено», но соответствующий Change Request отсутствует — претензия не подлежит удовлетворению.

7.3. При просрочке согласования Change Request Заказчиком общие сроки проекта автоматически продлеваются на период согласования.

---

8. Заключительные положения

8.1. Настоящий Регламент применяется ко всем проектам, выполняемым Исполнителем по Договору-оферте.

8.2. Конфликт настоящего Регламента и условий ТЗ конкретного проекта разрешается в пользу Регламента (как общего документа), за исключением случаев, когда ТЗ явно устанавливает иной порядок (например при абонементной модели).

8.3. Регламент не требует отдельного подписания — его действие основано на согласии Заказчика с Договором-офертой (п. 16 + п. 20.6 Договора-оферты).

---

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

Применение настоящего Регламента подтверждается акцептом Договора-оферты (раздел 4 Договора-оферты). Отдельное подписание не требуется.

При желании Стороны могут оформить отдельное подтверждение в порядке п. 10.3 Договора-оферты (email-акцепт).

---

Исполнитель: Коркин Егор Сергеевич ИНН 231219474294 hello@atomgram.ru