Руководство по документированию проектов

Зачем нужна документация

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

Такая ситуация называется bus factor (фактор автобуса): проект останавливается, если один из участников «попадает под автобус», потому что остальные не могут разобраться в процессах без него.

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

Кто этим занимается

Как правило, документацию в компании ведёт отдельный специалист — технический писатель. Он составляет внутренние документы для сотрудников и инструкции для пользователей.

В обязанности технического писателя входит:

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

Однако такой специалист есть не во всех компаниях, поэтому многие сотрудники ведут документацию самостоятельно.

Как начать документировать

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

• Процесс повторяется регулярно, а не один раз. Например, разовый процесс — команда три года работала в инструменте Jira, а теперь переходит в ClickUp. Документировать этот переход не обязательно. Повторяющийся процесс — участники команды регулярно ставили друг другу задачи в Jira, а теперь будут ставить в ClickUp. Как это делать в новом инструменте, нужно задокументировать.
• Процесс специфический и требует знаний и навыков. Допустим, для запуска проекта нужны какие-то неочевидные действия: установка сторонних программ, получение прав доступа. Интуитивно разобраться не получится — значит, это нужно задокументировать.

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

• Confluence — разработан специально для документирования и создания баз знаний на проектах. Есть готовые шаблоны, в том числе для документации. В сервисе можно создавать иерархическое дерево страниц, помечать их метками, добавлять перекрёстные ссылки. Есть возможность командной работы и встроенные интеграции с другими продуктами Atlassian: Jira, Trello.

• Notion — сервис для создания текстовых документов, списков дел, баз данных, таблиц, баз знаний, ведения проектов и командной работы. Есть готовые шаблоны под задачи разных отделов: маркетинг, дизайн, разработка, HR, продажи. Поддерживает подсветку синтаксиса для более чем 60 языков программирования. Есть встроенные интеграции со всеми популярными сервисами: Figma, Jira, Github, Slack, Asana и другими.

• Archbee — сервис для создания технической документации. Поддерживает списки, таблицы, загрузку файлов, изображений и видео, многоязычное редактирование кода и создание диаграмм. Интегрируется с разными инструментами разработчика: Mermaid для построения диаграмм на JavaScript, Swagger для создания клиентских библиотек, языком запросов GraphQL и другими.

• Docsie — сервис для создания документации по продукту. Можно использовать для создания как внутренних, так и внешних инструкций. Позволяет собирать текстовые отзывы от пользователей, чтобы улучшать документы. Есть встроенный переводчик на базе нейросети, но русский язык не поддерживается.

• Miro — сервис для планирования и визуализации идей. Его можно использовать как основную платформу для ведения документации в виде блок-схем, канбан-досок и инфографики, а также как дополнительный инструмент: у Miro есть встроенные интеграции с Confluence и Notion.

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

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

3 правила, как вести документацию

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

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

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

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

С чего начинается проектная документация, почему визуальные схемы работают лучше текста, как наличие прототипов проекта влияет на уровень эмпатии клиента, рассказал Виталий Арбузов, CEO digital-агентства INPRO.digital.

Почему проектная документация упрощает разработку проекта 

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

• cнизить риски в ходе самого проекта. Когда веб-разработка уже будет в активной стадии, вам нужно будет пройти еще несколько этапов утверждения. Если на стадии обсуждения вы придете с заказчиком к консенсусу, то вероятность того, что все придется переделывать в середине работы будет сведена к минимуму;
• упростить и декомпозировать комплексные задачи. Управление проектом с помощью фасилитации — одно из ключевых преимуществ проектной документации.  Результат становится наглядным, поэтому и согласование с клиентом проходит легче и команда более четко понимает стоящие перед ней задачи и ожидаемый итог работы;
• выстроить нормальные отношения с клиентом. Уровень взаимопонимания с заказчиком напрямую влияет на успешность вашего проекта, скорость и качество его реализации. Общение на равных за счет упрощения и визуализации поможет вам на следующих этапах разработки быть более мобильными в принятии решений и одновременно даст больше возможностей для дополнительных продаж, так как вы будете лучше понимать, что именно необходимо для функционирования ресурса. 

С чего начать составление проектной документации

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

1. Хочет ли клиент добавить на сайт такую же функцию? 

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

2. Нужна ли бизнесу клиента данная функция? 

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

3. Насколько сильно добавление этой функции повлияет на смету и сроки проекта? 

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

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

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

Схематичная визуализация результатов асессорского аудита

Кто входит в команду разработки проектной документации

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

1. Ведет всю коммуникацию с клиентом. Даже если вы привлекаете других специалистов для разработки проектной документации, постарайтесь сделать так, чтобы напрямую с заказчиком общался только кто-то один. Так клиенту не придется запоминать несколько имен, дублировать информацию и объяснять свои пожелания по нескольку раз. Проектный менеджер коммуницирует с клиентом, записывает ключевые идеи и передает их своей команде. 
2. Контролирует деятельность сотрудников, работающих над проектом. Проектный менеджер отвечает за то, чтобы все было сделано в срок, все комментарии отработаны, а обратная связь отправлена. В его задачи входит и мониторинг деятельности команды: он выстраивает коммуникацию между специалистами, следит за всеми чатами, отвечает на любые вопросы. 
3. Согласовывает все этапы работ. Все специалисты отправляют свои наработки сначала проектному менеджеру, он вносит правки и только после этого отправляет макеты на согласование клиенту. 

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

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

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

Визуализация структуры сайта

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

Примеры вайрфреймов

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

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

Фото на обложке: CoffeeMate/Depositphotos.com

Как вести документацию, чтобы не было обидно за потраченное время

Привет, Хабр! Меня зовут Татьяна Шуравина, я системный аналитик Innovative People, работаю на проекте в банковском секторе. Вместе с командой оптимизируем и автоматизируем операции сотрудников банка для обслуживания юридических лиц. В своей первой статье я рассказывала, как стать системным аналитиком без специального образования. Сегодня хочу поделиться с теми, кто начал свой путь в аналитике, тонкостями магического процесса ведения проектной документации. Не для кого не секрет, что зачастую бывает такое, что система есть, а документации, чтобы понять, как она работает, нет. В статье расскажу, какие есть подходы к ведению документации, зачем это нужно и поделюсь практическим опытом.

Что относится к проектной документации?

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

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

Итак, на первом этапе ведется предпроектная документация, которая описывает подготовку для запуска проекта и крупными мазками — план‑график проекта.

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

Едем дальше: этап реализации проекта. К этому этапу относится документация, с которой работает команда разработки. Тест‑кейсы и данные для проведения функционального, интеграционного и бизнес‑тестирования. В своей статье я подробно остановлюсь на ведении документации, необходимой для системного анализа и разработки.

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

Зачем нужны правила оформления документации?

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

1) сокращение сроков первичных согласований на предпроектном этапе;

2) быстрый онбординг новичков и адекватная оценка сроков проекта;

3) легкость в передаче экспертизы коллегам в соответствии с разными компетенциями, представлении продукта заинтересованным лицам;

4) прозрачность и понимание для коллег, сопровождающих систему после внедрения.

Документация, необходимая для системного анализа и начала разработки продукта

Для начала системного анализа в моей команде аналитику достаточно иметь 3 основные составляющие:

• согласованный вижн;

• бизнес‑требования;

• макеты интерфейсов.

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

Бизнес‑требования могут приходить в аналитику в разных вариантах: в виде оформленного документа в ворде или user‑story, в которой описано поведение системы сейчас (as is) и как должно быть, в соответствии с требованиями заказчика (to be).

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

Ведение документации на примере одного проекта

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

Рассмотрим два распространенных метода ведения проектной документации на моей практике:

1) ведение спецификаций требований к АС (СТАС) по ГОСТу в электронном виде с загрузкой документа в электронный архив;

2) ведение документации в электронном виде в рабочем пространстве, которое используется на проекте в соответствии с определенной структурой;

Сравним описанные выше подходы на предмет удобоваримости формата работы с каждым.

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

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

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

Для аналитики мы разбили информацию на несколько разделов и подразделов:

• архитектура;

• описание процессов;

  • подраздел метрики;

• база данных.

  

В разделе «Архитектура» отображена общая схема взаимодействия модуля с разными сервисами и сторонними системами через api. Аналитик описывает контракты для интеграции с другими системами, рисует UML‑диаграммы с последовательностью вызовов для получения данных.

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

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

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

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

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

Эффект от ведения документации, которое устраивает всю команду

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

Полная, доступная и единообразная документация должна работать как навигатор. Мне очень нравится фраза «Порядок в голове — порядок везде». Это я к чему: структурированная определённым образом документация, которая вовремя актуализируется, может дать только положительные эффекты.

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

• Google Drive для хранения разного вида файлов с общим доступом и редактированием онлайн.

• Dropbox, как замена Google Drive. Если, кто‑то из сотрудников потерял телефон, то в Dropbox можно отключить доступ к этому устройству.

• Confluence — общее рабочее пространство, база знаний для создания, хранения, редактирования документов.

• Notion — «википодобный» ресурс. Хорошо работает для базовой документации, особенно о каком‑то продукте. В целом, можно использовать как замену Confluence и сильно экономить, потому что Notion дешевле.

• Miro помогает сделать быстрое ревью документа. Похож на большой lite‑board или Paint, куда можно вставлять различную информацию: ретроспективу, анонсы, согласование дизайна со стейкхолдерами, превью дизайна с разработчиками.

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

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

2. Документация должна быть доступной. Перепроверяйте права доступа.

В течении всего жизненного цикла проекта:

• выбирайте правильные инструменты для хранения и работы с документами;

• создавайте навигацию, в которой сможет разобраться даже новичок;

• делегируйте работу и проверяйте сделанное другими.

Так же полезными ссылками на интересные статьи:

Документация в порядке

Подход к ведению документации на ОС: наш опыт

Как научиться создавать полезную проектную документацию ИТ‑систем

Успехов всем начинающим и помните, ведение документации — это непрерывный процесс: «Вы можете откладывать, но время этого не сделает». — Бенджамин Франклин

Руководство по подготовке проектной документации для объектов капитального строительства производственного и гражданского назначения
СОДЕРЖАНИЕ

1. 1. Общие положения
2. 2. Нормативные ссылки
3. 3. Термины и определения
4. 4. Исходные и разрешительные документы
5. 5. Предпроектные проработки
6. 6. Задание на проектирование
7. 7. График выполнения проектных работ
8. 8. Договор на выполнение работ по подготовке проектной документации
9. 9. Описание технологической последовательности подготовки проектной документации
10. 10. Таблица технологического процесса подготовки проектной документации по разделам
11. 11. Контроль качества проектной документации
1. 11.1 Общие положения
2. 11.2 Предпроектный контроль
3. 11.3 Текущий контроль
4. 11.4 Нормоконтроль — за правильностью применения проектных норм при выполнении работ по подготовке проектной документации
5. 11.5 «Выходной» контроль
6. 11.6 Внешний контроль — экспертиза проекта
12. 12. Нормоконтроль
1. 12.1 Назначение
2. 12.2 Область применения
3. 12.3 Применяемые термины и сокращения
4. 12.4 Ответственность
5. 12.5 Описание выполняемых действий
6. 12.6 Записи по качеству
13. 13. Согласование проектной документации
14. 14. Выдача проектной документации заказчику
15. 15. Порядок внесения изменений в проектную документацию
16. 16. Передача проектной документации в архив
17. 17. Приложения
18. 18. Библиография

Введение

Настоящее «Руководство по подготовке проектной документации для
объектов капитального строительства производственного и гражданского
назначения» направлено на создание единой организационно-технологической
системы подготовки проектной документации, в соответствии с Градостроительным кодексом Российской Федерации [1], Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании» [2], Федеральным законом от 30 декабря 2009 г. №384-Ф3 «Технический регламент о безопасности зданий и сооружений» [3].

1. Общие положения

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

Соблюдение требований настоящего Стандарта обеспечивает выполнение
требований «Положения о составе разделов проектной документации и
требованиях к их содержанию» утвержденного постановлением Правительства РФ
от 16 февраля 2008 г. № 87. [8].

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

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

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

• от кого он получает задание и кому в свою очередь его выдает;
• с кем согласовывает свой раздел проекта и какие разделы в свою очередь
  согласовывает сам.

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

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

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

Вернуться наверх

2. Нормативные ссылки

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

• Федеральный закон от 30.11.1994 г. № 51-ФЗ «Гражданский кодекс
  Российской Федерации».
• Федеральный закон от 29.12.2004 г. № 190-ФЗ «Градостроительный кодекс
  Российской Федерации».
• Федеральный закон от 27.12.2002 г. № 184-ФЗ «О техническом
  регулировании».
• Федеральный закон от 23 ноября 2009 г. № 261-ФЗ «Об энергосбережении и
  о повышении энергетической эффективности и о внесении изменений в отдельные
  законодательные акты Российской Федерации».
• Федеральный закон от 30.12.2009 г. № 384-Ф3 «Технический регламент о
  безопасности зданий и сооружений».
• Федеральный закон от 22.07.2008 г. № 123-Ф3 «Технический регламент о
  требованиях пожарной безопасности».
• Постановление Правительства РФ от 12.08.2008 г. № 590 «О порядке
  проведения проверки инвестиционных проектов на предмет эффективности
  использования средств федерального бюджета, направляемых на капитальные
  вложения».
• Положение о составе разделов проектной документации и требованиях к их
  содержанию», утвержденное постановлением Правительства РФ от 16 февраля
  2008 г. № 87.
• РМД 11-08-2009 «Руководство по проектной подготовке
  капитального строительства в Санкт-Петербурге».
• Постановление Правительства Российской Федерации от 19.01.2006 г. № 20
  «Об инженерных изысканиях для подготовки проектной документации,
  строительства, реконструкции объектов капитального строительства».
• Постановление Правительства РФ от 09.06.2007 г. № 360 «Об утверждении
  Правил заключения и исполнения публичных договоров о подключении к
  системам коммунальной инфраструктуры» (с изменениями и дополнениями от
  16.07.2009 г., 27.11.2010 г., 16.04.2012 г.).
• СП 44.13330.2011 «Административные и бытовые здания».
• РД 78.36.003-2002 «Инженерно-техническая укрепленность. Технические
  средства охраны. Требования и нормы проектирования по защите объектов от
  преступных посягательств».
• Форма градостроительного плана земельного участка, утвержденная
  приказом Министерства регионального развития Российской Федерации от
  10.05.2011 г. №207.
• СП 118.13330.2012 «Общественные здания и сооружения».
• СП 22.13330.2011 «Основания зданий и сооружений».
• «Правила устройства электроустановок» (ПУЭ, 7 издание). Главы: 1.1, 1.2,
  1.7, 1.9, 7.5, 7.6, 7.10.
• СП 30.13330.2012 «Внутренний водопровод и канализация зданий».
• СП 124.13330.2012 «Тепловые сети».
• СП 60.13330.2012 «Отопление, вентиляция, кондиционирование воздуха».
• СП 134.13330.2012 «Системы электросвязи зданий и сооружений. Основные
  положения проектирования».
• СП 133.13330.2012 «Сети проводного радиовещания и оповещения в зданиях
  и сооружениях. Нормы проектирования».
• Технический регламент о безопасности сетей газораспределения и
  газопотребления, утвержденный постановлением Правительства Российской
  Федерации от 29.10.2010 г. № 870.
• СП 62.13330.12 «Газораспределительные системы».
• СП 48.13330.2011 «Организация строительства».
• РД 153-39.4р-006-96 «Положение о составе и порядке сбора исходных
  данных
  для проектирования объектов нефтепродуктообеспечения».
• СанПиН 2.2.1/2.1.1.1200-03 «Санитарно-защитные зоны и санитарная
  классификация предприятий, сооружений и иных объектов».
• СанПиН 2.1.7.1322-03 «Гигиенические требования к размещению и
  обезвреживанию отходов производства и потребления».
• СП 2.2.1.1312-03 «Гигиенические требования к проектированию вновь
  строящихся и реконструируемых промышленных предприятий».
• СанПиН 2.1.2.2645-10 «Санитарно — эпидемиологические требования к
  условиям проживания в жилых зданиях и помещениях».
• СП 1.13130.2009 «Системы противопожарной защиты. Эвакуационные пути
  и выходы».
• СП 2.13130.2012 «Системы противопожарной защиты. Обеспечение
  огнестойкости объектов защиты».
• СП 3.13130.2009 «Системы противопожарной защиты. Система оповещения
  и управления эвакуацией людей при пожаре. Требования пожарной безопасности».
• СП 5.13130.2009 «Системы противопожарной защиты. Установки пожарной
  сигнализации и пожаротушения автоматические. Нормы и правила
  проектирования».
• СП 11.13130.2009 «Места дислокации подразделений пожарной охраны.
  Порядок и методика определения».
• СП 59.13330.2012 «Доступность зданий и сооружений для маломобильных
  групп населения».
• СП 50.13330.2012 «Тепловая защита зданий».
• Требований к энергетическому паспорту, составленному по результатам
  обязательного энергетического обследования, и энергетическому паспорту,
  составленному на основании проектной документации, и правил направления
  копии энергетического паспорта, составленного по результатам обязательного
  энергетического обследования, утвержденные приказом Министерства энергетики
  Российской Федерации от 19.04.2010 г. № 182.
• ГОСТ Р 22.1.12-2005 «Безопасность в чрезвычайных ситуациях.
  Структурированная система мониторинга и управления
  инженерными системами зданий и сооружений. Общие требования».
• ГОСТ Р 21.1101-2013 «Основные требования к проектной и рабочей
  документации».
• СП 88.13330.2012 «Защитные сооружения гражданской обороны».
• СП 11-107-98 «Порядок разработки и состав раздела «Инженернотехнические
  мероприятия гражданской обороны. Мероприятия по
  предупреждению чрезвычайных ситуаций» проектов строительства» (отменен).
• МДС 81-35.2004 «Методика определения стоимости строительной
  продукции на территории российской федерации».
• СП 16.13330.2011 «Стальные конструкции».
• СП 132.13330.2011 «Обеспечение антитеррористической защищенности
  зданий и сооружений, общие требования проектирования».

Вернуться наверх

3. Исходные и разрешительные документы

В случае, если подготовка проектной документации осуществляется
физическим или юридическим лицом на основании договора с застройщиком или
техническим заказчиком, застройщик или технический заказчик обязан
предоставить такому лицу следующие исходные документы (п. 6 ст. 48 [2]):

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

Для подготовки проектной документации на объект капитального
строительства необходимы следующие исходные данные (п. 10, п.п.б [8]):

• задание на проектирование — в случае подготовки проектной документации
  на основании договора;
• отчетная документация по результатам инженерных изысканий;
• правоустанавливающие документы на объект капитального строительства —
  в случае подготовки проектной документации для проведения реконструкции или
  капитального ремонта объекта капитального строительства;
• утвержденный и зарегистрированный в установленном порядке
  градостроительный план земельного участка, предоставленного для размещения
  объекта капитального строительства;
• документы об использовании земельных участков, на которые действие
  градостроительных регламентов не распространяется или для которых
  градостроительные регламенты не устанавливаются, выданные в соответствии с
  федеральными законами, уполномоченными федеральными органами
  исполнительной власти, или уполномоченными органами исполнительной власти
  субъектов Российской Федерации, или уполномоченными органами местного
  самоуправления;
• технические условия, предусмотренные частью 7 статьи 48 Градостроительного
  кодекса Российской Федерации и иными нормативными правовыми актами, если
  функционирование проектируемого объекта капитального строительства
  невозможно без его подключения к сетям инженерно-технического обеспечения
  общего пользования;
• документы о согласовании отступлений от положений технических
  условий;
• разрешение на отклонения от предельных параметров разрешенного
  строительства объектов капитального строительства;
• акты (решения) собственника здания (сооружения, строения) о выведении
  из эксплуатации и ликвидации объекта капитального строительства — в случае
  необходимости сноса (демонтажа);
• иные исходно-разрешительные документы, установленные
  законодательными и иными нормативными правовыми актами Российской
  Федерации, в том числе техническими и градостроительными регламентами;
• решение органа местного самоуправления о признании жилого дома
  аварийным и подлежащим сносу — при необходимости сноса жилого дома;

Вернуться наверх

4. Термины и определения

В настоящем Стандарте используются следующие термины и определения:

Технический регламент — документ, который принят на основании
международного договора Российской Федерации, ратифицированный в порядке,
установленном законодательством Российской Федерации, указом Президента
Российской Федерации или постановлением Правительства Российской Федерации
и устанавливающий обязательные для применения и исполнения требования к
объектам технического регулирования (продукции, в том числе зданиям, строениям
и сооружениям, процессам производства, эксплуатации, хранения, перевозки,
реализации и утилизации) (ст. 2 [3]).

Стандарт — документ, в котором в целях добровольного многократного
использования устанавливаются характеристики продукции. правила
осуществления и характеристики процесса производства, эксплуатации, хранения,
перевозки, реализации и утилизации, выполнения работ или оказания услуг (ст. 2
[3]).

Национальный стандарт — стандарт, утвержденный национальным органом
Российской Федерации по стандартизации (ст. 2 [3]).

Стандарт организации — стандарт коммерческой, общественной, научной
организации, саморегулируемой организации, объединения юридических лиц,
разработанный и утвержденный ими самостоятельно, исходя из необходимости его
применения для достижения целей (ч. 1 ст. 17 [3]).

Застройщик — физическое или юридическое лицо, обеспечивающее на
принадлежащем ему земельном участке строительство, реконструкцию,
капитальный ремонт объектов капитального строительства, а так же выполнение
инженерных изысканий, подготовку проектной документации для их строительства
(ч. 16 ст. 1 [2]).

Проектировщик — физическое или юридическое лицо, непосредственно
осуществляющее подготовку проектной документации в установленном порядке
(п. 3.2 ч. 3 [9]).

Руководитель проекта — лицо, ответственное за подготовку проектной
документации для конкретного объекта, назначенное приказом руководителя
предприятия из числа главных инженеров (архитекторов) проектов.
Объект капитального строительства — здание, строение, сооружение,
объекты, строительство которых не завершено, за исключением временных
построек, киосков, навесов и других подобных построек (п. 10 ст. 1 [2]).

Строительство — создание зданий, строений, сооружений, в том числе на
сносимых объектов капитального строительства (п. 13 ст. 1 [2]).

Реконструкция объектов капитального строительства — изменение
параметров объекта капитального строительства, его частей (высоты, количества
этажей, площади, объема, в том числе надстройка, перестройка, расширение
объекта капитального строительства, а так же замена (или) восстановление
несущих строительных конструкций объекта капитального строительства, за
исключением замены отдельных элементов таких конструкций на аналогичные или
иные улучшающие показатели таких конструкций элементы и (или)
восстановление указанных элементов (п. 14 ст. 1 [2]).

Капитальный ремонт объектов капитального строительства — замена и (или)
восстановление строительных конструкций объектов капитального строительства
или элементов таких конструкций, за исключением несущих строительных
конструкций, замена и (или) восстановление систем инженерно — технического
обеспечения и сетей инженерно — технического обеспечения объектов
капитального строительства или их элементов, а так же замена отдельных
элементов несущих строительных конструкций на аналогичные или иные
улучшающие показатели таких конструкций элементы и (или) восстановление
указанных элементов (п. 14.2 ст. 1 [2]).

Технический заказчик — физическое лицо, действующее на
профессиональной основе, или юридическое лицо, которое уполномочено
застройщиком и от имени застройщика заключает договоры о выполнении
инженерных изысканий, о подготовке проектной документации, о строительстве,
реконструкции, капитальном ремонте объектов капитального строительства,
подготавливает задание на выполнение указанных видов работ, представляет
лицам, выполняющим инженерные изыскания и (или) осуществляющим
подготовку проектной документации на строительство, реконструкцию,
капитальный ремонт объектов капитального строительства, материалы и документы, необходимые для выполнения указанных видов работ, утверждает
проектную документацию, подписывает документы, необходимые для получения
разрешения на ввод объекта капитального строительства в эксплуатацию,
осуществляет другие функции (п. 22 ст. 1 [2]).

Вернуться наверх

5. Предпроектные проработки

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

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

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

Технологический процесс подготовки проектной документации по разделам на
Этапе 1 «Поиск и принятие концептуальных объемно-планировочных и
архитектурных решений, согласованных с требованиями действующих
нормативных документов. Согласование принятых решений в установленном
заданием на проектирование порядке» на стадии «Предварительные решения
проектной документации», приведен в Приложении 11-10. Таблица 1 ТХ-ПР.

Вернуться наверх

6. Задание на проектирование

Подготовка проектной документации для объектов капитального
строительства осуществляется на основании задания застройщика или
технического заказчика, (при подготовке проектной документации на основании
договора), результатов инженерных изысканий, градостроительного плана
земельного участка, в соответствии с требованиями технических регламентов,
техническими условиями, разрешением на отклонение от предельных параметров
разрешенного строительства, реконструкции объектов капитального строительства,
(ч. 11 ст. 48 (п. 6 ст. 48 [2]).

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

Задание на проектирование неотъемлемая часть договора подряда,
утверждаемая застройщиком (техническим заказчиком), определяющая характер и
объем подготавливаемой проектной документации и иные требования к ней.
Правовой основой для подготовки задания на проектирование являются
положения ст. 759 [1], устанавливающие, что:

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

Задание на проектирование объекта капитального строительства должно
включать (п. 14 разд. III [8]):

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

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

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

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

Форму и содержание задания на проектирование приведены в Приложениях: 1-6, 2-6, 3-6, 4-6.

Вернуться наверх

7. График выполнения проектных работ

Неотъемлемой частью договора на подготовку проектной документации
является Календарный план подготовки проектной документации. (Приложение 67.
Таблица 1).

На основании Календарного плана подготовки проектной документации
руководителем проекта (ГИП, ГАП) разрабатывается подробный график
подготовки проектной документации, который согласовывается руководителями
подразделений (исполнителями), участвующими в подготовке проектной
документации и утверждается руководителем проектного предприятия
(подразделения).

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

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

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

• Этап 1 — 10-15%. («Предварительные решения проектной документации».
  Поиск и принятие концептуальных объемно-планировочных и архитектурных
  решений, согласованных с требованиями действующих нормативных документов.
  Согласование принятых решений в установленном заданием на проектирование
  порядке).
• Этап 2 — 15-20%. (Поиск и принятие объемно-планировочных и
  архитектурных решений, согласованных с требованиями действующих
  нормативных документов).
• Этап 3 — 8-12%. (Разработка и согласование инженерных решений с
  объемно-планировочными решениями).
• Этап 4 — 10-15%. (Разработка разделов ПЗУ, АР, КР, ЭЭ, ОДИ, ИОС
  проектной документации в полном объеме и выдача документации руководителю
  проекта (ГИПу, ГАПу).
• Этап 5 — 6-10%. (Разработка разделов СМ, ПОС, ПОД, ООС проектной
  документации в полном объеме и выдача документации руководителю проекта
  (ГИПу, ГАПу).
• Этап 6 — 1-3%. (Выдача проектной документации в полном объеме
  заказчику).

Пример оформления Календарного плана и Графика подготовки проектной
документации приведен в Приложении 6-7. Таблицы 1, 2,3,4.

Перечень и состав заданий руководителя проекта, разработчикам разделов
проектной документации приведен в приложениях: Приложение 7-9. Таблица 1. и
Приложение 9-10. Таблица 1.

Перечень и состав заданий начальников отделов (групп) руководителю
проекта (ГИПу, ГАПу) и разработчикам разделов проектной документации
приведен в Приложениях: Приложение 10-10. Таблица 1., Приложение 11-10.
Таблица 1., Приложение 12-10. Таблица 1., Приложение 13-10. Таблица 1.,
Приложение 14-10. Таблица 1., Приложение 15-10. Таблица 1., Приложение 16-10.
Таблица 1.

Перечень и состав заданий разработчиков разделов проектной документации
приведен в приложениях: Приложение 10-10. Таблицы 2,3,4,5,6., Приложение 1110.
Таблицы 1,2,3,4., Приложение 12-10. Таблицы 2,3., Приложение 13-10. Таблица
2., Приложение 14-10. Таблица 2., Приложение 15-10. Таблица 2., Приложение 1610.
Таблицы 2,3.

На основе Графика подготовки проектной документации может быть
выполнен полистовой график с указанием исполнителей по каждому виду работ или листу, срокам разработки каждого вида работ или листа. (Пример приведен в
Приложении 6-7. Таблица 3).

Вернуться наверх

8. Договор на выполнение работ по подготовке проектной документации

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

Отношения между застройщиком (техническим заказчиком) и
привлекаемыми на договорной основе регулируются ст. 758-762 [1].

По договору подряда на выполнение проектных работ проектная
организация (подрядчик) обязуется по заданию заказчика разработать проектную
документацию, а заказчик обязуется ее принять и оплатить. Подрядчик обязан:

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

Заказчик обязан:

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

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

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

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

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

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

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

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

Согласно п. 5.2 ст. 48 [1] договором о подготовке проектной документации
может быть предусмотрено задание на выполнение инженерных изысканий. В этом
случае проектная организация осуществляет также организацию и координацию
работ по инженерным изысканиям и несет ответственность за достоверность,
качество и полноту выполненных инженерных изысканий. Договором также может
быть предусмотрено получение проектной организацией технических условий на
подключение к сетям инженерно — технического обеспечения.

Вернуться наверх

9. Описание технологической последовательности подготовки
проектной документации

Технологическая последовательность подготовки проектной документации
состоит из 6-ти этапов:

• Этап 1. «Предварительные решения проектной документации». Поиск и
  принятие концептуальных объемно-планировочных и архитектурных решений,
  согласованных с требованиями действующих нормативных документов.
  Согласование принятых решений в установленном заданием на проектирование
  порядке.
• Этап 2. Поиск и принятие объемно-планировочных и архитектурных
  решений, согласованных с требованиями действующих нормативных документов.
• Этап 3. Разработка и согласование инженерных решений с объемнопланировочными
  решениями.
• Этап 4. Разработка разделов ПЗУ, АР, КР, ЭЭ, ОДИ, ИОС проектной
  документации в полном объеме и выдача документации ГИПу.
• Этап 5. Разработка разделов СМ, ПОС, ПОД, ООС проектной
  документации в полном объеме и выдача документации ГИПу.
• Этап 6. Выдача проектной документации в полном объеме заказчику.
  Объемы работ по этапу 1 производятся по объектам капитального
  строительства, расположенным в особо значимых местах застройки и имеющим
  ключевое значение в организации застройки территорий, архитектурное и
  объемно-планировочное решение которых требует профессионального и
  общественного обсуждения, а также по объектам технически и технологически
  сложным и не имеющим аналогов.
  Подготовка проектной документации по объекту производится на
  основании задания руководителя проекта (ГИПа, ГАПа).
  Форма и содержание задания руководителя проекта на подготовку
  проектной документации отделам (группам) приведена в Приложении 7-9.
  Таблица 1.
  Этапность и технологическая последовательность подготовки проектной
  документации, порядок выдачи заданий разработчиками разделов проектной
  документации друг другу приведены в Приложении 8-10. Таблицы 1,2.
  Перечень и состав заданий руководителя проекта, разработчикам разделов
  проектной документации приведен в Приложении 9-10. Таблица 1.
  Перечень и состав заданий начальников отделов (групп) руководителю
  проекта (ГИПу, ГАПу) и разработчикам разделов проектной документации
  приведен в Приложениях: Приложение 10-10. Таблица 1., Приложение 11-10.
  Таблица 1., Приложение 12-10. Таблица 1., Приложение 13-10. Таблица 1.,
  Приложение 14-10. Таблица 1., Приложение 15-10. Таблица 1., Приложение 16-10.
  Таблица 1.
  Перечень и состав заданий разработчиков разделов проектной документации
  приведен в приложениях: Приложение 10-10. Таблицы 2,3,4,5,6., Приложение 1110.
  Таблицы 1,2,3,4., Приложение 12-10. Таблицы 2,3., Приложение 13-10. Таблица
  2., Приложение 14-10. Таблица 2., Приложение 15-10. Таблица 2., Приложение 1610.
  Таблицы 2,3.

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

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

Вернуться наверх

10. Таблицы технологической последовательности

Этапность и технологическая последовательность подготовки проектной
документации, порядок выдачи заданий разработчиками разделов проектной
документации друг другу приведены в Приложении 8-10. Таблицы 1,2.

Перечень и состав заданий руководителя проекта, разработчикам разделов
проектной документации приведен в Приложении 9-10. Таблица 1.

Перечень и состав заданий начальников отделов (групп) руководителю
проекта (ГИПу, ГАПу) и разработчикам разделов проектной документации
приведен в Приложениях: Приложение 10-10. Таблица 1., Приложение 11-10.
Таблица 1., Приложение 12-10. Таблица 1., Приложение 13-10. Таблица 1.,
Приложение 14-10. Таблица 1., Приложение 15-10. Таблица 1., Приложение 16-10.
Таблица 1.

Перечень и состав заданий разработчиков разделов проектной документации
приведен в приложениях: Приложение 10-10. Таблицы 2,3,4,5,6., Приложение 1110.
Таблицы 1,2,3,4., Приложение 12-10. Таблицы 2,3., Приложение 13-10. Таблица
2., Приложение 14-10. Таблица 2., Приложение 15-10. Таблица 2., Приложение 1610.
Таблицы 2,3.

Вернуться наверх

11. Контроль качеств
11.1 Общие положения

Контроль качества является неотъемлемой частью разработки проектной
документации и ее завершающим этапом.

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

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

Рекомендуемая периодичность осуществления контроля качества проектных
работ:

• до начала работ (предпроектный контроль);
• текущий (при выполнении работ);
• нормоконтроль (при завершении разделов, подразделов и работ в целом);
• выходной контроль (при выдаче проектной документации заказчику).

Вернуться наверх

11.2 Предпроектный контроль

До заключения контракта руководитель проекта (ГИП, ГАП) определяет
соответствие уровня возможностей предприятия предполагаемому для исполнения
заданию на проектирование, а именно:

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

Результат предпроектного контроля оформляется руководителем проекта
(ГИПом, ГАПом), в виде служебной записки на имя руководителя предприятия для
принятия решения о заключении контракта и планирования мер по его
исполнению.

Вернуться наверх

11.3 Текущий контроль

Осуществляется руководителем проекта (ГИПом, ГАПом), назначенным
Приказом по предприятию для руководства проектными работами для конкретного
объекта капстроительства.

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

Документация передаётся на текущий контроль для подписания в графах
«Проверил» после получения подписей разработчиков смежных разделов
(подразделов) в боковых дополнительных графах «Согласовано».

В случае выявления нарушений в расчетах, оформлении чертежей и т.д. или
Несоответствия принятых проектных решений действующим нормативным
документам, техническим регламентам и заданию на проектирование,
руководитель проекта ГИП (ГАП) или руководитель группы выдаёт разработчику перечень замечаний со сроками их исправлений, и уведомляет руководителя
предприятия служебной запиской о нарушениях имеющих системный характер для
принятия корректирующих действий.

Вернуться наверх

11.4 Нормоконтроль — за правильностью применения проектных норм при выполнении работ по подготовке проектной документации

Нормоконтроль осуществляется в соответствии с разделом 12 настоящего
«Руководства по подготовке проектной документации для объектов капитального
строительства производственного и гражданского назначения».

Вернуться наверх

11.5 «Выходной» контроль

«Выходной» контроль осуществляется рабочей комиссией в составе
руководителя проекта ГИПа (ГАПа), руководителей отделов (групп), других
специалистов, назначенных распоряжением руководителя предприятия, с целью
определения готовности результатов работ, выполненных работниками
предприятия и субпроектировщиками, для предъявления заказчику.

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

В случае положительного решения рабочей комиссии о готовности разделов
(подразделов) или проектной документации в целом, для предъявления Заказчику,
руководитель предприятия (главный инженер, исполнительный директор) ставит
свою утверждающую подпись на титульных листах соответствующих разделов и
подразделов, а руководитель проекта (ГИП, ГАП) подписывает в пояснительной
записке заверение, о том, что проектная документация разработана в соответствии
с заданием, техническими регламентами и т.п.

Вернуться наверх

11.6 Внешний контроль — экспертиза проекта

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

Вернуться наверх

12. Нормоконтроль проектной документации
12.1 Назначение

Настоящий раздел Руководства по подготовке проектной документации для
объектов капитального строительства производственного и гражданского
назначения устанавливает задачи, порядок проведения и содержание
нормоконтроля проектной документации для строительства объектов
капитального строительства, а также ответственность и права специалиста,
осуществляющего нормоконтроль. Раздел обеспечивает реализацию
окончательного контроля готовой проектной продукции, предусмотренного
стандартом организации СТО-04006399-06-2005 и п.8.2.3. ГОСТ ISO 9001-2011.

Раздел включает требования ГОСТ Р 21.1002-2008 и дополняет их в части
обеспечения качества, рассматривая нормоконтроль как один из видов
контроля в системе менеджмента качества.

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

Вернуться наверх

12.2 Область применения

12.2.1 Требования раздела распространяется:

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

Вернуться наверх

12.3 Применяемые термины и сокращения

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

12.3.2 Применяемые сокращения:

• ПИО — проектно-изыскательская организация;
• СМК — система менеджмента качества;
• РК — руководство по качеству;
• СТО — стандарт организации;
• РИ — рабочая инструкция;
• ДП — документированная процедура;
• ТЭО — технико-экономические обоснования проекта.

Вернуться наверх

12.4 Ответственность

12.4.1 Руководство организации несет ответственность за уровень
компетенции, объективности и подготовки специалиста, назначенного
выполнять функции лица, осуществляющего нормоконтроль.

12.4.2 Главный инженер организации несет ответственность:

• за осуществление нормоконтроля проектной документации в организации,
  как вида проверки в процессе производства, обязательность проведения
  которой является не только требованием ГОСТ ISO 9001-2011, но и
  установлена межгосударственными стандартами СПДС (ГОСТ Р 21.1002 и
  ГОСТ Р 21.1101).

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

12.4.4 Руководитель проекта (ГИП, ГАП) несет ответственность за проведение
нормоконтроля всех видов проектной документации, выполняемой по
договору, руководителем работ которого он является.

12.4.5 Специалист, осуществляющий нормоконтроль, несет ответственность
за:

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

Вернуться наверх

12.5 Описание выполняемых действий

12.5.1 Задачи нормоконтроля:

12.5.1.1 Основными задачами нормоконтроля являются:

• Обеспечение соответствия проектной документации требованиям
  действующих межгосударственных, государственных, отраслевых стандартов,
  стандартов предприятия, строительных норм и правил и др. внешних и
  внутренних нормативных документов, применяемых при проектировании
  объекта строительства;
• Обеспечение комплектности документации, передаваемой Заказчику в
  объеме, установленном договором (контрактом) и соответствующими
  нормативными документами;
• Проведение корректирующих действий по исправлению обнаруженных
  отклонений от нормы до выпуска продукции;
• Анализ выявленных замечаний в целях возможности подготовки
  предупреждающих действий и улучшения качества.

12.5.1.2 Нормоконтроль должны осуществлять высококвалифицированные
специалисты, утвержденные приказом или распоряжением руководства
организации.

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

12.5.1.4 Всю проектную документацию предъявляют на нормоконтроль в
соответствии с планом — графиком ее выпуска, в котором должно быть
предусмотрено время на проведение нормоконтроля.

12.5.2 Порядок проведения нормоконтроля:

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

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

12.5.2.3 При проведении проверки специалист, осуществляющий
нормоконтроль, должен руководствоваться только установленными
требованиями действующих документов.

12.5.2.4 Предъявленная на нормоконтроль документация должна быть
зарегистрирована в «Карточке учета документации и регистрации и
несоответствий» при проведении нормоконтроля. Форма карточки приведена в
12-Приложении 5.

12.5.2.5 Документы, не подписанные нормоконтролером, не должны
приниматься техническим архивом (на учет, хранение и тиражирование) и не
подлежат передаче Заказчику.

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

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

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

12.5.2.9 Специалисты, не назначенные руководством или участвующие в
разработке документа, не имеют право подписывать документы за
нормоконтролера.

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

12.5.2.11 Подпись специалиста, осуществляющего нормоконтроль, следует
проставлять на каждом листе подлинника документа в основной надписи,
выполняемой по формам 3, 4, и 5 приложения Ж ГОСТ Р 21.1101.2013.
При привязке типовых и повторно — применяемых проектов подпись
нормоконтролера проставляют в штампах привязки. При оформлении
«Разрешения на внесение изменений» — в дополнительных графах основной
надписи (ГОСТ Р 21.1101-2013).

Специалист, осуществляющий нормоконтроль, проверяет правильность
внесенных изменений в соответствии с содержанием «Разрешения на внесение
изменений» и подписывает подлинник документа в дополнительных графах
основной надписи, отведенных для согласования.

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

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

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

12.5.3 Содержание нормоконтроля

12.5.3.1 Нормоконтролю подлежат:

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

12.5.3.2 Специалист, осуществляющий нормоконтроль проектной
документации проверяет:

• соответствие обозначений документов, установленной в организации
  системе обозначения (кодирование);
• внешний вид предъявляемой проектной документации;
• комплектность и состав проектной документации;
• соблюдение требований, установленных к документации, подлежащей
  микрофильмированию;
• правильность оформления привязок типовых проектов (типовых
  проектных решений);
• правильность применения типовых конструкций, изделий и узлов;
• наличие и правильность ссылок на действующие нормативные
  документы;
• соответствие оформления документации требованиям стандартов СПДС
  и ЕСКД, распространяющихся на строительство (ГОСТ Р 21.1101, 12-
  Приложении 6;
• возможность сокращения объема документации, отсутствие
  дублирования на чертежах и в текстовых документах;
• правильность оформления Разрешений на внесение изменений и
  наличие в них необходимых подписей;
• соответствие внесенных изменений в ранее выполненную и выданную
  Заказчику проектную документацию утвержденному Разрешению на внесение
  изменений;
• целесообразность замены индивидуальных конструкций, изделий и
  узлов типовыми, стандартизированными или повторно — применяемыми;
• правильность присвоения наименований и обозначений изделиям и
  материалам;
• правильность нанесения позиционных обозначений (марок) на
  сборочных чертежах, марок оборудования и элементов конструкций — на
  чертежах расположения оборудования и схемах расположения элементов
  конструкций;
• соответствие предусмотренного в документации оборудования
  указанному в действующих каталогах или согласованному с заказчиком;
• соблюдение правил заполнения основных надписей, ведомостей,
  спецификаций и др. таблиц;
• правильность наименований и обозначений и документов на изделия,
  материалы, записанных в ведомостях, спецификациях и таблицах.

12.5.3.3 Средняя норма проверки документов специалистами,
осуществляющими нормоконтроль за 8-часовой рабочий день (независимо от
специализации), составляет 80-100 листов, приведенных к формату А4. Нормы
проверки Разрешений на внесение изменений должны быть такими же, как и
для документов, на которые эти Разрешения выполняют.
При необходимости проведения нормоконтроля документов в подлинниках и
оригиналах, норма проверки соответственно увеличивается.

В эту норму не входит время, затрачиваемое на:

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

12.5.3.4 Специалист, осуществляющий нормоконтроль, проводит анализ
несоответствий, обнаруженных при проверке документа, и результаты анализа
(по форме, приведенной в 12-Приложении 6), ежемесячно передает в службу
качества.

12.5.4 Права специалиста, осуществляющего нормоконтроль. Специалист, осуществляющий нормоконтроль имеет право:

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

Вернуться наверх

12.6 Записи по качеству

Результаты управления процессами, описанными в разделе 12.5,
обеспечивающие нормоконтроль проектной документации, должны
подтверждаться соответствующими данными по установленной форме.
Регистрацию записей по качеству следует осуществлять с учетом требований
процедуры СМК-ДП-02/05.

Сведения о записях по качеству, осуществляемых в процессе выполнения
данной процедуры, приведены в «12 — Таблица 1».

Вернуться наверх

13. Согласование проектной документации

Проектная документация утверждается застройщиком или техническим
заказчиком. В случаях, предусмотренных статьей 49 ГК № 190-ФЗ, застройщик или
технический заказчик до утверждения проектной документации направляет ее на
экспертизу. При этом проектная документация утверждается застройщиком или
техническим заказчиком при наличии положительного заключения экспертизы
проектной документации, (п. 15 ст. 48 [2]).

Не допускается требовать согласование проектной документации, заключение на
проектную документацию и иные документы, не предусмотренные настоящим
Кодексом, (п. 16 ст. 48 [2]).

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

• если требование о согласовании проектной документации включено в задание
  на проектирование или в исходно-разрешительных документах. В этом случае в
  задании на проектирование или в исходно-разрешительных документах должно
  быть конкретно отражено, какие разделы проектной документации и с какими
  организациями должны быть согласованы.
• если при подготовке проектной документации допущены отклонения от
  положений технических условий на инженерное обеспечение объекта. В этом
  случае согласование производится только с организациями, выдавшими
  технические условия, по которым произошли отклонения.
• если при подготовке проектной документации допущены отклонения от
  требований и положений действующих градостроительных документов,
  градостроительного плана и в случае отклонения от предельных параметров
  разрешенного строительства и реконструкции объектов капитального
  строительства. Правообладатели земельных участков, размеры которых меньше
  установленных градостроительным регламентом минимальных размеров
  земельных участков либо конфигурация, инженерно-геологические или иные
  характеристики которых неблагоприятны для застройки, вправе обратиться за
  разрешениями на отклонение от предельных параметров разрешенного
  строительства, реконструкции объектов капитального строительства, (п. 1 ст. 40
  [2]). Порядок согласования отклонения от предельных параметров разрешенного
  строительства, реконструкции определен ГК № 190-ФЗ. (ст. 40 [2]).
• случае если для разработки проектной документации на объект капитального
  строительства недостаточно требований по надежности и безопасности,
  установленных нормативными техническими документами, или такие требования
  не установлены, разработке документации должны предшествовать разработка и
  утверждение в установленном порядке специальных технических условий. Порядок разработки и согласования специальных технических условий
  устанавливается Министерством регионального развития Российской Федерации
  по согласованию с федеральными органами исполнительной власти,
  осуществляющими функции по нормативно-правовому регулированию в
  соответствующих сферах деятельности, (п. 5 [8])

Вернуться наверх

14. Выдача проектной документации заказчику

Копии текстовых и графических материалов проектной документации, а
также отчетной технической документации по инженерным изысканиям
брошюруют в тома сложенными на формат А4 по ГОСТ 2.301. (п.8.1 [40]).

Под брошюровкой понимается размещение материалов проектной
документации в переплетах или твердых папках с легкоразъемными креплениями
(замками), (п.8.1 [40]).

Копии документов рабочей документации для передачи заказчику
комплектуют в папки полистно сложенными на формат А4, как правило, отдельно
по разделам проектной документации, (п.8.2 [40]).

Правила оформления сброшюрованной документации приведены в п. 8 ГОСТ
Р 21.1101.2013 [40].

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

Руководитель проекта (ГИП, ГАП) формирует полный комплект проектной
документации, а также материалов отчетно-технической документации по
инженерным изысканиям на электронном носителе в форматах, определенных
заданием на проектирование.

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

Выдачу проектной документации заказчику осуществляет Отдел механизации
и выпуска проектов на основании указаний руководителя проекта (ГИПа, ГАПа).
Отдел механизации и выпуска проектов комплектует, оформляет и
переплетает проектную документацию, оформляет накладные документы и
отправляет проектную документацию заказчику.

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

Отдел механизации и выпуска проектов передает руководителю проекта
(ГИПу, ГАПу) полный комплект проектной документации, состоящий из
сброшюрованных в тома текстовых и графических материалов проектной
документации, а также материалов отчетно-технической документации по
инженерным изысканиям для передачи в архив.

Вернуться наверх

15. Порядок внесения изменений в проектную документацию

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

Обозначение документа допускается изменять только в случае, если разным
документам ошибочно присвоены одинаковые обозначения или в обозначении
документа допущена ошибка.

Внесение изменений в расчеты не допускается, (п.7.1.2 [40]).

Если изменение документа неприемлемо, то должен быть выпущен новый
документ с новым обозначением, (п.7.1.3 [40]).

Любое изменение в документе, вызывающее какие-либо изменения в других
документах, должно одновременно сопровождаться внесением соответствующих
изменений во все взаимосвязанные документы, (п.7.1.4 [40]).

Общий порядок и правила внесения изменений в проектную документацию
регламентирован п.7 «Правила внесения изменений» ГОСТ Р 21.1101.2013. [40].

Особенности внесения изменений в проектную документацию
регламентированы п.7.4 ГОСТ Р 21.1101.2013. [40].

Вернуться наверх

16. Передача проектной документации в архив

Передача проектной документации в архив осуществляется руководителем
проекта (ГИПом, ГАПом) по завершению 6-го этапа «Выдача проектной
документации заказчику» технологического процесса подготовки проектной
документации по разделам. Руководитель проекта (ГИП, ГАП) обязан передать в
архив полный комплект проектной документации, как на бумажном, так и на
электронном носителях.

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

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

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

Вернуться наверх

Скачать «Руководство по подготовке проектной документации для объектов капитального строительства производственного и гражданского назначения»