Как оформлять документацию по проекту

Проектная документация – что это?

В соответствии с «Градостроительным кодексом РФ» от 29.12.3004 №190-ФЗ (ГрК РФ) статьей 48: проектная документация – это документы, которые содержат материал в текстовых или графических форматах, определяют различные строительные решения, обеспечивающие строительство, реконструкцию объектов, их частей, а также капитальный ремонт.

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

Способы оформления проектной и рабочей документации

Документальное оформление имеет ряд ключевых требований не только к содержанию, но и к оформлению. Для создания проекта, необходимо следовать нормам и правилам СПДС и ЕСКД. Оформить проектную документацию можно в классическом бумажном виде или в цифровом (электронном). В бумажном виде документы необходимо прошить и пронумеровать. Нумерация проектной документации по ГОСТу осуществляется арабскими цифрами, учитывается титульный лист.

Электронная форма должна быть подана с использованием ЭЦП, заменяющей бумажную подпись и предназначенной для идентификации заявителя. Чтобы получить ЭЦП, нужно обратиться в удостоверяющий центр. Электронная документация должна полностью совпадать с названием бумажного варианта. Проект дополняют файлами с различными расширениями и указывают не более 150 носителей. Входящие в состав проекта текстовые приложения объединяют в дополнительные папки, а таблицы могут оформляться в отдельных файлах. Находящиеся в приложениях документы не требуют подписи.

Цифровое оформление является предпочтительным и для него соблюдаются нормы ГОСТ 2.051-2013. Разработчик проекта должен взять на себя ответственность за обеспечение соответствия между бумажными документами и электронными.

Как оформляется проектная документация: технические требования

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

Общеустановленными правилами указано, что:

На титульном листе должно содержаться название проекта, наименования заказчика и проектной организации, ФИО проектировщика. Также должна быть прописана информация о лицензиях или договорах, месте и годе оформления, а также необходимо сделать пометки о составлении и согласовании проектных бумаг (поставить штамп или печать).
Если в проектную документацию внесено две или более частей – на каждой из них нужно оглавление.
Проектная и рабочая документация: шифры в ней должны соответствовать ГОСТ Р 2.105-2019, учитывая разделы настоящего стандарта 5.1 и 5.2.
Все таблицы нужно оформлять арабскими цифрами.
В текстовую часть проекта должны включаться данные о проекте, количестве используемых списков, таблиц и приложений, данные о сметной стоимости строительства.
Источники добавляются в виде текстового приложения к документам, разделяя их на опубликованные и неопубликованные.
Правила оформления говорят, что каждое из приложений проекта должно быть составлено как продолжение документа или самостоятельный раздел.
Графические материалы проектной документации должны иметь номера, масштабирование, наименование проектной компании и ФИО исполнителя проекта. Каждое из обозначений указывается в приложениях или на отдельных листах, в соответствии с условными знаками.

Как не должны оформляться документы: основные признаки некачественного проекта

Некачественная документация определяется наличием ряда недостатков:

Если в проекте не хватает ряда документов, отсутствуют обязательные разделы или проектные сведения внутри разделов, например, инженерные расчеты, схемы и тд;
Неполные чертежи, отсутствуют принципиальные схемы, узлы или расчетные обоснования;
Листы документации без подписей специалистов, ГИПа;
Разрешение на внесение изменений в проектную документацию не было получено, но они внесены после утверждения проекта. Внесение изменений возможно только до подачи на утверждение;
Устаревшие или недостоверные инженерные изыскания;
Часто встречаются неверные расчеты объемов по разным видам работ, что влияет на сметную стоимость строительно-монтажных работ.

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

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

Поделиться:
Новые статьи Популярные статьи

КТБ Железобетон в проектно-образовательном интенсиве «Школа Шухова 3.0»
Строительный контроль сегодня и завтра
Аудит проектной документации
Исходные материалы для проектирования
Проектно-изыскательская документация
Правила обследования зданий и сооружений
Обследование несущих конструкций здания
Виды лабораторий в строительстве
Аккредитованная строительная лаборатория
Сроки разработки проектной документации

Как вести IT-документацию, чтобы удерживать порядок на проекте

Советует Technical Program Manager в Booking.com — Тарас Федорук.

В криминологии существует теория разбитых окон: «Если в здании разбито одно окно и его никто не замечает, то через какое-то время не останется ни одного целого окна». Согласно этому, если не поддерживать порядок, люди более охотно его нарушают и «забивают» на правила.

Во время разработки IT-проектов важно вести документацию и следить за тем, чтобы в ней был порядок. Именно на нее смотрят, чтобы сделать выводы относительно проекта. А еще это ваша защита на случай, если что-то пошло не по плану. Разобрались с Technical Program Manager в Booking.com Тарасом Федоруком, зачем в IT проектная документация и как ее вести, чтобы снизить риски в ходе разработки.

Тарас — президент украинского представительства PMI. Прошел более 10 профессиональных сертификаций, в частности PMP (Project Management Professional) и PSM ІІ (Professional Scrum Master ІІ). Получил награды «Лучший руководитель проектов в IT» по версии Ukrainian IT Awards в 2019 году и PMI Rising Leader в 2022.

*Скоро у Тараса стартует онлайн-курс в Laba «Проджект-менеджмент в IT».

Что такое проектная документация и зачем ее готовят

Задание на разработку начинается с идеи. Чтобы что-то создать, сначала это нужно представить. Чтобы не потерять мысли, лучше зафиксировать их в виде текста или графически. Фактически проектная документация — это процесс описания идеи от момента ее возникновения до выпуска результатов в релиз.

Позднее, в течение проекта, документация расширяется не только благодаря информации о продукте, а и о процессе. Другими словами, мы отвечаем на вопрос «Как?» — как коммуницировать, отчитываться, работать с качеством и т. д. Объем документации зависит исключительно от того, какую проектную информацию нужно сохранить и насколько легко ее потом можно получить.

Многие бизнесы недооценивают важность внутренней документации, пока нормальный ход процессов не нарушит непредвиденная ситуация. Согласно исследованиям, лишь 4% компаний всегда документируют внутренние процессы. Еще 50% признаются, что занимаются этим время от времени.

Что дает проектная документация в IT:

Меньше обсуждений в командных чатах и поисков причин «почему так, а не иначе»
Более быстрое погружение в контекст
Более простое понимание и оценка объемов изменений
Более простое принятие управленческих решений (например, понимание того, какой сервис можно убрать и как это отразится на всей системе)
Возможность комплексно оценить IT-структуру и вовремя заметить ошибки или пробелы в архитектуре
Возможность комплексной оценки хода проекта: что из процессов эффективно, что — лишнее (и почему), что нужно улучшить

По моему опыту, 80–90% проектов реализуются без существенных проблем или вопросов со стороны клиента. Он даже может не требовать наличия технической документации (но это не значит, что ее не нужно вести).

В то же время в остальных IT-проектах финансовые потери из-за отсутствия тщательно составленной проектной документации могут достигать сотен тысяч долларов. Всегда есть и будут клиенты, с которыми проектная документация станет спасательным жилетом на случай, если что-то пойдет не по плану.

Что может случиться, если не вести проектную документацию

Как-то я работал на проекте, где не было конкретных стандартов документации. Ее никто не требовал и не проверял, но я всегда готовлю документацию.

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

Команда провела исследование, после чего подготовила отчет, как именно реализует задачу и какой бюджет на это нужно выделить. При согласовании заказчик попросил добавить в IT-систему функционал, который мы не обсуждали на старте. Тогда мы оценили, во сколько это обойдется. Но у клиента не было столько времени и бюджета на дополнительные функции. Чтобы не тратить время зря, мы начали работать над функционалом, согласованным в контракте.

Через 5 недель клиент вернулся и расторг договор. В контракте была прописана компенсация на такой случай — заказчик не мог просто выйти из проекта. Но он задал прямой вопрос: «А чем вы занимались эти 5 недель? Как я могу быть уверен, что вы действительно работали над проектом?»

В таких ситуациях устав проекта, еженедельные отчеты, план фаз проекта и другие документы спасают команду от перспективы остаться «у разбитого корыта». У нас была необходимая проектная документация, поэтому клиент выплатил компенсацию за расторжение договора и не стал обращаться в суд (как обещал, пока мы не показали IT-документацию).

«Я хотел системно взглянуть на управление IT-проектами. Выбирал из 10 курсов и остановился на Laba»

Какие бывают виды документации на проекте

Всю документацию можно разделить на две категории:

System documentation — документы, которые описывают саму систему и ее части: Requirement documents, Design decisions, Architecture descriptions, Program Source code, Testing documents и т. д.
User documentation — инструкции, подготовленные преимущественно для конечных пользователей продукта и команды поддержки: Tutorials, User guides, Troubleshooting manuals, Installation и Reference manuals.

7 принципов создания проектной документации в IT

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

#1. Придерживайтесь однотипной структуры

У каждого документа должна быть структура: заголовок, название проекта, автор, история изменений, кто подписал документ и краткое intro, в котором описываем цель существования каждого документа. К примеру, типичное интро для устава проекта может выглядеть так:

«Устав проекта служит базовым соглашением между командой проекта и стейкхолдерами относительно цели проекта, основных ограничений и контекста проекта. Документ будет использован в качестве основы для дальнейшей детализации проектной среды и служить источником основной информации для принятия решений».

#2. Пишите просто и понятно

Техническая документация может выглядеть по-разному: быть оформленной в Microsoft Word, в форме таблицы, дизайн-системы в Figma или дерева в Confluence.

Но правило для всех форматов одно: объясняйте все простым языком, избегайте сокращений и запутанных фраз. Выделяйте подзаголовки и маркированные списки, чтобы документ можно было легко просматривать и быстро находить нужное.

#3. Используйте схемы и диаграммы

Визуальная информация воспринимается легче и быстрее, а также лучше запоминается. Чем больше данных вы предоставите графически, тем доступнее и короче будет документация. Я сейчас наблюдаю распространение популярности Google Slides и других программ для создания презентаций — как раз по этой причине.

#4. Используйте в документации элементы, из которых складывается проект, даже если нет возможности красиво их оформить. Такими элементами могут быть, например, письма с договоренностями, примеры данных и ссылки. Иначе вы просто забудете, что такое когда-то было. А если необходимо будет подтвердить информацию, не придется тратить час на поиск нужного письма или сообщения.

#5. Обеспечьте удобный доступ к документации

Я не сторонник того, когда вся проектная информация собирается в одном Excel-документе, где есть куча вкладок с расписанием, рисками, принципами коммуникации и т. д.

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

Также все документы должны просто и однотипно называться. Если это устав — его нужно оформить отдельно и дать соответствующее название, например:

Называя файлы, подходите с позиции своих коллег и клиента, которые будут пытаться найти нужную информацию. Простые и недвусмысленные формулировки значительно сократят время на поиски. Используйте признанную в вашей организации терминологию, не называйте устав проекта «брифом», если так больше никто не делает.

#6. Развивайте культуру документирования в команде

Не обязательно все должен документировать один человек. Например, устав — это ответственность руководителя проекта. В то же время техническую документацию должны создавать архитекторы или Senior/Lead-разработчики, стандарты тестирования — QA Lead, User Guide — технические райтеры.

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

#7. Закрывайте техдолг

Выделяйте время на дооформление «хвостов» — иначе клиенту или другой команде не видать доработки системы без стрессов. Представьте, что вы приходите на этот проект сейчас и никто из предшественников с вами пообщаться не сможет.

Пишите документацию так, чтобы проект можно было легко и безболезненно передать другой команде.

Как создать идеальную внутреннюю документацию

Допустим, один из ваших коллег работает в команде уже много лет, самостоятельно выполняет кучу заданий, и когда нужно быстро получить ответ на вопрос, все идут к нему.

А теперь представьте, что он решил уволиться.

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

Простите, если заставили вас нервничать! Но напряжение, которое вы ощутили, является отличной иллюстрацией того, насколько важна внутренняя документация.

Давайте подробно рассмотрим, что вам нужно знать для того, чтобы запустить и (или) оптимизировать этот процесс, не дожидаясь острой необходимости. Вы ведь знаете: готовить сани нужно летом…

Что такое внутренняя документация?

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

Она отличается от внешней документации, которую (как это ясно по названию) используют люди за пределами вашей организации, — например, от инструкций для покупателей.

Вопрос ведения внутренней документации может показаться запутанным, ведь чаще всего его обсуждают в контексте разработки программного обеспечения и ИТ. Таким командам необходимо очень точно документировать код разрабатываемых приложений и ПО.

Несмотря на определенные технические корни, ведение документации может оказаться полезной практикой для всей компании, от отдела кадров до команд по поддержке клиентов.

Типы внутренней документации

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

Разумеется, это не единственный возможный вид внутренней документации. Другие распространенные типы перечислены ниже.

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

В этой статье мы поговорим прежде всего о справочной документации (в частности, документации процессов). Но для общего представления полезно знать и о других типах внутренней документации.

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

Для чего нужна документация

Слишком многие компании недооценивают роль внутренней документации (пока нормальное течение процессов не нарушит какой-нибудь кризис, оставив их у разбитого корыта). Согласно исследованию BPTrends, лишь 4 % компаний всегда документируют внутренние процессы. Еще 50 % признают, что занимаются этим вопросом от случая к случаю.

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

Выполняйте больше работы, не тратя время впустую

Допустим, вам требуется вместо коллеги выполнить рассылку клиентам информационного обзора за месяц. Быстро ли получится, если вы станете разбираться во всем самостоятельно? Или же будет гораздо быстрее, если перед вами окажется подробная инструкция со снимками экрана, поясняющими, как именно нужно извлечь и распространить информацию?

Второй вариант очевидно быстрее, да?

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

Поднимите адаптацию сотрудников на новый уровень

По данным компании Gallup, лишь 12 % сотрудников полностью согласны, что их организация успешно справляется с адаптацией новых кадров.

И это печально, потому что приступать к новым обязанностям и всему учиться самостоятельно — едва ли не худшее, что может случиться с вами на работе.

Стабильная практика создания внутренней документации формирует для новых участников команды ценный источник знаний, к которому они могут обращаться, спокойно осваивая все тонкости новой работы.

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

Запустите процесс обмена знаниями

Слишком часто ценная информация и опыт хранятся только в голове у отдельных участников команды, а значит, недоступны другим. В этом случае увольнение сотрудников становится серьезной проблемой — особенно с учетом результатов одного из исследований, где 42 % опрошенных признали, что выполнение их работы требует уникальных знаний.

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

Формирование процесса работы с внутренней документацией

Продуманный процесс формирования внутренней документации (с шаблонами!) может помочь не только всерьез упростить написание документов, но и добиться в этом вопросе единого подхода в масштабе всей компании. Существует процесс для описания процессов — и мы готовы помочь вам его освоить. Выполните следующие шаги.

1. Определите основные процессы

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

Начните с создания базовых правил о том, какой тип работы вы будете документировать. Может быть, процесс должен повториться определенное количество раз (допустим, трижды), прежде чем вы примете решение о его документировании? Может быть, этот процесс должен повторяться на регулярной основе (как минимум раз в месяц)?

Ставя перед собой задачу задокументировать абсолютно все, вы явно завышаете планку и рискуете захлебнуться в работе. Поэтому лучше сразу определить критерии, что именно стоит документировать.

2. Создайте стандартный шаблон

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

Краткое описание, для чего существует данный процесс
Основные участники процесса
Что требуется для выполнения процесса (ПО, ресурсы и т. п.)

Эти поля послужат гарантией того, что у каждого читателя будет достаточно информации, чтобы легко выполнить описанное в документе.

БОНУСНЫЙ СОВЕТ.

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

3. Определите, где хранить описания процессов

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

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

4. Выделите время для наведения порядка

Даже когда вы внедрите строгий процесс формирования документации, ситуация иногда будет выходить из-под контроля. Документы окажутся в неправильном месте или же потребуется что-то обновить.

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

Прочтите это руководство, чтобы подробно разобраться, как организовать процесс ведения внутренней документации.

Чем может помочь ПО для создания внутренней документации

Когда доходит до создания общей внутренней документации, помощь вашей команды становится неоценимой, однако технологии тоже могут серьезно упростить работу. Рекомендуем не использовать файловые системы на отдельных компьютерах, а выбрать специальное ПО для ведения внутренней документации. Такой подход обеспечивает удобство совместной работы: специальное ПО позволяет вместе редактировать страницы, собирать отзывы в комментариях (встроенных или относящихся ко всей странице) и упоминать участников команды, которые внесли свой вклад в процесс.

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

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

Избавьте команду от лишних проблем и забот

Многие считают, что внутренняя документация — это излишняя формальность. Но представьте еще раз: что случится, если завтра решит уволиться ваш ключевой сотрудник? Сколько ценных знаний и важного опыта вы потеряете?

Если внедрить строгую практику создания документации, вы и ваша команда будете выходить из подобных непредвиденных обстоятельств с оптимизмом и уверенностью.

Оформление проектной документации

Как выполнить оформление проектной документации? Дублировать ли в содержании тома содержание пояснительной записки? Давать ли входящим в проект чертежам самостоятельные обозначения?

Определение проектной документации: ГОСТ 21.001-2013 «Система проектной документации для строительства. Общие положения» «3.1.5 проектная документация: Совокупность текстовых и графических документов, определяющих архитектурные, функционально-технологические, конструктивные и инженерно-технические и иные решения проектируемого здания (сооружения), состав которых необходим для оценки соответствия принятых решений заданию на проектирование, требованиям технических регламентов и документов в области стандартизации и достаточен для разработки рабочей документации для строительства».

Подраздел 4.1 ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» посвящён вопросам оформления проектной документации. Например:

«4.1.4 Текстовые и графические материалы, включаемые в том, в общем случае комплектуют в следующем порядке:

обложка;
титульный лист;
содержание тома;
ведомость «Состав проектной документации»;

Примечание — Допускается не включать ведомость «Состав проектной документации» в состав каждого тома, а комплектовать ее отдельным томом;

текстовая часть;
графическая часть (чертежи и схемы)».

Такая маленькая цитата, но с ней связаны достаточно большие проблемы.

1. Состав проектной документации, согласно ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» п.8.8, выполняют по форме 14 приложения С. В него включают «последовательный перечень томов проектной … документации». Начиная только с редакции 2013-го года в виде обоснованного исключения примечанием к п.4.1.4: «Допускается не включать ведомость «Состав проектной документации» в состав каждого тома, а комплектовать ее отдельным томом«. В чём вопрос? Проект более-менее приличного объекта (промышленная площадка) содержит сотни томов. Некоторые тома содержат всего по десятку «полезных» листов. А состав проекта размещается на десяти – пятнадцати листах, что вдвое и более увеличивает размер тома за счёт не несущего новой информации «Состава. «. Далее, в какой-то момент возникает необходимость внести изменение в состав проекта, и это изменение фактически должно быть внесено в сотни разных томов! С другой стороны, состав проекта разрабатывается генпроектировщиком. Какую полезную ИНФОРМАЦИЮ несёт включение этого документа в состав каждого тома, непонятно. Поэтому один из применяемых на практике подходов состоит в вынесении состава проекта в отдельный том, «нулевой». Решение грамотное, хорошо, что его легализовали.

Обратите внимание: стандарт не требует включать пустой лист, на котором написано «Состав проекта приводится отдельным томом». Этот приём очень часто попадается на глаза.

2. Гораздо более принципиальная проблема связана с интерпретацией приведенной выше цитаты о текстовой и графической частях из ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» как разработчиками этого ГОСТа, так и значительным числом проектировщиков. Дело в следующем. Лично я понимаю приведённый выше порядок комплектования так, что за всеми оформительскими листами типа обложки и содержания следует сначала описательная часть проекта, а затем его содержательная часть. Описательная часть представлена текстовыми документами, содержательная – графическими. То есть слова «текстовая» и «графическая» части являются некими родовыми понятиями, указывающими на способ представления информации. Альтернативный взгляд представлен в Сборнике разъяснениq, выпуск 1 «Сборник разъяснений требований стандартов системы проектной документации для строительства (вопросы и ответы). Выпуск 1. — ОАО «ЦНС», Москва, 2011» (п.25,30,31 и др., приложение В). Он выражается в том, что слова «текстовая» и «графическая» части используются в качестве наименования документов: 2345-ПОС.ТЧ – текстовая часть, состоящая из листов, 2345-ПОС.ГЧ – графическая часть, также состоящая из листов. Фактически изобретён новый вид документов с названиями текстовая часть и графическая часть. Ошибочность данного подхода легко продемонстрировать на основе анализа примера из приложения В Сбоника разъяснений, выпуск 1 «Сборник разъяснений требований стандартов системы проектной документации для строительства (вопросы и ответы). Выпуск 1. — ОАО «ЦНС», Москва, 2011» . В нём приведен пример листа «Содержание тома» для проектной документации. Я не буду приводить весь лист, приведу только тексты в графах таблицы:

Пример оформления листа «Содержание тома» для проектной документации

Для понимания ошибки следует взглянуть на ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» п.8.6, в котором приводятся указания по заполнению содержания тома. Там совершенно чётко сказано, что «в графе «Наименование» — наименование документа в полном соответствии с наименованием, указанным в основной надписи или на титульном листе». Возникает вопрос: в каком из листов проекта в основной надписи можно найти то, что приведено выше и в Сборнике разъяснений, выпуск 1 «Сборник разъяснений требований стандартов системы проектной документации для строительства (вопросы и ответы). Выпуск 1. — ОАО «ЦНС», Москва, 2011» ? Где написано «Текстовая часть», где «Графическая часть», где «лист 1 – Строительный генеральный…». Ответ прост: ни в каком и нигде. Это искусственный приём, который используется для того, чтобы перечислить в содержании каждый отдельный лист, входящий в графическую часть. А нужно это для того, чтобы в дальнейшем иметь возможность при необходимости в графе «Примечание» проставлять сведения об изменениях, вносимых в те или иные чертежи.

Как же следует правильно, придерживаясь требований ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» , оформить содержание и первую графу чертежей? Приведённый выше пример можно выполнить только двумя способами. Если считать текстовую часть и графическую часть документами, то никакой росписи отдельных листов в содержании тома быть не должно:

Вариант 1 правильного оформления листа «Содержание тома» для проектной документации

На такой вариант наталкивает аналогия с текстовой частью, ведь в ней имеется собственное содержание данной текстовой части, в котором и перечислены все разделы и пункты документа, который вместо «Пояснительной записки по разделу» назвали «Текстовая часть». Ничто не мешает поступить аналогичным образом и с графической частью, что в итоге превратит её в аналог основного комплекта рабочих чертежей, поскольку потребуется создать содержание (ведомость чертежей), в основной надписи чертежей писать порядковые номера этих чертежей и так далее. Только зачем городить огород?

Я сторонник использования другого варианта. Приведённый выше пример следует выполнить так:

Вариант 2 правильного оформления листа «Содержание тома» для проектной документации

Вуаля, все требования соблюдены: текст из графы Обозначение соответствует графе 1 основной надписи, текст из графы Наименование соответствует графам 4 (для графической части) и 5 (для текстовых документов). Никаких нарушений и ничего лишнего.

Делается это на основании ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» п.4.1.2 «каждому текстовому и графическому документу, включенному в том, присваивают самостоятельное обозначение, которое указывают на обложке, титульном листе и/или в основной надписи». Обратили внимание: ни слова о количестве текстовых и графических документов! Хоть десять, хоть сто. В соответствии с ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» п.4.1.3 «. могут быть разработаны стандарты организаций по обозначению текстовых и графических документов, входящих в состав проектной и рабочей документации. », поэтому вместо обозначения 2345-ПОС.ТЧ в приведённом выше примере Вы можете использовать 2345-ПОС.ПЗ, указав в графе «Наименование» «Пояснительная записка к разделу». Вместо 2345-ПОС.ГЧ1 можно написать 2345-ПОС.1 или что-нибудь ещё. Это Ваше право. При этом старайтесь следить за тем, чтобы обозначения чертежей или текстовых документов не были аналогичны обозначениям разделов и подразделов проектной документации и не повторялись.

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

3. Очень плохо, когда одни и те же слова обозначают разные понятия. Мы имеем дело с содержанием тома, в котором перечисляются входящие в том документы. Одновременно есть содержание пояснительной записки (или текстовой части), которое является содержанием текстового документа. Всегда приходится уточнять, о каком содержании в данный момент речь. Нередко возникают вопросы: нужно ли содержание пояснительной записки приводить в содержании тома. Николай Иванович Сорокин, который от имени ОАО «ЛЕНМОРНИИПРОЕКТ» занимался внесением изменений в ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» , на семинаре рассказывал, что настаивал на замене наименования «содержание тома» другим, например «опись документов». Я считаю, что это действительно было бы правильным решением, которое позволило бы исключить путаницу в понятиях. А пока что нужно понимать, что в содержание тома Вы включаете текстовый документ «Пояснительная записка» или «Текстовая часть». В соответствии с ГОСТ 2.105-95 «Единая система конструкторской документации. Общие требования к текстовым документам» : «4.1.11 В документе…большого объёма на первом (заглавном) листе…помещают содержание, включающее номера и наименования разделов и подразделов с указанием номеров листов». Таким образом, содержание текстового документа является всего лишь составной частью этого документа, и нет никаких оснований для того, чтобы дублировать его в другом документе – содержании тома. Пример оформления содержания тома приведён на следующей странице сайта в файле projectdoc.pdf.

С проблемами разобрались, теперь несколько слов по оформлению самих материалов. Примеры оформления некоторых листов приводятся в приложениях к ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» . Обращайте внимание на то, что некоторые из них являются обязательными, как разобранное выше содержание, а оформление других всего лишь рекомендуемое, как обложка и титульный лист. Поэтому в принципе Вы вольны в своём творчестве. Обращу Ваше внимание только на один момент. Лично меня всегда интересовало, почему некоторые организации текст на обложке и титульном листе в поле 3 – «наименование объекта капитального строительства и, при необходимости, вид строительства» ( ГОСТ Р 21.1101-2013 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации» приложение Н) выполняют заглавными буквами. Объяснение нашёл в ГОСТ 2.105-95 «Единая система конструкторской документации. Общие требования к текстовым документам» п.6 «Общие требования к оформлению титульного листа и листа утверждения», п.6.9 которого прямо требует выполнять наименование изделия (аналог приведённого выше поля 3) заглавными буквами. Так что не следует считать такое выполнение надписи происками злобных капслокеров.

Добавить комментарий
46401 просмотр

Как оформлять документацию по проекту