Замечание полезно только тогда, когда по нему можно принять решение. «Нет исходных данных» оставляет заказчика гадать, каких именно сведений не хватает. «В п. 4.2 указано подключение к существующей сети, но в полученном комплекте нет названных в п. 9 исходных нагрузок; просим передать согласованные нагрузки либо указать, кто и когда их определяет» — уже рабочий вопрос. Его можно проверить по документу, назначить ответственного и закрыть после ответа.
Это руководство — для ГИПа, проектировщика и технического заказчика, которые рассматривают уже подготовленное задание на проектирование. По статье 759 ГК РФ задание и другие исходные данные передаются в рамках договора проектных и изыскательских работ. Статья не задаёт универсальную форму реестра замечаний или письма: приведённые ниже поля и примеры — рабочая методика, а не обязательный бланк.
Что делает замечание проверяемым
Начните с точной опоры: пункт, таблица, лист или приложение задания. Если документа нет, укажите, откуда известно о его существовании: например, п. 9 перечисляет приложение, но в переданном комплекте оно не обнаружено. Затем запишите наблюдение без обвинения, возможное влияние на проектирование и одно решение, которое нужно от заказчика. Не подменяйте вопрос категоричным нормативным выводом, если применимость требования ещё не установлена.
Четыре типа записей
Удобно различать четыре типа записей:
- Пробел: данных для конкретного решения в полученном материале не найдено.
- Противоречие: два пункта задания описывают разные виды работ, стадии или границы.
- Неясный объём: формулировка допускает несколько вариантов результата или ответственности.
- Гипотеза для проверки ГИПом: классификация объекта, применимость процедуры или нормативной ссылки пока не подтверждена.
Последний тип нельзя автоматически превращать в письмо с требованием «исправить нарушение». Иногда правильный результат анализа — снять замечание после проверки специалистом.
Демонстрационный реестр: учебный «Объект А»
Все сведения в таблице полностью вымышлены. «Объект А» — условный производственный корпус; номера пунктов и тексты созданы для объяснения структуры, не взяты из реального клиентского ТЗ. Это пример рабочего реестра, а не точный экспорт Сокола.
| № и тип | Где искать в учебном задании | Наблюдение и возможное влияние | Вопрос или действие | Статус проверки |
|---|---|---|---|---|
| 01 · противоречие | П. 2.1: «реконструкция корпуса»; п. 3.4: «новое строительство корпуса» | Разный вид работ может изменить предмет проектирования и исходные условия | «Просим указать согласованный вид работ и утвердить единый текст пунктов 2.1 и 3.4» | ГИП сверяет предмет договора и сведения об объекте; не объявлять вид работ автоматически |
| 02 · пробел | П. 4.2: подключение к существующей сети; п. 9: ссылка на приложение «Нагрузки» | Приложение упомянуто, но в учебном полученном комплекте отсутствует; нельзя принять исходные величины | «Просим передать согласованные нагрузки и сведения о точке подключения либо сообщить порядок их получения» | Проверить, не передано ли приложение отдельным каналом |
| 03 · противоречие | П. 5.1: «разработать ПД и РД»; п. 8.3: «результат — только РД» | Не определён согласованный состав выдачи | «Просим уточнить состав документации и привести пункты 5.1 и 8.3 к одной редакции» | Сверить с договором; решение за заказчиком и ГИПом |
| 04 · гипотеза | П. 2.6: «объект относится к ОПО» без приложенных характеризующих сведений | Формулировка может требовать дополнительных исходных данных; по одному тексту нельзя установить официальный статус объекта | «Просим указать, на каких сведениях основано отнесение к ОПО, и передать имеющиеся подтверждающие материалы» | ГИП/профильный специалист проверяет применимость; не писать «класс установлен» |
Демонстрационная таблица показывает логику формулировок, но для работы с версиями задания нужны поля о ходе рассмотрения. Они есть в пустом шаблоне ниже; при необходимости добавьте дату запроса и срок ответа по договору. Не нужно перегружать внешнее письмо всеми внутренними полями: заказчику важны понятный вопрос и материал, который следует предоставить или согласовать.
Пустой шаблон для собственного реестра
Это редакционный шаблон для ручной работы команды, а не форма или экспорт из Сокола. Сервис сейчас не выдаёт отдельный DOCX/XLSX реестра замечаний. Сделайте отдельную строку на каждый проверяемый вопрос. В «источнике» укажите редакцию и пункт задания или приложение; в «наблюдении» — тип записи и обнаруженный факт; во «влиянии» — какое решение остаётся неопределённым. Поле «вопрос заказчику» должно вести к конкретному ответу или материалу. Назначьте ответственного внутри команды. В «статусе» различайте «новое», «проверяется ГИПом», «направлено заказчику», «получен ответ» и «закрыто». Зафиксируйте содержание ответа со ссылкой на документ; ответ заказчика не заменяет решение ГИПа.
| Источник | Наблюдение | Влияние на проектирование | Вопрос заказчику | Ответственный | Статус | Ответ заказчика | Решение ГИПа |
|---|---|---|---|---|---|---|---|
Формулировку «противоречие» используйте, когда сопоставлены два конкретных положения. Если материала нет в полученном комплекте, это нехватка доступных данных, а не доказательство его отсутствия у заказчика. Предположение о статусе объекта или применимости нормы оставляйте гипотезой до предметной проверки.
Как расставить приоритеты и сгруппировать вопросы
Сначала выделите неопределённости, без которых нельзя согласовать предмет или исходные предпосылки работ; затем вопросы, влияющие на отдельные разделы; затем редакционные уточнения. Это профессиональный порядок обработки, не установленная законом шкала тяжести. Запись «высокий приоритет» должна иметь причину: например, нельзя определить объём договора или принятое решение зависит от неуказанной нагрузки.
Группировать удобно по действию заказчика: утвердить вариант формулировки, передать исходные сведения, подтвердить применимость, уточнить состав выдачи. Внутри группы сохраняйте ссылку на пункт. Не соединяйте десять разных пробелов в одну фразу «предоставить полный комплект ИРД» — это затруднит ответ и последующую проверку.
Что оставить для внутреннего ревью
Отдельно держите вопросы, где нужна проверка нормы, редакции документа или квалификации объекта. ГИП решает, превратить ли такую запись в запрос заказчику, оставить во внутренней работе либо снять. Ссылка на норматив в машинном черновике ещё не подтверждает её актуальность и применение к конкретному объекту.
Образец письма заказчику
Ниже полностью вымышленный демонстрационный текст для «Объекта А». Он не является действующим письмом Сокола, обязательной формой или перепиской с реальным заказчиком. Номера пунктов условны; перед отправкой ГИП заменяет их на проверенные ссылки и согласует письмо внутри организации.
Тема: Уточнение задания на проектирование объекта «А»
Адресат: техническому заказчику
Уважаемые коллеги!
При рассмотрении переданного задания на проектирование объекта «А» выявлены вопросы, ответы на которые нужны для согласования объёма работ и исходных данных. Просим уточнить следующее.
- В п. 2.1 указан вид работ «реконструкция», в п. 3.4 — «новое строительство». Просим сообщить принятый вид работ и направить согласованную редакцию этих пунктов.
- В п. 4.2 предусмотрено подключение к существующей сети, а п. 9 ссылается на приложение «Нагрузки». В переданном нам комплекте приложение не обнаружено. Просим направить согласованные нагрузки и сведения о точке подключения либо уточнить порядок и срок их получения.
- П. 5.1 предусматривает ПД и РД, п. 8.3 называет результатом только РД. Просим уточнить состав передаваемой документации и согласовать единую редакцию задания.
После получения ответов сверим уточнения с действующей редакцией задания и согласуем дальнейшую работу по открытым вопросам. Просим указать контактное лицо для технических уточнений.
С уважением,
ГИП проектной организации
В письме нет утверждения, что проектирование «невозможно по закону» или что заказчик нарушил конкретную норму: для таких выводов нужны дополнительные факты и экспертная проверка. Нет и произвольно придуманного обязательного срока ответа. Если срок предусмотрен договором, его укажут после сверки с договором.
Как Сокол помогает подготовить материал
Сокол читает загруженное задание в PDF или DOCX, извлекает сведения, сопоставляет условно применимые пункты своего чек-листа и формирует внутренние структурированные записи замечаний. На их основе в штатном сценарии собираются отчёт и редактируемый DOCX-проект письма; отдельно формируется паспорт объекта. Письмо группирует включённые замечания по важности. Часть записей, помеченных для рассмотрения ГИПом, может оставаться в отчёте и не входить в письмо. Пустой шаблон выше составлен редакцией: сервис не заполняет его и не выдаёт отдельный DOCX/XLSX реестра. Три предусмотренных DOCX также следует проверять на комплектность: возможна частичная выдача.
Машинный черновик даёт исходный список вопросов для проверки по длинному заданию. ГИП всё равно сверяет каждую ссылку на исходный документ, решает, применим ли пункт к объекту, проверяет любые нормативные ссылки, редактирует тон письма и проверяет комплектность выданных файлов. Сокол не отправляет письмо заказчику, не исправляет само задание и не гарантирует безошибочность замечаний или юридическую корректность выводов.
Как закрывать замечания после ответа
Не помечайте вопрос закрытым только потому, что пришло письмо. Сохраните ответ, проверьте, отвечает ли он на конкретную неопределённость, и зафиксируйте согласованную редакцию задания или исходных данных. Если заказчик изменил предмет или приложил новый документ, ГИП должен пересмотреть связанные пункты: прежний вывод может больше не относиться к новой версии. Для команды это важнее красивого реестра — иначе исправленный пункт и старое замечание начнут жить параллельно.