Коротко: критерии приёмки нужно согласовать до начала работы. На сдаче отделяйте баги от новых функций, фиксируйте замечания воспроизводимо и проверяйте передачу исходников и доступов.
Если критерии готовности появляются только в день сдачи, спор почти неизбежен. Приёмка начинается ещё на этапе постановки задачи: стороны должны заранее понимать, что именно будет проверяться.
Базовый чек-лист приёмки
- Все функции из согласованного объёма реализованы.
- Критичные сценарии проверены.
- Мобильные состояния соответствуют требованиям.
- Формы и интеграции передают данные.
- Ошибки обрабатываются предсказуемо.
- Переданы исходники и доступы.
- Нет тестовых паролей в публичном доступе.
Баг, правка и новая функция — разные вещи
ТипЧто этоКак обрабатываетсяБагРезультат не соответствует требованиюИсправляется в рамках работыПравкаКорректировка внутри согласованной концепцииЗависит от числа итерацийНовая функцияМеняет исходный объёмОценивается отдельноКак правильно формулировать замечания
Укажите место проблемы, шаги воспроизведения, фактический результат и ожидаемый результат по ТЗ. Для визуального дефекта приложите скриншот, для динамической ошибки — короткое видео или последовательность действий.
Приёмка дизайна
- Все экраны и состояния.
- Адаптивы.
- Переполнение текстов.
- Единообразие компонентов.
- Исходный файл и ресурсы.
- Handoff с разработчиком.
Приёмка разработки
- Основные пользовательские сценарии.
- Роли и права.
- Пустые и ошибочные состояния.
- Аналитика и логи по договорённости.
- Репозиторий и инструкции запуска.
- Доступы к инфраструктуре.
Когда закрывать финальный этап
Финальный платёж логично привязать к прохождению согласованной приёмки и передаче результатов. Мелкие некритичные замечания можно вынести в отдельный список со сроком исправления.
Почему приёмка должна быть воспроизводимой
Замечание полезно исполнителю только тогда, когда проблему можно повторить. Для сайта укажите URL, устройство, браузер и шаги. Для дизайна — конкретный экран и компонент. Для аналитической работы — исходные данные и ожидаемую формулу или критерий.
Такой формат ускоряет исправление и уменьшает спор о субъективных ощущениях. Он особенно важен, когда над проектом работает несколько людей и замечание передаётся от заказчика через менеджера к исполнителю.
- Где возникла проблема.
- Что сделал пользователь.
- Что произошло фактически.
- Что ожидалось по требованиям.
- Скриншот или видео при необходимости.
Что проверить после передачи проекта
После получения исходников попробуйте открыть их в своём аккаунте и убедитесь, что критичные ресурсы действительно принадлежат заказчику. Для разработки полезно проверить запуск по инструкции на чистом окружении или хотя бы доступ нового специалиста к репозиторию.
Финальная приёмка — также момент для фиксации известных ограничений. Если есть некритичные технические долги или запланированные улучшения, лучше записать их сразу, чтобы следующая команда не искала контекст заново.
Практический чек-лист
- Сверить результат с ТЗ.
- Прогнать критичные сценарии.
- Отделить баги от новых требований.
- Проверить исходники и доступы.
- Зафиксировать оставшиеся замечания.
- Только после этого закрыть финальный этап.
Частые вопросы
Что считается багом?
Поведение, которое не соответствует согласованному требованию или сценарию.
Сколько правок должен сделать фрилансер?
Количество итераций лучше согласовать заранее; исправление бага и изменение решения заказчиком — разные вещи.
Можно ли принимать частями?
Да, для крупных проектов поэтапная приёмка предпочтительна.
Что получить после разработки?
Репозиторий/исходники, нужные доступы, инструкции и документацию, предусмотренную договорённостями.
Что делать дальше
Опишите задачу, срок, бюджет и критерии готовности. Сравните несколько релевантных предложений и выберите исполнителя по опыту, процессу и качеству коммуникации, а не только по цене.
Naimio помогает заказчикам находить профильных специалистов под конкретные задачи, а фрилансерам — получать релевантные заказы.