Фраза «не хватает исходных данных» редко помогает проектировщику действовать. Один материал действительно не передан, другой получен в старой редакции, третий есть в комплекте, но команда ещё не проверила, подходит ли он для нужного решения. Эта статья — о контроле состояния каждого исходного материала при работе с уже полученным заданием на проектирование. Задача инженера — собрать проверяемую запись и адресно запросить недостающее; ГИП решает, какие сведения нужны для данного объёма и когда вопрос можно закрыть. Общий порядок входного контроля задания разобран отдельно.
Учитывать материал, а не только замечание
Начните с версии задания и перечня документов, на которые оно ссылается. Для каждого потенциального исходного материала зафиксируйте, что фактически поступило команде: файл, редакция, дата передачи и источник. Статусы «назван в задании», «файл получен» и «годится для рассматриваемого решения» не равнозначны. Если приложению присвоен номер, но его нет в полученной папке, сначала проверьте журнал передачи и переписку. Если файл есть, сравните его редакцию с заданием. Если сведений в задании нет, проверьте, требуются ли они именно для текущего объёма работ; не копируйте в запрос универсальный перечень.
Следующий столбец учёта — проектное решение. Запись «нужен план» слишком широка. Запись «нужна согласованная планировка существующего этажа, чтобы определить границу изменения помещений» объясняет, почему команда открыла вопрос. Это рабочая методика, а не установленная нормативом форма: состав данных зависит от объекта, договора и задачи.
Таблица контроля исходных материалов
Полностью вымышленный пример. Условная команда получила задание на изменение планировки помещений «Объекта Г». Номера пунктов, обозначения редакций и факты ниже придуманы для демонстрации учёта; это не клиентский документ. В задании сказано, что помещения после обмеров менялись. Команда получила прежний обмерный план, но не нашла подтверждённую схему текущей планировки. Проектировщик ещё не делает вывода, что сведений нет у заказчика вообще.
На узком экране строки таблицы показаны вертикально; все поля сохранены.
| Наименование данных | Ссылка на задание или приложение | Полученная редакция / статус получения | Для какого проектного решения нужны сведения | Обнаруженная неопределённость | Следующее действие | Ответственный | Статус закрытия |
|---|---|---|---|---|---|---|---|
| Обмерный план этажа | П. 3.2, приложение 1 | Получена условная редакция 1; п. 3.5 упоминает более поздние изменения | Уточнить фактические границы помещений, затронутых заданием | Не подтверждено, отражает ли план текущее состояние | Сверить журнал передачи; запросить актуальную редакцию или письменное подтверждение применимости полученной | Инженер-проектировщик | Открыто: ожидается ответ |
| Схема изменений планировки после обмеров | П. 3.5 | В полученном комплекте не обнаружена; обозначение редакции неизвестно | Сопоставить новое задание с фактической планировкой | Неясно, какие изменения уже выполнены и каким документом они зафиксированы | Уточнить, существует ли схема; при её отсутствии согласовать с ГИПом способ получения исходных сведений | ГИП / технический заказчик | Открыто: требуется решение |
| Перечень помещений, входящих в работу | П. 2.1 и таблица приложения 2 | Получена условная редакция 2; инженер сверил с текущим заданием | Определить границы выдачи по помещениям | Расхождения при сверке не обнаружены | Указать проверенную редакцию в рабочем реестре; повторно открыть при изменении задания | Инженер-проектировщик | Закрыто после сверки ГИПом |
Эта таблица — редакционный инструмент команды, а не форма, отдельный DOCX/XLSX-экспорт или автоматически заполненный реестр Сокола. В реальной работе можно добавить дату запроса и ссылку на ответ; сохраняйте связь строки с конкретной редакцией. «Не применимо» тоже допустимый итог, но его определяет специалист, а не отсутствие файла в папке.
Из строки учёта — в конкретный запрос
Для первой открытой строки вопрос адресован не «всем недостающим ИРД», а редакции плана: «В переданном комплекте имеется редакция 1 обмерного плана, тогда как п. 3.5 задания указывает на последующие изменения. Просим сообщить, какая редакция отражает состояние, принятое для проектирования, и передать её либо подтвердить применимость редакции 1». Для второй строки сначала полезно выяснить, существует ли схема изменений; требовать конкретный документ как уже существующий было бы предположением. ГИП проверяет оба вопроса по журналу передачи, договору и фактическому объёму до отправки.
Подробный реестр замечаний и структура письма нужны уже на следующем шаге, когда команда решила направить согласованные вопросы заказчику. Здесь главная работа — учёт источника и состояния ответа, а не оформление письма.
Когда вопрос действительно закрыт
Статус «получен ответ» не равен «исходные данные приняты». Для закрытия строки укажите, что поступило, в какой редакции, к какому решению относится и кто сверил это с заданием. Если ответ только обещает будущий документ, строка остаётся открытой с новым ожидаемым действием. Если редакция изменилась, проверьте связанные строки: новый план может отменить прежний вывод о составе помещений. Если сведения признаны неприменимыми, запишите основание решения ГИПа. Так реестр показывает состояние работы, а не только историю переписки.
Что помогает подготовить Сокол
Сокол анализирует одно готовое задание в PDF или DOCX: извлекает указанные сведения, предварительно классифицирует задачу, сопоставляет её с условно применимыми пунктами чек-листа и формирует черновик замечаний. В штатном сценарии собираются паспорт объекта, отчёт-обоснование и проект письма заказчику в редактируемых DOCX. Сервис может обратить внимание на ссылку на приложение или неясное исходное условие, но не сверяет автоматически журнал передачи, редакции всех внешних файлов и статусы строк приведённой таблицы. Обнаружение конкретного пробела не гарантировано; фактическое наличие каждого DOCX в выдаче нужно проверить.
Инженер ведёт таблицу и сверяет комплект, ГИП подтверждает применимость сведений и закрытие вопросов.