Правовой каркас: три источника приёмки
Приёмка по 44-ФЗ опирается на три слоя. Первый — 44-ФЗ: статья 94 (порядок и сроки приёмки устанавливаются контрактом, по итогам оформляется документ о приёмке) и статья 41 (экспертиза результатов: внутренняя или внешняя; в ряде случаев привлечение внешних экспертов обязательно). Второй — Гражданский кодекс: заказчик обязан осмотреть и проверить результат, а обнаруженные недостатки зафиксировать — иначе потом не доказать (нормы о приёмке результатов работ применяются к поставке услуг через соответствующие статьи ГК). Третий — сам контракт и ТЗ: перечень сдаваемого, методики испытаний, сроки. Если в контракте нет методики проверки качества — спор почти гарантирован.
Этапы приёмки ПО: как это выглядит на практике
- Уведомление о готовности. Поставщик письменно (через ЭТП/ЭДО) сообщает: результат готов к приёмке, направляет комплект (сборка/доступ, документация, протоколы испытаний).
- Проверка на соответствие ТЗ. Комиссия заказчика проходит по пунктам технического задания — в идеале по заранее согласованным тест-кейсам. Каждый пункт: соответствует / не соответствует.
- Опытная эксплуатация. ПО работает у заказчика в боевом или тестовом контуре; её срок и критерии успешности должны быть в контракте, «бессрочная опытная эксплуатация» — красный флаг.
- Устранение замечаний. Замечания сводятся в ведомость; поставщик устраняет в срок из контракта; спорные пункты — повторная проверка.
- Документ о приёмке (акт). Подписывается комиссией; с этого момента запускаются гарантийные обязательства и расчёты.
В ИИ-системах к этому добавляется проверка метрик качества на эталонной выборке — как её строить, разобрано в статье «Экспертиза ИИ-компонентов в госзакупках» и в руководстве «ТЗ на разработку ИИ-системы».
Акт приёмки: что в нём должно быть
Акт — не формальность «подписали и разошлись», а доказательство. Рабочая структура:
- ссылка на контракт и этап (номер, предмет);
- перечень проверенных требований ТЗ (с указанием, чем подтверждено: тест-кейсы, протоколы испытаний);
- результаты опытной эксплуатации (период, метрики доступности/работоспособности, если заданы);
- замечания и решения по ним (устранено в ходе приёмки / принято с замечаниями и сроком устранения);
- состав передаваемого: код, документация, пароли/доступы, лицензии, обученные модели и датасеты — для ИИ-проектов это отдельный передаточный акт;
- вывод: этап/контракт исполнен, принимается; дата вступления гарантии.
«Принято без замечаний» без протоколов испытаний опасно обеим сторонам: заказчик теряет доказательства дефектов на гарантии, поставщик — доказательства объёма работ при споре. Если разница между MVP и промышленной системой для заказчика не зафиксирована в актах — читайте «Чем отличается MVP от промышленной системы».
Поэтапная приёмка и оплата
Если контракт разбит на этапы (аналитика → разработка → внедрение → сопровождение), у каждого этапа свои результаты и свой акт. Это полезно обеим сторонам: поставщик получает деньги без ожидания финала, заказчик — рычаг (не принял этап — не оплатил). Таблица ниже — типовая раскладка этапов ИТ-контракта.
| Этап | Результат для приёмки | Документ | Типичный риск |
|---|---|---|---|
| 1. Аналитика и ТЗ | утверждённые требования, протоколы интервью | акт/протокол согласования требований | «ТЗ ещё сырое» без критерия готовности |
| 2. Разработка | работающий функционал по пунктам ТЗ | протоколы испытаний, демо | проверка «на глаз» без тест-кейсов |
| 3. Внедрение | развёртывание в контуре заказчика, миграция | акт развёртывания | контуры/данные заказчика не готовы |
| 4. Опытная эксплуатация | стабильная работа за период, метрики | протокол ОЭ | бессрочная ОЭ без критериев завершения |
| 5. Итог | полный комплект, обучение, документация | итоговый акт приёмки | «докрутите ещё» вместо акта |
Спорные ситуации и что делать
Заказчик не подписывает акт и не даёт письменных замечаний. Отправьте уведомление о готовности и комплект результатов способом, фиксирующим дату (ЭДО/ЭТП), со ссылкой на срок приёмки из контракта. Молчание сверх срока — повод для претензии; далее — суд, который оценит, уклонялся ли заказчик от приёмки.
Замечания бесконечные и вне ТЗ. Требование то, чего нет в ТЗ, — вне предмета контракта. Письменно отделяйте: замечания по ТЗ (устраняем в срок) от новых требований (дополнительное соглашение за отдельную цену). Вежливо, но в письменной форме каждый раз.
Нашли дефект после подписания акта. Гарантийные обязательства: порядок и срок устранения — в контракте. Скрытый дефект — не основание «отменить» акт, но и поставщику выгодно чинить быстро: репутация в закупках дороже.
Заказчик не проводит экспертизу. Экспертиза — его обязанность (ст. 41), а не ваша. Напоминание письменно; затягивание проверки — то же уклонение от приёмки. Если подрядчик вообще исчез со стороны заказчика — разбор «Что делать, если подрядчик пропал».
Чек-лист поставщика перед передачей на приёмку
- Все пункты ТЗ закрыты и подтверждены: тест-кейсы пройдены, протоколы оформлены.
- Документация готова и передаётся комплектом (руководства, инструкции администратора).
- Уведомление о готовности отправлено способом с фиксацией даты.
- Ведомость замечаний ведётся с номерами и сроками устранения.
- Акт содержит перечень проверенного и состав передаваемого, а не только сумму.
- Гарантийные обязательства и их срок отражены в акте.
- Копии всего — в архив: они работают при спорах и в следующих закупках (подтверждение добросовестности).
Что мы предлагаем
Мы разрабатываем и сдаём ПО госзаказчикам годами и знаем, что приёмка начинается не в день демо, а в день написания ТЗ: правильные критерии приёмки в техзадании (статья «Как составить ТЗ на разработку ПО») избавляют от 90% споров. Нужен пакет приёмки — протоколы испытаний, ведомости, акты — под ваш контракт: напишите на sales@vyshka.cloud, подготовим за 1 рабочий день. Наши направления — каталог услуг, бюджеты реальных систем — кейс мобильного приложения и другие кейсы; частые вопросы — хаб вопросов.