Гарантия на разработку работает ровно в той мере, в какой в договоре написано, что считается дефектом. Если этого определения нет, каждое обращение после запуска превращается в переговоры: заказчик считает, что система должна была так уметь, подрядчик — что об этом не договаривались. Оба искренни, и оба формально правы, потому что граница не проведена.
Единственное определение, которое не порождает спора, звучит скучно: гарантийный случай — это отклонение системы от подписанного техзадания и от приёмочных сценариев, перечисленных в акте. Не «не работает», не «работает не так, как мы думали», а именно расхождение с тем, что зафиксировано на бумаге. Всё, что за пределами этих двух документов, — новое требование, и оно оплачивается отдельно.
Ниже — что попадает в гарантию и что не попадает, таблица «чиним бесплатно или выставляем счёт» на десять реальных случаев, два разных срока (реакции и устранения) и честная арифметика: сколько стоит гарантия на три, шесть и двенадцать месяцев и почему удержание части оплаты возвращается к вам ростом сметы. Мы инженерное бюро, а не юридическая фирма, поэтому вопросы права собраны в конце отдельным списком для юриста.
Гарантийный случай и то, что в него не входит
Ситуация, в которой принятая система ведёт себя иначе, чем описано в подписанной версии ТЗ или в приёмочном сценарии из акта этапа, а внешние условия при этом не менялись. Три части определения одинаково важны: есть подписанный документ, есть наблюдаемое расхождение с ним, внешняя среда та же. Уберите любую — и обращение перестаёт быть гарантийным.
Практический смысл третьей части виден сразу. Обмен с 1С:УТ работал полгода и перестал после обновления конфигурации: система ведёт себя иначе, документ есть, но среда изменилась. Это не дефект, а адаптация, и оплачивается она по договору поддержки либо по счёту.
Отсюда главное требование к договору: гарантия должна ссылаться на конкретные документы с версиями. «Исполнитель гарантирует надлежащее качество работ» не даёт ничего — под эту фразу подходит любой спор. Рабочая привязка: гарантия распространяется на соответствие системы приложению № 2 в версии от указанной даты и перечню приёмочных сценариев из акта этапа. Откуда берутся сами сценарии, разобрано в материале о поэтапной приёмке в договоре.
Приёмочные сценарии проверяют систему за несколько дней, а часть дефектов проявляется раз в две недели под нагрузкой или в ночном окне обслуживания. Такие случаи не перестают быть дефектами оттого, что на приёмке их не увидели: система всё равно расходится с требованием ТЗ. Это стоит записать в договор прямо — иначе подрядчик получает аргумент «вы же подписали акт».
С обратной стороны границы стоят пять категорий, которые не попадают в гарантию ни при какой формулировке. Спорить о них бессмысленно — лучше заранее решить, чем они закрываются: обычно договором поддержки, где такие работы либо входят в абонентскую плату, либо считаются по часам.
- Изменения внешних систем. Обновилась конфигурация 1С:УТ, Битрикс24 сменил формат ответа API, оператор телефонии перевёл номера на новую платформу. Наша работа не изменилась — изменился мир вокруг неё. Обновление интеграций при изменении чужого API — типовой пункт договора поддержки, а не гарантии.
- Рост нагрузки сверх расчётной. В ТЗ было 120 заявок в рабочий день, стало 400. Система, спроектированная под первое число, на втором работает медленнее — это не дефект, а исчерпание запаса. Поэтому расчётные объёмы нужно писать в ТЗ числами: они одновременно и обязательство подрядчика, и граница его ответственности.
- Новые требования. «Пусть уведомление уходит ещё и в MAX», «добавьте вторую схему скидок» — нормальные пожелания, которые появляются, когда система заработала. Их оформляют дополнительным соглашением с оценкой в часах и деньгах, а не заявкой в гарантию.
- Ошибки данных заказчика. Дубли в справочнике номенклатуры, склады, заведённые задним числом, контрагенты с одинаковыми ИНН. Сопоставление ошибается не потому, что алгоритм плох, а потому, что данные противоречивы. Что делать с этим до внедрения, а не после, — в материале о подготовке данных.
- Действия третьих лиц. Другой подрядчик поменял права в Битрикс24, системный администратор закрыл порт, сотрудник удалил служебного пользователя. Восстановление работоспособности — оплачиваемая работа, и это справедливо: наш код не менялся.
Схема с замкнутым контуром в центре. Внутри контура два блока: «Подписанное ТЗ, версия и дата» и «Приёмочные сценарии из акта», между ними подпись «расхождение = гарантийный случай». Снаружи контура пять блоков со стрелками, упирающимися в границу и не проходящими внутрь: «Обновление 1С:УТ и чужих API», «Нагрузка выше расчётной: было 120 заявок в день», «Новое требование», «Грязные справочники заказчика», «Действия других подрядчиков». Под схемой подпись: «снаружи — договор поддержки или счёт». Чертёжный стиль, все подписи по-русски.
Десять случаев: гарантия или счёт
Определение начинает работать, когда его один раз прогнали по реальным ситуациям. Ниже — десять обращений с модельного проекта: производственно-торговая компания, внедрение на 2 400 000 ₽ в пять этапов, обмен между почтой, 1С:УТ и Битрикс24, расчётный поток 120 заявок в рабочий день. Такую таблицу полезно приложить к договору: она не имеет самостоятельной силы, но снимает большую часть разговоров на второй месяц эксплуатации.
| Что произошло | Гарантия или счёт | Почему так |
|---|---|---|
| Заказ не создаётся в 1С:УТ по сценарию № 12, принятому актом третьего этапа | Гарантия | Прямое расхождение с принятым сценарием, среда не менялась |
| Обмен падает на спецификациях с ручной скидкой — такой случай описан в ТЗ | Гарантия | Требование есть в подписанной версии приложения |
| Раз в две недели ночью служба обмена не поднимается после перезапуска | Гарантия | Скрытый дефект: сценарии за 10 дней проверки его поймать не могли |
| Уведомление ответственному приходит через 6 минут вместо 2 минут из критерия | Гарантия | Числовой порог зафиксирован в приёмочном сценарии и нарушен |
| 1С:УТ обновили до новой версии, изменился формат документа реализации | Счёт или поддержка | Изменилась внешняя система, работа подрядчика не менялась |
| Битрикс24 сменил формат ответа API, перестали заполняться поля сделки | Поддержка | Типовой случай абонентского договора: чужой API вне нашего контроля |
| Поток вырос со 120 до 400 заявок в день, разбор писем не успевает за смену | Счёт | Расчётный объём в ТЗ — 120 заявок; нужна переработка, а не починка |
| Завели пять новых складов, правило маршрутизации о них не знает | Счёт | Новые данные порождают новое требование, а не дефект |
| В справочнике номенклатуры 1 200 дублей, сопоставление ошибается на них | Счёт | Ошибка данных заказчика; чистка справочника — отдельная работа |
| Другой подрядчик изменил права в Битрикс24, интеграция потеряла доступ | Счёт | Действия третьего лица; восстановление доступа оплачивается по часам |
Обратите внимание на четвёртую строку. Она гарантийная только потому, что в сценарии стояло число — 2 минуты. Без числа обращение попадает в серую зону: «медленно» — это оценка, а не факт, и спор о ней выигрывает тот, кто настойчивее. Это же правило работает и в обратную сторону: подрядчик, у которого есть числовые критерии, защищён от бесконечных «хотелось бы побыстрее».
Сравнение в две колонки на одной вертикальной оси. Левая колонка «Гарантия» с четырьмя строками: «сценарий № 12 не проходит», «падение на ручной скидке», «ночной сбой раз в две недели», «уведомление за 6 минут вместо 2». Правая колонка «Счёт или поддержка» с шестью строками: «обновление 1С:УТ», «смена API Битрикс24», «поток 400 заявок вместо 120», «пять новых складов», «1 200 дублей в номенклатуре», «чужие настройки прав». Между колонками вертикальная подпись «есть подписанное требование — нет подписанного требования». Чертёжный стиль, подписи по-русски.
Срок реакции и срок устранения — это два разных числа
Самая частая дыра в гарантийном разделе — одно число вместо двух. Написано «Исполнитель устраняет недостатки в течение 10 рабочих дней», и заказчик десять дней не знает, взялись за его обращение или оно потерялось. Нужны оба срока: за какое время подрядчик обязан ответить и подтвердить класс дефекта, и за какое — починить.
| Класс дефекта | Признак | Срок реакции | Срок устранения |
|---|---|---|---|
| Блокирующий | Процесс встал или теряются данные, обходного пути нет | 2 рабочих часа | 8 рабочих часов |
| Существенный | Сценарий выполняется, но не по числовому критерию, либо через обходной путь | 4 рабочих часа | 3 рабочих дня |
| Косметический | На результат сценария не влияет: тексты, подписи, порядок полей | 1 рабочий день | 15 рабочих дней |
Три уточнения, без которых таблица не работает. Первое: рабочие часы считаются внутри согласованного окна — например, с 10 до 19 по московскому времени в будни; иначе «8 рабочих часов» превращается в «завтра к обеду» или в «через двое суток» в зависимости от того, когда упало. Второе: класс дефекта определяет заказчик при подаче, а подрядчик вправе оспорить в срок реакции — так спор происходит один раз в начале, а не в конце. Третье: если починка требует изменения на стороне 1С:УТ или Битрикс24, срок приостанавливается до предоставления доступа — эта оговорка защищает обе стороны.
Те же три класса используются на приёмке, но со сроками 3, 5 и 20 рабочих дней. Разница не случайна: на приёмке система ещё не в бою, а в гарантийный период блокирующий дефект останавливает работу компании. Если в вашем договоре оба набора совпадают, один из них написан не глядя. Как устроены сроки и приоритеты в абонентском обслуживании — в материале про SLA в поддержке.
Три, шесть или двенадцать месяцев — и сколько это стоит
Длина гарантии определяется не щедростью подрядчика, а тем, успевают ли за этот срок пройти все циклы, в которых система участвует. Логика простая: гарантия должна пережить хотя бы один полный оборот бизнес-процесса.
| Срок | Когда достаточно | Что за это время успевает произойти |
|---|---|---|
| 3 месяца | Настройка готовой платформы без интеграций с учётом: воронка, шаблоны, права | Три закрытия месяца, полный цикл продажи, сезонных эффектов почти не видно |
| 6 месяцев | Рыночный ориентир для внедрения с интеграциями — наш модельный проект здесь | Шесть закрытий месяца, два квартальных отчёта, отпускной период с подменами |
| 12 месяцев | Годовой цикл: сезонность, годовая отчётность, инвентаризация, перезаключение договоров | Все календарные события компании ровно по одному разу |
Теперь цена вопроса. Гарантия — это зарезервированные часы разработчика, которые подрядчик не может продать никому другому, и она всегда стоит в смете, даже когда не названа отдельной строкой. На модельном проекте в 2 400 000 ₽ расчёт выглядит так; ставка подрядчика — 2 500 ₽ за час, как и во всех остальных расчётах этого кластера.
Отсюда практический вывод, неудобный для обеих сторон. Требовать двенадцать месяцев на проекте, где нет годовых циклов, — значит платить 63 000 ₽ за месяцы, в которых обращений почти не будет. И наоборот: соглашаться на 30 дней в интеграционном проекте бессмысленно, потому что первое закрытие месяца в промышленной эксплуатации часто наступает уже после истечения срока. Рабочая привязка для интеграций с учётом — отсчитывать гарантию не от подписания акта, а от первого закрытия месяца на живых данных.
Столбчатая диаграмма из двух столбцов на общей рублёвой шкале. Левый столбец «6 месяцев — 120 000 ₽ (5,0 % бюджета)», разбит на два сегмента: «40 часов × 2 500 ₽ = 100 000 ₽» и «риск-надбавка 20 000 ₽». Правый столбец «12 месяцев — 183 000 ₽ (7,6 % бюджета)», разбит на три сегмента: 100 000 ₽, 52 500 ₽, 30 500 ₽. Между столбцами выноска «разница 63 000 ₽». Внизу подпись «модельный проект 2 400 000 ₽, ставка 2 500 ₽/час». Чертёжный стиль, подписи по-русски.
Удержание оплаты до конца гарантии: почему больше 10 % не работает
Логика заказчика понятна: пока часть денег не выплачена, подрядчик заинтересован чинить. Логика работает, но только до определённого размера удержания — дальше она разворачивается и начинает работать против заказчика. Считаем на том же проекте в 2 400 000 ₽ со схемой оплаты 20/30/30/20, где последний платёж — 480 000 ₽.
Второй эффект важнее денежного. Удержание в 480 000 ₽ — это вся прибыль небольшой команды по проекту, замороженная на полгода. Такой подрядчик мотивирован не чинить, а закрыть гарантийный период, оспаривая каждое обращение. Мотивация появляется от денег впереди — от того, что вы остаётесь его клиентом по договору поддержки, — а не от размера залога позади.
Если в договоре нормальная поэтапная приёмка, у вас уже есть рычаг сильнее удержания: непринятый этап не оплачивается вовсе. Удержание нужно ровно для одного — для периода после приёмки последнего этапа. Ставить его поверх схемы, где половина платежей и так привязана к актам, — двойная страховка, за которую вы платите дважды: ростом сметы и испорченной мотивацией.
Сравнение в две колонки. Левая «Удержание 10 % — 240 000 ₽»: стоимость денег 30 000 ₽, рост сметы +1,25 %, подпись «подрядчик соглашается». Правая «Удержание 20 % — 480 000 ₽»: стоимость денег 60 000 ₽, рост сметы 5–8 % (120 000–192 000 ₽), подпись «подрядчик оспаривает каждое обращение». Внизу общая полоса с подписью «резерв на гарантию 6 месяцев — 120 000 ₽» для сравнения масштаба. Чертёжный стиль, подписи по-русски.
Гарантия и поддержка — не одно и то же
Их постоянно путают, и путаница дорого стоит: заказчик считает, что полгода гарантии заменяют договор обслуживания, а через месяц после запуска обнаруживает, что никто не следит за очередью обмена и не отвечает на вопросы менеджеров. Разница простая: гарантия чинит расхождения с тем, что уже подписано, а поддержка держит систему живой в меняющемся мире.
| Что делаем | Гарантия | Поддержка |
|---|---|---|
| Чиним расхождение с ТЗ и сценариями | Да, бесплатно | Да, бесплатно |
| Адаптируем к обновлению 1С:УТ и чужих API | Нет | Да, входит в абонентскую плату |
| Следим за очередями обмена и предупреждаем о сбоях | Нет | Да, мониторинг |
| Отвечаем на вопросы пользователей и учим новых | Нет | Да, в пределах часов пакета |
| Дорабатываем под новые требования | Нет | По часам сверх пакета |
| Действует | Фиксированный срок после акта | Пока действует договор |
Отсюда правило при выборе подрядчика: длинная гарантия без предложения поддержки — тревожный признак. Звучит выгоднее, а означает, что после запуска вас никто не ведёт. Из чего складывается цена обслуживания — в материале сколько стоит поддержка; что происходит с системой в первые месяцы эксплуатации — в статье о жизни системы после запуска.
Что решает инженер, а что несут юристу
Инженерная часть гарантийного раздела — это перечень принятых сценариев, числовые критерии, классификация дефектов и сроки. Всё это пишет тот, кто понимает процесс, и никакой юрист за него это не сделает. Юридическая часть — про то, как норма работает в вашей конкретной редакции договора, и здесь самодеятельность обходится дороже консультации.
Важная общая оговорка: правила о качестве работ и гарантии в договоре подряда в основном диспозитивны — стороны вправе договориться иначе, и договор перебивает норму по умолчанию. Поэтому смотреть надо не в общее правило, а в свой текст: то, что вы читали в чужой статье про гарантийный срок, может к вашему договору просто не относиться.
- 1Какой у нас договор по существу — подряд, возмездное оказание услуг или смешанный, и какие правила о качестве и гарантии к нему применяются.
- 2С какого момента считается гарантийный срок в нашей редакции: с подписания акта этапа, с акта последнего этапа или с ввода в промышленную эксплуатацию — и можно ли привязать его к первому закрытию месяца.
- 3Что происходит с гарантийным сроком на исправленную часть: начинается заново, продлевается на время устранения или не меняется.
- 4Как соотносятся гарантия и общий потолок ответственности: не оказывается ли стоимость устранения дефектов внутри того же лимита, что и неустойка.
- 5Вправе ли мы привлечь другого подрядчика для устранения дефекта за счёт исполнителя, если он не уложился в срок, и как это оформляется.
- 6Как оформлено удержание части оплаты: это обеспечительный платёж, отсрочка или что-то третье, и что происходит с ним при споре.
- 7Сохраняется ли гарантия, если мы сами вносили изменения в код или настройки, и как разграничить последствия наших правок и его работы.
Нести юристу стоит не весь договор с вопросом «всё ли нормально», а этот список плюс гарантийный раздел и приложение со сценариями. Тогда разбор занимает два-три часа, а не два дня, и вы получаете ответы, а не общую вычитку.
Гарантия не делает систему надёжной. Она определяет, кто платит, когда система оказалась ненадёжной, — и только там, где заранее написано, какой она должна быть.
Когда длинная гарантия не нужна
Длинный гарантийный срок стоит денег и в некоторых случаях покупает воздух. Честный перечень таких случаев короткий.
- Настройка готовой платформы без нового кода. Воронка в Битрикс24, права, шаблоны документов, регламенты. Ломаться тут может платформа вендора, а не работа подрядчика; трёх месяцев достаточно, а дальше дешевле купить помесячную поддержку и платить только за те месяцы, когда она нужна.
- Короткий проект до 300 000 ₽. Резерв в 5 % от такой суммы — 15 000 ₽, то есть 6 часов работы. Торговаться за то, будет их шесть или двенадцать, дороже самого предмета торга; проще договориться о почасовой ставке на исправления и не усложнять договор.
- Проект, после которого сразу заключается договор поддержки. Если обслуживание начинается в день подписания последнего акта, гарантийный срок перестаёт быть отдельной сущностью: дефекты и так чинятся бесплатно, пока действует договор. Именно так устроены наши обязательства, и это честнее, чем обещать год гарантии и исчезнуть после запуска.
- Система, которую вы дорабатываете сами. Как только ваши разработчики вносят изменения в переданный код, разграничить причину дефекта становится почти невозможно. Здесь полезнее не длинная гарантия, а нормально переданные исходники, схемы и инструкции — и оплачиваемые консультации автора по мере надобности.
И обратное правило, такое же честное. Если система участвует в закрытии месяца, в отчётности или в расчётах с контрагентами, гарантию короче шести месяцев брать нельзя ни при каком бюджете: до первого настоящего закрытия вы просто не узнаете, работает она или нет.
