Как принять работу разработчика: чек-лист перед оплатой

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

Начните с критериев готовности

Для каждой задачи заранее запишите: кто выполняет действие, что он видит, какие данные создаются и что считается ошибкой. Хороший критерий можно проверить без автора задачи.

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

Порядок проверки

Что проверить в результате

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

Как фиксировать замечания

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

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

Когда нужна независимая проверка

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

Как фрилансеру подготовить результат к приёмке

Приёмка начинается до того, как вы отправили ссылку на готовую страницу. Сверьте результат с задачей, удалите тестовые записи, проверьте чистый аккаунт и подготовьте список того, что изменилось. Если часть требований отложена, напишите это явно, чтобы у клиента не было ложного ожидания.

Пакет сдачи

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

Фрилансеру выгодно показывать не только результат, но и способ его проверки. Это уменьшает количество субъективных правок и позволяет быстрее закрыть этап.

Как считать дополнительные изменения

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

Окно проверки и оплата

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

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

После приёмки сохраните финальную версию и дату передачи. Это помогает отличить гарантийное исправление от новой доработки через несколько недель.

Финальный вопрос перед оплатой

Спросите себя: сможет ли другой человек повторить проверку без объяснений автора? Если нет, не хватает критерия, тестовых данных или инструкции. Добавьте их в пакет сдачи и только после этого закрывайте этап.

Такая дисциплина полезна и клиенту, и фрилансеру. Клиент получает воспроизводимый результат, а исполнитель — ясную границу между исправлением своей работы и новой задачей.