Разработка проектной документации задерживается не там, где чаще всего ищут причину

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

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

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

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

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

Легко сказать постфактум, что нужно было сверять разделы раньше. Сложнее объяснить, почему в моменте это не выглядит очевидным решением. Когда команда работает над проектом, который формально идёт по графику, промежуточная сверка кажется лишней тратой времени, которое лучше потратить на то, чтобы довести свой раздел до полной готовности. Ошибка в этой логике проявляется только один раз, на экспертизе, и к этому моменту её уже дорого исправлять.

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

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

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

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

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

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

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