Проверка комплектности документации перед приемкой ИТ-проекта

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

Эта страница не про строительные разделы проектной документации, экспертизу или Постановление 87. Здесь речь о приемке ПО и ИТ-системы: требования, ТЗ или спецификация, техническое решение, ПМИ, протоколы испытаний, дефекты, эксплуатационные инструкции, код, версии, changelog и открытые вопросы.

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

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

Для приемки важно показать trace: каждое существенное требование должно иметь способ проверки и понятный статус. Это не обязательно тяжелая матрица трассировки; для небольшого проекта достаточно таблицы, где требование связано с экраном, API, отчетом, тест-кейсом, протоколом или известным отклонением.

• Требование: что должно работать и в каких границах.
• Критерий приемки: как понять, что результат достаточен.
• Проверка: тест, демонстрация, протокол, отчет или сценарий приемки.
• Статус: принято, принято с замечаниями, отклонено, перенесено в следующий этап.
• Отклонение: что осталось, кто владелец, какой срок и как это влияет на эксплуатацию.

ПМИ или тест-план фиксирует не весь процесс тестирования, а проверяемую часть приемки. В нем должны быть сценарии, входные данные, ожидаемый результат, окружение, ответственные и правила фиксации замечаний. Протокол испытаний показывает, что сценарии выполнены, а список дефектов объясняет, какие проблемы устранены, какие приняты с ограничениями и какие не входят в текущий объем.

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

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

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

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

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

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

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

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

• проверять оформление раньше смысла и актуальности документов;
• считать, что backlog автоматически заменяет ТЗ, критерии приемки и согласованные изменения;
• не связывать дефекты и отклонения с требованиями;
• передавать код без инструкции сборки, версии и зависимостей;
• принимать систему без эксплуатационного комплекта;
• смешивать строительную комплектность проектной документации с приемкой ИТ-результата;
• закрывать этап без реестра открытых вопросов и владельцев.

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