Проверка проекта перед подачей

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

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

Предмет и рабочая версия проекта

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

Предмет экспертизы проектной документации включает оценку её соответствия установленным требованиям, заданию на проектирование и результатам инженерных изысканий; отдельные вопросы проверки сметной стоимости имеют собственные условия применения. Такая нормативная рамка следует из части 5 статьи 49 Градостроительного кодекса Российской Федерации. Поэтому предварительная проверка должна быть привязана к реальному составу будущей подачи, а не к абстрактному перечню возможных проектных документов.

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

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

Комплектность проектной документации

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

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

Если документа нет, важно установить его функцию. Отсутствующий расчёт, отсутствующий исходный документ и отсутствующая спецификация создают разные разрывы. В первом случае может не прослеживаться обоснование решения, во втором — основание принятого расчётного параметра, в третьем — связь между проектным решением и принятыми характеристиками оборудования или материалов. Простого указания «добавить недостающий документ» недостаточно: сначала определяют, какую связь он должен восстановить.

Объектом негосударственной экспертизы являются проектная документация и (или) результаты инженерных изысканий в предусмотренном законодательством предметном составе. Это предусмотрено пунктом 5 Положения об организации и проведении негосударственной экспертизы. Поэтому частичная внутренняя проверка отдельного файла не должна восприниматься как подтверждение готовности всего заявленного предмета.

Исходные данные и результаты инженерных изысканий

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

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

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

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

Расчётные обоснования и проектные решения

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

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

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

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

Спецификации и связанные проектные документы

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

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

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

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

Согласованность решений разных разделов

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

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

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

Удобно разделять выявленные ситуации на три группы:

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

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

Стабильный, изменяющийся и неполный комплект

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

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

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

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

Отдельный разбор того, когда такая предварительная работа особенно оправданна, приведён в материале «Когда полезна проверка проекта до экспертизы».

Перечень нерешённых вопросов и готовность к передаче

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

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

К моменту передачи желательно получить четыре состояния:

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

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

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