Как принимать работу у подрядчика — чек-лист приемки

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

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

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

Что именно проверять

1. Сквозные сценарии на реальных данных. Не отдельные кнопки, а путь целиком: принять заявку, назначить, выполнить, закрыть, выставить документ. И на своих справочниках, а не на тестовых «ООО Ромашка».
2. Роли и права. Зайти под каждой ролью и попробовать сделать то, чего нельзя. Особенно — открыть чужую запись, подставив ее номер в адресе. Это самая частая дыра.
3. Интеграции по сверке. Не «данные поехали», а сверочный отчет, где сходятся количество и суммы с обеих сторон.
4. Объем. Загрузить реальный объем данных и открыть тяжелые экраны. Система, быстрая на сотне записей, может умереть на пятидесяти тысячах.
5. Поведение при сбоях. Выключить интеграцию, оборвать связь, отправить кривой файл. Правильное поведение — понятное сообщение и сохранность данных, а не белый экран.
6. Передача. Код в вашем репозитории, доступы к серверам у вас, резервное копирование настроено и проверено восстановлением, есть краткая инструкция для администратора.

Кто должен принимать

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

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

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

• Одно замечание — одна запись. Письмо с двадцатью пунктами в абзаце превращается в спор о том, что было исправлено.
• С шагами воспроизведения. Что сделали, что ожидали, что получилось. Без этого половина замечаний возвращается с ответом «у меня работает».
• С разделением на типы. Ошибка — не работает как описано. Доработка — работает, но хочется иначе. Первое исправляется в рамках этапа, второе оценивается отдельно. Смешивать их — прямой путь к конфликту.
• Со сроком. По каждому замечанию — когда будет исправлено. Список без сроков живет вечно.

Опытная эксплуатация

Между приемкой и полноценной работой полезен период, когда система уже в бою, но под наблюдением.

Обычно это две-четыре недели. Старый способ работы еще доступен, исполнитель на связи и реагирует быстро, замечания собираются в одном месте. Это не признак недоверия, а нормальная практика: часть проблем видна только на потоке.

Заканчивается период формально — актом или письмом, после которого начинается обычная поддержка со своими сроками реакции.

Что передается вместе с системой

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

• Код в вашем репозитории. Не архивом на диске, а в git с историей изменений.
• Доступы к серверам и сервисам. На ваши учетные записи, а не на почту подрядчика.
• Инструкция по развертыванию. Как поднять систему с нуля. Проверяется единственным способом — поднять по ней на чистом сервере.
• Резервное копирование. Настроено, проверено восстановлением, понятно, где лежат копии и как долго хранятся.
• Краткое описание архитектуры. Из чего состоит, что с чем связано, где что лежит. Две-три страницы, но они экономят недели следующей команде.
• Инструкция для пользователей. Короткая, по ролям, лучше со скриншотами. Иначе обучение придется проводить лично и каждому.

Гарантия и поддержка

Это разные вещи, и их стоит развести в договоре.

Гарантия — исправление того, что работает не так, как описано в ТЗ. Обычно три-шесть месяцев после приемки, бесплатно. Сюда не входят новые пожелания.

Поддержка — платная услуга: обновления, консультации, мониторинг, реакция на инциденты в оговоренные сроки. Начинается после гарантийного периода или параллельно с ним.

Граница между «ошибка» и «доработка» должна быть описана до запуска. Иначе каждое обращение будет начинаться со спора о том, кто за это платит.

Где здесь ИИ

Приемка — та часть, где инструменты помогают заказчику, а не только исполнителю.

Генерация проверок по ТЗ. По описанию требований модель составляет список сценариев для проверки, включая неудобные случаи, о которых обычно не вспоминают. Это дает заказчику готовый чек-лист без привлечения тестировщика.

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

Наполнение тестовыми данными. Реалистичный объем с пограничными значениями создается быстро, а именно на объеме проявляется половина проблем.

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

Частые вопросы

Сколько времени закладывать на приемку

Для системы на один процесс — неделя проверки плюс две-три недели опытной эксплуатации. Если закладывают два дня, значит, приемки не планировалось.

Что делать, если замечаний очень много

Разделить на блокирующие и остальные. Если блокирующих нет, систему можно запускать в опытную эксплуатацию, а остальное исправлять по ходу. Держать запуск из-за некритичных замечаний обычно дороже, чем запустить.

Можно ли не подписывать акт

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

Дальше по теме