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

Обновлено: 05.07.2024

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

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

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

Кому будет полезна статья:

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

тендерным специалистам со стороны как заказчика (специалистам по закупкам), так и исполнителя;

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

Если у вас есть опыт в этом вопросе, мы рекомендуем перейти к части второй, где мы расскажем, “откуда растут ноги” у ГОСТа и так ли он неизбежен при работе с госзакупками.

Часть 1. Общие понятия

Что такое техническое задание (ТЗ) и зачем оно нужно?

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

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

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

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

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

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

Проекты без технического задания

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

Тем не менее документация НУЖНА, даже если это просто описание user stories. Иногда команде достаточно иметь определенные паттерны, чтобы понимать, что определенная user story предполагает наличие функции, которая должна быть реализована тем или иным способом.

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

Часть 2. ГОСТ: необходимость или неизбежность?

История вопроса

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

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

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

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

Так как же получилось, что ГОСТ 34.602-89 стал практически обязательным для государственного заказчика?

Серия ГОСТ 34 рассматривает не только производство ТЗ. Она была создана как единый комплекс стандартов и регламентирует все стадии производства ИС, а также артефакты, которые в результате появляются.

Серия ГОСТ 34 описывает правила проведения испытаний при приемке работ. Исходным документом для программы и методики испытаний является ТЗ. При этом для госзаказчика проведение испытаний – очень важная часть контракта.

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

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

Недостатки ГОСТ

Наряду с бесспорными плюсами, ГОСТы серии 34 имеют ряд недостатков:

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

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

В ГОСТ отсутствуют отдельные понятия IT-отрасли, связанные с управлением проектами и рисками.

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

Так нужно ли писать ТЗ именно по ГОСТ 34.602-89?

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

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

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

Что же с госсектором?

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

Посмотрим внимательно на состав ТЗ по ГОСТ 34, а именно:

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

В ином случае будет сложно и бесполезно писать ТЗ к тому, что еще пока неизвестно. В составе конкурсной документации, как правило, такой документ будет содержать очень много “воды” и подобных формулировок: "Требования будут уточнены на стадии проектирования и зафиксированы в частном техническом задании (ЧТЗ)".

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

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

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

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

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

Что же делать?

Многие команды разработки стремятся найти гибкие решения для проектирования, подстраиваясь под пожелания крупного бизнеса и госсектора писать ТЗ по ГОСТ 34.

В частности, разработчики могут сформировать для заказчика отдельный документ (например, на один из модулей системы) по ГОСТ 34, как ЧТЗ. В некоторых случаях подобный документ называют “описанием постановки задачи” (ОПЗ), и он содержит в своем составе описание бизнесовой части, схемы бизнес-логики на основании требований законодательства (НПА). В таком виде документация презентуется заказчику.

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

Этот документ может быть оформлен не по ГОСТ 34 (так называемая "дельта" для разработки), в нем нет общих формулировок и "воды". Естественно основной документ в базе знаний постоянно актуализируется, после мержа туда таких вот "дельт".

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

Другие стандарты

Помимо ГОСТ, существуют международные стандарты по проектированию требований, зачастую более современные:

Также есть стандарты и нотации практически для любой области разработки, например, по управлению услугами в сфере IT (SERVICE DESK) — ITIL Foundation.

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

Выводы

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

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

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

атомарность (независимость от других требований);

абстрактность (независимость от способов реализации);

Спасибо за внимание! Будем рады услышать ваши мнения в комментариях.

Свидетельство и скидка на обучение каждому участнику

Зарегистрироваться 15–17 марта 2022 г.

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

Образовательные:

1. Формирование понятия "т ехническая документация", виды документации, профессии

Воспитательные:

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

2. Воспитание дисциплинированности, установленных требований к поведению и труду.

Развивающие:

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

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

Тип урока: комбинированный

Ход урока

1. Организационный момент.

2 . Актуализация
Можно ли для создания чего-то нового и оригинального руководствоваться словами из известной сказки " пойди туда - не знаю куда, принеси то - не знаю что"?

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

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

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

I . Выписать название единых систем стандартов технической документации.

(В технической документации указываются вид, устройство и состав изделия, разработанные и созданные в соответствии с Единой системой конструкторской документации (ЕСКД) и Единой системой технологической документации (ЕСТД), входящими в Государственную систему стандартизации Российской Федерации (ГОСТ). В этих документах представлены технические идеи и решения, технологии и средства производства. По этим документам проекта осуществляется производство (изготовление) задуманного продукта труда.)

II . Типы технической документации.

Заполните таблицу, используя учебник с. 8.

Типы технической документации

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

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

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

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

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

Основой технической документации являются конструкторская и технологическая документация.

5. Знакомство с профессиями и производством.

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

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

6. Итог урока.

Закрепление и обобщение.

Ответьте на вопросы:

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

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

Методология управления проектами содержится в стандартах управления проектами. Сегодня существует ряд стандартов:

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

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

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

1. Project Management Body of Knowledge (PMВОК) Американского института управления проектами.

Данный стандарт подлежит обновлению примерно один раз в четыре года. Одной из самых распространенных редакций является редакция 2000 г., а самой актуальной, четвертая версия стандарта, вышла в конце 2008 г.– The Guide to the PMBOK, 4th Edition. Стандарт был принят первоначально Американским национальным институтом стандартов (ANSI) как национальный стандарт в США, а на сегодняшний день имеет мировое признание.

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

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

управление контрактами проекта (Project Procurement Management);
управление рисками проекта (Project Risk Management);
управление взаимодействием в проекте (Project Communications Management);
управление человеческими ресурсами проекта (Project Human Resource Management);
управление качеством проекта (Project Quality Management);
управление стоимостью проекта (Project Cost Management);
управление сроками проекта (Project time Management);
управление содержанием проекта (Project Scope Management);
управление интеграцией проекта (Project Integration Management).

Рис. 1. Пространство процессов управления

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

2. IPMA Competence Baseline (ICB) представляет собой международный нормативный документ, который определяет систему международных требований к уровню компетентности менеджеров проектов. Данный стандарт был составлен международной ассоциацией IРМА (International Project Managers Association). На его базисе осуществляется разработка требований к уровню компетентности сотрудников в странах, которые являются членами IPMA. Национальным системам требований необходимо соответствовать ICB IPMA и официально ратифицироваться (утверждаться) соответствующими органами IPMA. Для 32 стран-участников IPMA является базисом для создания национальных сводов знаний. 16 стран в настоящее время имеют утвержденные национальные своды знаний, которые соответствуют ICB.

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

ICB издан на английском, французском и немецком языках. Базисом для него стали несколько национальных разработок: Body of Knowledge of АРМ (Великобритания); PM-ZERT/GPM (Германия); Beurteilungsstruktur, AFITEP (Франция); VZPM (Швейцария); PM-Kanon Criteres d'analyse.

Каждая, входящая в состав IPMA национальная ассоциация является ответственной за формирование и утверждение собственных Национальных требований по компетентности (National Competence Baseline – NCB) в соответствии с ICB, а также учитывая национальные особенности и культуры. Национальные требования на соответствие ICB и основным критериям сертификации согласно стандарту EN 45013оцениваются специальным Комитетом IPMA.

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

Стандарт ISO 10006 - основополагающий документ из серии стандартов рассматриваемого профиля, подготовленным техническим комитетом ISO/TC 176 "Управление качеством и обеспечение качества" Всемирной федерации национальных органов стандартизации (члены ISO).

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

В данной серии стандартов процессы группируют на две категории. К первой категории относят процессы, которые связаны с обеспечением продукта проекта (проектирование – производство – проверка). Описание данных процессов содержится в стандарте ISO 9004–1. Ко второй категории относятся непосредственно процессы управления проектом и содержатся они в стандарте ISO 10006.

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

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

Второй группой охвачено управление взаимосвязями процессов.

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

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

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

Необходимо также обозначить и стандарты зрелости управления проектами, также имеющие функции международных. В 2004 г. PMI был разработан стандарт оценки уровня зрелости компании по управлению проектами ОРМЗ (Organization Project Management Maturity Model), который содержит методологию выявления состояния управления проектами в компании.

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

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

Таблица 1 - Общая характеристика уровней зрелости организации

Начальный, нулевой уровень.

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

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

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

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

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

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

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

элемент "оценка" (assessment) - инструмент, помогающий компаниям оценить уровень текущей зрелости управления проектами и установить области улучшения;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте также: