Гарантийный срок на веб-разработку защищает клиента от ошибок в реализованном функционале. Разберём, что исправляет студия бесплатно, а что требует отдельной оплаты. Читайте до конца, чтобы правильно зафиксировать условия гарантии в договоре.
Гарантийный срок на веб-разработку: зачем он нужен
После запуска сайта работа студии не всегда заканчивается. В первые недели могут проявиться ошибки, которые не удалось обнаружить на тестовом сервере.
Например, форма заказа не отправляет письмо. Или кнопка оплаты не работает после обновления модуля.
В таких случаях помогает гарантийный срок на веб-разработку. Он определяет ответственность исполнителя после сдачи проекта.
Важно разделять две ситуации:
- в готовом функционале обнаружилась ошибка;
- клиент попросил изменить готовый функционал.
Первая ситуация обычно относится к гарантии. Вторая считается доработкой.
Такой подход защищает обе стороны. Клиент понимает границы бесплатных исправлений. Студия понимает объём своих обязательств.
Что означает гарантия простыми словами
Гарантия означает простое правило:
Если реализованная функция работает не так, как согласовали, студия исправляет ошибку без дополнительной оплаты.
При этом гарантия не означает бесплатную техническую поддержку на любой случай.
Она также не означает, что любые изменения после запуска входят в стоимость проекта.
Поэтому гарантийный срок на веб-разработку нужно описывать конкретно.
Что обычно покрывает гарантийный срок
Хороший гарантийный срок на веб-разработку связан с результатом работы студии.
Рассмотрим основные случаи.
Ошибка в реализованном функционале
Допустим, интернет-магазин должен рассчитывать стоимость доставки.
В техническом задании указана формула расчёта. После запуска она работает неправильно.
Клиент сообщает об ошибке.
Студия проверяет логику. Специалист находит ошибку в собственном коде.
В этом случае гарантия действует.
Исправление не должно превращаться в новый коммерческий этап.
Неисправность формы
Форма обратной связи должна отправлять заявку на почту.
После запуска пользователь заполняет поля. Но письмо не приходит.
Если причина находится в коде формы, студия исправляет проблему по гарантии.
Но есть важное исключение.
Если клиент самостоятельно изменил SMTP-настройки, хостинг или почтовый сервис, причина может быть внешней.
Тогда сначала нужно установить источник сбоя.
Ошибка адаптивной версии
Сайт должен корректно работать на согласованных разрешениях экранов.
После запуска на смартфоне обнаруживается наложение блоков.
Такой дефект обычно относится к гарантийным случаям.
Особенно если проблема воспроизводится в поддерживаемом браузере.
Ошибка интеграции
Представим, что сайт передаёт заявки в CRM.
Интеграция была частью согласованного проекта.
После запуска данные перестали передаваться.
Если причиной стал дефект разработанного решения, работает гарантия.
Если CRM изменила API после сдачи сайта, ситуация может быть другой.
Здесь важно учитывать причину проблемы.
Что не входит в гарантию сайта
Гарантийный срок на веб-разработку имеет ограничения.
Они нужны не для отказа клиенту. Они помогают отделить исправление ошибки от новой работы.
Обычно отдельно оплачиваются:
- новые функции;
- изменение утверждённого дизайна;
- новый сценарий работы пользователя;
- изменение бизнес-логики;
- новые интеграции;
- перенос сайта на другой сервер;
- настройка стороннего сервиса;
- изменение контента;
- SEO-работы;
- наполнение каталога;
- создание новых страниц;
- изменения по инициативе клиента;
- исправление последствий стороннего вмешательства.
Пример: клиент хочет новую функцию
На сайте есть фильтр товаров.
Он работает согласно техническому заданию.
Через месяц клиент просит добавить сохранение фильтров.
Это не ошибка.
Это новая возможность.
Следовательно, гарантийный срок на веб-разработку здесь не применяется.
Студия оценивает задачу отдельно.
Пример: изменились требования
В техническом задании указана одна логика корзины.
После запуска клиент решает изменить сценарий.
Теперь корзина должна работать иначе.
Это также доработка.
Даже если запрос появился вскоре после запуска, гарантия его не покрывает.
Пример: клиент изменил код
Клиент получил доступ к WordPress и установил сторонний плагин.
После этого перестала работать форма.
Специалист выявил конфликт плагинов.
В таком случае причина возникла после передачи проекта.
Гарантийный срок на веб-разработку может не распространяться на такой случай.
Гарантия или доработка: как отличить
На практике спор часто возникает из-за одного вопроса:
«Это ошибка или новое требование?»
Помогает простой тест.
Сравните фактическую работу сайта с утверждённым результатом.
| Ситуация | Гарантия | Доработка |
|---|---|---|
| Кнопка не работает по ТЗ | Да | Нет |
| Форма не отправляет заявку | Да | Нет |
| Добавление новой кнопки | Нет | Да |
| Изменение дизайна блока | Нет | Да |
| Ошибка в расчёте | Да | Нет |
| Новая интеграция | Нет | Да |
| Изменение логики корзины | Обычно нет | Да |
| Сбой после стороннего плагина | Обычно нет | Возможна |
| Исправление опечатки в контенте | Зависит от договора | Возможна |
| Ошибка после обновления сторонней системы | Зависит от причины | Возможна |
Такой принцип делает гарантийный срок на веб-разработку понятным.
Но окончательное решение зависит от договора и технического задания.
Как прописать гарантийный срок в договоре
Одной фразы «гарантия 30 дней» недостаточно.
Она не отвечает на ключевые вопросы.
Лучше зафиксировать несколько параметров.
1. Срок гарантии
Укажите точный период.
Например:
Гарантийный срок — 60 календарных дней с даты подписания акта сдачи-приёмки.
Конкретная дата снижает риск споров.
На практике студии используют разные сроки. Часто встречается диапазон от 30 до 90 дней.
2. Объект гарантии
Нужно указать, что именно гарантируется.
Например:
- программный код;
- реализованный функционал;
- адаптивная вёрстка;
- предусмотренные интеграции;
- соответствие техническому заданию.
3. Порядок обращения
Опишите канал связи.
Например, клиент отправляет заявку через электронную почту или систему поддержки.
В обращении желательно указать:
- страницу с проблемой;
- описание ошибки;
- последовательность действий;
- скриншот;
- видео экрана при необходимости.
Это ускоряет диагностику.
4. Срок реакции студии
Гарантийный срок на веб-разработку не равен сроку исправления.
Поэтому полезно разделить эти понятия.
Например:
- ответ на обращение — до 1 рабочего дня;
- диагностика — до 3 рабочих дней;
- исправление — в согласованный срок.
Срок зависит от сложности проблемы.
Гарантийный срок на веб-разработку и WordPress
Для WordPress есть отдельный нюанс.
Сайт зависит не только от кода студии.
На работу проекта влияют:
- WordPress;
- тема;
- плагины;
- PHP;
- сервер;
- хостинг;
- CDN;
- внешние API;
- платёжные системы.
Поэтому гарантийный срок на веб-разработку должен учитывать сторонние компоненты.
Что происходит после обновления плагина
Представим типовую ситуацию.
Вы запускаете сайт. Через две недели обновляется плагин.
После обновления ломается фильтр каталога.
Если студия не меняла плагин и проблема возникла из-за его новой версии, источник нужно подтвердить.
Возможны разные варианты:
- студия исправляет совместимость в рамках поддержки;
- обновление откатывают;
- клиент оплачивает адаптацию к новой версии;
- стороны согласуют отдельные работы.
Поэтому договор должен описывать такие ситуации заранее.
Что делать, если студия отказывается исправлять ошибку
Вы столкнулись с проблемой.
Студия говорит, что это доработка.
Не стоит сразу спорить.
Сначала сравните три документа:
- договор;
- техническое задание;
- акт сдачи-приёмки.
Затем зафиксируйте проблему.
Опишите конкретное поведение сайта.
Не пишите только: «Сайт работает неправильно».
Лучше написать:
«При оформлении заказа пользователь выбирает доставку. После нажатия кнопки оплаты страница возвращает ошибку. Согласно ТЗ №2 пользователь должен перейти на страницу платёжного сервиса».
Такое описание позволяет проверить результат объективно.
Кейсовый пример
Проблема: форма заявки не передаёт телефон в CRM.
Причина: в коде интеграции отсутствовало поле передачи номера.
Решение: разработчик исправил обработчик формы.
Результат: заявки снова передаются в CRM без изменения функционала.
Это гарантийный случай.
Теперь другой сценарий.
Проблема: клиент хочет передавать в CRM ещё и город.
Причина: поле города не входило в ТЗ.
Решение: добавить новое поле и изменить интеграцию.
Результат: появляется новая функция.
Это уже доработка.
Разница очевидна: в первом случае исправляют ошибку. Во втором создают новый результат.
Как снизить количество гарантийных споров
Лучший способ решить спор — не допустить его.
Для этого ещё до разработки нужно подготовить подробное ТЗ.
В нём стоит описать:
- функциональность;
- страницы;
- пользовательские сценарии;
- интеграции;
- поддерживаемые браузеры;
- адаптивность;
- ограничения;
- порядок приёмки.
Отдельно зафиксируйте критерии готовности.
Например:
«Форма считается реализованной, если заполненные данные передаются на указанный email и сохраняются в административной панели».
Такое описание лучше фразы «на сайте должна быть форма».
Чем точнее ТЗ, тем проще определить гарантийный случай.
Чек-лист: что проверить перед подписанием договора
Перед запуском проекта проверьте гарантийные условия.
В договоре должны быть:
- точный срок гарантии;
- дата начала гарантии;
- перечень гарантийных обязательств;
- исключения;
- порядок подачи заявки;
- сроки реакции;
- сроки исправления;
- условия работы со сторонними сервисами;
- правила после вмешательства третьих лиц;
- порядок определения доработки.
Перед приёмкой сайта проверьте:
- формы;
- авторизацию;
- корзину;
- оплату;
- доставку;
- интеграции;
- мобильную версию;
- основные браузеры;
- административную часть;
- отправку уведомлений.
Такой чек-лист снижает риск недопонимания после релиза.
Почему гарантия не заменяет техническую поддержку
Гарантия отвечает на один вопрос:
«Исправит ли студия ошибку в реализованном функционале?»
Поддержка отвечает на другой:
«Кто будет развивать и обслуживать сайт дальше?»
После окончания гарантии сайт всё равно требует внимания.
Например, нужно:
- обновлять WordPress;
- проверять плагины;
- контролировать резервные копии;
- следить за безопасностью;
- обновлять интеграции;
- менять контент;
- развивать функционал.
Поэтому бизнесу часто выгодно разделить гарантию и поддержку.
Гарантия закрывает дефекты разработки.
Поддержка обеспечивает стабильную работу проекта.
Развитие создаёт новые возможности.
Это три разных услуги.
Как мы в «Компьюти» разделяем гарантию и доработки
В веб-студии важно не просто дать обещание гарантии.
Нужно заранее определить правила работы.
В «Компьюти» логика может выглядеть так:
Вы столкнулись с проблемой → мы воспроизводим её → сравниваем результат с ТЗ → определяем причину → исправляем гарантийный дефект или оцениваем доработку.
Такой процесс удобен для обеих сторон.
Клиент получает понятный ответ.
Студия не тратит время на спор о формулировках.
А проект получает прозрачный процесс сопровождения.
Особенно это важно для интернет-магазинов, корпоративных сайтов и сложных WordPress-проектов.
Частые вопросы о гарантии
Можно ли дать гарантию на весь сайт?
Да, но формулировка «на весь сайт» слишком широкая.
Лучше гарантировать конкретные результаты разработки.
Так проще определить ответственность сторон.
Сколько должен длиться гарантийный срок?
Универсального срока нет.
Часто используют 30, 60 или 90 дней.
Оптимальный срок зависит от сложности проекта и условий договора.
Гарантия действует после обновления WordPress?
Это зависит от условий договора.
Если обновление не повлияло на разработанный код, гарантия может сохраняться.
Если обновление изменило сторонний компонент, потребуется диагностика.
Исправляет ли гарантия ошибки контента?
Не всегда.
Если текст или изображение передал клиент, ответственность обычно лежит на заказчике.
Если контент размещала студия и допустила ошибку, условия могут быть другими.
Что делать, если гарантия закончилась?
Обратиться в студию всё равно стоит.
Ошибка может иметь отдельные условия исправления.
Кроме того, можно заключить договор технической поддержки.
Заключение: как сделать гарантию понятной
Гарантийный срок на веб-разработку защищает клиента от ошибок в реализованном функционале. Но гарантия не превращает любые будущие изменения в бесплатные работы.
Главное правило простое:
ошибка относительно согласованного ТЗ — гарантийный случай; новое требование — доработка.
Гарантийный срок на веб-разработку лучше фиксировать в договоре. Укажите срок, объект гарантии, исключения и порядок обращения.
Если вы планируете разработку сайта, интернет-магазина или WordPress-проекта, специалисты «Компьюти» помогут определить гарантийные условия ещё до начала работ. Это снижает риски и делает сопровождение проекта прозрачным.
Обсудите ваш проект с «Компьюти» и заранее зафиксируйте, что входит в гарантию, а что будет считаться доработкой.
