Что проверить перед оплатой финального этапа разработки

Финальный платёж за сайт или сервис — точка, после которой мотивация подрядчика объективно меняется. Деньги получены, проект закрыт, а любые доработки переходят в разряд отдельных задач и новых смет. Дело не в недобросовестности: так устроена экономика студий, где команда уже переключилась на следующий проект. Поэтому последние проценты работы — самые дорогие. На приёмке заказчик либо забирает результат в нужном ему виде, либо узнаёт, что часть обещанного «доделают потом».

Разберём, что проверять перед оплатой финального этапа, чтобы запуск не превратился в долгий спор.

Начните с договора и ТЗ, а не с сайта

Самый частый источник конфликтов — разные представления о том, что значит «готово». Перед приёмкой поднимите ТЗ, договор и переписку, где согласовывались изменения. Сверьте список функций: что входит в финальный этап, а что относится к следующей итерации.

Полезно заранее выписать критерии приёмки. Хорошо, если они сформулированы не как «сайт работает», а проверяемо: «каталог фильтруется по трём параметрам», «интеграция с CRM передаёт заявку с полями имя, телефон, источник». Если критериев нет — составьте их сейчас и согласуйте письменно. Это займёт час, но сэкономит недели споров.

Пройдите функциональность по сценариям

Не по страницам, а по пользовательским путям. Возьмите 5–7 типовых сценариев и пройдите каждый от начала до конца:

• первый визит: главная → каталог → карточка товара → заявка;
• поиск по сайту с опечаткой и запросом без результатов;
• регистрация, вход, восстановление пароля;
• повторная покупка или повторная заявка тем же клиентом;
• работа в личном кабинете с разными правами доступа.

Отдельно проверьте неприятные сценарии: что покажет сайт при пустой корзине, неверно заполненной форме, отменённом платеже. Именно здесь чаще всего всплывают недоработки, не видимые при демонстрации.

Техническая проверка

Кроссбраузерность и адаптив

Откройте проект в актуальных Chrome, Safari, Firefox и в мобильном Safari. Проверьте не только главную, но и внутренние страницы, формы, модальные окна. Отдельно — планшетную ширину, которую часто пропускают, верстая «под телефон и под десктоп».

Скорость и стабильность

Замерьте показатели через PageSpeed Insights и убедитесь, что заявленные в ТЗ ориентиры достигнуты. Проверьте поведение сайта при медленном соединении, что происходит при ошибке на сервере, есть ли страница 404 и настроены ли редиректы со старых адресов, если был переезд.

Базовое SEO и безопасность

Если в проекте были технические требования по SEO, проверьте корректные title и description, один h1 на страницу, человекопонятные URL, sitemap.xml, robots.txt без случайно закрытых разделов, настроенный SSL и принудительный переход на https. Микроразметка, канонические адреса и склейка зеркал — тоже пункты приёмки, а не задачи «когда-нибудь потом».

Формы, интеграции и аналитика

Это то, что чаще всего работает на тесте и молчит в бою. Проверьте:

• письма с сайта доходят и не падают в спам;
• заявки появляются в CRM или на почте с полным набором полей;
• платежи, если они есть, прогнаны в боевом режиме минимальной суммой, а не только в песочнице;
• цели и события в аналитике срабатывают, а не «в теории настроены»;
• уведомления приходят тем, кому должны, и не дублируются.

Уточните, где хранятся ключи и доступы, кто отвечает за их продление. Если интеграция опирается на сторонний сервис с платной подпиской, это стоит зафиксировать письменно.

Контент, админка и роли

Проверьте, что весь оговорённый контент загружен: тексты, изображения в нужных размерах, файлы для скачивания. Оцените админку глазами человека, который будет пользоваться ей ежедневно — редактора или менеджера. Можно ли добавить страницу, поменять баннер, опубликовать новость без разработчика?

Проверьте права ролей: редактор не должен иметь доступ к финансовым настройкам, менеджер — к правке кода. Если нужна инструкция или короткое обучение, лучше заложить их в финальный этап, а не запрашивать после оплаты.

Доступы, код и документация

Перед финальным платежом вы должны получить всё, чем будете владеть и управлять:

• доступ к регистратору домена и хостингу, оформленный на вас;
• доступы к CMS с административной ролью, к серверу, к базе данных;
• репозиторий с исходным кодом и правами на него;
• перечень использованных библиотек, платных тем и лицензий с указанием, на кого они оформлены;
• информацию о том, как настроены резервные копии;
• краткую документацию: структура проекта, внешние сервисы, переменные окружения.

Отдельный пункт — аккаунты сотрудников подрядчика внутри ваших систем. Их стоит передать вам или отключить, чтобы после завершения проекта доступ остался только у владельца.

Гарантия, акт и границы правок

В договоре должен быть прописан гарантийный срок и то, что в него входит. Обычно это исправление ошибок, а не новые функции, и это нормально — важно, чтобы формулировка была понятной. Уточните срок реакции на критические проблемы: сайт упал, не проходят заявки, сломался платёж.

Акт подписывайте только после того, как прошли чек-лист. Если часть пунктов закрыта не полностью, есть два пути: зафиксировать их как замечания с датой устранения или уменьшить сумму платежа. Оба варианта обсуждайте до подписания документов, а не после.

Короткий чек-лист приёмки

1. Все пункты ТЗ и согласованных правок закрыты.
2. Основные пользовательские сценарии пройдены без ошибок.
3. Сайт корректно работает в ключевых браузерах и на мобильных.
4. Скорость соответствует заявленным ориентирам.
5. Формы, интеграции, платежи и аналитика проверены в боевом режиме.
6. Контент загружен, админка понятна, роли настроены.
7. Доступы, код и документация переданы.
8. Гарантия и условия поддержки зафиксированы письменно.

Если недостатки всё-таки нашлись

Соберите их в один список, а не в поток сообщений. По каждому пункту: шаги воспроизведения, ожидаемое и фактическое поведение, скриншот или ссылка. Расставьте приоритеты — отдельно критичное, блокирующее запуск, и отдельно косметика.

Так подрядчик видит объём работы и не тратит время на уточнения, а вы получаете прозрачный статус. И главное: договоритесь о дате повторной приёмки. Финальная оплата — это не финал отношений, а точка, с которой начинается нормальная работа с поддержкой и развитием продукта.