Акт приёмки — документ, после которого работа считается выполненной, а споры о качестве становятся сложнее. Поэтому принимать продукт нужно по плану, составленному заранее, на реальных данных и с участием тех, кто будет им пользоваться. Этот урок даёт чек-лист и правила: как проверять, как записывать замечания и когда принимать частично.
После урока вы сможете
- Составить план приёмки по критериям из брифа
- Проверить роли и права, данные, резервные копии, документацию и доступы
- Решить, принимать работу полностью, частично или отказаться, и записать замечания
Содержание
Подготовьте приёмку до того, как получите продукт
Хорошая приёмка начинается за неделю-две до сдачи. Вам нужно:
- Критерии. Они уже есть в брифе (урок «Как описать задачу»). Превратите каждый в тест: что сделать, что должно получиться.
- Окружение. Приёмка проходит на тестовой версии, отдельной от рабочей, с данными, близкими к настоящим. Выясните, как их получить, не раскрывая лишнего: персональные данные клиентов лучше заменить или обезличить.
- Люди. Привлеките представителя пользователей и того, кто отвечает за данные. Руководитель, который «просто посмотрел», приёмку не заменит.
- Срок. Закрепите в договоре, сколько дней у вас на проверку и что считается принятием по умолчанию. Если срок короткий, а продукт большой, согласуйте приёмку по частям.
Чек-лист приёмки
Пройдите по блокам и отметьте каждый пункт: проверено, есть замечание, не проверено.
Функции
- Что проверить
- Каждый критерий из брифа выполнен; главные сценарии пройдены от начала до результата; проверены и неудобные случаи (пустое поле, неверный формат, отмена действия)
Роли и права
- Что проверить
- Каждая роль входит под своей учётной записью и видит только положенное; сотрудник не открывает чужие данные, в том числе по прямой ссылке; уволенный сотрудник теряет доступ
Данные
- Что проверить
- Перенесённые данные сверены выборочно с источником; количество записей совпадает; нет дублей и потерянных связей; отчёты дают те же цифры, что и ваши расчёты
Интеграции
- Что проверить
- Обмен с внешними системами идёт в обе стороны; что происходит при сбое внешнего сервиса; ошибки видны, а не теряются молча
Резервные копии
- Что проверить
- Копии делаются автоматически, известно расписание и место хранения; восстановление из копии хотя бы раз проверено, а не только создание
Окружения и запуск
- Что проверить
- Рабочая и тестовая версии разделены; известно, как выпускается обновление и как вернуться к прошлой версии
Документация
- Что проверить
- Есть инструкция пользователя, инструкция администратора, описание того, как развернуть продукт заново, и перечень интеграций
Доступы
- Что проверить
- Передан список аккаунтов, ключей и сервисов; репозиторий, домен и облако оформлены на вас (подробнее в уроке «Код, доступы, данные»)
Безопасность
- Что проверить
- Нет тестовых учётных записей с простыми паролями; у администраторов включена двухфакторная проверка, если сервис её поддерживает; секретные ключи не лежат открытым текстом в переписке
Часть пунктов (резервные копии, развёртывание, репозиторий) можно проверить без знания кода — как это сделать за один созвон с исполнителем, описано в статье «Как проверить качество продукта и работу подрядчика». Если подозрения касаются качества кода или безопасности, привлекайте независимого специалиста до подписания акта, а не после.
Как записывать замечания
Замечание, высказанное устно, через неделю не существует. Записывайте каждое в общий список (таблица или трекер) по схеме: что сделал, что ожидал, что получил, где это видно (экран, шаг, пример данных). Присваивайте приоритет:
- Блокирующее. Главный сценарий не работает, данные теряются, нарушены права доступа. Без исправления принимать нельзя.
- Существенное. Функция работает, но с ошибкой или неудобством, которое мешает ежедневной работе. Исправление нужно в согласованный срок.
- Незначительное. Опечатки, оформление, мелкие неудобства. Можно исправить после приёмки, но запись остаётся в списке.
Отделяйте замечания к выполненному от новых пожеланий. Первое исправляется по договору, второе оформляется как отдельная задача. Если граница размыта, обращайтесь к критериям из брифа: они единственная точка опоры.
Когда принимать частично
Полная приёмка не всегда возможна или нужна. Частичное принятие оправдано, когда:
- основная часть работает и приносит пользу, а несколько функций требуют доработки;
- можно запустить продукт в работу для части пользователей, а остальные вопросы закрыть отдельным этапом;
- проект разбит на этапы, и каждый из них имеет самостоятельный результат.
В акте частичной приёмки перечислите, что принято, что не принято, список замечаний с приоритетами и срок исправления. Не подписывайте акт «без замечаний» с намерением позже договориться устно: подписанный акт читается буквально. Как удерживать часть оплаты до исправления и что считается акцептом по умолчанию, зависит от договора и закона, поэтому перед подписанием покажите акт юристу.
Рабочий лист: план приёмки
Заполните лист до сдачи и согласуйте с исполнителем. Ответы сохраняются в вашем браузере; готовый план — одна-две страницы.
Рабочий лист
План приёмки
Заполнено 0 из 8
Для каждого критерия: что сделать и что должно получиться
Где идёт приёмка, какие данные, как обезличены персональные
Представитель пользователей, ответственный за данные; кто ведёт список замечаний
Сколько дней и что считается принятием по умолчанию
Под какими учётными записями проверяете и что должно быть закрыто
Что сверяем с источником, как проверяем восстановление из копии
Инструкции, описание развёртывания, список аккаунтов и ключей
Принимаем полностью, частично или не принимаем — и по каким условиям
Ответы хранятся только в вашем браузере — на нашем сервере их нет. Скачайте файл, чтобы не потерять.
Чек-лист: перед подписанием акта
Девять блоков проверены
Выполнено 0 из 9
Отметки хранятся только в вашем браузере.
Проверьте себя
Самопроверка: приёмка
0 из 5
Ответы хранятся только в вашем браузере.
Что дальше
Приёмка закрывает работу, а вопрос о том, чем вы владеете после неё, надо решать заранее. Следующий урок: «Код, доступы, данные: что закрепить заранее». О том, что происходит после подписания, читайте в статье «Что происходит после запуска». Если нужен независимый взгляд на продукт до подписания акта, описание такой проверки есть на странице аудита; как мы ведём проекты сами — на странице заказной разработки ПО.