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

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

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

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

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

Состав проектной документации объектов капитального строительства определен Градостроительным кодексом Российской Федерации, который предусматривает необходимость разработки не менее 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» с учетом потребностей национальной экономики Российской Федерации и особенностей российской национальной стандартизации, предусматривает выделение четырех стадий процесса проектирования объектов капитального строительства. Положительный опыт использования в европейских стандартах многостадийного проектирования позволяет рассмотреть возможность исключения излишней детализации проектных решений и сокращения разделов проектной документации на момент прохождения экспертизы до количества, достаточного для последующего качественного проектирования и строительства зданий и сооружений с надлежащими параметрами безопасности, надежности и эффективности.

Выводы

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

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

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

что это, основные разделы и виды

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

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

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

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

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

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

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

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

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

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

В каких случаях не требуется проектная документация

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

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

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

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

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

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

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

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

Требования к составу разделов документации четко регламентированы пунктом 13 статьи 48 Градостроительного кодекса. Кроме этого Постановление Правительства РФ № 87 содержит перечень требований.

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

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

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

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

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

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

В постановлении № 87 можно подробно ознакомиться с требования к содержанию проектов. Комплектуется готовая документация отдельно по конкретным разделам и подразделам. В таблицах А.1 и А.2 ГОСТа 21.1101-2013 приведены все наименования разделов и их шифры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обязательные и необязательные разделы

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

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

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

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

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

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

Если планируется строительство рядом с памятником культурного наследия, то здесь принимаются ко вниманию требования Федерального закона № 73-Ф3, обосновывающие потребность в разработке мероприятий, направленных на полную сохранность такого объекта.

Согласно Свода Правил 132.13330.2011 предусмотрено внесение в проект раздела «Мероприятия по борьбе с терроризмом».

Особую актуальность приобрел также раздел «Мероприятия по эксплуатации объектов капитального строительства». При составлении проектов на жилые дома наличие его обязательно.

Проектная документация для капитального ремонта

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

В зависимости от типа предстоящих работ определяется состав и содержание подлежащих разработке разделов.

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

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

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

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

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

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

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

Если установленных нормативными документами требований по безопасности и надежности объекта недостаточно, то согласно п.5 ПП № 87 проектирование выполнять нужно по специальным техническим условиям (СТУ).

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

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

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

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

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

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

Утверждение проектной документации

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

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

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

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

Описание состава разделов проектной документации, а также о требованиях к содержанию, предусмотрены в Постановлении Правительства РФ от 16.02.2008 N 87 (ред. от 23.01.2016). Так как проектная документация для строительства разбивается на несколько стадий, рассмотрим по порядку состав разделов проектной документации. Для начала обратимся к Википедии: 

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

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

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

• Стадия 1 — ПП. Предпроектные проработки (Эскизный проект). На этой стадии разрабатывается концепция будущего объекта строительства, определяются основные технико-экономические характеристики. Эскизом определяется строительство объекта на конкретном участке, его объемно-пространственное решение, конструктивная схема. Подсчитываются основные инженерные нагрузки по воде, теплу и электроэнергии, т. н. расчет нагрузок. Разработка Стадии «ПП» не является обязательной, но помогает сэкономить время и средства при дальнейшем проектировании.
• Стадия 2 — ПД. Проектная документация. Является обязательной и подлежит согласованию в государственных органах исполнительной власти. По результатам согласования Стадия «Проект» выдается разрешение на строительство объекта. Состав и содержание данного этапа регулируется Постановлением Правительства РФ №87 от 16.02.2008. В следующем абзаце мы подробно расскажем, что входит в состав разделов проектной документации состав. 
• Стадия 3 — РД. Рабочая документация нужна в первую очередь строителям, так как в ней наиболее полно и детально разрабатываются проектные решения, которые в Стадии  «ПД» только были обозначены. В отличие от «П»,  состав разделов проектной документации  «РД» включает в себя чертежи узлов, аксонометрические схемы и профили инженерных сетей, спецификации и т. д. С другой стороны, на рабочей стадии документация лишается некоторых разделов, полнота которых была исчерпана на стадии проектной (например, ПОС, ООС, КЕО, ИТМ ГОиЧС и т. д.). Как и на Стадии «П», состав «РД» будет индивидуален для каждого проекта.

В состав разделов проектной документации ПД входят:

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

Утверждение проектной документации осуществляется заказчиком. Согласно ст. 49 ГКРФ, до утверждения проектной документации заказчик может направить ее на экспертизу. На нашем сайте можно получить исчерпывающую информацию о порядке проектирования и строительства. Если у вас появились вопросы, вы можете обратиться к нам, заполнив форму обратной связи, или позвонив по телефону 209-09-40.

Проектирование зданий и сооружений в Москве! Услуги проектирования недорого!

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

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

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

Состав проектной документации по 87 постановлению 2016 года Правительства РФ включает в себя следующие документы.

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

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

Мы оперативно выполним по ГОСТу оформление проектной документации и поможем организовать Вам государственную экспертизу проектной документации для строительства.

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

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

Заказать услуги

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

Главная → Услуги → Стадии и состав проектирования

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

1. Стадия «Эскизный Проект» (предпроектное предложение)

2. Стадия «Проектная документация»

3. Стадия «Рабочая документация»

4. Стадия «Рабочий проект»

Стадия «Эскизный Проект» (предпроектное предложение)

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

«Эскизный проект»выполняется с целью:

— градостроительного обоснования размещения объекта нового строительства,

— демонстрации внешнего вида и внутренних планировок проектируемого объекта

— определения инвестиционной привлекательности проекта,

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

Состав эскизного проекта:

1. Пояснительная записка

2. Ситуационный план с прилегающими территориями

3. Генеральный план (схема организации земельного участка)

4. Поэтажные планы с экспликациями помещений

5. Разрезы с описанием «пирогов» и конструктивных элементов

6. Фасады

7. Цветовое и объемное решений фасадов

8. Фотомонтаж объекта в существующей ситуации

9. 3D Визуализация

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

Стадия «Проектная документация»

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

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

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

Пояснительная записка

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

Архитектурные решения

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

Система электроснабжения

Система водоснабжения

Система водоотведения

Система вентиляции и кондиционирования

Система отопления

Сети связи (телевидение, телефонизация и радиофикация, компьютерная сеть)

Технологические решения

Проект организации строительства

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

Мероприятия по охране окружающей среды

Мероприятия по обеспечению пожарной безопасности

Мероприятия по обеспечению доступа инвалидов

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

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

Дополнительные разделы:

видеонаблюдение

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

автоматизация (диспетчеризация) инженерных систем

охранная сигнализация

система пожаротушения

вертикальный транспорт (лифт)

Проект внутриплощадочных инженерных сетей

Проект внеплощадочных инженерных сетей

Проектная документация на стадии «Проект» является основой для разработки «Рабочей документации».

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

Стадия «Рабочая документация»

Стадия рабочая документация включает в себя

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

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

Рабочая документация зданий и сооружений при двухстадийном проектировании разрабатывается после утверждения документации на стадии «Проектная документация» в соответствии с принятыми в нем решениями.

Проектная документация при затрагивании несущих конструкций здания ОБЯЗАТЕЛЬНО подлежит государственной экспертизе.

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

Стадия «Рабочий проект» включает в себя:

Одностадийное проектирование (рабочий проект)дает возможность сократить срок разработки проекта в 1,5-2 раза и снизить стоимость проектирования на 30%. В составе Рабочего проекта разрешается в отдельных случаях при необходимости для объектов средней сложности разрабатывать проектные решения в объеме Проекта, а затем дорабатывать по ним рабочие чертежи.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сметная документация

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

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

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

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

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

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

Кроме того, могут понадобиться сметные нормативы.

Сметные нормативы

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

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

Сметные нормативы Российской Федерации делятся на несколько типов:

• ГСН — разрабатываются и вводятся Госстроем России;
• ОСН — разрабатываются и вводятся в действие министерствами, а также иными органами федерального управления. Они относятся к производственно-отраслевому строительству, ведущемуся в пределах той отрасли, для которой нормы и разработаны;
• ТСН — их вводят органы исполнительной власти субъектов РФ в отношении строительства, которое ведется на территории конкретного региона. К примеру, существуют территориальные сметные нормативы для Москвы;
• ФСН — они учитывают реальные условия и специфику работы конкретного предприятия-исполнителя работ, которое находится в ведомственном подчинении.

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

КС 2 и КС 3 что это?

Кс 2 акт о приемке выполненных работ, а кс 3 — справка о стоимости выполненных работ и затрат. Эти первичные документы являются основой для бухгалтерского и налогового учетов. И оттого, насколько грамотно составлены эти документы – формы КС-2 и КС-3, насколько четко происходит документооборот между контрагентами, зависят налоговые обязательства. Поэтому важно научиться правильно составлять формы КС-2 и КС-3, так как это позволит избежать претензий со стороны контролирующих органов и снизит риски возникновения споров.

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

Образец сметы

• Локальная смета на ремонт помещения
• Полный локальный сметный расчет на монтажные работы
• Полный локальный сметный расчет на пусконаладочные работы

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

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

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

Проектная документация

Проектная документация на объекты капитального строительства производственного и непроизводственного назначения должна включать в себя 12 разделов:

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

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

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

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

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

Рабочая документация

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

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

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

Контроль строительных работ

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

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

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

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

Постановление под № 87 принято в феврале 2008 года, почти вся информация по этому вопросу содержится в Градостроительном кодексе, в 48-й статье.

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

Сфера применения Положения

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

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

Виды объектов, попадающих под действие Положения

Параграфы условий проектирования распространяются на:

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

Разделение документации

В соответствии с нормами Положения разделение документации осуществляется на:

• проектные разработки;
• рабочий проект.

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

Первая стадия «П»

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

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

Последующая стадия — «РП»

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

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

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

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

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

1. Планировка организации строительных работ на участке.
2. Принятые архитектурные варианты строительства.
3. Пояснительная записка к проекту дома.
4. Разработанные объемно-планировочные и конструктивные решения.
5. Информация об инженерных сетях, оборудовании, список технических мероприятий, обоснование технологических процессов.
6. Разработанная система электрической проводки и снабжения.
7. Чертежи водопроводной системы.
8. Схема устройства канализационной очистки.
9. Система подачи отопления, расположение тепловых магистралей, кондиционирование внутреннего пространства.
10. Расположение системы связи.
11. Газопроводные магистрали и приборы.
12. Технология производства работ, учитывающая планы этажей.
13. ПОС (проект организации строительства).
14. Описание мероприятий по демонтажу существующих строений капитальной группы.
15. Список действительных мероприятий по охране окружающего пространства.
16. Перечень действий по обеспечению пожарной безопасности.
17. Конструктивные элементы здания по облегчению передвижения инвалидов.
18. Список мероприятий по соблюдению энергетической целесообразности и снабжения строений приборами учета использованных ресурсов.
19. Смета общая и соответствующие локальные на возведение постройки.
20. Другая документация в особых случаях.

Исходные проектные данные

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

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

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

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

Число стадий проектирования в зависимости от сложности объекта

Сложность строительства влияет на выбор количества стадий проектирования:

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

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

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

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

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

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

Задачи инженерных изысканий

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

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

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

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

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

Пояснительная записка: образец заполнения

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

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

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

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

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

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

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

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

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

Расчет стоимости

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

(жилые дома, склады, административные здания, торговые центры, бизнес центры и т.д.)

ГПЗУ

Договор аренды

Кадастровый план

Договор на землю

Технические условия

СРО проектировщиков

Проектная документация

1.Пояснительная записка

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

3.Архитектурные решения

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

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

5.1. Система электроснабжения

5.2. Система водоснабжения

5.3. Система водоотведения

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

5.5. Сети связи

5.6. Система газоснабжения

5.7. Технологические решения

6.Проект организации строительства

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

8.Перечень мероприятий по охране окружающей среды

9.Мероприятия по обеспечению пожарной безопасности

10.Мероприятия по обеспечению доступа инвалидов

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

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

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

12.1. Безопасная эксплуатация зданий и сооружений

12.2. ГО и ЧС

12.3. Антитеррористические мероприятия

12.4. Организация дорожного движения

Инженерно-геологические

Инженерно-геодезические

Инженерно-экологические

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

(газопроводы, водонапорные узлы, сети электроэнергии и т.д.)

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

ГПЗУ

Договор аренды

Кадастровый план

Договор на землю

Технические условия

СРО проектировщиков

Проектная документация

1.Пояснительная записка

2.Проект полосы отвода

3.Технологические и конструктивные решения линейного объекта. Искусственные сооружения

4.Здания, строения и сооружения, входящие в инфраструктуру линейного объекта

5.Проект организации строительства

6.Проект организации работ по сносу (демонтажу) линейного объекта

7.Мероприятия по охране окружающей среды

8.Мероприятия по обеспечению пожарной безопасности

9.Смета на строительство

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

Документы по результатам инженерных изысканий

Инженерно-геологические

Инженерно-геодезические

Инженерно-экологические

Расчет стоимости

Рассмотрим все стадии проекта по порядку:

• Стадия 2 — ПД. Проек тная документация

Стадия 1 — ПП. Предпроектные проработки (Эскизный проект)

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

Разработка Стадии «ПП» не является обязательной, но помогает сэкономить время и средства при дальнейшем проектировании.

Стадия 2 — ПД. Проектная документация

В отличие от Эскизного проекта Стадия «Проект» («ПД» или просто «П») является обязательной и подлежит согласованию в государственных органах исполнительной власти. По результатам согласования Стадия «Проект» выдается разрешение на строительство объекта. Состав и содержание данного этапа регулируется Постановлением Правительства РФ №87 от 16.02.2008. Безусловно, состав будет индивидуален для каждого проекта, но мы попробуем составить наиболее полный перечень всех возможных разделов и подразделов Стадии «ПД»:

Номер	Шифр раздела	Название раздела
Раздел 1		Пояснительная записка
Том 1	— ОПЗ	Пояснительная записка
Том 2	— ИРД	Исходно-разрешительная документация
Раздел 2	— ПЗУ	Схема планировочной организации земельного участка
Раздел 3	— АР	Архитектурные решения
Раздел 4		Конструктивные и объемно-планировочные решения
Том 1	— КР1	Железобетонные конструкции
Том 2	— КР2	Металлические конструкции
Том 3	— КР3	Деревянные конструкции
Том 4	— КРР	Статический расчет
Раздел 5		Сведения об инженерном оборудовании, о сетях инженерно-технического обеспечения, перечень инженерно-технических мероприятий, содержание технологических решений.
Подраздел 1		Система электроснабжения
Том 1	— ИОС1.1	Наружное электроснабжение
Том 2	— ИОС1.2	Силовое электрооборудование
Том 3	— ИОС1.3	Электроосвещение
Подраздел 2		Система водоснабжения
Том 1	— ИОС2.1	Наружное водоснабжение
Том 2	— ИОС2.2	Внутреннее водоснабжение
Подраздел 3		Система водоотведения
Том 1	— ИОС3.1	Наружное водоотведение
Том 2	— ИОС3.2	Внутреннее водоотведение
Подраздел 4		Отопление, вентиляция и кондиционирование воздуха, тепловые сети
Том 1	— ИОС4.1	Отопление и вентиляция
Том 2	— ИОС4.2	Теплоснабжение
Том 3	— ИОС4.3	Индивидуальный тепловой пункт
Подраздел 5		Сети связи
Том 1	— ИОС5.1
Том 2	— ИОС5.2
Том 3	— ИОС5.3
Том 4	— ИОС5.4	Видеонаблюдение
Том 5	— ИОС5.5	Охранная сигнализация
Том 6	— ИОС5.6
Том 7	— ИОС5.7	Прочие слаботочные системы
Подраздел 6		Система газоснабжения
Том 1	— ИОС6.1	Наружное газоснабжение
Том 2	— ИОС6.2	Внутреннее газоснабжение
Подраздел 7		Технологические решения
Том 1	— ИОС7.1	Технологические решения
Том 2	— ИОС7.2
Том 3	— ИОС7.3	Воздухоснабжение
Том 4	— ИОС7.4	Холодоснабжение
Том 5	— ИОС7.5	Снабжение паром
Том 6	— ИОС7.6	Пылеудаление
Том 7	— ИОС7.7	Прочие технологические системы
Раздел 6	— ПОС	Проект организации строительства
Раздел 7	— ПОД	Проект организации работ по сносу или демонтажу объектов капитального строительства
Раздел 8
Том 1	— ООС	Перечень мероприятий по охране окружающей среды
Том 2	— ООС.ТР	Проект технологического регламента обращения со строительными отходами на объекте
Том 3	— ИЭИ	Инженерно-экологические изыскания
Раздел 9
Том 1	— ПБ1	Мероприятия по обеспечению пожарной безопасности
Том 2	— ПБ2
Том 3	— ПБ3
Том 4	— ПБ4
Раздел 10	— ОДИ	Мероприятия по обеспечению доступа инвалидов
Раздел 10(1)	— МЭ	Мероприятия по обеспечению соблюдения требований энергетической эффективности и требований оснащенности зданий, строений и сооружений приборами учета используемых энергетических ресурсов
Раздел 11
Том 1	— СМ1	Смета на строительство объектов капитального строительства
Том 2	— СМ2	Мониторинг цен на материалы
Раздел 12		Иная документация в случаях, предусмотренных Федеральными законами
Том 1	— КЕО	Светотехнические расчеты инсоляции и естественной освещенности (КЕО)
Том 2	— ЗШ	Мероприятия по защите от шума и вибраций. Оценка шумового воздействия на период эксплуатации объекта
Том 3	— ИТМ ГОиЧС	Инженерно-технические мероприятия гражданской обороны. Мероприятия по предупреждению чрезвычайных ситуаций
Том 4	— ЭД	Инструкция по эксплуатации здания
Том 5	— ПТА	Мероприятия по противодействию террористическим актам
Том 6	— ДПБ	Декларация промышленной безопасности опасных производственных объектов

Стадия 3 — РД. Рабочая документация

Стадия «РД» нужна в первую очередь строителям, так как в ней наиболее полно и детально разрабатываются проектные решения, которые в Стадии «ПД» лишь обозначались. В отличие от «П», «Рабочка» включает в себя чертежи узлов, аксонометрические схемы и профили инженерных сетей, спецификации и т. п. С другой стороны, на рабочей стадии документация лишается некоторых разделов, полнота которых была исчерпана на стадии проектной (например, ПОС, ООС, КЕО, ИТМ ГОиЧС и т. п.). Как и на Стадии «П», состав «РД» будет индивидуален для каждого проекта, но мы попробуем составить наиболее полный перечень всех возможных разделов Стадии «Рабочая документация»:

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

ГОСТ Р 21.1101-2013 Система проектной документации:

4.2. Рабочая документация
4.2.1. В состав рабочей документации, передаваемой заказчику, включают:
— рабочие чертежи, предназначенные для производства строительных и монтажных работ;
— прилагаемые документы, разработанные в дополнение к рабочим чертежам основного комплекта.
4.2.2. В состав основных комплектов рабочих чертежей включают общие данные по рабочим чертежам, чертежи и схемы, предусмотренные соответствующими стандартами Системы проектной документации для строительства (далее — СПДС).
…
4.2.6. К прилагаемым документам относят:
— рабочую документацию на строительные изделия;
— эскизные чертежи общих видов нетиповых изделий, выполняемые в соответствии с ГОСТ 21.114;
— спецификацию оборудования, изделий и материалов, выполняемую в соответствии с ГОСТ 21.110;
— опросные листы и габаритные чертежи, выполняемые в соответствии с данными заводов — изготовителей оборудования;
— локальную смету по формам;
— другие документы, предусмотренные соответствующими стандартами СПДС.
Конкретный состав прилагаемых документов и необходимость их выполнения устанавливаются соответствующими стандартами СПДС и заданием на проектирование.
…
4.2.8. В рабочих чертежах допускается применять типовые строительные конструкции, изделия и узлы путем ссылок на документы, содержащие рабочие чертежи этих конструкций и изделий. К ссылочным документам относят:
— чертежи типовых конструкций, изделий и узлов;
— стандарты, в состав которых включены чертежи, предназначенные для изготовления изделий.
Ссылочные документы в состав рабочей документации, передаваемой заказчику, не входят. Проектная организация, при необходимости, передает их заказчику по отдельному договору.

СНиП 11-01-95 Состав рабочей документации:

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

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

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

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

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

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

Проектная документация состоит из текстовой и графической частей.

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

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

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

Подраздел «Система электроснабжения» раздела 5 должен содержать:

в текстовой части

а) характеристику источников электроснабжения в соответствии с техническими условиями на подключение объекта капитального строительства к сетям электроснабжения общего пользования;

б) обоснование принятой схемы электроснабжения;

в) сведения о количестве электроприемников, их установленной и расчетной мощности;

г) требования к надежности электроснабжения и качеству электроэнергии;

д) описание решений по обеспечению электроэнергией электроприемников в соответствии с установленной классификацией в рабочем и аварийном режимах;

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

ж) перечень мероприятий по экономии электроэнергии;

з) сведения о мощности сетевых и трансформаторных объектов;

и) решения по организации масляного и ремонтного хозяйства — для объектов производственного назначения;

к) перечень мероприятий по заземлению (занулению) и молниезащите;

л) сведения о типе, классе проводов и осветительной арматуры, которые подлежат применению при строительстве объекта капитального строительства;

м) описание системы рабочего и аварийного освещения;

н) описание дополнительных и резервных источников электроэнергии;

о) перечень мероприятий по резервированию электроэнергии;

в графической части

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

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

с) принципиальную схему сети освещения — для объектов непроизводственного назначения;

т) принципиальную схему сети аварийного освещения;

у) схемы заземлений (занулений) и молниезащиты;

ф) план сетей электроснабжения;

х) схему размещения электрооборудования (при необходимости). (пп. «х» введен Постановлением Правительства РФ от 07.12.2010 N 1006)

Что касается выполнения рабочей документации , то согласно Постановлению №87 имеем следующее:

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

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

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

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

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

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

NormaCS ~ ГОСТ Р 21.1101-2013 ~ Состав проектной документации – отдельный том?

akostin, добрый день!

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

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

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

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

Но если вместо документа с одним обозначением, и совсем не по причине ошибки в обозначении, выпускают другой документ с другим обозначением (например, был 2345-12-АР, а выпустили 2345-12-АР1), то первый документ требуется аннулировать и именно для этого выпускают разрешение (п.7.2.1 «Изменение документа (в том числе его аннулирование) выполняют, как правило, на основании разрешения на внесение изменений).

В графе 6 разрешения при аннулировании документа в графе делают запись, например, «2345-12-АТХ1 аннулировать». Если взамен аннулированного документа следует пользоваться документом с другим обозначением, то в графе делают запись, например, «2345-12-КЖ1.И-Б1 аннулировать. Заменен чертежом 2345-12-КЖ1.И-Б3».

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

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

3. О неприемлемости. Это вы и заказчик решаете, что приемлемо и что неприемлемо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

для системы проектирования Lightning Design от Salesforce указана дата выпуска.Изображение предоставлено Salesforce.

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

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

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

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

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

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

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

Создать легкий доступ

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

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

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

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

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

Обновить документацию автоматически

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

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

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

Заключение

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

Что это такое и как его создать! (Шаблон включен)

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

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

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

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

Что такое проект программного обеспечения? (Определение)

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

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

Подробнее: Что такое документ о требованиях к программному обеспечению

Почему документы разработки программного обеспечения важны?

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

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

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

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

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

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

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

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

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

Введение: Обеспечивает обзор всего документа.

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

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

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

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

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

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

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

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

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

Подробнее: Лучшие инструменты онлайн-документации по программному обеспечению

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

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

Bit.ai — это новый программный инструмент для документации и управления знаниями, который помогает командам сотрудничать, обмениваться, отслеживать и управлять всеми знаниями компании в одном месте. Битовые документы, в отличие от стандартных документов Word и Google, являются интерактивными . Это означает, что разработчики могут легко добавлять блоки кода в документ одним щелчком мыши!

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

Совместная работа с разработчиками, командой разработчиков и клиентами

Несколько человек могут одновременно работать над смарт-документом Bit в режиме реального времени. Это отличный способ для разработчиков программного обеспечения работать с различными аспектами программного обеспечения вместе под одной крышей.

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

Быстрая документация без отвлекающих факторов

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

Когда вы закончите создание документов, вы можете легко экспортировать их как PDF, Word, Markdown и многое другое. Markdown поддерживается GitHub и другими инструментами разработки программного обеспечения, что позволяет легко делиться работой, которую вы делаете внутри Bit, с другими платформами.

Обеспечение безопасности и надежности программных документов

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

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

Гостевой доступ, клиентские порталы и комнаты данных

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

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

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

Работайте с любимыми приложениями!

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

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

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

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

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

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

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

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

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

Шаг 1: Создайте учетную запись Bit

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

Шаг 2. Создание рабочего пространства

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

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

Шаг 3. Добавление участников группы

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

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

Шаг 4: Создайте желаемый документ

Как только вы окажетесь в рабочем пространстве, нажмите кнопку « Create New» . В раскрывающемся списке выберите «Из шаблона» .

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

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

🎥Посмотрите это видео, чтобы узнать больше👇

До встречи!

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

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

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

Если у вас есть какие-либо вопросы о приведенном выше шаблоне дизайна программного обеспечения или вы хотите узнать, как Bit может помочь вашему бизнесу добиться успеха, сразу же напишите нам в Твиттере @bit_docs!

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

Что такое проектный документ

Что такое дизайн Документ?

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

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

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

Если у вас трехдокументный модель:

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

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

— Внедрение — пошаговое список того, что можно сделать, чтобы воспроизвести произведение, возможно, кто-то, кто не знаком с дизайном или планом.

Другой взгляд на это может быть так:

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

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

— Если вы просто обеспечиваете реализацию шаги без плана, как вы узнаете, что выполнили работу?

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

Время чтения: около 8 минут

Автор: Lucid Content Team

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

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

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

Документация по разработке программного обеспечения в стадии разработки (Щелкните, чтобы начать разработку с помощью нашего шаблона)

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

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

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

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

Почему важны SDD?

Если вы разработчик, возможно, вы бывали здесь раньше: вы написали тысячи строк кода только для того, чтобы понять, что у вас и вашего клиента совершенно разные взгляды на проект.Это тысячи строк кода — и кто знает, сколько часов работы — вам, возможно, придется выбросить.

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

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

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

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

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

Название, авторы и рецензенты

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

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

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

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

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

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

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

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

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

См. Наш учебник.

Цели и этапы.

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

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

Приоритизация

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

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

Текущие и предлагаемые решения

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

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

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

Временная шкала

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

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

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

Держите свой язык простым

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

Включите визуальные эффекты

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

Получите обратную связь пораньше

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

Обновите SDD

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

Оцените преимущества документирования дизайна программного обеспечения. Начните прямо сейчас с нашим шаблоном.

Попробовать сейчас

Как написать проектную документацию по программному обеспечению (SDD)

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

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

Что такое проектный документ программного обеспечения?

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

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

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

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

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

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

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

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

Если вы работаете в качестве разработчика-фрилансера, проектный документ также может избавить вас от многих проблем в будущем, помогая избежать потенциальных разногласий с вашими клиентами и добавляя ясности к согласованным целям.«Без этого документа вы попадете в петлю язвительной двусмысленности: клиенты будут оспаривать то, что они сказали вам или что вы им сказали, гневно посылая вырезки из предыдущих сообщений, интерпретируя и спорив до тех пор, пока не придет время, когда клиент требует, чтобы вы внесли изменения », — предупреждает Кристофер Дж. Фокс, внештатный инженер-программист с более чем 30-летним опытом.

Анатомия документа по разработке программного обеспечения

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

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

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

Обзор и заинтересованные стороны

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

Контекст и цели

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

Предлагаемое решение

Конкретное подробное предложение по новой технической архитектуре.

Временная шкала

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

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

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

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

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

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

Существует множество инструментов для совместной работы с документами, которые могут облегчить такие рабочие процессы, включая Nuclino.«Важно, чтобы члены вашей команды могли комментировать документ и указывать на ошибки и упущения», — сказал Дэвид «Талин» Джойнер, программист игр и бывший разработчик программного обеспечения в Google+.

Сделайте это наглядным с помощью диаграмм и диаграмм

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

Будьте внимательны

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

Не пишите в Word

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

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

Не делайте это слишком длинным или сложным

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

«Не позволяйте своему желанию показать, насколько вы умны, отвлекаться», — рекомендует Джоунер.

Не позволяйте ему устареть

“ Дизайн будет развиваться, и изменения должны быть отражены в вашем документе .За свой 25-летний опыт я ни разу не работал над проектом, где бы этого не происходило. Даже тогда я создал проектный документ с подробными спецификациями и скорректировал его по мере необходимости », — объяснил Кристофер Дж. Фокс, бывший старший инженер Microsoft и RealNetworks.

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

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

Nuclino: единый источник истины для вашей команды

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

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

• Общайтесь с помощью вдумчивых подробных описаний и тратите меньше времени на душераздирающие встречи и хаотичные каналы Slack.

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

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

Попробовать сейчас

Зачем вам нужен шаблон проектной документации (и как его создать) | by Pangara

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

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

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

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

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

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

Раньше вы имели дело исключительно с людьми, которые хорошо знали проблемы, возникающие при разработке.

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

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

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

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

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

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

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

1: Введение

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

2: Сценарии

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

3: Обзор конструкции

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

4: Объем работы

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

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

5: Проектирование системы

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

6: Детальное проектирование

Обычно разделено на 4 подраздела, в которых вы объясняете структуру системы, компоненты, интерфейс и модули.

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

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

8: Нефункциональные требования

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

9: Объяснение использованного тестирования

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

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

10: Конечные результаты

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

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

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

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

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

1: Используйте свой шаблон дизайн-документа, чтобы продемонстрировать свои успехи

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

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

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

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

2: Ваша проектная документация гарантирует воспроизведение хороших результатов

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

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

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

3: Ваш проектный документ держит всех на одном уровне Страница

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

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

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

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

4: Правильная проектная документация делает всех счастливыми

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любой проект — это путешествие в неизведанное, с хорошей картой намного проще.

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

Документирование — это проектирование: как документация способствует улучшению результатов проектирования | by Heidi Adkisson

Это была ранняя стадия нового дизайн-проекта, и я работал над диаграммой потока задач, когда мой коллега спросил меня об этом.«Ты делаешь это сейчас? Обычно я жду окончания проекта ».

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

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

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

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

Еще одно преимущество интеграции документации в вашу конструкторскую практику состоит в том, что она помогает развить навыки пояснительного письма. Если вы дизайнер, у которого нет роскоши преданного писателя, вам, скорее всего, придется писать текст как часть вашей дизайнерской работы, даже если это всего лишь небольшие фрагменты.Но эти маленькие кусочки иногда могут быть важной частью опыта. Если вы не чувствуете себя комфортно с вашими навыками письма UX (или даже если да!), Я настоятельно рекомендую Writing is Designing Майкла Меттса и Энди Велфа.

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

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

• Пользовательские истории
• Сценарии использования
• Описание сценария
• Блок-схемы экрана
• Документация на уровне страниц

Документация по структурной перспективе включает:

• Объектная модель
• Системный словарь
• Карта архитектуры
• Navigation Framework
• Page Архетипы
• Стандартизированные компоненты

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

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

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

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

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

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

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

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

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

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

Пример экранной блок-схемы, показывающей условную логику

Если вы не знакомы со стандартными соглашениями о блок-схемах, я настоятельно рекомендую How to Build a Task Flow by Laura Klein.

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

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

Документация на уровне страницы обычно включает:

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

Пример документации на уровне страницы показан ниже:

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

ДЕМО: Показать / скрыть дополнительные теги
1) Щелкните заголовок панели «Дополнительные теги», чтобы открыть ее.
2) Щелкните еще раз, чтобы закрыть.

ДЕМО: Редактировать эксперимент
1) Нажмите кнопку «Редактировать»
… система отображает форму редактирования…

Примечание процесса: Хотя приведенное выше может показаться большим количеством набора текста, я установил стандарт фразы документации в Text Expander, что значительно ускоряет процесс создания такого уровня детализации.

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

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

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

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

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

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

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

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

Я считаю, что структура навигации включает:

• Панель меню верхнего уровня (глобальная), включая глобальные функции, такие как поиск
• Меню верхнего уровня, отображающие темы или функции второго уровня
• Навигация на уровне страницы, включая Схема навигации, панели навигации и меню на уровне страницы
• Элементы управления внутристраничным представлением

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

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

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

• Для веб-сайта: Домашняя страница> Обзор темы> Детали темы
• Для приложения: Панель инструментов> Сводка состояния> Детали статуса
• Для пути, инициированного через поиск: Главная> Результаты поиска > Подробности темы

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

Архетипы страниц — это страницы определенных жанров, которые имеют общие характеристики макета и выполняют одну и ту же важную функцию.

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

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

Соглашения о макете для архетипа страницы

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