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