Согласование разделов ПД внутри бюро: из почты — в статусы

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

Что такое внутреннее согласование раздела ПД?

Проектная документация (ПД) — это документы, описывающие архитектурные, конструктивные и инженерные решения объекта. Состав разделов и требования к их содержанию задаёт постановление Правительства РФ № 87 (официальный текст), а сам процесс архитектурно-строительного проектирования описан в статье 48 Градостроительного кодекса РФ. Оба документа говорят о результате. Про внутренний порядок проверок — ни слова. Как раздел рождается внутри бюро — кто и в каком порядке его проверяет — решает не закон, а внутренний регламент бюро.

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

Почему согласование по почте буксует?

Почта не создавалась для рабочих процессов с состоянием. У письма нет статуса, кроме «прочитано» и «не прочитано». На этом всё. Отсюда типичные симптомы: ГИП пересылает раздел с фразой «глянь, пожалуйста», и эта фраза — единственный след процесса. Через три дня никто не помнит, ответил ли прямой руководитель. Автор дорабатывает раздел по правкам из старой версии письма, потому что новая осталась в другом треде. Технический директор видит раздел впервые за день до сдачи, хотя формально должен был согласовать его неделю назад.

Отдельная проблема — видимость для руководителя. У ГИПа обычно 6–10 разделов в работе одновременно по разным проектам. Чтобы понять, что застряло, приходится открывать почту, искать по теме письма и вспоминать, кому что отправлял, — это уже не работа с проектом, а розыск информации о проекте.

Регламент согласования ГИП: цепочка от прямого руководителя до технического директора

Цепочка согласования — это настроенный порядок, в котором раздел проходит через согласующих, и статус, который присваивается разделу на каждом шаге. Базовый план для большинства бюро. Прямой руководитель → ГИП → технический директор. Цепочка настраивается в интерфейсе, без программиста, — бюро вправе сократить её для простых работ или добавить звено для сложных объектов.

Раздел проходит через десять статусов, и каждый отвечает на конкретный вопрос «где сейчас раздел и что с ним делать»:

Статусы можно настраивать под бюро: помечать системные и терминальные, менять порядок перетаскиванием. Но принцип не меняется — у раздела в любой момент есть один статус, а не цепочка писем, из которой этот статус нужно реконструировать вручную.

Сколько бюро теряет на почтовых циклах? Пример расчёта

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

Четыре с половиной рабочих дня ожидания против двух часов реальной проверки. Разница — не труд, а ожидание в чужом почтовом ящике. Умножьте это на десяток разделов, которые бюро согласовывает параллельно каждую неделю, — и станет понятно, почему ГИП тратит время не на архитектуру объекта, а на розыск писем по темам «Re: Re: раздел АР». При десятке параллельных разделов дни ожидания складываются в простой всего портфеля, хотя сама проверка стоит часы, а не дни.

Как выглядит согласование в статусах, а не в почте?

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

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

Прозрачность для заказчика: что видно снаружи?

Внутренние статусы — «на согласовании», «правки», «отклонено» — заказчику не нужны и даже вредны: он не обязан разбираться во внутренней кухне бюро. Для него есть упрощённая версия. Кнопка «Сформировать PDF для заказчика» выпускает печатный документ с понятной схемой: к работе → в работе → на проверке → готово. Никаких внутренних деталей — только прогресс.

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

Согласование и стадии П и Р: где раздел рождается?

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

С чего начать внедрение регламента согласования?

1. Зафиксировать цепочку письменно. Кто за кем проверяет раздел по каждому типу работ — это должно быть одной страницей, а не устной договорённостью, которую помнят по-разному.
2. Договориться о статусах, а не о формулировках. «Согласовано» должно значить одно и то же у всех, а не «вроде норм, но я не проверял детали».
3. Перенести очередь из почты в систему. Пока задача согласования живёт в переписке, у неё нет единого места, где виден статус, — значит, нет и самого процесса, только его имитация.
4. Договориться о сроке ответа. Без ожидаемого времени реакции на статус «на согласовании» цепочка снова растянется на дни, просто теперь это будет видно в системе, а не в почте.
5. Начать с одного проекта. Обкатать цепочку на реальных разделах, поправить порядок звеньев, и только после этого распространять регламент на всё бюро.

Частые ошибки регламента согласования

• Одна цепочка на все типы работ. Простая доработка чертежа и новый раздел сложного объекта не должны идти через одинаковое число звеньев.
• Статус «отклонено» не используется. Всё, что не подошло, помечается как «правки», и цикл доработок растягивается на недели без явного решения «переделывать заново».
• ГИП не видит очередь по команде. Без фильтра «мои подчинённые» руководитель узнаёт о застрявшем разделе только когда сгорает срок.
• Внешний PDF путают с внутренним контролем. Отчёт для заказчика показывает укрупнённый прогресс — управлять по нему согласованием внутри бюро не получится, для этого нужны рабочие статусы.