С 2016 года я начала работать с большим количеством поточной информации, которую систематизировали и автоматизировали различными инструментами в организации. В ходе работы не только проектировщиком, но и главным по ВК, то есть проверить, привести к единому решению, исправить, донести другим в отделе, что работа требует доработки и т.д. не только своих проектов, но и сделанных чужими руками, пришла к мнению, что для экономии своего времени нужно понимать истинные цели проверки документации.
Но были и ряд проектов, которые требовали проверки "на пригодность к использованию". Как правило, это были компании, дружественные нам, которые вполне себе оправдано могли обратиться к нам, к проектировщикам проверить таких же проектировщиков.
Зачем проверить? Вот тут были разные цели этого мероприятия. На самом деле проверить на достаточность материалов и оборудования для строительства, по сути проверить технические решения и спецификацию, чтобы убедиться самому и успокоить строителей, что выделенной сметы хватит.
И была ещё одна цель, которая казалась несколько скользкой темой, это написать как можно больше замечаний от технических решений и спецификаций до оформления тома. И тут главным образом становилось понятно, что работу каким-то образом отберут у прошлых проектировщиков и отдадут местным. Для нас в случае большого количества работы, данная перспектива не казалась интересной. И честно скажу, мы писали и не раз замечания, но их все можно было и нужно было устранить без длительных препираний. Да были откровенно говоря плохие проекты, но большинство всё же можно было принять в производство работ.
Я как проектировщик на подрядных работах часто провожу аудит документации, или проверку, при этом со временем стала разделять цели таких проверок. У меня лично нет целей отобрать чужой уже сделанный в какой-то степени проект и переделать его под себя, поэтому интересуюсь, а какие у Вас цели моей проверки документации?
1. Цель на пригодность к прохождению экспертизы проектной документации.
Заказчик явно понимает, что что-то пошло не так. Формально проектная организация или отдельный проектировщик выполнил Проект по ПП87 и даже написал все пункты, но решения сомнительны, проверить Заказчик сам не может в вижу того, что в штате нет главспеца по разделу. А могу ли я сам передать такую документацию дальше и не выглядеть совсем в невыгодном свете?
2. Цель на пригодность к производству работ рабочей документации.
Заказчик прошел экспертизу, вроде бы даже что-то получил в виде рабочей документации, но проблема та же самая некому проверить документацию или же ему пишут со стройки непонятные вещи, а ответить и оценить адекватность ситуации не представляется возможным.
3. Цель сделать идеальную показательную документацию.
Проверка документации на коллизии, на бесконечно подробные решения технического плана, всё это может производится с целью сделать идеальный показательный проект, который показывается где-либо. Поэтому показать что-то недоработанное, технически неверное, может оказаться позором для компании и отдельного человека во главе этого процесса.
4. Цель не платить своему подрядчику.
Как это не прискорбно, но иной раз цель совсем наивна и проста. Заказчик не хочет расставаться с деньгами, которые уже пообещал подрядчику и они их очень ждут за сделанную работу. В таких случаях кипа замечаний от "нечитаемая арматура" до "выполнено оформление чего-либо не по ГОСТ" может быть нескончаема. И это формально мотивированный отказ от подписания акта и выплат, и с другой стороны конфликт сторон с дальнейшим решением через суд и прочее.
5. Цель показать свою приоритетность.
Иной раз Заказчик обладает службой технического заказчика со специалистами различного профиля, они профессионально подходят к рассмотрению проекта, могут в комплексе написать замечания, подвести под правильные решения, но порой включается игра "я начальник- ты дурак, ты начальник - я дурак". Сфера проектирования очень мала. Через 10 лет активной безостановочной и плодотворной работы делают из вчерашнего выпускника ВУЗа ценным специалистом, которого как правило уже знают в узких проектных кругах и могут приглашать на работу вот так просто без резюме и долгих собеседований. Вопрос влияния очень велик. Бывает так, что непримиримые враги в одной сфере встречаются по разные стороны баррикад. На этом можно остановиться, и работу ни принять, ни сдать, ни исправить фактически уже просто невозможно, потому что это личные интересы двух противоборствующих сторон. Личный интерес утереть другому нос, доказать что-то другим, себе и всему миру становится выше понимания этот проект достойный или требует тщательных доработок.
6. Цель написать замечания лишь бы они были.
Самая странная цель, но тоже встречалась с таким. Свойственно некоторым негосударственным экспертизам или частным организациям, чья работа заключается только в проверке документации и выставлении замечаний. Конечно чем больше. тем лучше, но в целом это их хлеб и не написать ни одного замечания просто преступление. Что-то должно быть найдено! И это что-то ищут! Один мой коллега признавался, что порой специально делает ошибку (лёгкую, незначительную описку в тексте или на чертеже), чтобы проверяющий смог зацепиться за это, написать замечание, обрадоваться и успокоиться на этом. Факт состоит в том, что хотя бы одно замечание должно быть найдено. Это работа проверяющего, а работа проектировщика, которого проверяли, с радостью и удовольствием согласиться и исправить это замечание.
7. Цель найти решение лучше или улучшить имеющийся проект.
Редко встречается данная цель аудита документации, но всё же бывает. Заказчик или начал делать проект, или уже сделал его своими или чужими руками и вот ему понадобился совет на данном этапе, что с этим делать. Так бывает, что принципиальные решения были приняты, но вдруг захотелось иного. И тут задача аудита не разнести в пух и прах имеющийся проект, а его отработать и предложить варианты развития событий и влияния на другие разделы, системы, бюджет проекта. В большей степени это совет для отработки индивидуального запроса Заказчика. Что ему не хватает для счастья? Или всего лишь убедить его, что сделано всё возможное и проект и без того прекрасен.
В своей работе как проектировщика, которого проверяют, я сталкивалась со всеми целями аудита. Увы, я могу их понять, но порой приходится сталкиваться с эпическими вывертами в процессии.
В своей работе аудитора чужой документации чаще всего я встречаюсь с целями №1,2 и реже с №4 и 7. Я прекрасно понимаю, что непродуктивно "валить" проектировщика, который готов отрабатывать замечания и идёт на диалог.
С какими целями аудита документации встречаетесь Вы чаще всего? Вас проверяют? Вы проверяете? Насколько оправдано Вы считаете Вас оценивают? Пишут ли бесконечные замечания и не принимают работу, которую Вы сделали действительно с душой и потратили время, силы и знания?
