Смета на разработку проектной документации: Ошибка: 404 - Страница не найдена

Содержание

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

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

Раздел «Сметный расчет» разрабатывается как на РД для обоснования стоимости строительства объетка.

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

— Методики определения сметной стоимости;

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

— Используемые программные комплексы при выполнении работ;

— Состав сметной документации.

Москвы с последующими дополнениями), в 2-х уровнях цен (базовый уровень и текущий уровень в ценах действующих на момент разработки ПСД). МДС 81-35.2004 «Методика определения стоимости строительной продукции на территории РФ» утвержденная Постановлением Госстроя России от 05.03.2004г. № 15/1 («Ценообразование и сметное нормирование в строительстве» № 8, 2004г.

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

Примерный состав сметной документации на стадии «РД»:

1. Сводная ведомость объемов работ

2. Сводный сметный расчет

3. Локальные сметы.

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

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

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

Срок разработки сметной документации от 5 рабочих дней.

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

Если мы Вам не ответили в течение 2-х часов, мы Вам гарантируем 10% скидку от полной стоимости работ. Для этого просим вас написать на info@specrazdel. ru, указав в теме письма СМЕТА РД скидка 10%.

9.1.2 Сборник на проектные работы

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

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

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

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

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

Это можно увидеть в окне с дополнительной информацией о позиции на закладке Прочие.

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

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

Значения коэффициентов относительной стоимости указываются в зависимости от стадии проектирования П, РД или РП (П – проектная документация, РД – рабочая документация, РП – рабочий проект).

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

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

Прочие. Данная информация отображается в сметах и выводится на печать.

На какой стадии разрабатываются сметы

Стадии проектирования. На какой стадии разрабатывается сметная документация

Проектирование ведется в две или одну стадию.

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

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

Это удобно при небольших объемах проектных работ.

Практически эти схемы осуществляются следующим образом.

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

стадия «Проект»(П)
стадия «Рабочая документация» (РД)

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

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

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

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

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

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

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

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

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

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

Двухстадийное проектирование (проект, рабочая документация) – для объектов V, IV категорий сложности и для объектов III категории сложности по индивидуальным проектам.

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

megaobuchalka.ru

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

Раздел «Сметный расчет» разрабатывается как на РД для обоснования стоимости строительства объетка.

— Методики определения сметной стоимости;

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

— Используемые программные комплексы при выполнении работ;

— Состав сметной документации.

Для объектов, строительство которых планируется на территории г. Москвы в соответствии с постановлением Правительства Москвы № 900-ПП от 14.11.2006 г., сметную документацию необходимо выполнить в соответствии с территориальными сметными нормативами ТСН-2001 для г. Москвы с последующими дополнениями), в 2-х уровнях цен (базовый уровень и текущий уровень в ценах действующих на момент разработки ПСД). МДС 81-35.2004 «Методика определения стоимости строительной продукции на территории РФ» утвержденная Постановлением Госстроя России от 05.03.2004г. № 15/1 («Ценообразование и сметное нормирование в строительстве» № 8, 2004г.

Примерный состав сметной документации на стадии «РД»:

1. Сводная ведомость объемов работ

2. Сводный сметный расчет

3. Локальные сметы.

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

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

Срок разработки сметной документации от 5 рабочих дней.

Если мы Вам не ответили в течение 2-х часов, мы Вам гарантируем 10% скидку от полной стоимости работ. Для этого просим вас написать на [email protected], указав в теме письма СМЕТА РД скидка 10%.

specrazdel.ru

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

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

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

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

Одностадийное проектирование

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

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

Двухстадийное проектирование

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

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

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

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

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

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

Предпроектное предложение

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

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

Стадия «Проект»

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

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

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

На стадии «Р» проектные решения прорабатываются более детально, на основании чего разрабатывается:

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

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

ГОСТ 21.101-93 «СПДС. Основные требования к рабочей документации»;
ГОСТ 21.110 «СПДС. Правила выполнения спецификации оборудования, изделий и материалов».

Марки комплектов рабочих чертежей

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

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

АР – архитектурные решения. Поэтажные планировки, разрезы, чертежи фасадов.

КР – конструкции решения. Чертежи фундаментов, стен, перекрытий, лестниц, металлических конструкций.

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

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

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

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

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

pnproject.ru

Стадии проектирования. На какой стадии разрабатывается сметная документация

Проектирование ведется в две или одну стадию.

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

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

Практически эти схемы осуществляются следующим образом.

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

стадия «Проект»(П)
стадия «Рабочая документация» (РД)

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

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

Двухстадийное проектирование (проект, рабочая документация) – для объектов V, IV категорий сложности и для объектов III категории сложности по индивидуальным проектам.

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

student2.ru

Пересчет сметной документации при двухстадийном проектировании. В помощь сметчику. Электронный бератор. Сметное дело.

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

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

Возведение, реконструкция, реставрация, капитальный ремонт, благоустройство объекта осуществляются на основе утвержденной проектной документации (утвержденной части проектной документации), в т. ч. сметы (сметной документации). Это установлено п. 1 ст. 51 Закона Республики Беларусь от 05.07.2004 № 300-З «Об архитектурной, градостроительной и строительной деятельности в Республике Беларусь», в редакции от 04.01.2014 № 130-З.

Утверждение проектной документации осуществляется на основании Положения о порядке разработки, согласования и утверждения градостроительных проектов, проектной документации, утвержденного постановлением Совмина от 08.10.2008 № 1476, в редакции от 17.11.2015 № 958.

В соответствии с п. 42 Положения № 1476 при проектировании в две стадии утверждению подлежит архитектурный проект.

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

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

В соответствии с п. 41 Положения № 1476 утвержденная проектная документация является основанием для финансирования строительства, а также для получения разрешения на производство СМР.

Условие проведения пересчета сметной документации установлено п. 3 Положения о порядке формирования неизменной договорной (контрактной) цены на строительство объектов, утвержденного постановлением Совмина от 18.11.2011 № 1553, в редакции от 10.11.2014 № 1061. Указанным пунктом закреплено, что если с даты начала разработки сметной документации до даты фактического начала строительства объекта прошло более 12 месяцев, то по заданию заказчика необходимо произвести пересчет сметной документации с применением цен и тарифов на дату фактического начала строительства объекта с повторным прохождением государственной экспертизы в установленном порядке. Таким образом, в Положении № 1553 не уточнено, какая сметная документация, входящая в состав архитектурного или строительного проектов, подлежит пересчету.

Определение понятия сметной документации приведено в ст. 1 Закона № 300-З и п. 3 ТКП 45-1.02-295-2014 «Строительство. Проектная документация. Состав и содержание», утвержденного приказом Минстройархитектуры от 27.03.2014 № 85, с учетом изменения № 2.

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

Также в ст. 1 Закона № 300-З и п. 3 ТКП 45-1.02-295-2014 приведены понятия проектной документации, архитектурного и строительного проекта.

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

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

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

Из приведенных определений следует, что сметная документация входит в состав проектной документации, а, в свою очередь, строительный и архитектурный проекты являются стадиями разработки проектной документации. Также пп. 5.1.2, 5.1.4, 5.1.6 ТКП 45-1.02-295-2014 установлено, что одним из разделов архитектурного проекта является сметная документация, а п. 3.2 СТБ 2255-2012 «Система проектной документации для строительства. Основные требования к документации строительного проекта», утвержденного постановлением Госстандарта от 12.03.2012 № 14, установлено, что сметная документация входит в состав строительного проекта. То есть сметная документация разрабатывается как при первой стадии проектирования, так и при второй.

В соответствии с п. 4.4 ТКП 45-1.02-295-2014 строительный проект при двухстадийном проектировании разрабатывается на основе утвержденного архитектурного проекта, материалов инженерных изысканий.

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

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

Наталья Ходорик, инженер

smetnoedelo.by

Этапы и стадии проектирования: нормы, принципы и требования

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

Характеристика стадии ПД

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

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

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

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

Характеристика стадии РД

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

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

Какие существуют стадии в процессе строительства?

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

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

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

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

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

К основным стадиям проектирования можно отнести:

ТЭО – техническое и экономическое обоснование.
ТЭР – технические и экономические расчеты.
ЭП – эскиз проектов
П – проект.
РП – рабочий проект.
Р – рабочие документы.

Характеристика стадий в процессе проектирования

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

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

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

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

1. Объекты, которые имеют 1 и 2 категорию сложности, выполняются:

в один этап с помощью рабочего проекта;
в два этапа с помощью проекта эскиза.

2. Объекты, имеющие 3 категорию сложности, выполняются в два этапа: проект и рабочая документация.

3. Для объектов, имеющих 4 и 5 категорию сложности, предусмотрены три этапа:

ЭП для непроизводственных строений и ТЭО;
проектная разработка;
рабочие документы.

Проектирование, выполняющееся в один этап

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

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

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

Проектирование, выполняющееся в два этапа

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

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

Из чего состоят проектные документы?

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

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

Предпроектные документы

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

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

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

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

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

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

Этап, в который входят рабочие документы

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

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

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

Ряд требований для строительной площадки

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

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

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

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

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

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

fb.ru

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

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

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

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

Особенности создания

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

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

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

Подготовительные мероприятия

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

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

Нормативная база

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

Область действия предписаний

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

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

Положение действует в отношении:

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

Состав

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

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

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

Для капитальных сооружений проектно-сметная документация состоит из 12 разделов, таких как:

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

Дополнительно

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

Экспертиза

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

Экспертиза не проводится:

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

Самым продолжительным этапом считается согласование (утверждение) проектно-сметной документации.

Разрешение

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

angaraleshoz.ru

NormaCS ~ Ответы экспертов ~ Существует ли сейчас стадия проектирования «рабочий проект»?

Градостроительным кодексом Российской Федерации от 29. 12.2004 № 190-ФЗ и подзаконными актами, введенными в действие в развитие указанного Кодекса, стадия проектирования «рабочий проект» не установлена.

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

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

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

При этом, согласно подпункту «г» пункта 13 Положения об организации и проведении государственной экспертизы проектной документации и результатов инженерных изысканий, утв. постановлением Правительства Российской Федерации от 05. 03.2007 № 145, для проведения государственной экспертизы проектной документации, в том числе, представляется «проектная документация на объект капитального строительства в соответствии с требованиями (в том числе к составу и содержанию разделов документации), установленными законодательством Российской Федерации», т.е. в объеме, установленном Положением, утв. постановлением Правительства Российской Федерации от 16.02.2008 № 87.

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

Однако частью 2.1 статьи 49 данного Кодекса предусмотрено: «В случае, если строительство, реконструкцию указанных в части 2 настоящей статьи объектов капитального строительства планируется осуществлять в границах охранных зон объектов трубопроводного транспорта, экспертиза проектной документации на осуществление строительства, реконструкции указанных объектов капитального строительства является обязательной».

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

Вместе с тем необходимо иметь в виду, что, например:

1. Согласно пункту 6 Правил принятия решения о предоставлении бюджетных инвестиций юридическим лицам, не являющимся государственными или муниципальными учреждениями и государственными или муниципальными унитарными предприятиями, в объекты капитального строительства за счет средств федерального бюджета, утв. постановлением Правительства Российской Федерации от 24.10.2013 № 941, в проект решения включаются инвестиционные проекты, которые «соответствуют качественным и количественным критериям и предельному (минимальному) значению интегральной оценки эффективности использования средств федерального бюджета, направляемых на капитальные вложения, проведенной главным распорядителем в порядке, установленном Правилами проведения проверки инвестиционных проектов на предмет эффективности использования средств федерального бюджета, направляемых на капитальные вложения, утвержденными >постановлением Правительства Российской Федерации от 12 августа 2008 г. № 590, а также документам территориального планирования Российской Федерации, в случае если объект капитального строительства и (или) объект недвижимого имущества являются объектами федерального значения, подлежащими отображению в этих документах».

Как указано, в подпункте «и» пункта 7 Правил проведения проверки инвестиционных проектов на предмет эффективности использования средств федерального бюджета, направляемых на капитальные вложения, утв. постановлением Правительства Российской Федерации от 12.08.2008 № 590, проверка осуществляется на основе качественных критериев оценки эффективности использования средств федерального бюджета, направляемых на капитальные вложения, к числу которых отнесено:

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

2. Подпунктами «б» и «в» пункта 3 Правил предоставления субсидий из федерального бюджета, главным распорядителем в отношении которых является Министерство строительства и жилищно-коммунального хозяйства Российской Федерации, бюджетам субъектов Российской Федерации на софинансирование объектов капитального строительства государственной собственности субъектов Российской Федерации, не включенных в федеральные целевые программы, бюджетные инвестиции в которые осуществляются из бюджетов субъектов Российской Федерации, и (или) на предоставление соответствующих субсидий из бюджетов субъектов Российской Федерации на софинансирование объектов капитального строительства муниципальной собственности, не включенных в федеральные целевые программы, бюджетные инвестиции в которые осуществляются из местных бюджетов, утв. постановлением Правительства Российской Федерации от 31.03.2014 № 255, установлено, что субсидия предоставляется, в том числе, при следующих условиях:

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

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

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

www.normacs.info

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

Стадии проектирования в строительстве и их особенности.

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

Трёхстадийная система разработки проектной документации.

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

1-Обоснования инвестиций (стадия «ОИ»). На этой стадии рассматриваются разного рода технические и экономические аспекты создания конечного объекта по заданным исходным данным. Примечание: Стадия обоснования инвестиций на особо сложные или опасные объекты подлежит обязательной государственной экспертизе как предпроектная документация;

2-Технико-экономическое обоснование (стадия «П») или сокращённо «ТЭО» На этой стадии проект разрабатывается на основании утвержденных и прошедших экспертизу ОИ и состоит из принятых технических решений, описания функционирования объекта с учетом внешних условий, требований к эксплуатации и т. д. ТЭО подлежит отдельной государственной экспертизе;

3-Рабочая документация (Стадия «Р»). Комплект рабочей документации (РД) содержит все чертежи и технологические пояснения, необходимые строительства объекта. РД – основной документ для производителя работ, бригадиров, монтажников. Помимо РД выполняется разработка смет к проекту, содержащих подробный расчёт стоимости объекта.

Рекомендуем также: «Нужна ли экспертиза на проектную документацию по строительству сетей связи ?» и другие статьи раздела: «Правовая грамотность».

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

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

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

2-Рабочая документация (РД) – рабочие чертежи, необходимые для производства СМР с пояснениями;

3-Сметная часть комплекта проектной документации.

P.S. В России при подготовке проектной документации необходимо использовать Градостроительный кодекс Российской Федерации (ст. 48, 49) и Постановления Правительства Российской Федерации № 87 от 16 февраля 2008 г. «Положение о составе разделов проектной документации и требованиях к их содержанию» и № 145 от 05.03.2007 г. «О порядке организации и проведения государственной экспертизы проектной документации и результатов инженерных изысканий» (с изменениями от 29.12.2007 г., 16.02.2008 г.).

Смотрите состав исполнительной в разделе: «Состав исполнительной»

Скачивайте акты, протокола и другое в разделе: «Акты и прочее»

Скачивайте полезные книги, ГОСТы, СнИПы в разделе: «ГОСТы и книги«

xn--80aalccoafpfcpgdfeii1bzaks8eyg5cl.xn--p1ai

Можно ли ограничиться локальным сметным расчетом при закупке работ по капитальному ремонту объекта капитального строительства?

Вопрос о том, можно ли ограничиться локальным сметным расчетом при закупке работ по капитальному ремонту объекта капитального строительства для заказчиков, применяющих Закон №44-ФЗ всегда вызывал споры. Началось все с того, что буквальное прочтение пункта 1 части 9 статьи 22 Закона №44-ФЗ указывает на то, что проектно-сметный метод обоснования начальной (максимальной) цены контракта может быть применен к закупке работ по капитальному ремонту объекта капитального строительства исключительно при наличии проектной документации.

Данную позицию в своих письмах от 12.09.2016 N Д28и-2409 и от 25.11.2016 N Д28и-3139 неоднократно подтверждало Минэкономразвития России.

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

В письме Минэкономразвития России от 24.04.2017 N ОГ-Д28-5206 прямо указывается на то, что проектно-сметный метод может применяться для определения начальной (максимальной) цены контракта исключительно при наличии проектной документации.

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

С внесением изменений в Закон №44-ФЗ в июле 2019 года проблема локального сметного расчета стала вновь актуальной. Так согласно пункта 8 части 1 статьи 33 Закона №44-ФЗ документация о закупке при осуществлении закупки работ по строительству, реконструкции, капитальному ремонту, сносу объекта капитального строительства должна содержать проектную документацию, утвержденную в порядке, установленном законодательством о градостроительной деятельности, за исключением случая, если подготовка проектной документации в соответствии с указанным законодательством не требуется.

В соответствии с частью 3.1. статьи 66 Закона №44-ФЗ первая часть заявки на участие в электронном аукционе в случае включения в документацию о закупке проектной документации должна содержать исключительно согласие участника закупки на выполнение работ на условиях, предусмотренных документацией об электронном аукционе (такое согласие дается с использованием программно-аппаратных средств электронной площадки). Таким образом, исключается необходимость предоставления конкретных показателей материалов, используемых при выполнении работ, участниками закупок в составе их заявок.

Более того, сокращен срок проведения аукциона на выполнение строительных работ при наличии проектной документации. Так, согласно части 3 статьи 68 Закона №44-ФЗ электронный аукцион в случае включения в документацию о закупке проектной документации проводится через четыре часа после окончания срока подачи заявок на участие в аукционе.

Весьма интересной является позиция Союза инженеров –сметчиков, которая была изложена в письме 19.09.2019 г. № РС-ПГ-164/19 «О надлежащем исполнении требований п. 8 ч. 1 ст. 33 Закона о контрактной системе № 44-ФЗ при подготовке проектной документации в объеме сметы на капитальный ремонт объекта капитального строительства» относительно допустимости применения локального сметного расчета в качестве проектной документации.

Основываясь на положениях части 12.2 статьи 48 Градостроительного кодекса РФ в письме делается вывод, что при возникновении потребности в капитальном ремонте объектов капитального строительства заказчики могут ограничиваться только разработкой раздела 11 «Смета на капитальный ремонт объектов капитального строительства» или раздела 9 «Смета на капитальный ремонт для линейных объектов» и не разрабатывать проектную документацию в полном объеме.

Тем самым, по мнению Союза инженеров –сметчиков проектная документация подготовлена в объеме сметы на капитальный ремонт объекта капитального строительства и Заказчиком соблюдены требования пункта 8 части 1 статьи 33 Закона о контрактной системе в сфере закупок № 44-ФЗ.

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

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

Разработка проектной документации | «ТЕХПРОЕКТ»

Главная / Разработка сметной документации

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

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

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

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

Цель разработки сметной документации — определение стоимости строительно-монтажных работ на основании представленной документации и (или) визуального осмотра.

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

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

В случае необходимости наши специалисты выедут на объект заказчика.

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

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

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

Уважаемые заявители!

В соответствии со статьей 8. 3 Градостроительного кодекса РФ (далее Кодекс) сметная стоимость строительства, реконструкции, капитального ремонта объектов капитального строительства, финансируемых с привлечением средств бюджетов бюджетной системы Российской Федерации, а также сметная стоимость капитального ремонта многоквартирного дома определяется с обязательным применением сметных нормативов, внесенных в федеральный реестр сметных нормативов, и сметных цен строительных ресурсов.
Согласно части 12 статьи 48 Кодекса в состав проектной документации объектов капитального строительства включается раздел «Смета на строительство, реконструкцию, капитальный ремонт объектов капитального строительства, финансируемые с привлечением средств бюджетов бюджетной системы Российской Федерации…».
Сметная документация на строительство, реконструкцию, капитальный ремонт объектов капитального строительства должна содержать сводку затрат, сводный сметный расчет стоимости строительства, объектные и локальные сметные расчеты (сметы), сметные расчеты на отдельные виды затрат.
Пунктом 4.89 «МДС 81-35.2004. Методика определения стоимости строительной продукции на территории Российской Федерации» утвержденной Постановлением Госстроя России от 5 марта 2004 г. N 15/1, установлено, что в главу 12 «Проектные и изыскательские работы, авторский надзор» сводного сметного расчета стоимости производственного и жилищно-гражданского строительства включаются, в частности, средства — на выполнение проектно-изыскательских работ (услуг) — раздельно на проектные и изыскательские.
Согласно пункту 4.90 МДС 81-35.2004 стоимость проектных и изыскательских работ для строительства определяется на основе справочников базовых цен с использованием индексов изменения стоимости проектных и изыскательских работ. Сметы на проектно –изыскательские работы оформляются в соответствии с в Приложением N 2 (образцы 2п, 3п, 1пс) к МДС 81-35.2004.

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

Информационные Строительные Технологии СМЕТА ПИР (лицензия), Единая нормативная база МРР. Модуль расчета стоимости проектных работ по сборникам базовых цен города Москвы

СМЕТА ПИР предназначена для определения стоимости проектных работ и расчета стоимости проведения государственной экспертизы проектной документации и результатов инженерных изысканий в соответствии с требованиями нормативных документов Российской Федерации (МДС 81-35.2004, Методические указания по применению справочников базовых цен на проектные работы в строительстве, Разъяснения по применению Сборника цен и Справочников базовых цен на ПИР и другие)

Программа поможет:

Рассчитать стоимость проектных работ по сборникам СБЦ и МРР.
Рассчитать стоимость изыскательских работ.
Рассчитать стоимость земельно-кадастровых работ.
Составить сметы на разработку технической документации на АСУТП.
Рассчитать стоимость проведения государственной экспертизы проектной документации и результатов инженерных изысканий.

Гибкость

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

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

Расчет проектных работ (от натуральных показателей и от стоимости строительства), расчет инженерных изысканий, сметы на АСУ ТП, сметы на земельно-кадастровые работы, расчет стоимости государственной экспертизы

✅ Купите Информационные Строительные Технологии СМЕТА ПИР (лицензия), Единая нормативная база МРР. Модуль расчета стоимости проектных работ по сборникам базовых цен города Москвы на официальном сайте

✅ Лицензия Информационные Строительные Технологии СМЕТА ПИР (лицензия), Единая нормативная база МРР. Модуль расчета стоимости проектных работ по сборникам базовых цен города Москвы по выгодной цене

✅ Информационные Строительные Технологии СМЕТА ПИР (лицензия), Единая нормативная база МРР. Модуль расчета стоимости проектных работ по сборникам базовых цен города Москвы, лицензионное программное обеспечение купите в Москве и других городах России

Предлагаем также:

Документация Планирование проекта в цифрах

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

Более точные оценки проекта. Со временем вы сможете оценить, когда ваша команда сможет выполнить конкретный проект, и лучше распределять ресурсы для каждого проекта.
Четкое и конкретное объяснение, когда что-то занимает больше времени, чем «должно быть». Если вы обновите инструмент планирования для проекта, если какой-либо из факторов изменится, вы будете знать, какие факторы повлияли на время доставки. Лучше всего сохранить исходные расчеты, чтобы вы могли сравнить свою оценку с фактическими результатами в ходе проекта.
Отличный способ обосновать новые ресурсы, бюджет для подрядчиков или просто сказать «нет».” Разговоры о деньгах и ресурсах становятся намного проще, когда вы точно знаете, сколько времени это займет, и можете учесть это время/ресурсы, доступные вам.
Способность принимать стратегические решения. Используя инструмент планирования, вы сможете сравнивать различные каналы доставки (например, печатные и онлайновые), а также другие факторы, такие как шаблоны, уровни редактирования и т. д. Если у вас есть возможность скорректировать масштаб проекта, вы можете сделать это на основе достаточно точных показателей.

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

Наука о метриках документирования — оценка времени, которое потребуется

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

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

Начните с цели

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

Собери

Шаг 1 : определение важных факторов

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

Факторы, которые мы включили в наш инструмент планирования, включают:

Коэффициент	Описание
Размер документа	Печать: количество страниц Онлайн: количество тем
Уровень производства	Новое: создание содержимого, редактирование, форматирование Новое: предоставленный контент, редактирование, формат Обновление: добавьте новый контент; редактировать, формат Обновление: редактировать, только форматировать
Сложность
Формат	Microsoft Word, Microsoft Visio, HTML, прочее
Требования к шаблону	Новый шаблон Существующий шаблон Пересмотреть шаблон с документом Без шаблона
Графика
Канал доставки	Печать/PDF Онлайн (HTML, CBT) Документ Word Несколько форматов
Цикл обзора	# рецензенты/заинтересованные стороны Требуются полные обзоры (содержание/структура/доказательство) Только обзоры контента Только проверка (орфография, грамматика)

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

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

Шаг 2: Определите вес

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

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

Шаг 3: Подсчитайте итоги

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

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

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

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

Шаг 4. Используйте и проверьте еще раз

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

Как я узнаю, что получил его?

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

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

Попробуй!

Если вы хотите попробовать наш инструмент на основе Excel. Удачной обработки чисел! Другие статьи по документации и техническому написанию

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

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

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

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

ТЭО

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

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

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

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

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

БЕСПЛАТНЫЙ курс: Введение в CAPM®

Станьте CAPM® с этим курсом БЕСПЛАТНОЗарегистрируйтесь сейчас

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

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

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

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

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

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

Система отслеживания проблем

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

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

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

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

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

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

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

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

Полная программа по управлению проектамиОбзор курса

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

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

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

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

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

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

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

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

Документ о передаче

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

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

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

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

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

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

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

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

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

«Я хочу сделать приложение, подобное Uber.Сколько это будет стоить?» — это популярный запрос среди клиентов. Однако на этот вопрос нет четкого ответа, если у вас нет под рукой хорошо составленного документа с требованиями к программному обеспечению.

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

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

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

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

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

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

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

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

Сколько информации достаточно для оценки стоимости разработки?

Здесь, в CXDojo, мы часто имеем дело с 2 типами клиентов — с теми, у кого вообще нет спецификации требований к программному обеспечению (SRS), и с теми, у кого есть очень подробная документация по программному обеспечению.

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

❌ СЛУЧАЙ 1: Нет документации по разработке программного обеспечения

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

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

Рассмотрим характеристики страницы входа. В большинстве случаев недостаточно сказать, что пользователь должен иметь возможность авторизоваться. Нужно хотя бы указать способы — будь то обычная комбинация email-пароль или логин через социальные сети. Помните одно простое правило: «Если это не написано, этого не существует».

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

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

❌ СЛУЧАЙ 2: Чрезмерно подробный документ спецификации требований к программному обеспечению

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

Обычно этот документ SRS включает:

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

« Разве это не полезно?» — спросите вы.Это так, но для самой разработки. Для оценки стоимости такой документ несколько избыточен.

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

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

✅ ПРИМЕР 3: Минимальная документация по программному обеспечению для оценки проекта

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

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

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

Обзор продукции

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

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

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

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

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

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

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

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

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

Статья по теме: Что нужно знать о пользовательских историях?

Системные функции

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

Функциональность системы может включать:

Бизнес-правила
Административные функции
Правила аутентификации
Манипуляции с данными
Уровни авторизации

и т.д.

История пользователя

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

Системная функция

«Система должна автоматически сохранять платежную информацию в профиле пользователя после продажи».

Каркасы

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

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

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

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

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

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

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

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

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

Давайте на связи! Нам нужно многое обсудить.

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

‘) var buybox = документ.

querySelector(«[data-id=id_»+ метка времени +»]»).parentNode ;[].slice.call(buybox.querySelectorAll(«.вариант-покупки»)).forEach(initCollapsibles) функция initCollapsibles(подписка, индекс) { var toggle = подписка.querySelector(«.цена-варианта-покупки») подписка.classList.remove(«расширенный») var form = подписка.querySelector(«.форма-варианта-покупки») если (форма) { var formAction = форма.получить атрибут («действие») form.setAttribute(«действие», formAction.replace(«/checkout», «/cart»)) document.querySelector(«#ecommerce-scripts»).addEventListener(«load», bindModal(form, formAction, timestamp, index), false) } var priceInfo = подписка.querySelector(«.Информация о цене») var PurchaseOption = toggle.

parentElement если (переключить && форма && priceInfo) { переключать.setAttribute(«роль», «кнопка») toggle.setAttribute(«tabindex», «0») toggle.addEventListener («щелчок», функция (событие) { var expand = toggle.getAttribute(«aria-expanded») === «true» || ложный toggle.setAttribute(«aria-expanded», !expanded) form.hidden = расширенный если (! расширено) { покупкаВариант.classList.add («расширенный») } еще { покупкаOption.classList.remove(«расширенный») } priceInfo.hidden = расширенный }, ложный) } } функция bindModal (форма, formAction, метка времени, индекс) { var weHasBrowserSupport = window.

fetch && Array.from функция возврата () { var Buybox = EcommScripts ? EcommScripts.Ящик для покупок: ноль var Modal = EcommScripts ? EcommScripts.Modal : ноль if (weHasBrowserSupport && Buybox && Modal) { var modalID = «ecomm-modal_» + метка времени + «_» + индекс var modal = новый модальный (modalID) modal.domEl.addEventListener («закрыть», закрыть) функция закрыть () { форма.querySelector(«кнопка[тип=отправить]»).фокус() } форма.setAttribute( «действие», formAction.replace(«/checkout», «/cart?messageOnly=1») ) form.

addEventListener( «Отправить», Buybox.interceptFormSubmit( Буйбокс.fetchFormAction(окно.fetch), Buybox.triggerModalAfterAddToCartSuccess(модальный), консоль.лог, ), ложный ) document.body.appendChild(modal.domEl) } } } функция initKeyControls() { документ.addEventListener(«keydown», функция (событие) { if (document.activeElement.classList.contains(«цена-варианта-покупки») && (event.code === «Пробел» || event.code === «Enter»)) { если (document.activeElement) { событие.

preventDefault() документ.activeElement.click() } } }, ложный) } функция InitialStateOpen() { var buyboxWidth = buybox.смещениеШирина ;[].slice.call(buybox.querySelectorAll(«.опция покупки»)).forEach(функция (опция, индекс) { var toggle = option.querySelector(«.цена-варианта-покупки») var form = option.querySelector(«.форма-варианта-покупки») var priceInfo = option.querySelector(«.Информация о цене») если (buyboxWidth > 480) { переключить.щелчок() } еще { если (индекс === 0) { переключать.щелчок() } еще { toggle.

setAttribute («ария-расширенная», «ложь») form.hidden = «скрытый» priceInfo.hidden = «скрытый» } } }) } начальное состояниеОткрыть() если (window.buyboxInitialized) вернуть window.buyboxInitialized = истина initKeyControls() })()

Документы, которые вы ДОЛЖНЫ создать для любого проекта

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

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

От ошеломления к ясности

Мы застреваем, когда сосредотачиваемся на слишком многих вещах одновременно:

Выяснение того, как вести свой проект
Получение оценок от членов команды
Включение заинтересованных сторон
Настройка бюджета
Настройка общего доступа к документам
Как заставить ваш новый ноутбук работать
.. ДОБАВЬТЕ 100 ДРУГИХ Вещей, о которых стоит беспокоиться

В конечном итоге вы полностью подавлены и не можете двигаться вперед.

И я не хочу, чтобы это случилось с тобой.

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

Задайте себе этот вопрос

Вместо того, чтобы начинать с пустой страницы, задайте себе этот вопрос:

Какие документы мне нужно подготовить для моего нового проекта?

Так ваша работа станет намного проще.

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

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

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

Посмотрите на это:

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

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

Таким образом вы можете организовать свой календарь.

Например:

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

После 2-3 недель работы с Word и Excel ваш проект готов к работе!

Писать значит думать

Знаете, что мне больше всего помогло в этом процессе?

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

Просто записав, подумав и доработав.

Документы, необходимые для любого проекта

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

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

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

Описание документов

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

1. Отслеживание действий и проблем

Запишите все действия и проблемы в простой файл Excel. Вот трекер действий, который я использую:

Получите все мои шаблоны проектов (включая трекер действий) с моим пакетом шаблонов проектов .

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

Устав проекта подобен контракту между вами и клиентом.Он содержит важную информацию о проекте, такую как вехи, бюджет, расписание и общий объем работ, в обобщенной форме.

Узнайте, как заполнить устав проекта и скачайте шаблон (та же ссылка).

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

3. Проектная организация

Простая организационная схема всей организации проекта. Он показывает, кто работает в проекте.

Вы уже видели такие организационные схемы:

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

4. Роли и обязанности в проекте

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

Создайте простой Powerpoint с ключевыми ролями и обязанностями. Я рекомендую прочитать мою статью об определении ролей и обязанностей.

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

5. План проекта

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

Если вы регулярно создаете план проекта, я рекомендую использовать такой инструмент, как Tom’s Planner — он значительно упрощает рисование диаграмм Ганта.

Tom’s Planner — отличный инструмент для создания диаграмм Ганта.

6. Бюджет проекта

Очевидно, вам нужно куда-то заносить расходы… трекер бюджета!

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

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

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

7. Матрица заинтересованных сторон

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

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

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

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

8. Журнал рисков

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

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

Следует ли вам создать журнал рисков? Абсолютно!

Получить все мои шаблоны проектов (включая журнал рисков) с моим пакетом шаблонов проектов .

9. План коммуникаций проекта

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

Это то, что вы определяете в документе плана коммуникации проекта (включая шаблон).

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

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

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

10. Описание области применения (спецификация требований)

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

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

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

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

11. Отслеживание запросов на изменение

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

Примеры:

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

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

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

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

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

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

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

Еще несколько проектных документов, которые я здесь не указал

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

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

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

Рад помочь вам. Просто оставьте свой вопрос в виде комментария ниже и ответьте.

9.

Планирование содержания – Управление проектами – 2-е издание

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

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

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

Двухмоторный самолет против одномоторного
Красный маркер против зеленого маркера
Ежедневный отчет против еженедельного отчета
Решение для отдела по сравнению с корпоративным решением

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

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

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

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

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

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

Пример автомобиля

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

Пример компьютерной системы

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

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

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

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

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

Купленные грузовики должны быть грузовиками американского производства в связи с государственными льготами.
Грузовая площадка должна быть закрыта.
Грузовая площадка должна иметь высоту не менее 10 футов.

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

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

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

Система должна быть доступна с 9:00 до 17:00 с понедельника по пятницу.
Изначально система должна поддерживать 100 000 записей о клиентах.
Система должна иметь возможность добавлять 10 000 записей в год в течение 10 лет.
Запись должна быть полностью доступна в системе не менее семи лет.

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

Существует три основных типа нефункциональных ограничений разработки:

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

Технические требования

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

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

Бизнес-требования

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

Требования пользователя

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

Нормативные требования

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

Пример требований

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

Рисунок 9.1 банкомат.
Ниже представлен один из возможных примеров каждого типа требований, применяемых к внешнему банкомату банка.
Функциональные требования к банкоматам: система позволит пользователю выбирать, создавать ли печатную копию квитанции о транзакции перед ее завершением.
Нефункциональное требование банкомата: все дисплеи должны быть белыми, текст Arial размером 14 пунктов на черном фоне.
Техническое требование банкомата
: система банкомата будет беспрепятственно подключаться к существующей базе данных клиентов.
Требования к пользователю банкомата
: система выполнит стандартное снятие средств с личного счета, от входа в систему до наличных, менее чем за две минуты.
Бизнес-требование
ATM: Предоставляя нашим розничным клиентам превосходное обслуживание, сеть банкоматов Monumental Bank позволит нам ежегодно увеличивать доход от платы за обслуживание на 10% на постоянной основе.
Нормативное требование к банкоматам
: все банкоматы должны подключаться к стандартным источникам питания в пределах их гражданской юрисдикции и снабжаться источником бесперебойного питания, утвержденным компанией.
Эффективная спецификация требований — одна из самых сложных задач, с которыми сталкиваются руководители проектов. Неадекватно указанные требования гарантируют плохие результаты проекта.
Документирование требований — это гораздо больше, чем просто процесс записи требований так, как их видит пользователь; он должен охватывать не только то, какие решения были приняты, но и то, почему они были приняты. Понимание аргументации, которая использовалась для принятия решения, имеет решающее значение для предотвращения повторения.Например, тот факт, что конкретная функция была исключена из-за того, что она просто невыполнима, необходимо зафиксировать. Если это не так, проект рискует напрасной работой и повторением, когда заинтересованное лицо запрашивает восстановление функции во время разработки или тестирования.
После того, как требования будут задокументированы, попросите заинтересованных лиц подписать свои требования в качестве подтверждения того, чего они хотят.
Хотя руководитель проекта отвечает за документирование требований, это не означает, что руководитель проекта выполняет эту задачу.Менеджер проекта заручается поддержкой всех заинтересованных сторон (бизнес-аналитиков, аналитиков требований, владельцев бизнес-процессов, клиентов и других членов команды) для проведения обсуждений, мозгового штурма и интервью, а также для документирования и подписания требований. Менеджер проекта несет ответственность только за обеспечение процесса и его содействие. Если руководитель проекта считает, что качество документа сомнительно, его или ее обязанность — остановить процесс разработки.
Менеджер проекта просматривает требования, включает их в библиотеку проектной документации и использует в качестве исходных данных для плана проекта.
Основы требований к программному обеспечению
В этом разделе говорится о требованиях к «программному обеспечению», поскольку речь идет о проблемах, которые должны решаться программным обеспечением. Требование к программному обеспечению — это свойство, которое должно проявляться в программном обеспечении, разработанном или адаптированном для решения конкретной проблемы. Проблема может заключаться в том, чтобы автоматизировать часть задачи того, кто будет использовать ПО, поддерживать бизнес-процессы организации, запустившей ПО, исправлять недостатки существующего ПО, управлять устройством и т. д.Функционирование пользователей, бизнес-процессов и устройств обычно является сложным. Таким образом, требования к конкретному программному обеспечению обычно представляют собой сложную комбинацию требований от разных людей на разных уровнях организации и от среды, в которой будет работать программное обеспечение.
Существенным свойством всех требований к программному обеспечению является их верифицируемость. Проверка определенных требований к программному обеспечению может быть сложной или дорогостоящей. Например, проверка требований к пропускной способности колл-центра может потребовать разработки программного обеспечения для моделирования. Как требования к программному обеспечению, так и персонал по качеству программного обеспечения должны гарантировать, что требования могут быть проверены в пределах имеющихся ограничений ресурсов.
Требования имеют другие атрибуты в дополнение к поведенческим свойствам, которые они выражают. Типичные примеры включают рейтинг приоритета, позволяющий находить компромиссы перед лицом ограниченных ресурсов, и значение статуса, позволяющее отслеживать ход выполнения проекта. Как правило, требования к программному обеспечению однозначно идентифицируются, чтобы их можно было отслеживать на протяжении всего жизненного цикла программного обеспечения.
Требования к измерениям
На практике обычно полезно иметь некоторое представление об объеме требований к конкретному программному продукту. Это число полезно при оценке размера изменения требований, при оценке стоимости задачи разработки или сопровождения или просто при использовании его в качестве знаменателя в других измерениях (см. Таблицу 9.1).
Таблица 9.1: Требования к измерениям
Собственность Мера
Скорость
Обработано транзакций в секунду
Время отклика пользователя/события
Время обновления экрана
Размер
Кбайт
Количество микросхем ОЗУ
Простота использования
Время обучения
Количество кадров справки
Надежность
Средняя наработка на отказ
Вероятность недоступности
Частота отказов
Наличие
Прочность
Время перезапуска после сбоя
Процент событий, вызвавших отказ
Вероятность повреждения данных при сбое
Портативность
Процент целевых зависимых операторов
Количество целевых систем
Менеджер проекта собирает первоначальные сведения о проекте из устава проекта. Кроме того, справочная информация о рабочем месте заинтересованного лица, существующей бизнес-модели и правилах и т. д. помогает в создании видения конечного продукта/услуги и, следовательно, масштаба проекта (см. рис. 9.2).
Рисунок 9.2: Ввод-вывод области. [Описание изображения]
Техники
Безусловно, будучи опытным руководителем проекта, вы расширяете репертуар своих методов планирования масштабов. Опытный менеджер проектов может опираться на прошлый опыт работы с похожими проектами, чтобы определить работу, которая реально выполнима с учетом временных и стоимостных ограничений для текущего проекта.Коммуникабельность и навыки ведения переговоров также являются обязательными. Менеджеры проектов должны информировать заинтересованные стороны о влиянии некоторых требований на проект. Усложнение проекта может потребовать больше персонала, времени и/или денег. Это также может повлиять на качество проекта. Некоторые аспекты проекта могут оказаться невыполнимыми — заинтересованные стороны должны знать об этом, чтобы они могли скорректировать свое видение или подготовиться к будущим вызовам.
Сбор требований является частью определения области, и это можно сделать с помощью одного или нескольких из следующих методов:
Интервью
Фокус-группы
Управляемые группы, такие как JAD (совместная разработка приложений)
Техники группового творчества: мозговой штурм, именные группы, дельфи, интеллект-карта, аффинити-диагностика
Прототип
Наблюдение
Вопросы и опросы
Методы группового принятия решений: единогласие, большинство, множественность, диктатура
Матрица прослеживаемости требований — это таблица, которая связывает требования с их происхождением и отслеживает их на протяжении всего жизненного цикла проекта.Внедрение матрицы прослеживаемости требований помогает гарантировать, что каждое требование повышает ценность бизнеса, связывая его с бизнес-целями и целями проекта. Он предоставляет средства для отслеживания требований на протяжении всего жизненного цикла проекта, помогая гарантировать, что требования, утвержденные в документации по требованиям, будут реализованы в конце проекта. Наконец, он обеспечивает структуру для управления изменениями в области действия продукта. Этот процесс включает, помимо прочего, отслеживание:
Требования к потребностям бизнеса, возможностям, целям и задачам
Требования к целям проекта
Требования к результатам проекта по содержанию/декомпозиции работ
Требования к конструкции изделия
Требования к разработке продукта
Требования к стратегии тестирования и сценариям тестирования
Требования высокого уровня к более подробным требованиям
Атрибуты, связанные с каждым требованием, могут быть записаны в матрице прослеживаемости требований.Эти атрибуты помогают определить ключевую информацию о требовании. Типичные атрибуты, используемые в матрице прослеживаемости требований, могут включать уникальный идентификатор, текстовое описание требования, обоснование включения, владельца, источник, приоритет, версию, текущий статус (например, активный, отмененный, отложенный, добавленный, утвержденный), и дата завершения. Дополнительные атрибуты для обеспечения того, чтобы требование удовлетворяло заинтересованные стороны, могут включать стабильность, сложность и критерии приемлемости.
Поля матрицы
Это только предложения, которые могут меняться в зависимости от требований организации и проекта.
Уникальный идентификационный номер, содержащий общую категорию требования (например, SYSADM) и номер, присвоенный в порядке возрастания (например, 1.0, 1.1, 1.2)
Заявление о требовании
Источник требования (конференция, панель управления конфигурацией, назначение задач и т. д.)
Номер пункта спецификации/функциональных требований к программному обеспечению, содержащего требование
Номер параграфа проектной спецификации, содержащего требование
Программный модуль, содержащий требование
Спецификация теста, содержащая тест требований
Номер(а) тестового примера, в котором требование должно быть протестировано (необязательно)
Проверка успешного тестирования требований
Поле «Модификация» (если требование было изменено, исключено или заменено, укажите решение и полномочия для изменения. )
Замечания
Теперь, когда у нас есть четко определенные результаты и требования, начинается процесс разбивки работы над проектом с помощью структуры разбивки работ (WBS). WBS определяет объем проекта и разбивает работу на компоненты, которые можно планировать, оценивать и легко отслеживать и контролировать. Идея, лежащая в основе WBS, проста: вы делите сложную задачу на более мелкие задачи, пока не достигнете уровня, который нельзя разделить дальше.Любой, кто знаком с расположением папок и файлов в памяти компьютера или исследовал генеалогическое древо своих предков, должен быть знаком с этой идеей. Вы прекращаете разбивать работу, когда достигаете достаточно низкого уровня, чтобы выполнить оценку желаемой точности. В этот момент обычно легче оценить, сколько времени займет небольшая задача и сколько будет стоить ее выполнение, чем оценить эти факторы на более высоких уровнях. Каждый нисходящий уровень WBS представляет собой повышенный уровень детального определения работы над проектом.
WBS описывает продукты или услуги, которые должны быть предоставлены в рамках проекта, а также их разбивку и взаимосвязь. Это ориентированная на результат декомпозиция проекта на более мелкие компоненты. Он определяет и группирует отдельные рабочие элементы проекта таким образом, чтобы помочь организовать и определить общий объем работ по проекту.
WBS также предоставляет необходимую основу для подробной оценки и контроля затрат, а также предоставляет рекомендации по разработке и контролю расписания.
Обзор
WBS — это иерархическая декомпозиция проекта на этапы, результаты и рабочие пакеты. Это древовидная структура, которая показывает подразделение усилий, необходимых для достижения цели (например, программы, проекта и контракта). В проекте или контракте WBS разрабатывается, начиная с конечной цели и последовательно подразделяя ее на управляемые компоненты с точки зрения размера, продолжительности и ответственности (например, системы, подсистемы, компоненты, задачи, подзадачи и рабочие пакеты). которые включают все шаги, необходимые для достижения цели.
Создание WBS включает:
Список всех результатов проекта (результаты и другие прямые результаты)
Определение всех действий, необходимых для получения результатов
Разделение этих действий на подвиды деятельности и задачи
Определение результатов и этапов каждой задачи
Определение использования времени всех ресурсов (персонала и материалов), необходимых для выполнения каждой задачи
Целью разработки WBS является:
Упростить управление каждым компонентом
Разрешить точную оценку времени, затрат и требований к ресурсам
Разрешить более легкое распределение человеческих ресурсов
Разрешить более легкое распределение ответственности за деятельность
Пример WBS
Если я хочу убраться в комнате, я могу начать со сбора одежды, игрушек и других вещей, упавших на пол.Я мог бы использовать пылесос, чтобы убрать грязь с ковра. Я могу снять шторы и отнести их в чистку, а потом вытереть пыль с мебели. Все эти задачи являются подзадачами, выполняемыми для уборки комнаты. Что касается уборки комнаты, мне, возможно, придется достать пылесос из шкафа, подсоединить шланг, опорожнить мешок и поставить пылесос обратно в шкаф. Это небольшие задачи, которые необходимо выполнить при выполнении подзадачи, называемой очисткой. На рис. 9.3 показано, как это может быть отображено в формате WBS.
Рисунок 9.3: WBS для уборки комнаты. [Описание изображения]
Очень важно отметить, что мы не беспокоимся о последовательности, в которой выполняется работа, или о каких-либо зависимостях между задачами, когда мы делаем WBS. Это будет проработано, когда мы разработаем график. Например, при 3.0 Вакуумирование было бы очевидно, что 3.3 Вакуумирование ковров будет выполняться после 3.4 Подсоедините шланг и заглушку! Тем не менее, вы, вероятно, обнаружите, что думаете последовательно, поскольку, похоже, это заложено в человеческой природе. Основная идея создания WBS состоит в том, чтобы захватить все задачи, независимо от их порядка. Поэтому, если вы обнаружите, что вы и другие члены вашей команды думают последовательно, не беспокойтесь слишком сильно, но и не зацикливайтесь на попытках изобразить последовательность в виде диаграммы, иначе вы замедлите процесс определения задачи. WBS может быть структурирован любым удобным для вас и вашего проекта образом. На практике структура диаграммы используется достаточно часто, но ее можно составить и в виде схемы (рис. 9.4).
Рисунок 9.4: Чистая комната в виде контура.
Вы заметите, что каждому элементу на каждом уровне СДР на обоих рисунках присвоен уникальный идентификатор. Этот уникальный идентификатор обычно представляет собой число и используется для суммирования и отслеживания затрат, графиков и ресурсов, связанных с элементами СПП. Эти цифры обычно связаны с планом счетов корпорации, который используется для отслеживания затрат по категориям. В совокупности эти числовые идентификаторы известны как код счетов.
Существует множество способов организации WBS.Например, это может быть организовано либо по результатам, либо по фазам. Основные результаты проекта используются в качестве первого уровня WBS. Например, если вы работаете над мультимедийным проектом, его результаты могут включать выпуск книги, компакт-диска и DVD-диска (рис. 9.5).
Рисунок 9.5: WBS для мультимедийного проекта
Многие проекты структурированы или организованы по фазам проекта (рисунок 9.6). Каждая фаза будет представлять первый уровень WBS, а их результаты будут следующим уровнем и так далее.
Рисунок 9.6: Фазы проекта WBS
Менеджер проекта может свободно определять количество уровней в WBS в зависимости от сложности проекта. Вам нужно включить достаточное количество уровней, чтобы точно оценить время и стоимость проекта, но не так много уровней, чтобы их было трудно различить между компонентами. Независимо от количества уровней в WBS, самый низкий уровень называется рабочим пакетом.
Рабочие пакеты — это компоненты, которые можно легко назначить одному человеку или группе людей с четкой отчетностью и ответственностью за выполнение задания. На уровне рабочего пакета определяются оценки времени, оценки стоимости и оценки ресурсов.
Правило 100 процентов является наиболее важным критерием при разработке и оценке WBS. Правило гласит, что каждый разложенный уровень (дочерний) должен представлять 100 процентов работы, применимой к следующему более высокому (родительскому) элементу. Другими словами, если каждый уровень WBS следует правилу 100 процентов вплоть до действий, то мы уверены, что 100 процентов действий будут определены при разработке графика проекта.Когда мы составляем бюджет для нашего проекта, мы определяем 100 процентов необходимых затрат или ресурсов.
Описание содержания может принимать различные формы в зависимости от типа реализуемого проекта и характера организации. Описание содержания детализирует результаты проекта и описывает основные цели. Цели должны включать измеримые критерии успеха проекта.
Заявление о содержании охватывает в очень общих чертах продукт проекта: например, «разработка программной системы для сбора и отслеживания заказов на программное обеспечение. Заявление о содержании должно также включать список пользователей, использующих продукт, а также функции конечного продукта.
В качестве базового уровня операторы области действия должны содержать:
Название проекта
Устав проекта
Владелец проекта, спонсоры и заинтересованные стороны
Постановка задачи
Цели и задачи проекта
Требования к проекту
Результаты проекта
Нецели проекта (что выходит за рамки)
Вехи
Смета расходов
В организациях, в большей степени ориентированных на проекты, описание содержания может также содержать эти и другие разделы:
План управления содержанием проекта
Одобренные запросы на изменение
Предположения и риски проекта
Критерии приемлемости проекта
Описание изображений
Рис. 9.2 описание изображения: Менеджер проекта разрабатывает план управления содержанием, используя устав проекта, организационную память и план проекта и применяя следующие методы и инструменты:
Призывы к прошлому опыту работы над проектами
Использует шаблоны управления содержанием (SOS, WBS, план управления содержанием)
Использует коммуникативные навыки (для ведения переговоров и обучения клиентов)
[Вернуться к рисунку 9. 2]
Рисунок 9.3 описание изображения:
0.0 Чистая комната
1,0 Швабра для пола.
1.1 Выньте швабру и ведро.
1.2 Смешайте очиститель с водой в ведре.
1.3 Промыть ведро и швабру.
2.0 Пыль
2.1 Журнальный столик
2.2 Жалюзи
3,0 Вакуум
3.1 Достать пылесос из шкафа
3.2 Вакуумный ковер
3.3 Пустой мешок
3.4 Подсоединение шланга и заглушки
4.0 Подборщик пола
5.0 Чистые шторы
5.1 Снять шторы
5.2 Отдать в чистку
5.3 Подвесные шторы
[Вернуться к рисунку 9.3]
Атрибуты текста
Эта глава Управление проектами является производным от следующих текстов:
Краткое руководство по оценке стоимости проекта
Оценка стоимости проекта — это процесс прогнозирования общей стоимости задач, времени и ресурсов, необходимых для выполнения объема работ по проекту.
Занимаетесь ли вы проектированием, разработкой, инжинирингом или другими профессиональными услугами, одной из наиболее важных составляющих успешной работы над проектом является своевременная доставка в соответствии с объемом и бюджетом. Это требует точного прогнозирования, точного планирования и мониторинга прогресса. Оценка стоимости проекта — это процесс, применяемый руководителями проектов для помощи в составлении этих прогнозов.
Чтобы правильно спланировать задачи и определить, кто будет их выполнять, вы должны определить, сколько будет стоить проект и соответствует ли ценник бюджету вашего клиента.Чтобы отладить этот процесс, вам нужно знать, за какие результаты отвечает ваша команда, и отслеживать затраты после того, как проект запущен и запущен.
К сожалению, большинство компаний плохо оценивают стоимость своих проектов. Согласно отчету PMI 2018 Pulse of the Profession, 28 % всех проектов срываются из-за неточных оценок затрат.
Хорошая новость заключается в том, что точная оценка стоимости проекта не является сложной задачей, если у вас есть хороший процесс. Перечисляя свои задачи, рассчитывая затраты и отслеживая ход выполнения проекта, вы можете создавать точные оценки и следить за тем, чтобы ваши бюджеты не выходили из-под контроля.
В этой части мы собираемся разобрать, что такое оценка стоимости проекта, и три метода оценки, которые помогут сделать это правильно. 👌
Что такое оценка стоимости проекта?
Оценка стоимости проекта — это когда компания прогнозирует общую стоимость проекта, точно определяя объем работ.Это требует изучения задач, продолжительности и ресурсов, необходимых для прогнозирования общей стоимости проекта. Чем ближе оценка к фактической стоимости проекта, тем больше вероятность того, что расходы останутся в плюсе после начала проекта.
Хотя оценка стоимости проекта может быть не самой интересной частью вашей работы, правильное составление бюджета может означать разницу между успехом вашего проекта или провалом. В связи с тем, что число проектов, страдающих от расползания масштабов, растет, руководители групп должны проявлять усердие на этапах планирования и прогнозирования, чтобы обеспечить точную оценку стоимости проекта и выполнение работы, которая действительно приносит прибыль.
Источник: Success of Disruptive Times, PMI. отслеживание проекта. Оценка стоимости проекта не просто прекращается с началом проекта — ее необходимо отслеживать и корректировать по мере ее выполнения.
Точная оценка стоимости проекта с помощью программного обеспечения для управления ресурсами
Float занимает первое место в рейтинге G2 по управлению ресурсами и помогает командам точно прогнозировать затраты на проект, предоставляя подробное представление о своих мощностях, доступности и бюджетных расходах.
Попробуйте бесплатно
Как точно оценить стоимость проекта
Для оценки стоимости проекта необходимо разбить его на отдельные задачи и выяснить, какие члены команды будут чем заниматься. Как только проект запущен и запущен, главная цель — убедиться, что вы не перерасходуете и не сорвете свой бюджет!
Оценка стоимости проекта — это процесс, который можно разбить на пять этапов:
Составление списка задач и ресурсов, необходимых для их выполнения
Определение и распределение ресурсов для задач в зависимости от возможностей вашей команды
Оценка задачи длина для создания графика проекта (с некоторым буфером)
Расчет стоимости проекта на основе выбранного метода оценки
Использование инструментов оценки стоимости проекта для отслеживания бюджетов в режиме реального времени
Шаг 1: Составьте список задач и ресурсы, необходимые для их выполнения
Первым шагом оценки стоимости проекта является выяснение того, какие задачи и ресурсы вам потребуются.
Самый простой способ сделать это — разбить проект на более мелкие отдельные задачи. Например, если ваше агентство попросили создать веб-сайт с нуля, вам необходимо перечислить задачи для каждого этапа проекта:
📋 Исследования/планирование
🎨 Дизайн
💻 Внешний/внутренний интерфейс разработка
📝 Копирайтинг
🐛 Тестирование/исправление ошибок
🚀 Запуск
Очевидно, что список задач будет разным для каждого проекта. Но на первом этапе проект будет разбит на отдельные задачи, поэтому, когда вы назначите их членам команды с почасовой оплатой, будет проще рассчитать, сколько будет стоить каждая из них.
Единственный способ сделать это — убедиться, что вы и ваш клиент находитесь на одной волне и что объем вашей работы точно отражает то, что они хотят от проекта. Как рассказывает Shopify Труди Макнабб из Up at Five, на этом этапе также необходимо учитывать нетехнические части проекта.
«Это включает в себя электронные письма, личные встречи, телефонные звонки и общее управление клиентом — вы также хотите включить эти часы в свой бюджет. Не стоит недооценивать время, необходимое для эффективного управления проектом.Расширение масштабов происходит во всех областях проекта, а не только с технической точки зрения», — говорит Макнабб. будем рады, если ваша смета будет точной, чтобы прийти к моменту выставления счета
Шаг 2: Определите и распределите ресурсы для задач в зависимости от возможностей вашей команды
Далее вам необходимо убедиться, что у вас достаточно людей с нужными навыками наборы для выполнения заданий.
Это зависит от возможностей команды. Одна из самых больших проблем, с которой сталкиваются руководители команд, заключается в том, чтобы понять, есть ли у их команды место в календаре для выполнения новых задач или нет. Вероятно, это результат неадекватного планирования ресурсов, которое помогает определить, достаточно ли людей для выполнения проекта, исходя из их доступности и набора навыков. Используя планирование мощностей, вы также можете узнать:
Если вам нужно будет отложить или отменить проект в вашей воронке, потому что у вас недостаточно людей или нужных навыков, чтобы выполнить проект вовремя
Если вам нужно будет искать помощь со стороны, например, подрядчиков или фрилансеров, чтобы восполнить пробел в навыках / доступности, чтобы сохранить проект в нужном русле
Вы чувствуете закономерность?
Очень важно, чтобы у вас было необходимое количество людей и необходимое количество времени для завершения проекта. Лаура Макферсон из DesignLi говорит , что успешные проекты успешны, потому что команды укомплектованы высококвалифицированными людьми, которые знают, как добиться цели.
«Как говорит Джим Коллинз, вам нужно посадить «нужных людей в автобус, высадить из автобуса не тех людей и занять нужные места». Когда вы выбираете членов своей команды, ищите людей. которые являются специалистами в том, что они делают, и кто имеет опыт своевременного выполнения работы и работы с другими в командной среде для достижения общей цели.Люди, которых вы выберете, создадут или разрушат ваш проект».
После того, как вы определили навыки и доступность ваших людей, пришло время перейти к сути оценки стоимости проекта — рассчитать продолжительность и стоимость этих задач.
Шаг 3: Оцените продолжительность задачи для создания расписания проекта (с некоторым запасом)
Для руководителей групп естественно недооценивать продолжительность выполнения задач, но когда дело доходит до оценки стоимости проекта, важно быть реалистом — ради вашего проекта и, что еще важнее, ради вашей команды.
Арт-директор Vintage, Ольга Шевченко, говорит, что очень важно положить буфер на расчетную продолжительность проекта, чтобы учесть непредвиденные задержки и другие ситуации, такие как отпуск по болезни.
«Чтобы защитить себя от таких сценариев, лучше переоценить клиента, когда дело доходит до времени, и допустить погрешность. Например, в Винтаже мы говорим клиентам, что это должно занять в 1,5 раза больше времени, чем то, что обычно требуется.Если мы закончим работу быстрее, то мы снова превзойдем ожидания клиентов.Если возникнут трудности, мы все равно закончим проект вовремя», — говорит Шевченко. отслеживание времени, у них не было возможности записывать ежедневные часы своей команды или видеть свои оценки по сравнению с фактическими.«Если проект изменил масштаб или, возможно, обратная связь с клиентом занимает больше времени, чем ожидалось, это обычно имеет эффект домино на оставшееся время и запланированные этапы», — говорит управляющий директор Чарли Хартли.
«С Float представление календаря и возможность отслеживать время каждого были для нас неоценимы. Мы можем видеть полную активность команды на любой день или неделю вперед, включая информацию о том, кто находится в офисе и нет, кто занят встречами или отсутствует в отпуске». подсказка: Если ваша команда использует 100 %, это приведет к выгоранию. Идеальный коэффициент использования составляет 80 %, и у вашей команды остается немного свободного времени, чтобы наверстать упущенное в электронной почте или провести мозговой штурм с коллегами.Ознакомьтесь с нашим руководством и узнайте больше о том, как рассчитать использование ресурсов 📖
Шаг 4. Рассчитайте стоимость проекта на основе выбранного метода оценки
Здесь ваши данные вступают в игру.
Если у вас есть записи о похожих проектах, которые ваше агентство уже завершило, вы можете использовать их для анализа того, сколько времени заняла каждая задача и сколько она вам стоила. Без данных вам нужно будет создать приблизительные оценки, поэтому обратитесь к своей команде и попросите их помочь вам решить, сколько времени займет каждая задача.
Помните, что лучше честно говорить о своих оценках и о том, сколько времени, по вашему мнению, займет выполнение каждой задачи в вашем списке. Если вы не уделяете достаточно времени каждой задаче, это может снизить прибыль вашего проекта!
Прогнозируйте и отслеживайте затраты по проекту в режиме реального времени
Float — это программное обеспечение для управления ресурсами с мощными функциями прогнозирования затрат и составления отчетов. Более 3500 ведущих мировых команд доверяют нам планирование, планирование и отслеживание проектной работы.
Попробуйте бесплатно
Шаг 5. Используйте инструменты оценки стоимости проекта для отслеживания бюджета в режиме реального времени
Наконец, очень важно отслеживать проект, как только он стартует.
Это нормально, когда проект сталкивается с «лежачими полицейскими», и если вы не следите за происходящими изменениями, проект может полностью сорваться с рельсов, а ваш бюджет вылетит из строя!
Используя инструмент управления ресурсами, вы можете автоматически отслеживать бюджет проекта — от начала до завершения. Например, Float помогает руководителям групп отслеживать расходы на проект в режиме реального времени при распределении часов на проект. Часы будут отображаться как «рабочие часы», и каждый раз, когда член команды регистрирует часы, отработанные над проектом, они вычитаются из бюджета, чтобы дать вам точную оценку того, сколько времени еще доступно:
Хотите вместо этого использовать цифру доллара? Без проблем! Поплавок тоже может это сделать.Просто добавьте бюджет проекта, и он будет отслеживать расходы на основе выставленных вашей командой часов и индивидуальных почасовых ставок.
Это не только означает, что вам больше не придется вручную составлять электронные таблицы для отслеживания расходов (и мы не огорчаемся по этому поводу), Float также предупреждает вас, когда вы рискуете выйти за рамки бюджета.
До того, как Impression начала использовать инструмент управления ресурсами для планирования своих проектов, у них были трудности с отслеживанием оплачиваемого и неоплачиваемого времени своей команды.
Основатель и управляющий директор Чарли Хартли говорит, что они были шокированы пробелами и отсутствием точности в собственных данных, поэтому решили, что нужно что-то делать.
«Мы полагаемся на наши отчеты в Float, чтобы сообщить нам, когда мы в соответствии с бюджетами проекта, или чтобы предупредить нас, если мы хотим переехать».
Чарли Хартли, Impression
20+Йоркшир, Великобритания
Отслеживание бюджета также может помочь проверить прибыльность проекта после его завершения. VCFO делает это, когда ее команда тратит время на поиск талантов для профессионалов в области финансов, управления персоналом, бухгалтерского учета или высшего руководства. Директор по подбору персонала Вита Тревино-Гарсия говорит, что использование программного обеспечения для управления ресурсами помогает им рассчитать, была ли их общая плата за проект прибыльной.
Например, если один из сорсеров VCFO тратит 10 часов на поиск профессионала, а другой тратит на тот же поиск 5 часов, всего компания потратила на проект 15 часов. Тревино-Гарсия говорит, что после того, как компания их клиента наняла подходящего сотрудника, они оглядываются назад, чтобы посмотреть, сколько времени было потрачено на поиск найма и получили ли они прибыль. Если они платили своим источникам 40 долларов в час, их общая стоимость проекта составляет 600 долларов. Затем они сопоставляют эту цифру с той, которую они взимают со своего клиента. «Это дает нам очень четкое представление о нашей «стоимости найма» для каждого места размещения», — говорит Трвино-Гарсия.
Три метода оценки стоимости проекта
Объем проекта должен определять его бюджет, а не наоборот. Вот три расчета, которые вы можете использовать для точной оценки стоимости проекта.
1. Приблизительная оценка
Приблизительная оценка даст вам приблизительную стоимость проекта на основе предположений.
Ваш клиент знает свой бюджет? Если нет, приблизительный расчет даст вам приблизительную оценку, чтобы предложить вашему клиенту посмотреть, могут ли они позволить себе проект, прежде чем он начнется. Обычно этот расчет представляет собой комбинацию аналогичных проектов, которые вы выполняли в прошлом, а также любых расходов, уникальных для конкретного проекта.
Допустим, вашему клиенту нужно создать веб-сайт, и ваша команда уже выполняла аналогичные проекты в прошлом за 10 тысяч долларов. При использовании приблизительной оценки стоимость может варьироваться от -25% до +50% (7,5–15 000 долларов США).
Просто, правда? Ага. Хотя это не самый подробный способ оценки стоимости проекта.
2. Оценка параметров
Оценка параметров — это основанный на данных подход к оценке стоимости проекта.Он использует прошлые данные, чтобы дать вам более надежную оценку общей стоимости проекта.
Сначала подсчитайте, сколько времени будет потрачено на каждую задачу в вашем списке. Затем добавьте цифру затрат, умножив часы каждой задачи на почасовую ставку каждого члена команды.
Продолжительность задачи × Почасовая ставка сотрудника = Стоимость задачи
После того, как вы подсчитали стоимость каждой задачи, сложите их все, чтобы получить расчетную сумму.
Хотя этот метод требует больше времени, чем приблизительный расчет, он также более точен.Это лучше всего работает для проектов, у которых есть конкретные начальные и конечные точки для задач, таких как управление социальными сетями.
Расчет стоимости задач с помощью программного обеспечения для планирования ресурсов
Программное обеспечение для планирования ресурсов — отличный способ надежно и эффективно рассчитать стоимость задач. Установите оплачиваемую почасовую ставку для каждого члена вашей команды, чтобы вы могли быстро увидеть стоимость назначенных задач в сравнении с общим бюджетом вашего проекта. Это также устраняет риск любой человеческой ошибки при ручном вводе данных в электронную таблицу!
Попробуйте бесплатно
3.Трехточечная оценка
Трехточечная оценка — это способ расчета стоимости проекта на основе вероятных, оптимистичных и пессимистичных прогнозов затрат.
Преимущество оценки по трем точкам заключается в том, что она увязывает затраты проекта с неопределенностями и рисками, что позволяет планировать «наихудшие» сценарии.
Возьмем наш более ранний пример создания нового веб-сайта, стоимость которого составляет около 10 тысяч долларов. Ваши затраты могут выглядеть так:
💰 Вероятная стоимость: 10 тысяч долларов
😃 Оптимистичные затраты: 7 долларов.5k
😟 Пессимистичные затраты: $15k
Эти три цифры становятся основой для построения среднего эстимейта. Просто сложите их вместе и разделите на три:
10 000 + 7 500 + 15 000 = 32 500
32 500 ÷ 3 = 10 833
В результате средняя смета проекта составляет 3,10,83 доллара США.
Убедитесь, что если вы используете оценку по трем точкам, вы по-прежнему учитываете временные буферы и накладные расходы. Крис До из Futur подчеркивает важность учета накладных расходов в оценке стоимости проекта, говоря, что это ключ к получению прибыли.Он говорит, что очень важно делать надбавки к затратам и не недооценивать время, которое займет работа, не забывая при этом учитывать в бюджете другие вещи, такие как затраты на программное обеспечение.