Чек-лист приёмки: как проверить работу от подрядчика

Что такое приёмка разработки и зачем она заказчику

Приёмка — момент, когда ответственность за результат переходит от подрядчика к заказчику. После подписания акта претензии к явным недостаткам предъявить сложнее.

Гражданский кодекс это закрепляет. По статье 720 ГК РФ заказчик обязан осмотреть и принять работу, а недостатки, которые можно было увидеть при обычной проверке, после приёмки без оговорок уже не принимаются.

Поэтому чек-лист нужен до подписи, а не после.

Приёмка ПО: артефакты, которые должен передать подрядчик

• Исходный код в репозитории заказчика (GitHub, GitLab, Bitbucket), а не в архиве на почте.
• Инструкция по развёртыванию: как поднять проект с нуля на чистом сервере.
• Техническая документация: архитектура, интеграции, переменные окружения.
• Дамп базы данных и описание миграций.
• Макеты в Figma и дизайн-система, если дизайн делал подрядчик.
• Список сторонних сервисов и библиотек с лицензиями.

Доступы

Все доступы должны быть оформлены на заказчика, а не на подрядчика или его сотрудника. Это домен и DNS, хостинг или облако, админка CMS, почта для уведомлений, Яндекс Метрика, платёжный шлюз, SMS-шлюз.

Я видел проекты, где домен годами числился за бывшим фрилансером. Выкупать его обратно — долго и дорого.

Приёмка сайта без технических навыков

Проверить код самому нельзя, но можно проверить поведение. Для этого и нужны смоук-тесты — короткие проверки главных сценариев, которые занимают 30–60 минут.

• Открыть сайт с телефона и компьютера в Chrome, Safari и Яндекс Браузере.
• Пройти главный сценарий: регистрация, поиск, корзина, оплата тестовой картой.
• Отправить каждую форму и проверить, что заявка дошла в CRM или на почту.
• Проверить скорость страниц в PageSpeed Insights.
• Убедиться, что работают HTTPS, редиректы и страница 404.
• Попросить подрядчика показать восстановление из бэкапа.

Виды проверок при приёмке

У приёмки ПО есть устоявшаяся терминология. В госпроектах её описывает ГОСТ 34.603-92 «Виды испытаний автоматизированных систем», в коммерческих — договор и техническое задание.

Лицензии и юридические детали

Отдельный пункт — права. По статье 1296 ГК РФ исключительное право на программу, созданную по заказу, принадлежит заказчику, если договор не предусматривает иное. Но рассчитывать на норму по умолчанию рискованно: договор бывает подрядом на доработку, а не на создание. Надёжнее прямо прописать, что права на код переходят заказчику.

Платные компоненты — лицензия 1С-Битрикс, шрифты, фотобанки, плагины — должны быть куплены на юрлицо заказчика. Иначе через год продление окажется на чужом аккаунте.

Как организовать приёмку по шагам

Приёмку я планирую заранее, ещё на этапе договора. Тогда у обеих сторон одинаковое понимание, что считается готовым.

• Зафиксировать в договоре критерии готовности и срок на проверку, обычно 5–10 рабочих дней.
• За неделю до сдачи получить от подрядчика список передаваемых артефактов.
• Провести смоук-тесты и записать найденные ошибки в одну таблицу с приоритетами.
• Разделить замечания на блокирующие и косметические: косметика не повод не подписывать акт.
• Подписать акт с перечнем замечаний и сроками их исправления.
• Сменить все пароли и проверить, что доступы работают у вас, а не только у подрядчика.

Если подрядчик спорит с замечаниями

Спор почти всегда возникает из-за размытого ТЗ. Если в задании было «удобный поиск», доказать недостаток трудно. Если было «поиск находит товар по артикулу и названию с опечаткой в одну букву» — легко.

Мотивированный отказ от подписания акта нужно отправить письменно и в срок, указанный в договоре. Молчание заказчика часто считается согласием: многие договоры прямо пишут, что акт считается подписанным, если возражений нет в течение 5 дней.

Поэтому сроки проверки я ставлю себе в календарь в день сдачи.

Типичные ошибки при приёмке

• Подписать акт на демо-стенде, а не на боевом сервере.
• Принять работу без тестовых данных и реальной оплаты на небольшую сумму.
• Не зафиксировать гарантийный срок на исправление ошибок, обычно это 1–3 месяца.
• Оставить пароли в переписке и не сменить их после передачи проекта.

Что делать после подписания акта

Подписанный акт — не конец работы с проектом. Первые 2–4 недели после запуска всплывают ошибки, которые не поймал ни один тест: реальные пользователи ведут себя иначе, чем тестировщики.

Я договариваюсь о гарантийном периоде и о том, как подрядчик реагирует на критичные сбои: за сколько часов, по какому каналу, кто дежурит в выходные. Это фиксируется в SLA или в приложении к договору.

Полезно и самому подготовиться. Настроить мониторинг доступности сайта, оповещения об ошибках оплаты и ежедневные бэкапы с проверкой восстановления раз в месяц. Тогда проблема будет замечена за минуты, а не после жалобы клиента.