Проектирование проектной документации: Проектирование

Содержание

от составления ЗнП до согласования и экспертизы

Дата публикации: 12 апреля 2021
Дата обновления материала: 8 декабря 2021

  • Порядок и этапы проектирования
    • Составление задания на проектирование
    • Исходно-разрешительная документация
    • Инженерные изыскания
    • Разработка основных технических решений
    • Разработка проектной документации
    • Разработка рабочей документации
    • Экспертиза
    • Согласование и экспертиза проектной и рабочей документации

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

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

В данной статье рассмотрим такие вопросы, как:

  1. Методы проектирования.
  2. Этапы проектирования и их последовательность.
  3. Какие исходные данные необходимы для проектирования.
  4. Обязательные требования к Проектной и Рабочей документации.
  5. Согласование и экспертиза Проектной и Рабочей документации.

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

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

Различают одностадийное и двухстадийное проектирование.

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

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

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

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

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

Модели и чертежи обычно выполняются в специализированных программных комплексах — системах автоматизированного проектирования (САПР). Яркими примерами САПР являются Autodesk Autocad, Компас 3D и другие. Учитывая высокую стоимость лицензионных программных комплексов для разработки небольших объектов можно использовать бесплатные программы для проектирования, например, отечественную разработку nanoCAD.

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

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

  1. Составление задания на проектирование.
  2. Сбор исходно-разрешительной документации.
  3. Выполнение инженерных изысканий на площадке строительства.
  4. Разработка основных технических решений (ОТР).
  5. Разработка проектной документации для получения согласований и заключения экспертизы.
  6. Экспертиза проектной документации.
  7. Разработка рабочей документации.

Составление задания на проектирование

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

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

Согласно Постановлению Правительства о составе разделов проектной документации и требованиях к их содержанию №87 (ПП №87) существует документ «ЗАДАНИЕ НА ПРОЕКТИРОВАНИЕ» (далее — ЗнП). Юридических терминов «техническое задание на проектирование», «Техническое задание» в ПП №87 нет. Состав ЗнП линейных объектов в действующих федеральных нормативно правовых актах (НПА) не дан и устанавливается с учётом отраслевой специфики и вида строительства. Иными словами, вы не сможете дать юридического обоснования, почему задание на проектирование содержит или не содержит те или иные данные.

Мы можем порекомендовать согласовать форму ЗнП заранее.

На практике при заключении договора между Заказчиком и Подрядчиком на выполнение определённых работ к договору есть приложение — «Техническое задание» (далее — ТЗ). Обычно ТЗ объединяет в себе задание на проектирование и задание на СМР или объединяет в себе несколько направлений работ.

Например, ТЗ на проектирование и строительство ПС, ВЛЭП, отпаек от ВЛЭП и создание ВОЛС-ВЛ. Проектирование и строительство ВОЛС-ВЛ в этом случае — раздел в этом большом проекте.

Но не стоит отчаиваться, одним из выходов будет обратиться к внутренним стандартам организации ПАО «ФСК ЕЭС».  ПАО «ФСК ЕЭС» — владелец большинства магистральных ВЛЭП 35 кВ и выше в нашей стране, следовательно, его стандарты подойдут в большинстве случаев. Согласно СТО 56947007-33.180.10.171-2014 «Технологическая связь. Эталон проектной документации на строительство ВОЛС-ВЛ с ОКСН и ОКГТ» в разделе 5.2 даны требования к заданию на разработку проектной документации.

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

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

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

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

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

Почти при любом проектировании основными являются следующие ИД:

  1. ЗнП, выданное проектной организации заказчиком и служащее юридической основой для проектирования.
  2. Правоустанавливающие и разрешительные документы.
  3. Технические условия (ТУ).
  4. Данные об условиях участка под размещение объекта.

ЗнП, его состав и анализ были рассмотрены выше.

Правоустанавливающие и разрешительные документы закрепляют права на занимаемые территории и помещения, например:

  • решение местного органа исполнительной власти о согласовании места размещения объекта,
  • правоустанавливающие документы на землю,
  • акт выбора земельного участка (трассы) для строительства,
  • договор аренды помещения или определённого места в помещении/стойке.

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

ТУ могут быть:

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

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

  • топографический план участка проектирования,
  • данные об инженерно-геологических условиях участка,
  • климатические условия,
  • сведения о существующих сетях связи, существующих станционных и линейных сооружениях, затрагиваемых при данном проектировании,
  • строительные паспорта участков, содержащие основные технические данные по выбранным земельным участкам для прокладки трасс и наземных сооружений, коммуникаций,
  • информация по используемым сооружениям, подземным и наземным коммуникациям,
  • акты по определению пригодности оборудования (например, акты выбора ВЛ, акты обследования состояния опор и фундаментов ВЛЭП, заключение об их состоянии, отчёты о периодических осмотрах и отказах),
  • данные ГИС (Географическая информационная система — система сбора, хранения, анализа и графической визуализации пространственных данных и связанной с ними информации о необходимых объектах).

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

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

Сбор Исходных данных — не обязанность проектировщика, это услуга, которая оказывается за деньги.

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

Исходно-разрешительная документация

Сбор исходно-разрешительной документации (ИРД) выполняется на самых ранних этапах проектирования или предшествует ему, как самостоятельная, независимая работа.

Исходно-разрешительная документация — это комплект материалов, характеризующих будущий объект строительства и отведённую для этих нужд площадку.

В состав исходно-разрешительной документации обязательно включаются:

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

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

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

Инженерные изыскания

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

Состав и объем инженерных изысканий нормируется положениями Свода Правил СП 47.13330.2012 («Инженерные изыскания для строительства. Основные положения»).

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

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

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

Согласно Градостроительному кодексу результаты инженерных изысканий могут быть направлены на экспертизу одновременно с проектной документацией или до направления проектной документации на экспертизу.

Разработка основных технических решений

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

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

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

В настоящее время российские нормативы определяют две стадии проектирования: «Проектная документация» и «Рабочая документация». Состав и объём текстовых и графических материалов определяются в соответствии с Постановлением Правительства РФ №87 от 16.02.08 г. «О составе разделов проектной документации и требования к их содержанию» (ПП №87).

Согласно Постановлению №87, объекты капитального строительства в зависимости от функционального назначения и характерных признаков подразделяются на следующие виды:

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

При строительстве ВОЛС и ЛКС нас будет интересовать состав проектной документации для линейных объектов:

  • Раздел 1 “Пояснительная записка”,
  • Раздел 2 “Проект полосы отвода”,
  • Раздел 3 “Технологические и конструктивные решения линейного объекта. Искусственные сооружения”,
  • Раздел 4 “Здания, строения и сооружения, входящие в инфраструктуру линейного объекта”,
  • Раздел 5 “Проект организации строительства”,
  • Раздел 6 “Проект организации работ по сносу (демонтажу) линейного объекта”,
  • Раздел 7 “Мероприятия по охране окружающей среды”,
  • Раздел 8 “Мероприятия по обеспечению пожарной безопасности”,
  • Раздел 9 “Смета на строительство”,
  • Раздел 10 “Иная документация в случаях, предусмотренных федеральными законами”.

Разработка рабочей документации

Стадия «Рабочая документация» разрабатывается на основании технических решений (ОТР), определённых в Проектной документации.

Документом, регламентирующим состав, форму и содержание материалов данной стадии, является Национальный Стандарт Российской Федерации ГОСТ Р 21.101-2020 – “Система проектной документации для строительства. Основные требования к проектной и рабочей документации”.

Данный стандарт содержит требования к:

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

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

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

В соответствии с Положением о порядке проведения экспертизы проектной документации, утвержденным Постановлением Правительства Российской Федерации №145 от 05.03.2007 г., повторной экспертизе подлежат те части Проектной документации, в которые были внесены изменения, влияющие на конструктивную безопасность и надежность запроектированного объекта.

Экспертиза

Экспертиза проектной документации выполняется для всех объектов кроме случаев, оговоренных статьей 49 Градостроительного Кодекса РФ (в большинстве случаев это технически несложные объекты, на строительство которых не требуется разрешение).

Организация и проведение экспертизы проектной документации регламентируется Положением, утвержденным Постановлением Правительства Российской Федерации №145 от 05.03.2007 г.

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

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

Начиная с сентября 2016 года, подача материалов в Государственную экспертизу осуществляется только в электронном виде.

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

Стоит отметить, что если возведение объекта планируется на особо охраняемых природных территориях, то необходимо следовать «Правилам представления проектной документации объектов, строительство, реконструкцию, капитальный ремонт которых предполагается осуществлять на землях особо охраняемых природных территорий, для проведения государственной экспертизы и государственной экологической экспертизы» утверждённым постановлением Правительства РФ от 7 ноября 2008 г. N 822).

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

Оформленная должным образом проектная и рабочая документация передаётся на ознакомление и согласование с Заказчиком. Правила оформления и сроки предоставление документации Заказчику приведены в ЗнП.

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

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

С другой стороны, если в проекте запроектировано создание «объектов капитального строительства», которые попадают под действие «Градостроительного кодекса РФ» (ФЗ №190 от 29.12.2004г.), то необходима государственная экспертиза проекта.

«Объектами капитального строительства» могут быть опоры связи, кабельная канализация и прочее. Государственная экспертиза проекта проходит в уполномоченном органе государственной экспертизы — ФАУ «Главгосэкспертиза России» и его филиалах. Следует упомянуть, что это достаточно дорогое удовольствие, которое занимает немало времени. Если проект прошёл государственную экспертизу, тогда выдаётся разрешение на строительство объекта.

Иногда складывается ситуация, что Заказчик проекта хочет подстраховаться при строительстве объекта связи. Для этого Заказчик требует с проектировщика провести экспертизу ПД, например, в ФГБУ «Центр МИР ИТ». Стоит помнить, что согласно приказу Министерства связи и массовых коммуникаций РФ от 26 августа 2014 г. №258 «Об утверждении Требований к порядку ввода сетей электросвязи в эксплуатацию» не требуется экспертиза проектной документации в ФГБУ «Центр МИР ИТ» (т. н. «связная экспертиза»). В этом случае экспертиза выполняется за счет средств Заказчика.

Цели и задачи проведения экспертизы:

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

При проведении экспертизы предпроектной и проектной документации обеспечивается проверка её соответствия:

  • исходным данным и техническим условиям,
  • требованиям в области связи, установленным Федеральным законом «О связи».

Порядок проведения экспертизы, в общих чертах следующий:

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

Реалии в РФ таковы, что постоянно вводятся/отменяются новые постановления, законы, инструкции, методические рекомендации, пояснения, регламенты и прочее, которые меняют (а некоторые кардинально) положение дел при проектировании, строительстве и эксплуатации сетей связи. Следует постоянно следить за ситуацией в этой сфере — интересная работа ГИПу обеспечена.

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

Алексей Солодков,
эксперт в области проектирования

 

что это и в чем отличие

Проектная и рабочая документация: что это и в чем отличие

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

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

Стадии проектной документации утверждены нормативно-правовыми актами (ПП РФ №87), состоят из 12 разделов.

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

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

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

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

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

РД-проектная документация включает в себя следующий состав.

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

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

Отличительные черты правильно составленной строительной документации:

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

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

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

В чем отличия пакетов документов

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

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

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


Проектная документация: оптимизация требований к составу и содержанию разделов

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

А.В. Красавин

Начальник Управления

Управление промышленной, ядерной, радиационной, пожарной безопасности и ГОЧС

Проектная документация: оптимизация требований к составу и содержанию разделов

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

Правила и принципы

Состав проектной документации объектов капитального строительства определен Градостроительным кодексом Российской Федерации, который предусматривает необходимость разработки не менее 14 разделов. При этом определение состава и требований к содержанию разделов проектной документации отнесено к полномочиям Правительства Российской Федерации.

В настоящий момент все требования к проектной документации собраны в «Положении о составе разделов проектной документации и требованиях к их содержанию», утвержденном постановлением Правительства Российской Федерации от 16 февраля 2008 года № 87 (далее – Положение). Оно устанавливает состав и требования к содержанию разделов проектной документации применительно к различным видам объектов капитального строительства, в том числе к линейным объектам, объектам производственного и непроизводственного назначения, к отдельным этапам строительства объектов капитального строительства, а также при проведении капитального ремонта или реконструкции объектов капитального строительства, включая линейные объекты.

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

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

По мнению экспертного сообщества, для определения направления оптимизации требований к составу и содержанию разделов проектной документации необходима глубокая проработка данного вопроса с проведением сравнительного анализа требований к составу и содержанию проектной документации как в отечественных строительных нормах, регулировавших данный вопрос на более ранних этапах становления строительной отрасли, так и с современным альтернативным подходом к данному вопросу в технически раз- витых государствах. Нормативные технические документы Госстроя СССР, такие, например, как СН 202-62 «Инструкция по разработке проектов и смет для промышленного строительства», СН 202-69 «Инструкция по разработке проектов и смет для промышленного строительства», СН 202-76 «Инструкция по разработке проектов и смет для промышленного строительства», СН 202-81 «Инструкция о со- ставе, порядке разработки, согласования и утверждения проектов и смет на строительство предприятий, зданий и сооружений», СНиП 1.02.01-85 «Инструкция о составе, порядке разработки, согласования и утверждения проектно-сметной документации на строительство предприятий, зданий и сооружений», СНиП 11-01-95 «Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство пред- приятий, зданий и сооружений» последовательно сменяли друг друга на протяжении длительного времени. Их изучение позволяет провести сравнительный анализ действовавших норм. По мнению отдельных специалистов, нормативная база того времени не соответствовала современным потребностям и сдерживала развитие экономики Российской Федерации, что и стало одним из стимулов для проведения реформы технического регулирования в строительной отрасли. Тем не менее анализ СН 202-81 «Инструкции о составе, порядке разработки, согласования и утверждения проектов и смет на строительство предприятий, зданий и сооружений» наглядно показывает актуальность и соответствие этих норм современным требованиям в сфере технического регулирования.

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

Принцип 1

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

Принцип 2

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

Принцип 3

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

Принцип 4

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

Принцип 5

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

Принцип 6

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

Сравнительный анализ

В начале восьмидесятых годов ХХ века проектная документация состояла из пяти разделов. К 2016 году количество разделов увеличилось до семнадцати. Для получения адекватной оценки сопоставим требования к составу и содержанию проектной документации на 2017 год и к началу восьмидесятых годов ХХ века. Как уже отмечалось, строительные нормы 1981 года предусматривали в составе проектной документации пять разделов: общая пояснительная записка, технологические решения, строительные решения, организация строительства и сметная документация. К примеру, раздел «Строительные решения» должен был содержать:

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

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

Большое количество разделов и подразделов проектной документации усложняет и удорожает процессы проектирования и экспертизы. Необходимость готовить такое большое количество разделов и подразделов приводит к привлечению множества субподрядных проектных организаций, что отрицательным образом сказывается на качестве проектной документации в целом, так как действия субподрядчиков нередко недостаточно скоординированы генеральной проектной организацией. В СССР проектно-сметная документация, разработанная субподрядными проектными организациями, использовалась генеральной проектной организацией при составлении общей пояснительной записки и других разделов проекта, представляемого на экспертизу и утверждение. Сегодня зачастую вместо монолитного проекта имеется набор слабо увязанных между собой разделов проектной документации, разработанных субподрядными организациями. Появлению в смежных разделах проектной документации проектных решений, не увязанных между собой, способствуют многочисленные дублирующие требования к содержанию разделов проектной документации, установленные Положением. Субподрядные организации, разрабатывая свой раздел, а зачастую отдельную инженерную систему, технологическое или конструктивное решение, не имеют представления об общей концепции развития объекта капитального строительства и о проектных решениях, разрабатываемых иными субподрядными организациями по смежным разделам. Генеральный проектировщик, не обладая достаточным количеством времени, что особенно проявляется при устранении замечаний при прохождении экспертизы, не имеет возможности обработать большое количество разделов и проектных решений, отданных на откуп субподрядным организациям. Своевременность внесения изменений в проект постановления Правительства Российской Федерации «О внесении изменений в постановление Правительства Российской Федерации от 16 февраля 2008 г. № 87» в соответствии с пунктом 15 плана мероприятий («дорожная карта») «Оптимизация требований к составу и содержанию разделов проектной документации объектов капитального строительства», утвержденного распоряжением Правительства Российской Федерации от 29 июня 2013 г. № 1336-р, обусловлена необходимостью корректировки состава разделов проектной документации. Какими могут быть иные возможности оптимизации требований к проектной документации, которые могли бы способствовать совершенствованию правового регулирования градостроительной деятельности и улучшению предпринимательского климата в сфере строительства?

Способы оптимизации

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

Ведомственные инструкции о составе, порядке разработки, согласовании и утверждении проектной и сметной документации на строительство учитывали специфику объектов капитального строительства, включая линейные объекты, что исключало излишние требования к составу и содержанию проектной документации. Например, ведомственные строительные нормы ВСН 39-86 «Инструкция о составе, порядке разработки, согласования и утверждения проектно-сметной документации на строительство скважин на нефть и газ» регламентировали требования к составу и содержанию проектной документации на строительство скважин на нефть и газ, на суше и на море, но в отличие от СН 202-81 предъявляли требования с учетом специфики проектируемых объектов, минимизируя состав и содержание разделов проектной документации. Ведомственные строительные нормы облегчали работу проектировщика и экономили время, исключали из состава и содержания разделов излишние требования к разрабатываемой проектной документации. Для еще большей оптимизации требований к проектной документации в развитие строительных норм разрабатывались приложения, которые содержали как примерный состав рабочего проекта, например, жилого дома, общественного здания или сооружения, так и примерный состав материалов определенных мероприятий, разрабатываемых в рабочем проекте, например, по охране окружающей среды. В настоящее время Положением не предусмотрены уточняющие требования к составу и содержанию разделов проектной документации, отражающих специфику отдельных объектов капитального строительства. Проектным сообществом были бы востребованы соответствующие материалы, определяющие минимально необходимый и достаточный набор мероприятий, обосновывающих выполнение требований по гражданской обороне, предупреждению чрезвычайных ситуаций природного и техногенного характера, обеспечению промышленной безопасности и безопасной эксплуатации объектов капитального строительства для проектной документации повторного использования, модифицированной проектной документации, а также для объектов метрополитена, автомобильных дорог, железных дорог, линий связи, магистральных трубопроводов, по добыче полезных ископаемых.

Не менее значительным является вопрос о требованиях, предъявляемых к содержанию разделов, проработке и детализации принимаемых проектных решений. Крайне важно определить, что следует разрабатывать и представлять на экспертизу в объеме проектной документации. Отсутствие однозначных требований к содержанию разделов проектной документации приводит к разногласиям между экспертами, проектировщиками на этапах проектирования и экспертизы. Градостроительным кодексом и иными законодательными и нормативными правовыми актами Российской Федерации предусмотрено одностадийное проектирование в виде «рабочего проекта». Поэтому остро стоит проблема определения степени детализации проектных решений и соответственно глубины экспертизы. Объем и степень детализации проектных решений, представляемых сегодня на экспертизу, зачастую завышены, что приводит к необоснованному усложнению и удорожанию проектирования, препятствует внедрению инновационных технологий и современного оборудования. Для прохождения экспертизы проектировщикам приходится максимально задействовать свои ресурсы для детальной проработки проектных решений и подбора оборудования. В значительной мере время, отведенное на реализацию инвестиционного проекта, тратится на подготовку проектной документации для прохождения экспертизы и получения разрешения на строительство. С момента получения разрешения на строительство и выхода рабочих на объект до ввода объекта в эксплуатацию проходит значительный временной промежуток – от нескольких месяцев до нескольких лет в зависимости от сложности и технико-экономических показателей объекта капитального строительства. В период строительства, до ввода объекта в эксплуатацию, возможно появление новых строительных материалов, инновационных технологий и архитектурно- строительных решений. Внедрение новых строительных материалов, инновационных технологий и архитектурно-строительных решений на объекте, проектные решения которого прошли согласование в экспертизе, связано с переработкой проектной документации и, возможно, повторным прохождением экспертизы. Все это приводит к необоснованным расходам и увеличению сроков реализации инвестиционного проекта. Зачастую инвесторам и проектировщикам приходится отказываться от внедрения на объекте новых технологий, оборудования и инженерных систем в пользу устаревших из-за отсутствия времени на переработку проектной документации и согласование новых проектных решений.

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

В настоящее время в рейтинге Doing Business Всемирного банка по показателю получения разрешения на строительство Российская Федерация находится на 115-м месте. В этой связи на совещании с членами Правительства Российской Федерации, состоявшемся 31 октября 2017 года и посвященном, в том числе вопросам улучшения делового климата, Президент России В.В. Путин особо обратил внимание на необходимость активизации соответствующей работы в сфере строительства. 2 Разрешение на строительство представляет собой документ, который подтверждает соответствие проектной документации требованиям, установленным градостроительным регламентом, проектом планировки территории и проектом межевания территории. Градостроительный регламент устанавливает вид разрешенного использования земельных участков, предельные параметры разрешенного строительства, реконструкции объектов капитального строительства. Градостроительный план земельного участка содержит информацию о разрешенном использовании земельного участка, требованиях к назначению, параметрам и размещению объекта капитального строительства на указанном участке, информацию о технических условиях подключения (технологического присоединения) объектов капитального строительства к сетям инженерно-технического обеспечения. Таким образом, на момент прохождения экспертизы и получения разрешения на строительство должны быть определены назначение и предельные параметры объектов капитального строительства, а также необходимые сведения в целях обеспечения защиты жизни и здоровья граждан и охраны окружающей среды. Полный объем информации и проектных решений (рабочий проект) об объекте капитального строительства необходим только к моменту ввода его в эксплуатацию, поскольку разрешение на ввод объекта в эксплуатацию представляет собой документ, подтверждающий:

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

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

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

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

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

Стадия 0.

Предпроектные материалы – проектное задание (задание на проектирование).

Стадия 1.

Технико-экономическое обоснование (Design Concept) – набор основных положений, касающихся проекта, учитываемых на всех этапах проектирования и принимающих во внимание все существующие ограничения.

Стадия 2.

 Эскизный проект (Schematic design) – начальный проект, представленный на второй стадии процесса проектирования и основанный на концепции проекта.

Стадия 3.

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

Стадия 4.

Рабочая документация (Final design) – финальный этап проектирования, выполняемый после одобрительной оценки детального проектирования.

Стадия 5. Утвержденная рабочая документация

В нормативных документах стран таможенного союза ЕАЭС, таких как Беларусь и Казахстан, также сделан акцент на многостадийность процесса проектирования объектов капитального строительства. Но европейские нормативные документы предполагают более глубокую дифференциацию процесса проектирования, чем стандарты стран таможенного союза ЕАЭС. К тому же Европейский комитет по стандартизации (CEN) не остановился на достигнутом результате и продолжает работу в части структурирования стадийности проектных работ в области капитального строительства. Из национальных стандартов Российской Федерации только ГОСТ Р 55654-2013 (ИСО 16813:2006), являющийся модифицированным по отношению к международному стандарту ISO 16813:2006 «Building environment design – Indoor environment – General principles» с учетом потребностей национальной экономики Российской Федерации и особенностей российской национальной стандартизации, предусматривает выделение четырех стадий процесса проектирования объектов капитального строительства. Положительный опыт использования в европейских стандартах многостадийного проектирования позволяет рассмотреть возможность исключения излишней детализации проектных решений и сокращения разделов проектной документации на момент прохождения экспертизы до количества, достаточного для последующего качественного проектирования и строительства зданий и сооружений с надлежащими параметрами безопасности, надежности и эффективности.

Выводы

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

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

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

Проектирование — процесс создания проекта, прототипа, прообраза предполагаемого или возможного объекта, состояния.

Огромное спасибо за Ваши отзывы, предложения, замечания и критики.» href=»comment»>Книга отзывов

Обратная связь


 Группа в Telegram!

! «Сметное дело» !

Число посетителей:



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


Бесплатные программы в помощь Строителям и Сметчикам [67]
Инженер-сметчик должен ЗНАТЬ [26]
Исполнительная документация в строительстве [12]
Исходно-разрешительная документация (ИРД) [6]
Контроль качества СМР (Надзор) [16]

Все теги


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

Дополнительная информация по данной теме

Проектирование — процесс создания проекта, прототипа, прообраза предполагаемого или возможного объекта, состояния.

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

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

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

 

Виды проектирования

  • Инженерных систем (вентиляции, газопроводов, электросетей и др. инфраструктуры) — Инженерное проектирование
  • Транспорта и транспортной инфраструктуры (Дорог, мостов и др.) — Транспортное проектирование
  • Зданий и других наземных объектов — Архитектурное проектирование
  • Промышленных объектов — промышленное проектирование
  • Ландшафтное проектирование
  • Техники и оборудования — техническое проектирование
  • Наружного и внутреннего оформления — дизайн-проектирование
  • Других объектов.
  •  

    Общие сведения о проектировании

    Виды проектирования согласно Градостроительному кодексу РФ подразделяются на:

    • Территориальное планирование
    • Архитектурно-строительное проектирование

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

    Виды проектов

    В зависимости от специфики поставленных задач разрабатываемые проекты можно разделить на несколько основных видов:

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

    Проектная документация и рабочая документация. Стадийность проектирования

     

    В настоящее время, в связи с вступлением в силу Положения о составе разделов проектной документации и требованиях к их содержанию, утвержденного Постановлением Правительства РФ №87 от 16.02.2008, не предусматривается стадийность проектирования, а вводятся понятия «проектная документация» и «рабочая документация».

    • Основным проектным документом является проектная документация, состоящая из текстовой и графической частей. Проектная документация (за исключением некторых случаев) направляется застройщиком или заказчиком на государственную экспертизу и, при наличии положительного заключения государственной экспертизы, утверждается им. Здесь необходимо подчеркнуть, что объем проектной документации, как правило, недостаточен для строительства объекта: в ней отсутствуют необходимые спецификации и требуемая степень детализации. Проектная документация содержит только основные технические решения, позволяющие оценить их безопасность, а так же доказать техническую возможность (а в некоторых случаях — и экономическую целесообразность) реализации инвестиционного проекта.
    • Для реализации в процессе строительства технических решений, заложенных в проектной документации, разрабатывается рабочая документация, состоящая из текстовых документов, рабочих чертежей и спецификаций оборудования и изделий. Поскольку единого документа, регламентирующего состав и содержание рабочей документации, не существует, при ее разработке необходимо руководствоваться соответствующими стандартами СПДС. Однако Министерство регионального развития РФ в своем письме заявляет, что «объем, состав и содержание рабочей документации должны определяться заказчиком (застройщиком) в зависимости от степени детализации решений, содержащихся в проектной документации, и указываться в задании на проектирование». На наш взгляд целесообразно требования стандартов СПДС дополнять и конкретизировать в задании на проектирование требованиями заказчика, но при этом обеспечить непротиворечивость этих требований стандартам СПДС.

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

    • Одностадийное проектирование осуществляется при параллельной разработке проектной документации и рабочей документации. Ранее проектный документ, разрабатываемый при одностадийном проектировании, именовался «рабочий проект» (РП) и состоял из утверждаемой части рабочего проекта и рабочей документации. Эти две составляющие рабочего проекта соответствуют принятым в настоящее время понятиям «проектная документация» и «рабочая документация» соответственно.
    • Двустадийное проектирование осуществляется при последовательной разработке проектной документации и рабочей документации. Ранее проектные документы, разрабатываемые при двустадийном проектировании именовались «проект» или «ТЭО» (1 стадия) и «рабочая документация» (2 стадия). Эти два проектных документа так же соответствуют принятым в настоящее время понятиям «проектная документация» и «рабочая документация» соответственно.
    • Трехстадийное проектирование (предпроектное предложение, проект, рабочая документация) — для объектов V, IV категорий сложности и для объектов III категории сложности по индивидуальным проектам, с недостаточным перечнем исходно-разрешительной документации.
    ПИСЬМО МИНИСТЕРСТВО РЕГИОНАЛЬНОГО РАЗВИТИЯ РФ 22 июня 2009 г. N 19088-СК/08

    Письмо №19088-СК/08 от 22.

    06.09 В соответствии с пунктом 2 Постановления Правительства Российской Федерации от 16 февраля 2008 г. № 87 О составе разделов проектной документации и требованиях к их содержанию

     

    Министерство регионального развития Российской Федерации в соответствии с многочисленными обращениями, а так же в соответствии с пунктом 2 Постановления Правительства Российской Федерации от 16 февраля 2008 г. № 87 «О составе разделов проектной документации и требованиях к их содержанию» (далее — Положение) сообщает.

     

    Инструкция о порядке разработки, согласования, утверждения и составе документации на строительство предприятий, зданий и сооружений (СНиП 11-01-95), утвержденная постановлением Министерства строительства Российской Федерации от 30 июня 1995 г. № 18-64 со вступлением в силу указанного постановления не подлежит применению. Также не подлежит применению Порядок разработки, согласования, утверждения и состав обоснований инвестиций в строительство предприятий, зданий и сооружений (СП 11-101-95), утвержденный постановлением Минстроя России от 30. 06 1995 №18-63.

     

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

     

    С учетом того, что постановлением Правительства Российской Федерации «О порядке организации и проведения государственной экспертизы проектной документации и результатов инженерных изысканий» от 5 марта 2007 № 145 предусмотрен порядок проведение экспертизы в отношении документации, разработанной в объеме стадии «проектная документация», заказчик должен подготовить ее в соответствии с указанным положением, и представить для проведения государственной экспертизы.

     

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

     

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

     

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

     

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

    • проектная документация — 40% 
    • рабочая документация — 60%.

     

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

     

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

     

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

     

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

     

    Одновременно Минрегион России сообщает, что с выходом данного письма письмо Минрегиона России от 08.08.2008 № 19512-СМ/08 утратило силу.

    С. И. Круглик

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

     

    Общий состав проектной документации регламентирован Градостроительным кодексом РФ и конкретизирован в Положении о составе разделов проектной документации и требованиях к их содержанию, утвержденном Постановлением Правительства РФ №87 от 16.02.2008. Согласно этим документам проектная документация на объекты производственного и непроизводственного назначения (кроме линейных объектов) состоит в общем случае из 12 разделов

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

    Состав рабочей документации определяется соответствующими стандартами СПДС и конкретизируется и дополняется указаниями заказчика в задании на проектирование

     

    Исходные данные для проектирования

     

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

    • Градостроительный план земельного участка
    • Результаты инженерных изысканий (как правило, состоят из результатов инженерно-геодезических изысканий, инженерно-геологических изысканий, инженерно-экологических изысканий)
    • Технические условия на подключение к сетям инженерно-технического обеспечения

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

    • Разрешительное письмо Комитета по государственному контролю, использованию и охране памятников истории и культуры (для объектов, находящихся в зоне охраны недвижимых памятников истории и культуры).
    • Утверждённое задание на проектирование.
    • Утвержденное технологическое задание (для объектов со специальной технологией)
    • Инвентарные планы этажей окружающей застройки.
    • Обмерные чертежи (для объектов реконструкции).
    • Заключение по результатам обследования фундаментов и конструкций (по объектам окружающей застройки в стесненных условиях строительства и по объектам реконструкции).
    • Исходные данные и требования по инженерно-техническим мероприятиям ГО и ЧС.

    Справочная литература:

    • Основные требования к проектной и рабочей документации ГОСТ 21.101-97

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

    • ГОСТ 2.004—88 ЕСКД. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах вывода ЭВМ
    • ГОСТ 2.101—68 ЕСКД. Виды изделий
    • ГОСТ 2.102—68 ЕСКД. Виды и комплектность конструкторских документов
    • ГОСТ 2.105—95 ЕСКД. Общие требования к текстовым документам
    • ГОСТ 2. 108—68 ЕСКД. Спецификация
    • ГОСТ 2.109—73 ЕСКД. Основные требования к чертежам
    • ГОСТ 2.113—75 ЕСКД. Групповые и базовые конструкторские документы
    • ГОСТ 2.114—95 ЕСКД. Технические условия
    • ГОСТ 2.301—68 ЕСКД. Форматы
    • ГОСТ 2.302—68 ЕСКД. Масштабы
    • ГОСТ 2.303—68 ЕСКД. Линии
    • ГОСТ 2.304—81 ЕСКД. Шрифты чертежные
    • ГОСТ 2.305—68 ЕСКД. Изображения — виды, разрезы, сечения
    • ГОСТ 2.306—68 ЕСКД. Обозначения графические материалов и правила их нанесения на чертежах
    • ГОСТ 2.307—68 ЕСКД. Нанесение размеров и предельных отклонений
    • ГОСТ 2.308—79 ЕСКД. Указание на чертежах допусков форм и расположения поверхностей
    • ГОСТ 2.309—73 ЕСКД. Обозначение шероховатости поверхностей
    • ГОСТ 2.310—68 ЕСКД. Нанесение на чертежах обозначений покрытий, термической и других видов обработки
    • ГОСТ 2.311—68 ЕСКД. Изображение резьбы
    • ГОСТ 2. 312—72 ЕСКД. Условные изображения и обозначения швов сварных соединений
    • ГОСТ 2.313—82 ЕСКД. Условные изображения и обозначения неразъемных соединений
    • ГОСТ 2.314—68 ЕСКД. Указания на чертежах о маркировании и клеймении изделий
    • ГОСТ 2.316— 68 ЕСКД. Правила нанесения на чертежах надписей, технических требований и таблиц
    • ГОСТ 2.317—69 ЕСКД. Аксонометрические проекции
    • ГОСТ 2.410—68 ЕСКД. Правила выполнения чертежей металлических конструкций
    • ГОСТ 2.501—88 ЕСКД. Правила учета и хранения
    • ГОСТ 21.110—95 СПДС. Спецификация оборудования, изделий и материалов
    • ГОСТ 21.113—88 СПДС. Обозначения характеристик точности
    • ГОСТ 21.114—95 СПДС. Правила выполнения эскизных чертежей общих видов нетиповых изделий
    • ГОСТ 21.203—78 СПДС. Правила учета и хранения подлинников проектной документации
    • ГОСТ 21.501— 93 СПДС. Правила выполнения архитектурно-строительных рабочих чертежей.
    • ПОСТАНОВЛЕНИЕ от 16 февраля 2008 г. N 87 «О составе разделов проектной документации и требованиях к их содержанию»;
    • Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство предприятий, зданий и сооружений (СНиП 11-01-95);
    • Инструкция о составе, порядке разработки, согласования и утверждения проектно-сметной документации на капитальный ремонт жилых зданий (МДС 13-1.99);
    • Временные указания на разработку проектно-сметной документации автоматизированных систем управления в составе проектов животноводческих комплексов (ВСН 117-83).

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

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

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

    В соответствии с Постановлением Правительства Российской Федерации от 16 февраля 2008 г. N 87 «О составе разделов проектной документации и требованиях к их содержанию» проектная документация на объекты капитального строительства производственного и непроизводственного назначения состоит из 12 разделов:

    • Раздел 1 «Пояснительная записка».
    • Раздел 2 «Схема планировочной организации земельного участка».
    • Раздел 3 «Архитектурные решения».
    • Раздел 4 «Конструктивные и объемно-планировочные решения».
    • Раздел 5 «Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений»
      • а) подраздел «Система электроснабжения»;
        б) подраздел «Система водоснабжения»;
      • в) подраздел «Система водоотведения»;
      • г) подраздел «Отопление, вентиляция и кондиционирование воздуха, тепловые сети»;
      • д) подраздел «Сети связи»;
      • е) подраздел «Система газоснабжения»;
      • ж) подраздел «Технологические решения»;
    • Раздел 6 «Проект организации строительства».
    • Раздел 7 «Проект организации работ по сносу или демонтажу объектов капитального строительства».
    • Раздел 8 «Перечень мероприятий по охране окружающей среды».
    • Раздел 9 «Мероприятия по обеспечению пожарной безопасности».
    • Раздел 10 «Мероприятия по обеспечению доступа инвалидов».
    • Раздел 11 «Смета на строительство объектов капитального строительства».
    • Раздел 12 «Иная документация в случаях, предусмотренных федеральными законами».

    Проектная документация на линейные объекты капитального строительства (далее — линейные объекты) состоит из 10 разделов:

    • Раздел 1 «Пояснительная записка».
    • Раздел 2 «Проект полосы отвода».
    • Раздел 3 «Технологические и конструктивные решения линейного объекта. Искусственные сооружения».
    • Раздел 4 «Здания, строения и сооружения, входящие в инфраструктуру линейного объекта».
    • Раздел 5 «Проект организации строительства».
    • Раздел 6 «Проект организации работ по сносу (демонтажу) линейного объекта».
    • Раздел 7 «Мероприятия по охране окружающей среды».
    • Раздел 8 «Мероприятия по обеспечению пожарной безопасности».
    • Раздел 9 «Смета на строительство».
    • Раздел 10 «Иная документация в случаях, предусмотренных федеральными законами».

    Рабочая документация — в соответствии с Постановлением Правительства Российской Федерации от 16 февраля 2008 г. N 87 «О составе разделов проектной документации и требованиях к их содержанию» это документация, которая разрабатывается в целях реализации в процессе строительства архитектурных, технических и технологических решений.

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

    В соответствии с письмом Министерства регионального развития Российской Федерации от 22. 06.2009 №19088-СК/08 в отличие от ранее действовавших нормативных документов не предусматривается стадийность проектирования: «ТЭО», «Проект», «Рабочий проект», а используются понятия «Проектная документация» и «Рабочая документация».

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

    В связи с изменением требований к составу разделов проектной документации, предусмотренных Постановлением Правительства Российской Федерации от 16 февраля 2008 г. N 87, Минрегион России рекомендует при определении стоимости проектных работ, принимать распределение базовой цены проектирования, рассчитанной с использованием справочников базовых цен на проектные работы, в зависимости от стадии проектирования в следующих размерах: проектная документация — 40%, рабочая документация — 60%.

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

    Структурная схема Государственной экспертизы проектной документации на капитальное строительство


    • ГОСТ 21.101-97 (Основные требования к проектной и рабочей документации)

    • Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство предприятий, зданий и сооружений (СНиП 11-01-95)
    • Инструкция о составе, порядке разработки, согласования и утверждения проектно-сметной документации на капитальный ремонт жилых зданий (МДС 13-1. 99)
    • Временные указания на разработку проектно-сметной документации авт22оматизированных систем управления в составе проектов животноводческих комплексов (ВСН 117-83)
    • Постановление Правительства РФ от 16.02.2008 N 87(ред. от 15.02.2011)»О составе разделов проектной документации и требованиях к их содержанию» (в ред. Постановлений Правительства РФ от 18.05.2009 N 427, от 21.12.2009 N 1044, от 13.04.2010 N 235, от 07.12.2010 N 1006, от 15.02.2011 N 73)
      Письмо Минрегиона РФ от 22.06.2009 N 19088-СК/08<О применении Положения о составе разделов проектной документации и требованиях к их содержанию;
    • Постановление Правительства РФ от 05.03.2007 N 145 (ред. от 31.03.2012) «О порядке организации и проведения государственной экспертизы проектной документации и результатов инженерных изысканий»



    «Назад | Вперед »


    Официальные термины и определения в строительстве  |  Инвестиционный проект (Бизнес-план)  |  Схема последовательности разработки. ..  |  Исходно-разрешительная документация (ИРД)  |  Техническое задание на проектирование  |  Проектирование >>>>>  |  Проект организации строительства (ПОС, ПОКР)  |  Проект производства работ (ППР, ППРк, ПОД, ТК)  |  Календарный и сетевой график производства работ  |  Тендерная документация в строительстве  |  Составление договоров строительного подряда  |  Организация, планирование и управление в строительстве  |  Фотография рабочего времени (дня)  |  Классификация зданий. Основные конструктивные элементы зданий  |  Специализированные строительные машины и инструменты  |  Транспортировка, приёмка, складирование и хранение материалов  |  Норматива трудноустранимых потерь и отходов материалов в строительстве  |  Сертификация, физико-технические свойства и классификация  |  Нормативные документы в строительстве  |  Исполнительная документация в строительстве  |  Контроль качества строительно-монтажных работ  |  Пособие, рекомендации, инструкция, положение и т.д. по контролю и надзору СМР  |  Приемка объекта в эксплуатацию  |  Инновации и инновационные технологии в строительстве  |  BIM технологии в проектировании
    Основные требования к проектной и рабочей документации

    Версия для печати

     

    Подписка на рассылку

    Никакого спама !!!

    Разделы проектной документации и этапы проектирования чистых помещений

    Главная страница » Общая информация и требования » Этапы проектирования и разделы проектной документации

    06 октября 2015 г.

    Разделы проектной документации

    Состав разделов проектной документации и требования к их содержанию изложены в постановлении № 87 Правительства Российской Федерации. 

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

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

    • ТХ – технологические решения
    • ТГ – технологическое газоснабжение
    • ВО – вода очищенная
    1. Специалисты архитектурного и конструктивного проектирования в координации со специалистами технологического проектирования и технологами Заказчика определяют основные конструктивные и объемно-планировочные решения, разрабатывают ведомости отделки помещений, спецификации заполнения и требования строительной, пожарной безопасности объекта.

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

    • АР – архитектурные решения
    • КР – конструктивные решения
    1. Специалисты по проектированию инженерных систем производят расчет и подбор инженерного оборудования систем вентиляции, электроснабжения, водоснабжения и водоотведения, автоматизации, сигнализации и связи. Разрабатывают планы размещения оборудования и трасс инженерных систем, определяют спецификации необходимых к закупке материалов.

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

    • ОВ – вентиляция, кондиционирование, отопление
    • А – автоматизация инженерных систем
    • ЭОМ – электроснабжение и электроосвещение
    • СС – слаботочные системы
    • ВС – водоснабжение и водоотведение
    1. Специалисты подготовки сметной документации проводят комплекс работ по составлению локальных, объектных смет – на основании полученных объемов работ от всех проектных разделов. В ходе определения сметной стоимости строительства специалисты отдела учитывают все нюансы объекта в части применения факторов сложности, удорожания и расценок.

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

    • СМ – сметная документация

    Этапы разработки документации

    1. Разработка концептуального проекта и технико-экономическое обоснование строительства (реконструкции).

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

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

    Специалистами сметного отдела на основании первичных данных технологов, архитекторов и инженеров, опыта реализации аналогичных объектов составляется бюджет проекта и экономическое обоснование необходимых затрат. Разрабатывается и согласовывается с Заказчиком техническое задание на проектирование.

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

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

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

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

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

    1. Разработка проекта стадии «П» и экспертиза проектной документации

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

    По окончанию выполнения этого этапа работ Заказчику передаются 4 экземпляра документации в составе всех томов проекта на бумажном носителе и  1 экземпляр документации на CD диске.

    1. Сопровождение проектной документации в государственной и негосударственной экспертизе.

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

    1. Разработка проекта стадии «РД»

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

    Чертежи и спецификации утверждаются Заказчиком «в производство работ» и передаются на объект для выполнения строительно-монтажных работ. Из числа специалистов каждого направления выделяются сотрудники для осуществления авторского «проектного» надзора за исполнением работ по документации

     

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

    Для получения более подробной информации  свяжитесь с нами удобным для вас способом:

    по телефону +7 (812) 330-04-54 СПб

                             +7 (495) 119-80-42 Мск

    по электронной почте [email protected]

    либо Закажите бесплатную консультацию, заполнив форму обратной связи ниже

     

    Перейти к списку статей

    Смотрите также

    08 октября 2015 г.

    Лаборатория. Общие требования

    Определение Лаборатории. На что обратить внимание при проектировании и строительстве. Требования к «чистоте»

    06 октября 2015 г.

    Разработка концептуального проекта и его технико-экономическое обоснование

    Оценка строительства будущего производства.

    06 октября 2015 г.

    Где ещё нужны чистые зоны/комнаты/помещения?

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

    Иная проектная документация – СПЕЦИНЖПРОЕКТ

    № раздела ПДМаркаНаименование основного комплекта рабочих чертежейСтадия
    1ПЗПояснительная записка

    Раздел 1 (ПД)

     ОПЗОбщая пояснительная записка

    подраздел ПД

     ИРДИсходно-разрешительная документация

    подраздел ПД

     ИЗИ

    Технический отчет по инженерно- экологическим испытаниям

    подраздел ПД
     ГДЗ

    Технический отчет по инженерно-геодезическим изысканиям

    подраздел ПД
     ГЛД

    Технический отчет по инженерно-геологическим изысканиям

    подраздел ПД
     ГМИ

    Технический отчет по инженерно-гидрометеорологическим испытаниям

    подраздел ПД
     МОМатериалы обследованияподраздел ПД
    2ПЗУСхема планировочной организации земельного участка

    Раздел 2 (ПД)

     Г Т

    Генеральный план и сооружения транспорта (при объединении ГП и ТР)

    РД
     ГПГенеральный планРД
     ТР

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

    РД
     ПЖЖелезнодорожные путиРД
     АДАвтомобильные дорогиРД
     ПОДДПроект организации дорожного движения 
     ОДОбустройство дорогРД
     ДОДорожная одеждаРД
     РРекультивация земельРД
     ЗПЗемляное полотноРД
     БлагБлагоустройство и озеленениеРД
     

    Водост

    ВодостокиРД
     ВПТВодопропускные трубыРД
    3АРАрхитектурные решения

    Раздел 3 (ПД)

     АИ

    Интерьеры. Рабочие чертежи могут быть объединены с основным комплектом марки АР или АС

    РД
     АС

    Архитектурно-строительные решения (могут быть обьеденены с АР и КР)

    РД
    4КРКонструктивные и объемно-планировочные решения

    Раздел 4 (ПД)

     КРРКонструктивные решения. Статический расчетРД
     КЖКонструктивные решения. Железобетонные конструкцииРД
     КЖ0

    Конструктивные решения. Железобетонные конструкции. Фундаменты

    РД
     КМКонструктивные решения. Металлические конструкцииРД
     КМД

    Конструктивные решения. Металлические конструкции деталировочные

    РД
     КДКонструктивные решения. Деревянные конструкцииРД
    5ИОС

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

    Раздел 5 (ПД)

      Система электроснабжения 
     ЭИСЭлектроснабжение инженерных системРД
     ЭКЭлектроснабжение (внутреннее)РД
     ЭОЭлектрическое освещение (внутреннее)РД
     ПНОПроект наружного освещенияРД
     ЭСЭлектроснабжение (наружное)РД
     ЭНЭлектрическое освещение (наружное)РД
     ЭМСиловое электрооборудованиеРД
     ОЭСистема электрического оборгеваРД
     ЭГМолниезащзита и заземлениеРД
      Система водоснабжения и система водоотведения 
     НВНаружные сети водоснабженияРД
     НКНаружные сети канализацииРД
     НВК

    Наружные сети водоснабжения и канализации (при объединении НВ и НК)

    РД
     ВКВнутренние системы водоснабжения и канализацииРД
      

    Отопление, вентиляция и кондиционирование воздуха, тепловые сети

     
     ОВиКОтопление, вентиляция и кондиционирование воздухаРД
     ТСТеплоснабжениеРД
     ЦТПЦентральный тепловой пунктРД
     ИТПИндивидуальный тепловой пунктРД
     АИТКотельнаяРД
     ТМТепломеханические решения (Котельные, ТЭЦ и т. п.)РД
      Сети связи 
     НССНаружные сети связи объекта. Искусственные сооруженияРД
     СС.КККабеленесущие конструкции сетей связиРД
     СССистемы связиРД
     СЭССистема экстренной связиРД
     КВВСистема контроля и управления автотранспортомРД
     ДМФДомофонная связьРД
     СКПТТелевидениеРД
     ПВРадиофикацияРД
     РТРадиосвязь, радиовещание и телевидениеРД
     ВНВидеонаблюдениеРД
     ПСПожарная сигнализацияРД
     ОСОхранная сигнализацияРД
     СКУДСистема контроля и управления доступомРД
     СКССтруктурированные кабельные сетиРД
     ЛВСЛокальные вычислительные сетиРД
     СМИС

    Структурированная система мониторинга и управления инженерными сетями

    РД
     СОТСистема охранного телевиденияРД
     КТСОКомплекс технических средств охраныРД
      Система газоснабжения 
     ГСННаружное газоснабжениеРД
     ГСВВнутреннее газоснабжениеРД
      Технологические решения 
     ТХТехнологические решенияРД
     ТК

    Технологические коммуникации. При объединении рабочих чертежей всех технологических коммуникаций

     
     ВСВоздухоснабжениеРД
     ХСХолодоснабжениеРД
     ПУПылеудалениеРД
     ПССнабжение паромРД
     АТПАвтоматизиция технологических процессовРД
     ПТПожаротушениеРД
     ВТВертикальный транспортРД
     А…Автоматизация 
     АИСАвтоматизация инженерных системРД
     АТХАвтоматизация технологии производстваРД
     АК

    Автоматизация и диспетчеризация комплексная (при объединении АИС и АТП)

    РД
     АОВАвтоматика систем кондиционированияРД
     АПСАвтоматическая пожарная сигнализацияРД
     АПВАвтоматизация противопожарного водопроводаРД
     АПТ

    Автоматизация системы дымоудаления или автоматизация пожаротушения

    РД
     ПААвтоматика противодымной вентиляцииРД
     АСКУЭ

    Автоматизированная система коммерческого учета электроэнергии

    РД
     АСТУЭ

    Автоматизированная система технического учета электроэнергии

    РД
    6ПОСПроект организации строительства

    Раздел 6 (ПД)

    7ПОДПроект организации работ по сносу (демонтажу)

    Раздел 7 (ПД)

    8ООСОхрана окружающей среды

    Раздел (ПД)

     ООСОхрана окружающей средыПД
     

    ООС. ТР

    Проект технологического регламента обращения со строительными отходами на объекте

    ПД
     ИЭИИнженерно-экологические изысканияПД
    9ПБМероприятия по обеспечению пожарной безопасности

    Раздел 9 (ПД)

     МЭМероприятия по обеспечению пожарной безопасностиПД
     АУПАвтоматическая установка пожаротушенияРД
     АУПСАвтоматическая установка пожарной сигнализацииРД
     АППЗАвтоматика противопожарной защитыРД
     СОУЭ

    Система оповещения и управления эвакуацией людей при пожаре

    РД
    10ОДИМероприятия по обеспечению доступа инвалидов

    Раздел 10 (ПД)

    10-1ТБЭ

    Требования к обеспечению безопасной эксплуатации объекта капитального строительства

    Раздел 10-1 (ПД)

    11СМ

    Смета на строительство объектов капитального

    строительства

    Раздел 11 (ПД)

    11-1ЭЭ

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

    Раздел 11-1 (ПД)

    12 

    Иная документация, установленная законодательными актами РФ

    Раздел 12 (ПД)

     ГОиЧС

    Мероприятия по гражданской обороне, по предупреждению чрезвычайных ситуаций природного и техногенного характера

    подраздел ПД

     ДПБ

    Декларация промышленной безопасности опасных производственных объектов

    подраздел ПД

     ДБГДекларация безопасности гидротехнических сооружений

    подраздел ПД

     ЗШ

    Мероприятия по защите от шума и вибраций.

    Оценка шумового воздействия на период эксплуатации объекта

    подраздел ПД
     КЕО

    Светотехнические расчеты инсоляции и естественной освещенности

    подраздел ПД
     ИТМ

    Инженерно-технические мероприятия гражданской обороны

    подраздел ПД
     ЭДИнструкция по эксплуатации зданияподраздел ПД
     ПТАМероприятия по противодействию террористическим актамподраздел ПД
     ГРГидротехнические решения 
     

    Антикоррозионная защита конструкций зданий, сооружений

     
     АЗО

    Антикоррозионная защита технологических аппаратов, газоходов и трубопроводов

     
     ТИТепловая изоляция оборудования и трубопроводов 
      Гидромелиоративные линейные сооружения 
     ОРС

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

     
     ОСС

    Основной комплект рабочих чертежей линейных сооружений осушительной системы

     
     МС

    Основной комплект рабочих чертежей линейных сооружений осушительной и оросительной систем

     

    Конструкторская документация: зачем она нужна

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

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

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

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

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

    Зачем инвестировать в разработку документации?

    Уточнение требований к проекту

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

    Дизайнеры должны найти баланс между бизнес-целями и потребностями пользователей. Изображение предоставлено UX Booth.

    Оптимизация реализации проекта

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

    Мотивируйте свою команду

    Хорошая документация рассказывает о продукте на высоком уровне и вдохновляет членов команды на видение. Он отвечает на вопросы: «Как мы хотим это построить?» и, что немаловажно, «Почему мы хотим это построить?»

    Список необходимых документов

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

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

    Надлежащее документирование проекта

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

    Сделать документацию удобной для использования целевой аудиторией

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

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

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

    Примечания к выпуску Lightning Design System от Salesforce содержат дату выпуска. Кредит изображения Salesforce.

    Работа над проектной документацией поэтапно

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

    Тестовая документация

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

    Избегайте жаргона

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

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

    Создание простого доступа

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

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

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

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

    Adobe Spectrum сочетает визуальные примеры с текстовым описанием. Таким образом, это упрощает понимание пользователем. Изображение предоставлено Adobe.

    Автоматическое обновление документации

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

    Найдите шаблоны в существующих документах и ​​превратите их в шаблоны

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

    Заключение

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

    Words by
    Ник Бабич

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

    Документация по дизайн-проекту

    Домашняя страница / Дизайн / Документация по дизайн-проекту: советы, ресурсы и лучшие практики

    Дизайн, веб-дизайн

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

    Автор Envato

    Опубликовано 13 февраля 2017 г.

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

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

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

    1. Отличные документы Говорите со всеми
    2. Начиная с тайлов стилей
    3. Готовые руководства по стилю
    4. Захват пользовательского опыта
    5. Дополнительные ресурсы

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

    Отличные документы говорят всем

    Документация должна быть простой для восприятия, но при этом достаточно подробной, чтобы ее можно было изучить без каких-либо предварительных знаний. Хорошая проектная документация должна учитывать такие мельчайшие детали, как ширина пикселей и значения цвета RGB/Hex.

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

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

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

    Подумайте о проекте материального дизайна Google и о том, как далеко он продвинулся всего за несколько лет. Это яркий пример проектной документации в действии.

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

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

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

    Если вам нужны примеры, посетите DesignGuidelines, новый сайт, посвященный онлайн-руководствам по дизайну.

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

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

    Начиная с плиток стилей

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

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

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

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

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

    • Быстрее и проще создать с нуля
    • Визуальная форма быстрого прототипирования
    • Демонстрирует общую картину конструкции

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

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

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

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

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

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

    Чтобы узнать больше о плитках стилей, ознакомьтесь с некоторыми из этих связанных сообщений.

    • Плитки стилей: альтернатива полноценным дизайнерским композициям
    • Плитки стилей и принцип их работы
    • Шаблон плитки произвольного стиля

    Готовые руководства по стилю

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

    Material Design от Google — один из примеров бесплатной документации по дизайну с открытым исходным кодом. Он сообщает дизайнерам, как стилизовать кнопки, вкладки и другие виджеты. Он также углубляется в анимационные эффекты и то, как макет материала должен «ощущаться», когда пользователь взаимодействует со страницей.

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

    Конкретных ограничений нет, но следует учитывать различные темы:

    • Первичные/вторичные/третичные цвета
    • Типографские стили и варианты шрифтов
    • Фоновые узоры
    • Дизайн кнопок
    • Фотография
    • Стили иконок с примерами
    • Формы и поля ввода
    • Каркасные потоки

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

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

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

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

    Возьмем, к примеру, веб-страницу руководства по стилю Mozilla.

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

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

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

    Учет пользовательского опыта

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

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

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

    У вас есть анимация CSS/JS? И как создаются эти анимации интерфейса? Какое смягчение и тайминг следует использовать? Как насчет потоков страниц и интерактивных элементов, таких как формы?

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

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

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

    Вэл Хед — эксперт по эффектам пользовательского интерфейса, и она говорит об анимации в руководствах по стилю, прямо заявляя:

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

    Val Head

    Val упоминает пример документации IBM, в которой есть отдельная страница для анимации.

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

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

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

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

    Дополнительные ресурсы

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

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

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

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

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

    Если вы ищете более подробную информацию о создании проектной документации, вам могут быть интересны следующие статьи блога:

    • Как создать руководство по стилю веб-дизайна
    • Примеры руководства по фирменному стилю
    • Руководства по стилю внешнего интерфейса
    • Как написать идеальный шаблон спецификации веб-сайта

    BusinessUX

    Считаете ли вы эту статью полезной?

    Похожие посты

    Элементы Envato: Миллионы творческих ресурсов, неограниченное количество загрузок — бесплатно в течение 7 дней. *

    Получите 7 дней бесплатно

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

    Зазеркалье

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

    И это легче сказать, чем сделать.

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

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

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

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

    Создание общих дисков

    При запуске проекта, если между командами нет общего репозитория, создайте его. Поместите сюда все активы, такие как шрифты, изображения шаблонов, файлы Figma, презентации, PRD и DRD. Если вы используете программное обеспечение для управления проектами, такое как Jira и Confluence, создайте там общие диски.


    Повышение уровня передачи инженерно-конструкторских знаний

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

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

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

    Создание прототипов и обмен ссылками

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

    Добавление аннотаций к анимации

    Перед тем, как ознакомить инженеров со своими проектами, обязательно запишите небольшие аннотации рядом с потоками и экранами, которые помогут инженерам легко понять их даже позже в процессе и сократить количество сбоев в общении. Например: Transition(FadeIn, 0.5seconds,L→R)

    Вести учет решений

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

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

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

    Качество

    • Гордитесь ли вы своим дизайном?
    • Дизайн придерживается принципов установить принципы проектирования

      Insight

      • Дизайн помогает пользователям достичь своих целей
      • Дизайн обслуживает все сценарии и чехлы
      • Протестировано проектирование с реальными пользователями
      11119
    1. . 0003
      • Дизайн соответствует рекомендациям по доступности
      • Обсуждены все данные, представленные в дизайне
      • Рассмотрены потенциальные случаи и состояния, такие как крайние случаи, крайние случаи, пустые состояния, состояния ошибок
      • Копия соответствует рекомендациям по написанию и проверена , значки и изображения сделаны экспортируемыми и обновлены в руководстве по стилю
      • Компоненты были обновлены в руководстве по стилю с их вариантами
        • Возможные состояния и варианты
        • Ограничения и отзывчивость
        • Состояние и варианты подкомпонентов. например, пусто, заполнено, состояния ошибки
        • Состояния взаимодействия
      • Необходимые детали взаимодействия/анимации помечены и упомянуты
      • Прохождение всей руки может быть очень полезным
      • Удалить все неиспользуемые руководства, компоненты
      Заключительная неделя

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

      • Составьте указатель и расположите свои работы в хронологическом порядке и по функциям. Например, интервью с пользователями ➡️ Insights ➡️ Designs.
      • Организуйте встречи по обмену знаниями между всеми заинтересованными сторонами.
      • Выделите время, чтобы как можно быстрее ответить на вопросы или решить проблемы.

      Заключительное слово

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

      Связанные статьи

      Как писать документы по дизайну программного обеспечения: с примерами

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

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

      *Примечание:* Здесь я описываю небольших клиентов, которым нужна армия из одного человека от их разработчика. Это не единственный путь, по которому может пойти фрилансер, и это не единственные клиенты, с которыми мы работаем в Toptal, но этот путь мне нравится больше всего. Конечно, если вы работаете в команде, а не в одиночку, некоторые из приведенных ниже правил неприменимы. Например, если вы используете методологии Agile или Scrum, вы, вероятно, захотите структурировать свои вехи немного по-другому.

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

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

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

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

      Итак, когда вы беретесь за новый проект, еще до того, как вы откроете Xcode или Visual Studio, вам необходимо иметь четкие и согласованные цели проектирования . И эти цели должны быть установлены в документе спецификации. Если клиент еще не написал его, вы должны написать его и отправить ему на рассмотрение еще до того, как вы откроете свою IDE. И , если вы встретите клиента, который откровенно скажет: «У нас нет времени на проектную документацию», вам следует отказаться от проекта , потому что у вас впереди проблемы. Спецификация не должна быть особенно длинной; это может быть всего несколько страниц, но, по крайней мере, он должен отображать пользовательский интерфейс, включать каркасы (если есть компонент пользовательского интерфейса) и устанавливать этапы завершения.

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

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

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

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

      Пользовательский интерфейс

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

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

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

      1. Всегда ли элементы управления видны и/или включены? При каких условиях изменяются их состояния?
      2. Похоже на растровое изображение — это кнопка?
      3. Какие переходы происходят между этими состояниями и представлениями? И как их анимировать?

      Если вам нужно сгенерировать пользовательский интерфейс для согласования с клиентом, сделайте то же самое в обратном порядке: используйте инструмент каркаса и создайте полный набор макетов экрана, включая любые варианты, которые отображаются в представлениях в разных состояниях приложения. Это может быть утомительной и утомительной работой, но вы не пожалеете об этом — она может уберечь вас от повторного написания огромного количества кода и повторного создания интерфейсов из-за незначительного недоразумения с серьезными последствиями. Если вы создаете двойное приложение (например, для iPhone и iPad), создайте отдельные каркасы для обоих.

      Размеры экрана тоже важны. Существует (на момент написания статьи) три размера экранов iPhone. Отдельные каркасы для 3,5-дюймовых и 4-дюймовых экранов, вероятно, избыточны, но вам, возможно, придется их сделать; в большинстве случаев можно просто изменить пропорции.

      Если ваш клиент предоставляет вам графику, убедитесь, что она имеет правильный размер с правильным соотношением сторон; преобразование любого растрового изображения, содержащего текст или объекты (например, круги), приведет к искажению. Если они не совпадают, попросите клиента создать их заново с соответствующими размерами. Не думайте, что вы можете растянуть 3,5-дюймовую заставку в 4-дюймовую заставку и просто крутить ее.

      Функциональность

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

      • Что делает приложение и как быстро оно это делает?
      • Каковы возможные условия сбоя и как они обрабатываются?
      • Какие разовые операции выполняются при первом выполнении (т.е. после установки)?
      • Если пользователь создает записи любого типа (например, закладки), каковы ограничения?

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

      Вехи

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

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

      Заявление о целях

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

      Функциональное описание

      Что делает приложение до ? С какими состояниями приложения (высокоуровневые описания основных пользовательских сценариев) столкнется пользователь?

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

      • Первый запуск
      • Создание нового _____ (игра, поиск и т.д.)
      • Операции
      • Поведение фона и переднего плана

      Пользовательский интерфейс

      Включите каркасы для каждой страницы с подробным описанием:

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

      Вот каркасы, связанные с моим последним приложением для iOS, NotifEye:

      Если вам интересно, я сделал эти макеты с помощью инструмента для каркасов Balsamiq.

      Например, описание пользовательского интерфейса может выглядеть так:

      • Панель навигации
        • Левый навигационный элемент: возврат на главную страницу
        • Строка заголовка: текущий экран или имя операции
        • Новая кнопка: создать новую вещь
      • Табличный вид
        • Раздел 0: Название раздела
        • Раздел 0 строк:
          • Управление строкой 0 (например, изображение)
          • Строка текста 0
          • Строка текста 2

      Вехи

      Как описано выше, сроки выполнения и ожидаемые результаты.

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

      1. Фасадное приложение с экраном, временными переходами и примерами изображений/текста
      2. Протокол связи: приложение подключается к сети/серверу
      3. Функциональная веха 1: …
      4. Альфа-приложение (с полной функциональностью)
      5. Стабильность
      6. Выпуск

      Обеспечение актуальности документации по программному обеспечению

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

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

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

      1. Над чем только что работал разработчик?
      2. Над чем сейчас работает разработчик?
      3. Над чем дальше будет работать разработчик?

      Важность проектной документации в управлении проектами в 2022 году

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

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

      Использование проектной документации

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

      Управление проектом обычно состоит из основных этапов: инициация, планирование, контроль и закрытие.

      Подробная информация об этапах проектной документации

      ТЭО

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

      Устав проекта

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

      Спецификация требований

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

      Конструкторский документ

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

      Рабочий план/оценка

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

      Матрица прослеживаемости

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

      Система отслеживания ошибок

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

      Вот более 200 шаблонов и документов по управлению проектами.

      Документ управления изменениями

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

      Тестовый документ

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

      Вы заинтересованы в прохождении сертификационного обучения по управлению проектами? Ознакомьтесь с предварительным просмотром нашего сертификационного курса PMP®.

      Технический документ

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

      Функциональный документ

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

      Руководство пользователя

      Руководство пользователя

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

      План перехода/развертывания

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

      Передаточный документ

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

      Закрытие контракта

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

      Извлеченные уроки

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

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

      Вы с нетерпением ждете успеха в области управления проектами? Если да, зарегистрируйтесь в программе «Основы управления проектами» прямо сейчас и станьте на шаг ближе к своей карьерной цели!

      PMP® и PMI® являются зарегистрированными товарными знаками Project Management Institute, Inc.

      Дизайны, темы, шаблоны и графические элементы проектной документации на Dribbble

      1. Посмотреть документацию проекта (часть 1)

        Проектная документация (часть 1)

      2. View Dashboard — Project wiki/практика слияния

        Информационная панель — Project wiki/практика слияния

      3. Посмотреть 📑 Документы

        📑 Документы

      4. Просмотр индекса компонента

        Индекс компонента

      5. Просмотр значков Палиго

        Иконки Палиго

      6. Посмотреть главную страницу Палиго

        Дом Палиго

      7. Посмотреть веб-дизайн Paligo

        Веб-дизайн Paligo

      8. Посмотреть иллюстрацию

        Иллюстрация

      9. Просмотр Eximee — Дизайн-система

        Eximee — Дизайн-система

      10. Посмотреть веб-дизайн Paligo

        Веб-дизайн Paligo

      11. Посмотреть типографику

        Типография

      12. Просмотреть тематическое исследование → Документация по дизайн-системе

        Практический пример → Design System Docs

      13. Посмотреть веб-дизайн Paligo

        Веб-дизайн Paligo

      14. Просмотр страниц документации Flagpack

        Страницы документации Flagpack

      15. View Evergreen — система дизайна сегмента

        Evergreen — система проектирования сегмента

      16. View Evergreen — система дизайна сегмента

        Evergreen — система проектирования сегмента

      17. Посмотреть Предложение по брендингу арт-директора

        Предложение по брендингу арт-дирекшн

      18. Просмотр Mercury.

    Следующая запись

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

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