Отличие проектной от рабочей документации: Проектная и рабочая документация — Список статей — Главная — Департамент государственного жилищного и строительного надзора Свердловской области Официальный сайт

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

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

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


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

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

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

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

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

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

  5. Информация об инженерно-техническом обеспечении. Сюда относится система электроснабжения, система водоснабжения, система водоотведения, система отопления, система вентиляции и прочие инженерные сети.

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

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

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

  9. Разрабатываются в обязательном порядке противопожарные мероприятия.

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

  11. Подробный сводный сметный расчет строительства.

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

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

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

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


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

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

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

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

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

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

  5. Противопожарные мероприятия. Строительство объекта должно осуществляться с обязательным соблюдением пожарной безопасности. Все разделы РД обязательно включают требования по соблюдению и обеспечению пожарной безопасности.

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

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

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

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

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

  • корректная смета на строительство, учитывающая все спецификации материалов.

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


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

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

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

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

РД разрабатывается очень подробно, что бы было достаточно информации для производства строительства.

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


В чем принципиальное отличие проекта (стадия П) от рабочей документации (стадия РД) ведь и там, и там пояснительная записка, схемы, планы, спецификация?

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

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

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

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

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

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

Раздел 3 «Архитектурные решения».

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

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

а) подраздел «Система электроснабжения»;

б) подраздел «Система водоснабжения»;

в) подраздел «Система водоотведения»;

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

д) подраздел «Сети связи»;

е) подраздел «Система газоснабжения»;

ж) подраздел «Технологические решения»;

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

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

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

Раздел 9 «Мероприятия по обеспечению пожарной безопасности».

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

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

Раздел 12 «Смета на строительство объектов капитального строительства».

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

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

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

(«ГОСТ Р 21.1101-2009. Система проектной документации для строительства. Основные требования к проектной и рабочей документации» (утв. Приказом Ростехрегулирования от 30.11.2009 N 525-ст))

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

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

(«ГОСТ 21.502-2007. Система проектной документации для строительства. Правила выполнения проектной и рабочей документации металлических конструкций» (введен в действие Приказом Ростехрегулирования от 25.03.2008 N 58-ст))

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

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

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

Кроме того: Минрегион России рекомендует при определении стоимости проектных работ принимать «распределение базовой цены проектирования… в зависимости от стадии проектирования… проектная документация — 40%,   рабочая документация — 60%»

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

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

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

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

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

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

Преимущества нашей компании — решать задачи комплексно

Утверждение
архитектурно-градостроительного
облика

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

Проектирование всех
стадий, разделов,
любой сложности

Согласования и
утверждение в ИСОГД

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

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

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

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

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

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

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

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

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

Формирование документации в строительстве возможно одним из трех способов.

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

Требуется консультация по разработке рабочей документации (стадия Р)?

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

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

Содержание и оформление рабочей документации

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

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

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

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

Базовые требования ГОСТа к оформлению:

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

Рабочие документы также допускается формировать в электронном виде. Они могут быть отправлены на e-mail или переданы на физическом носителе.

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

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

Наиболее распространенные ошибки при формировании документации:

  • комплект является неполным, отсутствуют разделы или листы;
  • листы с документацией не подписаны;
  • при оформлении чертежей и текстовых файлов не соблюдены требования ГОСТа;
  • в рабочую документацию внесены изменения после ее утверждения;
  • данные инженерно-геологических изысканий, сопровождающих проект, являются устаревшими;
  • применены необоснованные решения в части организации фундаментной подложки;
  • проект сигнализации отклоняется от предписаний ГОСТа и закона № 123-ФЗ;
  • ошибки в проекте электроснабжения, нарушение положений закона № 261-ФЗ;
  • спецификация содержит перечень неиспользуемых материалов.

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

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

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

Порядок оказания услуг

Вероятные ошибки в составлении смет

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

В процессе экспертизы смет могут быть выявлены ошибки в применении:

  • повышающих/понижающих коэффициентов;
  • индексов;
  • единиц измерения;
  • расценок;
  • расходных нормативов;
  • норм прибыли.

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

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

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

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

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

Наши работы

Посмотрите на работы компании IR-Proekt

Заявка на консультацию по разработке рабочей документации (стадия Р)

Оставьте свои данные и мы свяжемся с Вами в ближайшее время!

*Поля отмеченные звездочкой обязательны для заполнения

Анализ объема допустимой застройки за 1 рабочий день Гарантия получения разрешения на строительство по договору

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

19 Января 2018

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

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

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

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

Выводы

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

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

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

Проектная документация — Институт Территориального Развития

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

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

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

Проектная и рабочая документация. В чем отличие?

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

Состав проектной документации определяется в соответствии с Постановлением Правительства РФ №87 и ГОСТ Р 21.1101-2013

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

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

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

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

Общая площадь запроектированных зданий — 1 227 000 м
2 , в том числе:
  •  Объекты жилого назначения — 964 000 м2
  •  Объекты промышленного назначения — 10 000 м2
  •  Объекты общественно-делового, социального и спортивного назначения — 253 000 м2

Проектная документация vs Рабочая документация | АРХБЛОГ

Речь пойдет о стадиях проектирования. Какие. Зачем. В чем разница.

Как всегда буду писать по-простому. Хотите большего. Пожалуйста. Читайте Постановление правительства №87 «О составе проектной документации…», и ГОСТы 21.1101-2013 и 21.501-2011 требования и правила выполнения.

Итак. Начинать все стоит с предпроектных проработок. Хотя тут тоже могут быть варианты в зависимости от масштаба проектируемых объектов. Может быть самой первой работой по объекту ТЭО — технико-экономическое обоснование. Может быть концепция. Может быть эскизный проект (или как его называют сейчас предпроектные проработки).

Концепция

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

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

Эскизный проект или предпроектные проработки

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

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

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

Картинка из эскизного проекта еще…

Картинка из эскизного проекта еще…

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

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

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

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

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

Для объектов капитального строительства обычно ПД состоит из 16 разделов, бывает и больше, если например есть газовая котельная. Архитектор на разных объектах может закрывать самостоятельно ПЗ, ПЗУ, АР, ТХ, ОДИ, ЭЭФ, ТОБЭ. Некоторые, знаю, делают ПБ сами. Но я отдаю узким специалистам. Всякий раз, смотрю на свои решения, думаю, все правильно… Отправляю им, и в итоге всегда есть такие тонкости, мелочи, нюансы, а бывают и серьезные ошибки, которые я не учел. Очень объемные нормы по пожарной безопасности, к тому же, бывает, нужны расчеты пожарного риска. В общем, считаю, на пожарной безопасности, как и на конструктиве нельзя экономить. И тот и другой раздел, как никакой другой влияет на безопасность и надежность здания. И то и другое должны делать самые опытные и серьезные специалисты.

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

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

Есть специальный ГОСТ 2.501-88, там прямо схемы нарисованы как сложить в папки, а как под сшивку.

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

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

Степень деталировки рабочки у каждого своя. Я пишу статью, а один мой знакомый архитектор в это время на свое здание вычерчивает 100-й!!! лист в раздел АР. И такое бывает. Фасады очень сложные с лепниной. И человек делает свою работу очень хорошо и качественно. Я работал в строительной компании, там требование было, на всех объектах все внутренние кирпичные перегородки вычерчивали в развертках с порядовками кирпича. Минимальный набор ведомостей и спецификаций в АР — это перемычки, отверстия, проемы, окна и двери, отделка внутренняя и наружная.

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

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

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

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

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

Понравилась статья, поставьте «палец вверх» и подпишитесь на канал

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

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

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

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

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


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

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

Функциональные спецификации 101
Функциональная документация, такая как документы функциональных спецификаций, создается после подписания документа требований. Эта документация определяет «средства для метода» приложения.

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

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

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

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

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

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

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

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

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

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

Аудитория проектной документации
Аудитория консультируется с проектной документацией для получения следующей информации:

  • Подробная информация об архитектуре приложения и целях проектирования
  • Проверка данных
  • Документация кода (высокий уровень)
  • Диаграммы потоков данных

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

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

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

  • «Эти документы никто не читает. Я просто вынесу документ, чтобы люди не жаловались.»
  • Нет времени писать и функциональную спецификацию, и конструкторскую документацию.

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

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


Функциональные vs.оформление в документации

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

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

Функциональные характеристики 101
Функциональная документация, такая как документы функциональных спецификаций, создается после подписания документа требований. Эта документация определяет «средства для метода» приложения.

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

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

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

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

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

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

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

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

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

    Конструкторская документация аудитория
    Аудитории обращаются к проектной документации для получения следующей информации:

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

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

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

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

    Техническая документация: В чем разница между HLD, LLD, DLD?

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

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

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

    Процесс проектирования, разработки и тестирования.

    Существует несколько типов технической документации, и в этой статье мы рассмотрим такие вещи, как HLD, LLD и DLD.Не знаете, что это значит и когда использовать какой? Читать дальше.

    TRENDINGБыстрое введение в алгоритмы машинного обучения для начинающих

    ДИЗАЙН ВЫСОКОГО УРОВНЯ (HLD)

    Проект верхнего уровня (HLD) — это общий проект системы. Он включает описание следующих частей:

    • Архитектура системы
    • Дизайн базы данных
    • Краткое упоминание всех платформ, систем, сервисов и процессов, от которых зависит продукт
    • Краткое описание взаимосвязей между модулями и функциями системы

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

    НИЖНИЙ УРОВЕНЬ ДИЗАЙНА (LLD)

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

    ПОДРОБНАЯ ИНФОРМАЦИЯ (DLD)

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

     Вам также может быть интересно: какой репозиторий кода выбрать для вашего проекта 

    Вот удобная инфографика, которая показывает разницу между HLD и LLD:

    Главная »Блог» Техническая документация: В чем разница между HLD, LLD, DLD?

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

    Техническая документация по разработке программного обеспечения: Типы и инструменты

    Время чтения: 22 минуты

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

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

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

    Гибкий подход и водопад

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

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

    Схема цикла гибкой разработки

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

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

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

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

    Соответствует следующей классификации.

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

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

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

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

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

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

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

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

    Документация по системе

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

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

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

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

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

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

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

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

    • Используйте ссылки и анкеры . Они помогут вам упростить чтение и поиск документа, поскольку читатели смогут постепенно понимать информацию. Например, вы можете предоставить ссылки на интервью с клиентами и ссылки на предыдущие обсуждения или другую внешнюю информацию, связанную с проектом.
    • Используйте графики и инструменты построения диаграмм , чтобы лучше сообщить о проблемах вашей команде. Люди более склонны воспринимать информацию, глядя на изображения, чем читая обширный документ. Различные визуальные модели помогут вам выполнить эту задачу и более эффективно обозначить требования. Вы можете включать диаграммы в процесс создания требований, используя следующие программные инструменты построения диаграмм: Visio, Gliffy, Balsamiq, Axure или SmartArt в Microsoft Office.

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

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

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

    • Персоны пользователей
    • Пользовательский сценарий
    • Карта сценария
    • Карта истории пользователя
    • Руководство по стилю UX

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

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

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

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

    Пример карты пользовательской истории с разбивкой на выпуски

    Источник: feedotter.com

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

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

    • Карты сайта
    • Каркасы
    • Мокапы
    • Прототипы
    • Схемы потоков пользователя или путь пользователя
    • Отчеты юзабилити-тестирования

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

    Пример структуры карты сайта

    Источник: uxforthemasses.com

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

    Схема работы пользователя приложения поиска работы

    Источник: medium.com

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

    Пример каркаса для мобильного приложения Peekaboo

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

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

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

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

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

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

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

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

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

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

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

    Схема архитектуры веб-приложения Azure

    Источник: docs.microsoft.com

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

    Исходный код, документ

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

    Документы с исходным кодом могут включать, но не ограничиваются следующими деталями:

    • Фреймворк для создания HTML и другие применяемые фреймворки
    • Тип привязки данных
    • Шаблон дизайна с примерами (например,грамм. модель-представление-контроллер)
    • Меры безопасности
    • Прочие модели и принципы

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

    Документация по обеспечению качества

    В Agile есть разные типы тестовых документов. Мы выделили самые распространенные:

    • План управления качеством
    • Стратегия тестирования
    • План испытаний
    • Технические характеристики тестового набора
    • Контрольные листы испытаний

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

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

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

    • Список функций для тестирования
    • Методы испытаний
    • Таймфреймы
    • Роли и обязанности (например, модульные тесты могут выполняться командой QA или инженерами)

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

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

    Справочное и техническое обслуживание

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

    Документация по API

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

    Документация по API

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

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

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

    • конечных пользователей
    • системные администраторы

    Документация для конечного пользователя

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

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

    Краткое руководство по началу работы с OneNote, источник: slideshare

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

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

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

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

    • Часто задаваемые вопросы
    • Видеоуроки
    • Встроенная поддержка
    • Порталы поддержки

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

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

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

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

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

    Технологическая документация

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

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

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

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

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

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

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

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

    Дорожные карты Agile-продуктов

    Дорожные карты продукта

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

    Есть три типа дорожных карт продукта, которые используются производственными группами Agile:

    • Стратегическая дорожная карта
    • Дорожная карта технологий или ИТ
    • План выпуска

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

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

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

    Источник: productplan.com

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

    Пример технологической дорожной карты

    Источник: hutwork.com

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

    Пример плана выпуска

    Источник: productplan.com

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

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

    Инструмент общего назначения

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

    • Atlassian Confluence — самый популярный инструмент для совместных проектов, в котором есть вся экосистема для управления требованиями к продукту и написания документации.Confluence известен стабильной вики-системой и эффективным интерфейсом управления пользовательскими историями.
    • Document 360 — это база знаний самообслуживания / платформа документации по программному обеспечению, разработанная для продуктов «Программное обеспечение как услуга».
    • bit.ai — это инструмент для совместного создания, хранения, обмена данными и использования вики-системы документации. Документация интерактивна, что означает, что разработчики могут встраивать блоки или фрагменты кода прямо в документ и делиться им одним щелчком мыши. Закончив редактирование документации, вы можете сохранить ее в формате PDF или в формате markdown и опубликовать на любой другой платформе.
    • Github не нуждается в представлении, за исключением тех, кто хочет использовать его для документации по программному обеспечению. Он предоставляет вам собственную вики-систему и позволяет преобразовывать вашу документацию в привлекательные витрины веб-сайтов.

    Редакторы Markdown

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

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

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

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

    Инструменты для документации UX

    Самыми популярными инструментами для проектирования пользовательского интерфейса являются инструменты для создания прототипов, которые помогают создавать эскизы, макеты, каркасы и интерактивные прототипы:

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

    Интерфейс эскиза

    • InVision — один из самых популярных инструментов для создания прототипов. InVision славится своими функциями совместной работы и кроссплатформенными возможностями, что делает его отличным инструментом для разработки будущих интерфейсов.
    • UXPin — это инструмент для проектирования Mac и Windows, который позволяет создавать любые типы чертежей. Вы также можете загрузить свои эскизы или каркасы из других продуктов и сделать из них интерактивный прототип.
    • Adobe XD — где XD означает опыт дизайна.Продукт ориентирован на UX-специалистов. Это позволяет дизайнерам создавать прототипы с высокой точностью и делиться ими через приложение.

    Инструменты для документации API

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

    • Swagger — это бесплатный сервис самодокументируемого программного обеспечения, предназначенный для создания и обновления веб-сервисов и API RESTful.
    • RAML 2 HTML — это простой генератор документации, использующий спецификации RAML.

    Инструменты для технических писателей

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

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

    Образцы и шаблоны программной документации

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

    Шаблоны общей проектной документации

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

    • Atlassian Confluence Templates предлагает готовые шаблоны проектной документации общего назначения вместе со своим продуктом.
    • ReadySET Pro — это большая библиотека шаблонов документации по программному обеспечению в формате HTML, которая включает документы планирования, архитектуру, дизайн, требования, тестирование и многое другое.
    • ReadTheDocs — это универсальный шаблон, созданный на платформе ReadTheDocs, содержащий инструкции по написанию каждого типа документа, который может вам понадобиться, от архитектуры и диаграмм UML до руководств пользователя.

    Шаблоны дорожных карт продукта

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

    Шаблоны документации по обеспечению качества

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

    • StrongQA.com имеет различные шаблоны документации для QA-специалистов. К ним относятся контрольные списки тестирования, шаблоны дымового тестирования, планы тестирования и многое другое.
    • Template.net имеет раздел с шаблонами планов обеспечения качества.
    • EasyQA предлагает SDK для тестирования программного обеспечения и шаблоны с подробным руководством по созданию качественного плана тестирования.
    • Тестирование программного обеспечения — это большая платформа, включающая блог, форум и всевозможные информационные материалы для специалистов по тестированию.

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

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

    Примеры специализированной архитектуры: AWS, Microsoft Azure и Google Cloud

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

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

    Как писать документацию по программному обеспечению: общие советы

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

    Напишите достаточно документации

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

    Учитывайте свою аудиторию

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

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

    Использовать перекрестные ссылки

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

    Не игнорируйте глоссарии

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

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

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

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

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

    Документация — совместная работа всех членов команды

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

    Нанять технического писателя

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

    Дополнительные советы по созданию и поддержке документации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Заключение

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

    Документирование — это проектирование: как документация способствует улучшению результатов проектирования | 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-дизайна, поэтому я не буду повторять это здесь, а вместо этого отсылаю вас к моей статье Object Modeling for Designers .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Типы документации по программному обеспечению и передовой опыт | by AltexSoft Inc

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

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

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

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

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

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

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

    Соблюдая следующие классификации.

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

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

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

    • Системную документацию и
    • Пользовательскую документацию

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

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

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

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

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

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

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

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

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

    1. Роли и обязанности .Начните свой документ с информации об участниках проекта, включая владельца продукта, членов команды и заинтересованных лиц. Эти детали прояснят обязанности и сообщат цели целевого выпуска для каждого из членов команды.
    2. Цели команды и бизнес-цель . Кратко опишите самые важные цели.
    3. Предпосылки и стратегическое соответствие . Кратко объясните стратегическую цель ваших действий. Зачем вы создаете продукт? Как ваши действия влияют на разработку продукта и соответствуют целям компании?
    4. Предположения. Составьте список технических или бизнес-предположений, которые могла бы иметь группа.
    5. Пользовательские истории. Перечислить или связать пользовательские истории, необходимые для проекта. Пользовательская история — это документ, написанный с точки зрения человека, использующего ваш программный продукт. Пользовательская история — это краткое описание действий клиентов и результатов, которых они хотят достичь.
    6. Взаимодействие с пользователем и дизайн . Свяжите со страницей исследования дизайна и каркасы.
    7. Вопросы. По мере того, как команда решает проблемы по ходу проекта, у них неизбежно возникает много вопросов. Хорошая практика — записывать все эти вопросы и отслеживать их.
    8. Не работает. Составьте список того, что вы не делаете сейчас, но планируете сделать в ближайшее время. Такой список поможет вам организовать работу в команде и расставить приоритеты.

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

    • Используйте ссылки и якоря .Они помогут вам упростить чтение и поиск документа, поскольку читатели смогут постепенно понимать информацию. Например, вы можете предоставить ссылки на интервью с клиентами и ссылки на предыдущие обсуждения или другую внешнюю информацию, связанную с проектом.
    • Используйте инструменты построения диаграмм , чтобы лучше сообщить о проблемах своей команде. Люди более склонны воспринимать информацию, глядя на изображения, чем читая обширный документ. Различные визуальные модели помогут вам выполнить эту задачу и более эффективно обозначить требования.Вы можете включать диаграммы в процесс создания требований, используя следующие программные инструменты построения диаграмм: Visio, Gliffy, Balsamiq, Axure или SmartArt в Microsoft Office.

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

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

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

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

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

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

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

    Документы исходного кода могут включать, но не ограничиваются следующими деталями:

    • Структура генерации HTML и другие применяемые структуры
    • Тип привязки данных
    • Шаблон проектирования с примерами (например,грамм. model-view-controller)
    • Меры безопасности
    • Другие шаблоны и принципы

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

    В Agile есть разные типы тестовых документов. Мы выделили наиболее распространенные:

    • Стратегия тестирования
    • План тестирования
    • Спецификации тестовых примеров
    • Контрольные списки тестов

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

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

    • Список тестируемых функций
    • Методы тестирования
    • Сроки
    • Роли и обязанности (e.грамм. Модульные тесты могут выполняться командой QA или инженерами. Обычно команда QA составляет отдельный документ со спецификациями для каждой единицы продукта. Спецификации тестового набора основаны на подходе, изложенном в плане тестирования. Хорошая практика — упростить описание спецификаций и избежать повторений тестовых примеров.

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

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

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

      • конечных пользователей
      • системных администраторов

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

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

      • Часто задаваемые вопросы
      • Видеоуроки
      • Встроенная поддержка
      • Порталы поддержки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    About Author


    alexxlab

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

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