Проект сдан, акты подписаны — и тут на сайте всплывает то, чего быть не должно: не проходит оплата, не отгружается заказ, «слетела» вёрстка карточки. Кто это чинит и за чей счёт? Здесь и начинается зона, где гарантийный период либо спасает отношения заказчика и подрядчика, либо превращает их в затяжной спор. И почти всегда исход зависит не от доброй воли, а от того, что было зафиксировано до сдачи.
Эта статья — практический разбор гарантийного периода на разработку сайта на 1С-Битрикс: что гарантия покрывает, чем баг отличается от доработки, как устроены сроки и SLA, как правильно принимать работу и сообщать о дефектах. Материал полезен обеим сторонам, а системную поддержку проекта после сдачи закрывает аудит и оптимизация 1С.
Коротко
- Гарантия покрывает дефекты — расхождения с согласованным ТЗ и приёмкой, а не новые пожелания.
- Баг — поведение против договорённостей; доработка — новое требование и отдельная оценка.
- Основа гарантии — качественная приёмка: непринятое нельзя объективно гарантировать.
- SLA с классами критичности превращает гарантию из обещания в измеримое обязательство по срокам.
Зачем нужен гарантийный период
Гарантийный период — это отрезок после сдачи, в течение которого подрядчик бесплатно устраняет дефекты своего кода. Его смысл двойной: для заказчика это защита от того, что скрытые ошибки вылезут в первые недели эксплуатации, для подрядчика — способ подтвердить качество и разграничить ответственность.
Без внятной гарантии каждая послепусковая проблема превращается в переговоры с нуля: баг это или каприз, чинить бесплатно или за деньги. Гарантийный период задаёт правила игры заранее, поэтому и заказчику, и исполнителю выгодно проговорить его до старта, а не после первого инцидента. Хорошая гарантия — не строчка в договоре «для галочки», а рабочий механизм, к которому обе стороны обращаются спокойно.
Что покрывает гарантия, а что нет
Ключ к бесконфликтной гарантии — чёткая граница покрытия. Она проходит по линии «согласованный объём работ»: гарантия отвечает за то, что было обещано и принято, но не за то, чего в договорённостях не было.
| Ситуация | Гарантия | Отдельная работа |
|---|---|---|
| Принятая функция сломалась | Да | — |
| Функция работает не по ТЗ | Да | — |
| Новое пожелание | — | Да |
| Изменение требований | — | Да |
| Последствия чужих правок | — | Да |
| Обновление среды/модулей | Спорно | Чаще да |
Из таблицы видно главное: гарантия — не «бесплатное развитие проекта», а обязательство по качеству уже сделанного. Чем точнее в договоре описано, что входит в объём, тем меньше поводов для спора. Размытое «сделать хороший магазин» гарантировать невозможно; конкретное «оформление заказа с оплатой картой и выгрузкой в 1С» — вполне.
Баг против доработки
Самый частый источник конфликтов — путаница между дефектом и новым требованием. Разграничить их помогает один вопрос: противоречит ли поведение системы согласованным договорённостям?
- Баг. Оформленная и принятая функция работает не так, как описано: не проходит оплата, неверно считается скидка, теряется заказ. Это гарантийный случай.
- Доработка. Вы хотите поведения, которого в ТЗ не было: добавить новый способ оплаты, изменить логику расчёта, вывести дополнительное поле. Это новая задача с отдельной оценкой.
Серые зоны неизбежны, и решать их лучше по документам, а не по памяти сторон. Если приёмка зафиксировала функцию как работающую, а теперь она сломана — это баг. Если «всегда хотелось иначе, но не написали» — это доработка. Честный подрядчик не прячет доработки под видом багов, а честный заказчик не выдаёт новые хотелки за гарантийные случаи.
Приёмка как основа гарантии
Гарантия держится на приёмке: гарантировать можно только то, что было проверено и принято как работающее. Поэтому качество приёмки напрямую определяет качество гарантии — небрежная сдача порождает бесконечные споры «а это работало или нет».
- Проверка по сценариям. Не «полистать сайт», а прогнать ключевые пути: заказ, оплата, регистрация, выгрузка в 1С, работа фильтра.
- Проверка на реальных данных. Настоящий каталог, настоящие цены и остатки, реальные способы оплаты и доставки.
- Фиксация результата. Что принято, что с замечаниями, что отложено — в письменном виде, а не «на словах».
- Точка отсчёта гарантии. С момента подписания приёмки принятая функциональность попадает под гарантию.
Тщательная приёмка выгодна обеим сторонам: заказчик получает работающий продукт, подрядчик — понятную границу ответственности. Ошибки, найденные при приёмке, — это ещё не гарантийные случаи, а часть сдачи; гарантия начинается после того, как система принята.
Сроки и что на них влияет
Единого «правильного» срока гарантии нет — он зависит от сложности проекта, объёма интеграций и договорённостей. Для сайтов и магазинов на 1С-Битрикс типична гарантия от нескольких месяцев до года на код подрядчика.
На разумный срок влияют:
- Сложность системы. Чем больше кастомной логики и интеграций, тем дольше «вылезают» редкие дефекты.
- Нагрузка и сезонность. Часть багов проявляется только под трафиком или в пик продаж.
- Зрелость платформы. Типовой функционал Битрикс стабильнее уникальной разработки.
Важнее длины срока — реальность гарантии и скорость реакции. Короткая, но честная гарантия с быстрым устранением дефектов полезнее «года на бумаге», по которому месяцами ничего не чинят. Оценивайте не только цифру в договоре, но и то, как подрядчик реагирует на обращения.
SLA и классы критичности
Чтобы гарантия была измеримой, а не «починим когда-нибудь», в неё вводят SLA — соглашение об уровне сервиса. Оно задаёт время реакции и устранения в зависимости от критичности дефекта.
- Критичный. Не работает приём или оплата заказов, сайт недоступен — реакция в часы, устранение в приоритете.
- Серьёзный. Ломается важная функция, но продажи идут — устранение в короткий срок.
- Обычный. Локальная ошибка без влияния на выручку — в плановом порядке.
- Косметический. Мелкий визуальный дефект — в ближайшем цикле работ.
Порядок обращения о дефекте
Скорость устранения дефекта во многом зависит от того, как о нём сообщили. Воспроизводимое обращение подрядчик чинит быстро, а «всё сломалось» — нет, потому что сначала надо понять, что именно.
Хорошее обращение о дефекте содержит:
- Шаги воспроизведения. Что делали по порядку, чтобы получить проблему.
- Ожидание и факт. Что должно было произойти и что произошло вместо этого.
- Контекст. Страница, браузер, устройство, роль пользователя, время.
- Доказательство. Скриншот или запись экрана, текст ошибки.
Заявки полезно вести в едином трекере с фиксацией времени — это делает и приёмку, и гарантию прозрачными. Кстати, устойчивость релизов и быстрый откат при регрессиях сильно упрощают устранение дефектов; мы разбираем это в статье про CI/CD и деплой на Битрикс.
Обновления, среда и чужие правки
Две ситуации регулярно выводят проблему за пределы гарантии — и о них стоит договориться заранее.
Обновления среды. Апдейт самой платформы 1С-Битрикс, коммерческих модулей, PHP или ОС — это изменение окружения, а не дефект сданного кода. Добросовестный подрядчик разделяет: если код развалился из-за несовместимости по вине разработки — это ближе к гарантии; если из-за самого факта обновления среды — это регламентное обслуживание. Поэтому обновления обычно выносят в отдельную поддержку.
Чужие правки. Если в код, настройки или структуру инфоблоков вносил изменения сторонний исполнитель или ваш программист, гарантия на затронутые участки, как правило, снимается — невозможно отвечать за чужие изменения. Это не отговорка, а защита от ответственности за то, что подрядчик не контролировал. Инфраструктурные аспекты стабильности мы разбираем в материале про инфраструктуру на BitrixVM.
Специфика 1С-Битрикс
Гарантия на проект под 1С-Битрикс имеет свои нюансы из-за устройства платформы. Часть системы — это ядро, модули и компоненты вендора, а часть — код подрядчика поверх них.
- Ядро и модули вендора. За их поведение отвечает 1С-Битрикс; подрядчик гарантирует корректную настройку и интеграцию, а не сам код платформы.
- Кастомная разработка. Свои компоненты, обработчики событий, логика на D7 — зона прямой гарантии подрядчика.
- Обмен с 1С. Настройка обмена CommerceML — частый источник спорных дефектов; важно фиксировать, что и как выгружается.
- Кэш и агенты. Ошибки часто связаны с кэшированием и фоновыми агентами — их поведение стоит проверять на приёмке.
Понимание этой границы помогает не спорить о том, за что подрядчик в принципе может отвечать. Как устроена собственная логика на платформе, мы показываем в статье про разработку модуля для Битрикс.
Гарантия и техподдержка
Гарантию часто путают с техподдержкой, и из этой путаницы рождаются конфликты. На деле это разные вещи, которые дополняют друг друга.
Гарантия — бесплатное устранение дефектов сданного кода в оговорённый срок. Она отвечает на вопрос «вы сделали качественно?». Техподдержка — платное сопровождение живого проекта: доработки, обновления, консультации, мониторинг, развитие. Она отвечает на вопрос «поможете жить и расти дальше?».
Разумная модель — гарантия сразу после сдачи плюс отдельный договор поддержки на развитие. Тогда границы ясны: баг чинится по гарантии, новая фича делается по поддержке. Смешивать их в одну «вечную бесплатную помощь» невыгодно обеим сторонам: подрядчик выгорает, заказчик не получает предсказуемого сервиса.
Частые споры и как их избежать
- Доработка под видом бага. Заказчик называет новое пожелание дефектом; лечится точным ТЗ и приёмкой.
- Нет фиксации приёмки. Непонятно, что было принято работающим; лечится письменной приёмкой по сценариям.
- Размытые сроки. «Скоро починим» без SLA; лечится классами критичности и временем реакции.
- Спор об обновлениях. Кто отвечает за апдейт среды; лечится оговоркой про обновления в договоре.
- Чужие правки. После вмешательства третьих лиц спорят о гарантии; лечится условием о снятии гарантии с изменённых участков.
- Невоспроизводимые заявки. «Не работает» без деталей; лечится шаблоном обращения и трекером.
- Гарантия как бесплатное развитие. Ожидание бесконечных доработок; лечится отдельным договором поддержки.
Чек-лист приёмки и гарантии
- Объём зафиксирован. ТЗ описывает функции конкретно, а не «сделать хороший сайт».
- Приёмка по сценариям. Ключевые пути проверены на реальных данных и приняты письменно.
- Срок гарантии в договоре. Указан период и что именно он покрывает.
- SLA согласован. Определены классы критичности и время реакции и устранения.
- Канал обращений. Есть трекер или тикеты с шаблоном заявки и фиксацией времени.
- Оговорки про среду и правки. Прописаны условия по обновлениям и вмешательству третьих лиц.
- Поддержка отдельно. Развитие и доработки вынесены в договор техподдержки.
Вывод
Гарантийный период — не формальность и не источник вечных споров, а рабочий механизм, который держится на трёх опорах: чётком объёме работ, качественной приёмке и понятном SLA. Когда границы покрытия описаны заранее, различие между багом и доработкой перестаёт быть предметом эмоций и становится вопросом документов.
Для проектов на 1С-Битрикс к этому добавляется понимание архитектуры: где заканчивается ответственность вендора и начинается зона подрядчика, как влияют обновления среды и чужие правки. Договоритесь об этом до старта, разделите гарантию и платную поддержку — и послепусковая жизнь проекта будет спокойной для обеих сторон, а дефекты будут устраняться быстро и без конфликтов.
