Раздел о приёмке защищает обе стороны тогда, когда в нём есть три вещи: сколько рабочих дней у заказчика на проверку, в какой форме он отвечает и что происходит, если он не ответил вовсе. В типовом договоре, который присылает подрядчик, обычно записана только третья — «работы считаются принятыми». Это не злой умысел: пункт написан юристом подрядчика и защищает подрядчика от заказчика, который пропал. Проблема в том, что при сроке проверки в два-три дня он же превращается в механизм, по которому непроверенный этап оплачивается автоматически.
Спор о приёмке почти никогда не бывает спором о деньгах: суммы в договоре записаны точно. Спорят о другом — считается ли работа выполненной. И если не написано, чем это проверяется и за сколько дней, выигрывает не тот, кто прав, а тот, у кого больше переписки и терпения.
Ниже — шесть шагов приёмки в формулировках договора, арифметика срока проверки, три редакции пункта о молчаливой приёмке и расчёт на модельном проекте, где этап на 640 000 ₽ был принят молчанием. Мы инженерное бюро, а не юридическая фирма, поэтому отдельным разделом собрано, что здесь решает инженер, а что несут юристу.
Шесть шагов приёмки в формулировках договора
Приёмка — это не «показали и подписали», а последовательность из шести шагов, каждый со своим сроком. Ниже — что должно быть написано в договоре по каждому шагу. Формулировки даны как рабочая заготовка: их можно взять в свой договор, но перед подписанием показать юристу, потому что редакция соседних пунктов может менять смысл.
- 1Шаг 1. Уведомление о готовности этапа
Подрядчик направляет уведомление на согласованный адрес и прикладывает комплект передачи: сборку в тестовом контуре, инструкцию по проверке, результаты своего прогона приёмочных сценариев. В договоре важно назвать адрес и способ: «направляется на адрес электронной почты, указанный в реквизитах, и считается полученным в день направления».
- 2Шаг 2. Срок проверки
Считается в рабочих днях и начинает течь со дня, следующего за передачей полного комплекта, а не с даты письма «мы всё сделали». Разница принципиальна: неполный комплект — это ситуация, в которой проверять нечего, и срок в ней течь не должен.
- 3Шаг 3. Протокол замечаний
Заказчик отвечает одним документом: перечень непройденных сценариев по номерам, класс каждого замечания и предлагаемая дата повторной проверки. Договор должен требовать именно перечень, а не «мотивированные возражения» — иначе фраза «нам не нравится, как работает» формально считается ответом.
- 4Шаг 4. Устранение
Сроки разные для разных классов замечаний: блокирующие — 3 рабочих дня, существенные — 5, косметические — до 20 или в ближайшее плановое окно. Единый срок «в разумный срок» не работает ни для кого: подрядчику он не даёт планировать, заказчику — требовать.
- 5Шаг 5. Повторная проверка — только по спорным пунктам
Это самый недооценённый пункт. Без него каждая итерация запускает полный прогон заново, и приёмка одного этапа растягивается на месяц. Формулировка: повторная проверка проводится только по замечаниям из протокола и по сценариям, на которые они влияют; срок повторной проверки — 3 рабочих дня.
- 6Шаг 6. Акт
Подписывается по результатам проверки, и в нём фиксируется, что именно принято: этап, версия ТЗ, перечень пройденных сценариев. Как выглядит такой акт и как в него вносятся оговорки, разобрано в материале про акт выполненных работ.
Горизонтальная схема из шести блоков со стрелками: «Уведомление и комплект передачи» → «Проверка, 10 рабочих дней» → «Протокол замечаний» → «Устранение: 3 / 5 / до 20 рабочих дней по классам» → «Повторная проверка только по спорным пунктам, 3 рабочих дня» → «Акт». Над вторым блоком выноска: «срок течёт со дня, следующего за передачей полного комплекта». От блока «Протокол замечаний» вниз отходит короткая ветка «замечаний нет — сразу акт». Чертёжный стиль, подписи по-русски.
Эти шесть шагов — договорная рамка. То, как процедура выглядит изнутри проекта — кто прогоняет сценарии, чем щупается каждый этап и как отличить дефект от нового требования, — мы разобрали в статье про приёмку работ по автоматизации. Здесь речь только о том, что из этого обязано попасть в текст договора.
Сколько дней на проверку: считаем, а не берём круглое число
Срок проверки — единственное число в разделе, которое нельзя списать из шаблона. Он зависит от того, что именно сдаётся, и считается снизу вверх: сколько человеко-дней нужно, чтобы этап действительно проверить. Дальше — модельный расчёт для этапа «Интеграция с 1С:УТ» ценой 640 000 ₽ в проекте на 2 400 000 ₽: 26 приёмочных сценариев, поток 120 заявок в рабочий день, четыре менеджера в качестве проверяющих.
Запас между 6 и 10 днями — не торг, а реальность: проверяющие заняты основной работой. Практический ориентир для договора — 5–10 рабочих дней: пять для этапов, где проверяется интерфейс и логика на тестовых данных, десять — для интеграций, отчётности и всего, где нужна сверка с боевыми данными.
Для интеграций есть отдельная оговорка, которую подрядчики принимают без спора, потому что она защищает и их: срок проверки течёт с момента предоставления тестового контура, а не с даты уведомления. Контур поднимает заказчик и не успел — просрочка на его стороне. Сборка не разворачивается по инструкции — комплект неполный, и срок не течёт.
Схема-ворота. Слева четыре блока комплекта передачи: «Сборка развёрнута в тестовом контуре», «Инструкция по проверке», «Результаты прогона подрядчика», «Доступ проверяющим». Все четыре сходятся в ворота с подписью «Комплект полный». За воротами — линейка на 10 рабочих дней с отметкой «6 дней — фактическая трудоёмкость проверки» и запасом до 10. Сбоку от ворот две красные ветки: «контур не поднимается по инструкции» и «доступ не выдан» с общей подписью «срок не течёт». Чертёжный стиль, подписи по-русски.
Частое возражение: «десять дней слишком долго, проект встанет». Не встанет: работа над следующим этапом идёт параллельно, останавливается только оплата текущего. Тормозит проект другое — приёмка, которая идёт третий круг, потому что каждая итерация запускает полный прогон заново.
Пункт о молчаливой приёмке: когда он честный, а когда ловушка
Само правило справедливо. Подрядчик не может держать этап открытым бесконечно только потому, что у заказчика не доходят руки: люди уходят в отпуск, ответственный меняется, и без такого пункта проект зависает без вины исполнителя. Ловушкой правило становится от сочетания двух вещей — короткого срока и размытого старта этого срока.
Условие договора, по которому работы считаются принятыми, если заказчик в отведённый срок не подписал акт и не направил мотивированный отказ. С этого момента возникает обязанность оплатить этап, а замечания, которые можно было обнаружить при обычной проверке, переходят в разряд платных доработок. Само по себе условие нормальное — опасны его параметры: срок, момент старта срока и отсутствие исключений.
| Редакция пункта | Что это означает на практике | Кому выгодно |
|---|---|---|
| «Работы считаются принятыми, если заказчик не подписал акт в течение 2 рабочих дней» | Проверить интеграцию за два дня физически нельзя: только развернуть контур и прогнать сценарии — 2,5 дня. Этап принимается непроверенным | Только подрядчику, и то до первого конфликта |
| «Работы считаются принятыми, если заказчик не направил возражения в течение 10 рабочих дней с даты уведомления» | Срок нормальный, но стартует от письма. Если сборку не удалось развернуть, три дня из десяти ушли на переписку | Скорее подрядчику |
| «Срок проверки — 10 рабочих дней со дня, следующего за передачей полного комплекта. Правило не применяется к недостаткам, которые не могли быть обнаружены при проверке по согласованным сценариям» | Рабочая редакция: у заказчика есть реальное время, у подрядчика — определённая дата закрытия этапа | Обеим сторонам |
Ограничивают пункт тремя приёмами, и ни один из них подрядчик обычно не оспаривает, потому что все три делают процедуру предсказуемой.
- Привязать старт срока к комплекту, а не к письму. Формулировка «со дня, следующего за передачей комплекта в составе, определённом приложением» — и в приложении перечислены четыре позиции: сборка, инструкция, результаты прогона подрядчика, доступы проверяющим.
- Исключить скрытые недостатки. Молчание закрывает только то, что можно было увидеть при проверке по согласованным сценариям. Дефект, который проявляется раз в неделю под нагрузкой, к явным не относится, и это стоит записать прямо.
- Ввести повторное уведомление. За два рабочих дня до истечения срока подрядчик направляет напоминание. Пункт выглядит как одолжение заказчику, но на деле защищает подрядчика: после напоминания молчание уже трудно объяснить тем, что письмо ушло в спам.
Дальше — во что обходится обратная ситуация. Модельный проект тот же: этап «Интеграция с 1С:УТ» на 640 000 ₽, срок проверки по договору — 2 рабочих дня, старт срока — от даты письма. Заказчик ответил на четвёртый день, этап к тому моменту считался принятым.
Механика простая. При недоступности 1С:УТ — регламентные работы, обновление, ночное закрытие — заявка не вставала в очередь, а исчезала: около 2 % потока, то есть 2–3 заявки в день при 120 заявках, за 26 рабочих дней — 62 штуки. Поведение при недоступности учётной системы в приёмочных сценариях прописано не было, поэтому подрядчик формально прав и оформил исправление как новое требование. При сроке в десять дней и состоявшемся прогоне дефект нашёлся бы на приёмке и был бы устранён бесплатно за те же 3 рабочих дня — как блокирующее замечание.
Написать раздел о приёмке в рабочей редакции — это примерно 6 рабочих часов совместной работы инженера и юриста, около 18 000 ₽. Разница с 252 900 ₽ — почти в 14 раз, и это ещё аккуратный сценарий: здесь стороны договорились, никто не пошёл в суд и проект не остановился.
Сравнение в две колонки. Левая — «Срок проверки 2 рабочих дня»: этап 640 000 ₽ принят молчанием, дефект найден после 26 рабочих дней эксплуатации, четыре строки расходов 27 900 ₽ / 90 000 ₽ / 90 000 ₽ / 45 000 ₽ и итог 252 900 ₽ (39,5 % цены этапа). Правая — «Срок проверки 10 рабочих дней»: дефект найден на приёмке, класс «блокирующее», устранение 3 рабочих дня, итог 0 ₽ сверх сметы. Внизу общая полоса: «Написать раздел о приёмке — 6 рабочих часов, 18 000 ₽». Чертёжный стиль, подписи по-русски.
Акт без оговорок закрывает дорогу к явным недостаткам
Это правило важнее любых сроков, и именно его чаще всего не знают на стороне заказчика. Гражданский кодекс для договора подряда исходит из того, что заказчик, принявший работу без оговорок, теряет право потом ссылаться на недостатки, которые можно было обнаружить при обычном способе приёмки. Это смысл пункта 2 статьи 720 ГК РФ. Скрытые недостатки — те, которые при обычной проверке увидеть нельзя, — под правило не подпадают.
Для процедуры отсюда следуют три практических вывода. Первый: подписывать акт «чтобы не портить отношения, а замечания решим по-человечески» — дорого. Устная договорённость после подписи ничем не подтверждается. Второй: если этап в целом рабочий, а мелочи не устранены, акт подписывается с оговорками — работа принимается, недостатки перечислены с датами устранения, оплата не срывается. Третий: понятие «обычный способ приёмки» перестаёт быть оценочным ровно тогда, когда в договоре есть согласованные приёмочные сценарии — они и определяют, что было явным.
Правило про акт без оговорок относится к подряду. Договор на внедрение часто оформляют как договор возмездного оказания услуг или как смешанный — там регулирование другое, и переносить вывод механически нельзя. Что именно у вас в договоре и какая норма к нему применяется — вопрос юриста, а не инженера. Как устроены сами конструкции договора и чем они отличаются, разобрано в материале про существенные условия.
Как требование ТЗ становится проверяемым критерием
Самая частая причина спора на приёмке — не недобросовестность, а требование, под которое можно сдать что угодно. «Настроить интеграцию с 1С» — это не критерий: подрядчик покажет, что заказ создался один раз руками, и формально будет прав. Критерий получается, когда в формулировке появляются три вещи: наблюдаемое событие, число и способ проверки.
| Формулировка из ТЗ | Что можно сдать под неё | Проверяемый критерий приёмки |
|---|---|---|
| Настроить интеграцию с 1С:УТ | Один заказ, созданный вручную из тестовой формы | Заказ появляется в 1С:УТ не позднее 60 секунд после подтверждения заявки; проверено на 20 заказах подряд, расхождений по позициям и ценам нет |
| Система распознаёт спецификации из писем | Демонстрацию на трёх удобных письмах | На выборке из 100 писем за прошлый месяц позиции извлечены без ручной правки в 88 и более случаях; список исключений приложен |
| Обеспечить надёжную работу обмена | Заявление «за неделю тестов сбоев не было» | При недоступности 1С:УТ заявка ставится в очередь и уходит после восстановления; проверено принудительным отключением на 30 минут, потерь нет |
| Настроить уведомления ответственному | Одно письмо, отправленное в момент демонстрации | По 10 тестовым заявкам уведомление приходит ответственному из карточки Битрикс24 в течение 2 минут; при смене ответственного адресат меняется |
| Обучить сотрудников работе в системе | Часовой созвон, на который пришли двое | Четыре менеджера самостоятельно проводят по одной заявке полного цикла без подсказок; инструкция на 3 страницы передана и лежит в общем доступе |
Сравнение в две колонки по пяти строкам. Левая колонка «Требование» с формулировками: «настроить интеграцию с 1С:УТ», «система распознаёт спецификации», «обеспечить надёжную работу обмена», «настроить уведомления», «обучить сотрудников». Правая колонка «Критерий приёмки» с числами: «60 секунд, 20 заказов подряд», «88 из 100 писем», «отключение на 30 минут, потерь нет», «10 заявок, 2 минуты», «4 менеджера, по одной заявке без подсказок». Между колонками вертикальная подпись «событие + число + способ проверки». Чертёжный стиль, подписи по-русски.
Правило, по которому такие критерии пишутся, простое: каждое требование обязано порождать хотя бы один сценарий приёмки, а каждый сценарий — заканчиваться наблюдаемым результатом. Требование, из которого нельзя сделать сценарий, либо переформулируется, либо честно уходит в раздел «пожелания» без обязательств. Где физически живут эти сценарии и как фиксируется их версия, разобрано в статье про техзадание как приложение к договору.
Классы замечаний: абзац, который снимает половину спора
Без классификации приёмка застревает на первом же прогоне: заказчик считает опечатку в подписи кнопки поводом не подписывать акт, подрядчик считает потерю заявки при сбое мелочью, которую поправят потом. Классы вводятся в договор одним абзацем, и дальше спор идёт не о том, подписывать ли акт, а о том, к какому классу отнести конкретное замечание — это разговор на десять минут вместо переписки на две недели.
- Блокирующее — сценарий не выполняется или выполняется с потерей данных, работать по процессу нельзя. Срок устранения 3 рабочих дня, акт не подписывается до повторной проверки.
- Существенное — сценарий выполняется, но не соответствует числовому критерию из ТЗ либо требует обходного пути. Срок 5 рабочих дней, акт не подписывается, но работа над следующим этапом идёт параллельно.
- Косметическое — на результат сценария не влияет: тексты, подписи, порядок полей. Срок до 20 рабочих дней или ближайшее плановое окно, акт подписывается с оговорками, замечания уходят в открытый список с датами.
К этому абзацу нужен второй, про новые требования. На приёмке заказчик впервые видит работающую систему и понимает, чего ему на самом деле хочется, — это нормально и происходит почти всегда. Плохо, когда такие пункты либо продавливаются как дефекты, либо отклоняются без записи. Рабочая формулировка: замечания, не следующие из ТЗ и приёмочных сценариев, вносятся в отдельный раздел протокола, оцениваются в часах и рублях и оформляются запросом на изменение. Постатейный разбор, что проверять на каждом этапе и чем это щупать, собран в чек-листе приёмки этапа.
Что решает инженер, а что несут юристу
Границу стоит провести явно, потому что обе стороны регулярно ждут решения не от того человека. Инженер отвечает за проверяемость: сценарии, числовые пороги, состав комплекта передачи, классы замечаний, реалистичность срока проверки. Юрист отвечает за последствия: какая норма применяется к вашей конструкции договора, что происходит при просрочке каждой из сторон, как соотносятся молчаливая приёмка и оплата, чем грозит подписанный акт.
- 1Какой у нас договор по существу — подряд, услуги или смешанный, и какие правила о приёмке к нему применяются. От ответа зависит почти весь раздел.
- 2Как в нашей редакции соотносятся пункт о молчаливой приёмке и пункт об оплате: возникает ли обязанность платить автоматически и с какой даты считается просрочка.
- 3Считается ли направленным мотивированный отказ, отправленный по электронной почте на адрес из реквизитов, и нужен ли дубль бумажным письмом.
- 4Что именно закрывает подписанный акт и как правильно сформулировать оговорки, чтобы сохранить право требовать устранения.
- 5Что происходит, если просрочили обе стороны: подрядчик сдал этап позже срока, а заказчик проверял дольше отведённого. Это самая частая реальная ситуация и самая редко описанная в договорах.
Приём простой: не носить юристу весь договор с вопросом «посмотрите, всё ли нормально» — ответ будет общим. Нести надо список выше плюс раздел о приёмке и приложение со сценариями: тогда проверка занимает два-три часа вместо двух дней.
Спорят почти всегда не о деньгах, а о том, считается ли работа выполненной. Раздел о приёмке — это и есть ответ на этот вопрос, написанный заранее.
Когда поэтапная приёмка избыточна
Процедура из шести шагов имеет цену: её пишут, согласовывают и потом соблюдают. На маленьком проекте эта цена сопоставима с самим проектом, и тогда честнее обойтись без неё.
- Проект до 300 000 ₽ и короче трёх недель. Разбивать его на этапы бессмысленно: он сам по себе один этап. Достаточно перечня приёмочных сценариев в приложении, срока проверки 5 рабочих дней и оплаты по факту подписания одного акта.
- Работа по подписке. Если вы платите за готовый сервис помесячно, приёмки в этом смысле нет вообще: есть настройка и есть право перестать платить. Раздел про этапы в такой договор попадает по инерции и ничего не регулирует.
- Внутренняя команда. Между отделами одной компании акт не подписывают. Здесь работают те же приёмочные сценарии, но как рабочий чек-лист, а не как договорная процедура: нужна проверяемость, а не документооборот.
- Почасовая работа с открытым объёмом. Принимать нечего по определению: платят за часы, а не за результат. Модель законная, но её риски закрываются лимитом часов и правом остановиться в любой момент, а не разделом о приёмке.
И последнее, что стоит сказать прямо: раздел о приёмке не заменяет проверку, а делает её возможной. Если сценарии никто не прогонит, самая аккуратная формулировка закончится тем же — актом, подписанным вслепую, просто на десятый день, а не на второй.
