Документирование объёмов работ проекта

Содержание

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

Документирование объёмов работ проекта
  /  Услуги архитектурного дизайн бюро

Рабочая документация — это совокупность текстовых и графических документов, обеспечивающих реализацию принятых в утвержденной проектной документации технических решений объекта капитального строительства, необходимых для производства строительных и монтажных работ, обеспечения строительства оборудованием, изделиями и материалами и/или изготовление строительных изделий. (Примечание: в состав рабочей документации входят основные комплекты рабочих чертежей, спецификации оборудования, изделий и материалов, сметы, другие прилагаемые документы, разработанные в дополнение к рабочим чертежам основного комплекта). [ГОСТ Р 21.1001-2009].

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

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

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

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

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

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

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

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

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

  • Одностадийное проектирование осуществляется при параллельной разработке проектной документации и рабочей документации. Ранее проектный документ, разрабатываемый при одностадийном проектировании, именовался “рабочий проект” (РП) и состоял из утверждаемой части рабочего проекта и рабочей документации. Эти две составляющие рабочего проекта соответствуют принятым в настоящее время понятиям “проектная документация” и “рабочая документация” соответственно.
  • Двустадийное проектирование осуществляется при последовательной разработке проектной документации и рабочей документации. Ранее проектные документы, разрабатываемые при двустадийном проектировании именовались “проект” или “ТЭО” (1 стадия) и “рабочая документация” (2 стадия). Эти два проектных документа так же соответствуют принятым в настоящее время понятиям “проектная документация” и “рабочая документация” соответственно.
  • Трехстадийное проектирование (предпроектное предложение, проект, рабочая документация) – для объектов V, IV категорий сложности и для объектов III категории сложности по индивидуальным проектам, с недостаточным перечнем исходно-разрешительной документации.

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

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

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

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

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

  • основных комплектов чертежей по маркам (АС – Архитектурно-строительные решения, КЖ – конструкции железобетонные, ЭС – Электроснабжение, ВК – Внутренние сети водоснабжения и канализации и другие), в соответствии с процессом организации строительно-монтажных работ;
  • СО (спецификации оборудования);
  • ВМ и СВМ (ведомостей потребления материалов, в т.ч. Сводной);
  • ВР и СВР (ведомостей строительно-монтажных работ, в т.ч. Сводной);
  • рабочей документации на строительные изделия:

  а. чертежей деталей;

  б. СБ (сборочных чертежей);

  в. спецификаций сборочных единиц;

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

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

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

В них отсутствуют излишняя информация и необоснованные повторения.

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

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

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

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

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

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

Не учтено расстояние между фундаментом и основанием откоса, необходимое для работы в пазухе котлована (согласно СНиПа оно должно быть не менее 0,6 м);

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

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

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

К другим нарушениям, выявляемым в процессе экспертизы смет, относятся ошибки в применении:

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

При подготовке статьи были использованы источники:

sevak-world.web-box.ru/construction/designing

dic.academic.ru/dic.nsf/ruwiki/1609069

Пример состава проекта интерьеров дома, стадии РД (рабочая документация)

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

Источник: https://www.ab-glushkov.ru/uslugi/p2_articleid/13615

Документирование объёмов работ проекта

Документирование объёмов работ проекта

Итак, мы формально и документально запустили проект. Теперь нужно разобраться, как выявить все объёмы работ нашего проекта и правильно их оформить. В классике проектного управления это называется «Планирование содержания проекта». Я же расскажу, как это «содержание» документировать.

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

Выяснить и оформить требования

Требования бывают двух типов:

  1. Требования к проекту – т.е. как мы должны управлять проектом.
  2. Требования к продукту – т.е. что мы должны получить в итоге проекта.

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

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

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

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

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

Нужно понимать, что изменения в проекте неизбежны.

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

Следовательно – требования будут меняться, а Реестр требований позволяет отследить эти изменяющиеся требования на всём протяжении проекта. Идеальным вариантом оформления и ведения этого документа – использование специального ПО для отслеживания требований, типа Redmine или того же MS Project Server, только немного «доработанного напильником».

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

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

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

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

Описать объёмы работ

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

Итогом действа будет документ, который ПМ-ы называют Описание содержания проекта.

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

Описание содержания включает в себя:

  • Описание продукта, описанного в Уставе проекта и в Документации по требованиям.
  • Критерии приемки, т.е. условия, которые должны быть выполнены для того, продукт и результаты проекта были приняты заказчиком.
  • Исключения из проекта — явная формулировка того, что именно в проекте точно не будет выполняться, чтоб не раздувать объёмы работ проекта.
  • Ограничения, т.е. пределы или ограничивающие условия, которые оказывают влияние на исполнение проекта, например, предопределенный бюджет.
  • Допущения — факторы, которые считаются верными, реальными или определенными без предоставления доказательств и без демонстрации. Допущения могут оказаться ошибочными и как правило являются источником рисков в проекте, но они позволяют запустить планирование проекта без долгих исследований. Одним из ярчайших примеров допущения в истории управления проектами является допущение, что луна твёрдая. Слышал о таком допущении? Нет? Я расскажу:Середина 60-х годов XX-го века. Советская лунная программа разрабатывается полным ходом. И тут возникает вопрос: каким делать шасси посадочной станции? Ведь невозможно проектировать его, не зная, хотя бы приблизительно, куда станция будет садиться. А что представляет собой грунт лунной поверхности, никто ещё точно сказать не мог. Одна группа астрономов утверждала, что на Луне почва твердая, а вторая столь же убедительно доказывала, что за многовековую историю Луны из-за постоянной бомбардировки метеоритами там образовался слой пыли, причем его толщина достигает 50-ти метров в кратерах, а на ровных участках – десяти… Королёв собрал совещание, пригласив всех заинтересованных в лунной программе специалистов. За два часа совещания все переругались друг с другом, и только сам Королев не произнес ни слова. Смотрел и слушал. Словно ждал чего-то. Наконец, взял слово. – Луна – твердая! – сказал он резко и, как обычно, безапелляционно. Кто-то из астрономов все-таки возразил: – Это еще доказать надо! Никто из учёных не берёт на себя смелость написать — на Луне, мол, такой-то грунт… и подписаться под этим! Королев посмотрел усталыми глазами на сидящих за столом: — Ах, вот чего вам не хватает… Взял блокнот, крупным почерком написал на его листке: «ЛУНА — ТВЕРДАЯ». Подписался: «С. КОРОЛЁВ». Поставил дату, вырвал листок из блокнота и передал сотруднику, которому предстояло непосредственно руководить проектированием станции.

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

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

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

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

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

Разбить на составляющие

Разбиение объёмов работ проекта на более мелкие и, следовательно, легче управляемые части позволяет получить WBS — структурированное видение того, что необходимо достичь.
WBS, т.е. work breakdown structure или иерархическая структура работ может быть организована по разному, к примеру, по этапам проекта, по основным конструктивам, по подпроектам или микс из этих элементов.

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

Визуализация на схеме:

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

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

Для чего структурируем?

  1. Для разбивки проекта на управляемые блоки
  2. Для перехода от общих описаний к конкретным заданиям
  3. Для распределения ответственности и определения комплексов работ/подрядов
  4. Для более точной оценки затрат

Наиболее подробно методика разработки WBS описана в Practice Standard for Work Breakdown Structures – Second Edition.

Итого

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

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

В следующей статье я расскажу, как документировать команду проекта.

Источник: http://www.pmdoc.ru/docs_of_project_scope/

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

Документирование объёмов работ проекта

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

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

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

  • Устав проекта (Project Charter) – фиксирует партнерство между исполнителем и клиентом. Устав, как правило, разрабатывается менеджером проектов. Цель создания документа – подтверждение запуска проекта, предоставление менеджеру проектов полномочий в использовании ресурсов компании, в планировании, исполнении проекта и контроля над ним.
  • План управления проектом – это документ, подробно описывающий, как проект будет выполняться, каким образом будет происходить мониторинг и контроль как отдельных этапов, так и проекта в целом.
  • Бизнес-требования (Business Requirements Document (BRD)) – детализируют бизнес-решения для проекта, включая документацию о потребностях и ожиданиях клиента. Как правило, основываются на использовании User Stories (короткие и простые описания фич).
  • Техническое задание (спецификация, SOW) – оговоренный набор требований к продукту, утвержденный заказчиком и компанией исполнителем (функциональные требования, которые должны быть реализованы разработчиками, чтобы пользователи могли выполнить свои задачи в рамках бизнес-требований).
  • Реестр заинтересованных сторон (Stakeholder Map) – по каждому стейкхолдеру описывается: фамилия, имя и отчество; должность; степень влияния; степень важности; «состояние» стейкхолдера (Работа со стэйкхолдерами); за что отвечает в проекте, а также перечень вопросов, которые с ним можно обсуждать; каналы коммуникации; контактные данные;
  • Матрица влияния стейкхолдеров на проект (Работа со стэйкхолдерами);
  • Communication Plan Matrix – содержит: тип информации, которой необходимо делиться с заинтересованными сторонами (Status Reports, Status Updates, результаты митингов и др.); цель ведения коммуникации; кто ответственный за доставку информации; кто получатель; способ и формат предоставления необходимой информации: телефонный звонок, e-mail, видеоконференция, сообщение в канале, отчет, презентация, и т.д.; с какой периодичностью и в какое время необходимо предоставлять информацию;
  • Расписание проекта (Project Schedule) – список контрольных событий и дат их реализации;
  • Meeting Notes (Kick off Meeting, Planning Meeting, Stand-up Meeting, Retrospective) – фиксация результатов любых встреч, которые касаются обсуждения вопросов, связанных с проектом.
  • Матрица ответственности по проекту – фиксация степени ответственности каждого члена команды за реализацию определенных функций.
  • Реестр рисков (Risk Register) – содержит сведения об идентифицированных рисках проекта, а также список возможных мер реагирования на риски. В документе отражается: номер; дата внесения; название риска; подробное описание; кто ответственный за управление риском; точки уязвимости (первопричины); вероятность возникновения риска; степень влияния на проект; стратегии снижения риска; тенденции риска.
  • Матрица вероятности и воздействия (матрица рисков) – включает критерии оценки рисков, а именно: уровень ущерба от реализации риска и вероятность наступления рискового события в течении определенного периода времени. В начале составляется шкала воздействия рисков (на примере «стоимость»: незначительное увеличение стоимости – показатель воздействия очень низкий (0,05), увеличение стоимости 40% – показатель воздействия очень высокий (0,8)), далее определяется вероятность возникновения риска и ожидаемое значение риска (произведение вероятности на воздействие). И такой анализ происходит по каждому риску.
  • Отчет по рискам – документ, содержащий информацию об источниках совокупного риска проекта, результаты качественного анализа рисков, количественного анализа рисков, планирования реагирования на риски, осуществления реагирования на риски и мониторинга рисков.
  • Risk Log – заполняется лишь в том случае, если пришлось воспользоваться реестром рисков и последовать рекомендациям, которые в нем описаны. В документе отражается: номер; дата возникновения; название риска; подробное описание; кто идентифицировал; кто ответственный за устранение; приоритет; степень влияния на проект; рекомендуемые действия; статус; дата закрытия.
  • Issue Log (Incident Report) – это документирование события, которое нарушило нормальную работу какой-либо системы (процесса и т.п.), и того, как эта ситуация была обработана. В документе фиксируется: номер инцидента; дата возникновения; название; подробное описание; кто идентифицировал; кто ответственный за устранение; приоритет; степень влияния на проект; рекомендуемые действия; статус; дата закрытия.
  • Журнал изменений (иногда называют Change Requests) – фиксация запросов на изменение какого-либо функционала продукта. Запрос на изменение часто возникает, когда клиент хочет что-то добавить или изменить, после того, когда уже все требования были согласованы. Такое изменение может включать в себя дополнительную функцию, настройку или расширение функционала. Поскольку запросы на изменение выходят за рамки соглашения, это обычно означает, что клиент должен будет заплатить за реализацию данного функционала дополнительно. Как правило, Change Requests содержит: наименование проекта; порядковый номер риквеста; наименование запроса; дату запроса; описание запрашиваемых изменений; причину внесения изменений; влияние изменений на: существующие требования, график выполнения работы, стоимость проекта.
  • Weekly Project Status Report – фиксация раз в неделю: достижений за прошлую неделю; невыполненных тасков на прошлой неделе; проблем, с которыми столкнулась команда на прошлой неделе; номеров Change Requests, которые появились за неделю; планов на следующую неделю; Upcoming Milestones (не все упоминать, а ближайшие 2-3 этапа); новых рисков; показателей по ключевым метрикам (Мониторинг и контроль выполненных работ по проекту).
  • Документация от тестировщиков (Test Plan и т.п.).
  • Руководство пользователя – документ, оказывающий помощь пользователю в процессе эксплуатации системы.
  • Руководство администратора – документ, оказывающий помощь не только в процессе эксплуатации системы, но и в ее установке и настройке.

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

Источник: https://itplus.org.ua/dokumentirovanie-proekta/

Рабочий проект: требования, состав, разделы и оформление

Документирование объёмов работ проекта

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

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

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

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

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

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

к оглавлению ↑

Зачем необходим рабочий проект

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

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

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

к оглавлению ↑

Особенности с точки зрения экспертизы

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

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

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

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

к оглавлению ↑

Еще немного об отличиях рабочего проекта

Частая ошибка застройщиков – работа исключительно для экспертизы.

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

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

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

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

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

к оглавлению ↑

Этапы разработки рабочего проекта

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

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

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

к оглавлению ↑

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

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

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

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

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

Задача заказчика здесь – составить техническое задание, которое учитывало бы требования СПДС.

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

к оглавлению ↑

Что входит в рабочий проект

Рабочая документация включает:

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

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

  • чертежи на используемые изделия (И);
  • локальная смета (ЛС);
  • спецификация на изделия, материалы и оборудование (С);
  • чертежи на нетиповые изделия (Н);
  • опросные листы и габаритные чертежи (Л).

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

к оглавлению ↑

Особенности составления

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

Для каждого проекта будет своя степень деталировки – все зависит от степени сложности объекта. Но очень важно отобразить в рабочей части все, что описано в проектной. Она является своеобразной основой, которую затем детализируют для качественного выполнения СМР.

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

к оглавлению ↑

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

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

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

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

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

  • АД – автомобильные дороги;
  • АР – архитектурные решения;
  • АИ – интерьеры;
  • АС – архитектурно-строительные решения;
  • ГП – генеральный план;
  • ПЖ – железнодорожные пути;
  • ТК – технологические коммуникации;
  • ТР – сооружения транспорта;

к оглавлению ↑

Другие разделы

Архитектурно-строительные разделы:

  • АЗ – антикоррозионная защита;
  • ГР – гидротехнические решения;
  • КМ – металлические конструкции;
  • КД – конструкции деревянные;
  • КМД – конструкции металлические деталировочные.

Электротехнические разделы:

  • ЭМ – силовое электрооборудование;
  • ЭН и ЭО – освещение наружное и внутреннее;
  • ЭС – электроснабжение.

Разделы водоснабжения и канализации:

  • ВК – внутренние сети канализации и водоснабжения;
  • НВК – наружные сети водоснабжения и канализации;
  • НВ – наружные сети водоснабжения;
  • НК – наружные сети канализации;
  • ПТ – системы пожаротушения.

Технологические разделы:

  • АЗО – антикоррозионная защита трубопроводов, газоходов, технологических аппаратов;
  • ТК – технологические коммуникации;
  • ТХ – технология производства;
  • ПУ – меры по пылеудалению.

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

https://www.youtube.com/watch?v=I_hCd11czj0\u0026list=PLynEAnOVAIEo98P2kBkBTHJF-y-QPmAZV

к оглавлению ↑

Основные нюансы оформления рабочей документации

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

После него должно идти содержание альбома с полным перечнем всех представленных документов. Его форма приведена в Приложении Г ГОСТ Р 21.1102-2013. Документы в содержании должны быть указаны в том порядке, в котором они представлены в пакете.

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

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

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

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

к оглавлению ↑

Частые ошибки при разработке

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

Нередко ошибки связаны с подсчетом объемов работ:

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

к оглавлению ↑

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

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

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

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

Источник: https://abv-proekt.ru/blogs/rabochij-proekt-trebovaniya-sostav-razdely-i-oformlenie/

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

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

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.