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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование и документирование проекта

Какие фазы можно выделить в жизненном цикле проекта внедрения?

Основа жизненного цикла проекта внедрения СЭД состоит из шести фаз:

1.      Фаза инициации проекта.

2.      Фаза проектирования.

3.      Фаза разработки.

4.      Фаза обучения пользователей.

5.      Фаза опытной эксплуатации.

6.      Фаза ввода в промышленную эксплуатацию.

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

Какие работы входят в фазу инициации проекта? 

Фаза инициации проекта

Ключевые задачи этапа:

§ Проведение первичного анкетирования Заказчика. Выявление сведений о среднем количестве документов за прошлый год (входящие, исходящие, ОРД), количество сотрудников, предполагаемых к подключению к СЭД, возможностей ИТ-структуры.

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

§ Описание границ и рамок проекта всеми заинтересованными лицами.

§ Согласование коммерческих условий выполнения работ по проекту (в случае консалтингового проекта), первичная оценка стоимости проекта.

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

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

Какие работы входят в фазу проектирования системы?

Фаза проектирования системы

Ключевые задачи:

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

§ Анализ и консолидация полученной информации. Формирование списка видов документов, распределение ответственности при обработке документов. Описание бизнес-процессов («как есть»).

§ Проведение краткого обучения ключевых сотрудников Заказчика возможностям СЭД (опционально).

§ Внесение предложений по оптимизации описанных процессов, разработка процессов «как будет». Утверждение описанных бизнес-процессов.

§ Сбор и анализ требований к СЭД. Определение требований к аппаратному и программному обеспечению СЭД. Утверждение требований к СЭД.

§ Определение структуры и категорий внутренних документов, ролей и прав доступа пользователей. (передача форм, помощь в заполнении).

§ Решение вопросов синхронизации при наличии других источников информации (баз данных).

§ Анализ требований Заказчика в разрезе отклонений от типового функционала системы.

§ Оформление согласование и утверждение Технического задания на проект.

§ Разработка, согласование и утверждение методики и программы испытаний СЭД в составе Технического задания на проект.

Какие работы входят в фазу разработки?

Фаза разработки

Ключевые задачи:

§ Разработка конфигурации СЭД, в которой реализованы все требования Технического задания.

§ Проведение тестирование СЭД со стороны Исполнителя.

§ Проведение испытаний СЭД со стороны Заказчика. Подписание акта сдачи-приемки.

§ Принятие решения о запуске СЭД в опытную эксплуатацию.

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

Фаза обучения пользователей

Ключевые задачи:

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

§ Разработка плана и методики проведения обучения.

§ Проведение обучения персонала использованию СЭД.

§ Тестирование и анализ проведения обучения.

Какие работы входят в фазу опытной эксплуатации?

Фаза опытной эксплуатации

Ключевые задачи:

§ Подготовка технической инфраструктуры для развертывания СЭД в опытную эксплуатацию.

§ Проведение опытной эксплуатации системы на основе реальных данных.

§ Проведение приемо-сдаточных испытаний (валидации) информационной системы.

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

§ Принятие решения о вводе СЭД в промышленную эксплуатацию с определенной даты, в виде формального документа с доведением до сведения сотрудников предприятия.

§ Эффективное управление изменениями, возникающих по факту использования системы в процессе опытной эксплуатации.

Какие работы входят в фазу ввода в промышленную эксплуатацию? 

Фаза ввода в промышленную эксплуатацию

Ключевые задачи:

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

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

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

§ Актуализация проектной документации (плана проекта, бюджетов и т.п.) по факту окончания проекта.

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

Основные факторы, влияющие на успешность проектов внедрения

10 факторов успеха проекта внедрения СЭД

1.       Ясно поставленные цели.

2.       Подробная детализация плана проекта.

3.       План-фактный анализ на каждой стадии выполнения проекта.

4.       Высокая квалификация руководителя проекта и членов команды.

5.       Выделение одного конкретного ответственного для каждой задачи.

6.       Наличие административной поддержки и высркая вовлеченность персонала.

7.       Достаточное количество времени и ресурсов.

8.       Отлаженное информационное сопровождение проекта и коммуникации в команде.

9.       Хорошая организация и четкая, последовательная структура проекта.

10.    Умение руководителей использовать механизмы поиска и коррекции отклонений.

3 ошибки, ведущие к провалу проекта

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

1.       Сроки.

Ошибка: неверная оценка временных затрат на работы (срыв сроков).

2.       Стоимость.

Ошибка: некорректная оценка стоимости.

Ошибка: увеличение стоимости работ за счет разработки некачественного ТЗ.

3.       Объем.

Ошибка: увеличение объема работ за счет составления некачественного ТЗ.

Ошибка: поверхностная верификация системы, порождающая доработки.

Управление ожиданиями заказчика в случае отклонений

1.       Документирование (качественное ТЗ, спецификация СЭД, протоколы совещаний).

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

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

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

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

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

Небольшое лирическое отступление про то, что меня вдохновило на написание этого текста:

Теория разбитых окон

При разработке ИТ-систем мне кажется очень важным поддерживать порядок в документации. Это и есть та самая “стена”, на фоне которой разворачивается проектная жизнь — на нее смотрят и делают выводы, что это за проект и как там все работает.

Зачем писать

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

Обоснованность наличия документации — отдельная тема, об этом писали, например, здесь.

Если коротко — то “без бумажки ты букашка”. Наша память обманчива и недолговечна. Завтрашний ты обманешь себя сегодняшнего или наоборот. Придет новый человек или уйдет старый — каждый такой финт будет стоить вам дорого. Без общей картины вы будете заниматься микроменеджментом и разработкой того, что уже кем-то сделано, но он забыл вам об этом сказать. Будете делать петли и вставлять друг другу палки в колеса. А через полгода мучительно вспоминать, зачем нужен этот огромный кусок кода, который все тормозит. И это даже не касаясь кейса, когда вы заказали разработку на стороне.

Что писать

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

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

Легче кому-то одному потратить пару часов на документирование, чем всей команде постоянно проверять свою память.

То есть даже когда обстоятельства не в пользу полноценного описания системы и вы работаете в “Agile”-режиме — важно понимать, что какая-то документация существенно облегчит процесс разработки и принесет много пользы.

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

Необходимый минимум

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

1. Документ-маршрутизатор

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

   

2. Артефакты проектных процессов

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

   

3. Глоссарий

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

4. Артефакты бизнес-потребности и бизнес-процесса

   Agile-манифест гласит: “Работающий продукт важнее исчерпывающей документации”. Но нельзя разработать работающий “как надо” продукт без четкого понимания, что же мы все-таки делаем и зачем. Бизнес-требования, схема процесса или просто письмо с постановкой от заказчика — что-то должно быть.

   

5. Концептуальная модель системы

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

   Используйте IDEF0, «дорожки» BPMN, просто схему или текстовый перечень — главное обозначить принцип работы вашей системы.

   

6. Классы пользователей и уровни доступа

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

7. Cценарии использования

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

8. Логика работы системы

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

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

   

9. Описание АПИ

   Да пребудет с нами swagger и стандартный формат ответа методов. Если с вами интегрируются внешние компании — не обойтись и без подробного описания параметров.

10. Тестовые данные

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

11. Ограничения/нефункциональные требования

    Вы договорились, что рассчитываете максимум на 100 пользователей? Делаете импорт справочников раз в сутки в час ночи? Внешняя система не умеет принимать какие-то значения? Сделайте приятно себе в будущем — запишите все эти детали.

Другие типы документов

Потребность в некоторых документах возникает вариативно, в зависимости от особенностей проекта:

1. Архитектура системы

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

2. Требования к данным

   Логическая модель, требования к составу и формату данных, особенности работы с ними и пр. Всё это не всегда покрывается характеристиками БД — в таком случае полезно зафиксировать их в отдельном документе.

   Сюда же можно добавить соглашения о формате БД — принципы наименования таблиц и атрибутов, используемые типы данных и пр.

3. UX/UI макеты и прототипы

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

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

   

4. Описание интеграций

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

   

5. Безопасность

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

6. Внешняя документация

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

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

Как писать

Несколько инсайтов о работе с документацией:

• Не забывайте про актуальность

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

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

  

• Неоформленные артефакты — тоже документация

  Удобно складывать в одно место те артефакты, которые нет возможности обработать и хорошо оформить.

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

• Растите культуру документирования в команде

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

  Важно договориться, как такая документация будет поддерживаться.

  

• Комментарии в коде не всегда спасают

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

• Планируйте и декомпозируйте работу с документацией

  Документирование — это задача, которую легко разбить на небольшие отрезки времени и “размазать” по спринту.

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

• Закрывайте техдолг

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

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

  

• Больше схем и диаграмм

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

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

• Учитесь писать нехудожественные тексты

  Навык написания текстов сильно ускоряет процесс документирования и повышает его качество. Рекомендую использовать https://glvrd.ru. Плюс по возможности почитать «Пиши, сокращай» и «Бизнес-копирайтинг». Так и работа быстрее пойдет, и тексты станут понятнее и приятнее.

  Вот еще хороший доклад на тему «Как писать полезные технические тексты».

Как итог

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

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

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

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

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-го этапа «Выдача проектной
документации заказчику» технологического процесса подготовки проектной
документации по разделам. Руководитель проекта (ГИП, ГАП) обязан передать в
архив полный комплект проектной документации, как на бумажном, так и на
электронном носителях.

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

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

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

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

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