Подтверждены цели и критерии результата
Готовность нельзя оценивать только по перечню реализованных функций. Сначала нужно вернуться к исходному управленческому решению: какую проблему должен был решить проект, какие процессы изменить и какой результат получить бизнес.
Критерий считается рабочим, если его можно проверить по фактам: показателю, сценарию, документу или принятому владельцем процесса результату. Формулировки вроде «система внедрена» или «основные функции работают» не дают основания для приёмки.
Выполнены договорные обязательства
Нужно сопоставить не статус задач, а согласованный объём поставки с фактическим результатом. В проверку входят функции, документация, лицензии, права на результаты, обучение, миграция данных и иные обязательства, влияющие на использование решения.
Если часть обязательств перенесена, у переноса должны быть зафиксированы владелец, срок, последствия и условия закрытия. Неопределённое обещание устранить замечания после приёмки переносит риск на заказчика.
Пройдены сквозные бизнес-сценарии
Демонстрация отдельных экранов не подтверждает готовность процесса. Проверяются сквозные сценарии: от входного события до результата, включая исключения, возвраты, корректировки, права доступа и управленческий контроль.
Сценарии должны выполняться на данных и в условиях, близких к реальной эксплуатации. Иначе тест подтверждает лишь техническую возможность, но не способность решения поддерживать работу бизнеса.
Данные и интеграции готовы
Миграция и обмены часто остаются за рамками красивой демонстрации. До приёмки нужно проверить полноту, качество и происхождение данных, правила сверки, обработку ошибок и ответственность за расхождения.
Для каждой критичной интеграции фиксируются доступность, производительность, мониторинг, повторная обработка и действия при сбое. Формальный факт подключения ещё не означает эксплуатационную готовность.
Определена эксплуатационная ответственность
После запуска должен существовать рабочий контур поддержки: владельцы системы и процесса, уровни сервиса, порядок регистрации инцидентов, резервное копирование, восстановление, мониторинг и управление изменениями.
Если команда проекта уходит, а эксплуатационная модель не создана, организация принимает не решение, а зависимость от отдельных участников и поставщика.
Критичные риски имеют владельцев и сроки
Наличие замечаний само по себе не блокирует приёмку. Важны их влияние и управляемость. Для каждого критичного риска нужны подтверждённое последствие, владелец, срок, способ контроля и условие, при котором решение может эксплуатироваться.
Риски безопасности, архитектуры и производительности оцениваются не изолированно, а через их влияние на обязательства, непрерывность процесса и бизнес-результат.
Решение о приёмке подтверждается доказательствами
Итоговая позиция должна разделять подтверждённые факты, заявления участников и вопросы, которые пока нельзя проверить. Это защищает руководство от решения, основанного на уверенности докладчика или объёме презентации.
На выходе нужны понятные варианты: принять результат, принять с условиями, продлить этап проверки, перезапустить часть работ или остановить проект. Для каждого варианта фиксируются последствия по срокам, затратам, рискам и ответственности.
Управленческий вывод
Принимать нужно доказанный результат, а не обещание завершить его позже
Если хотя бы один из семи контуров нельзя подтвердить, это не всегда означает остановку. Но неопределённость должна быть названа, оценена и включена в условия решения. Независимый аудит помогает восстановить факты, обязательства и реальные варианты до подписания приёмки.
Независимый аудит ИТ-проекта