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

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

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

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

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

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

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

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

• Стадия «Проект» (П) — это совокупность текстовых и графических материалов, предназначенных для согласования, экспертизы и утверждения. Перечень необходимых обязательных текстовых и графических материалов, входящих в стадию «Проект» (П) перечислен в Постановлении Правительства РФ от 16 февраля 2008 г. № 87 «Положение о составе разделов проектной документации и требованиях к их содержанию».
• Стадия «Рабочая документация» (Р) — это совокупность текстовых и графических материалов, предназначенных для производства строительных и монтажных работ. Перечень необходимых обязательных текстовых и графических материалов, входящих в эту стадию, так же перечислен в Постановлении Правительства №87 от 16.02.2008 года.

В самих формулировках мало различий для того, чтобы точно понять, чем отличается стадия «Проект» от стадии «Рабочая документация» при проектировании складов. Зато в статье 49 ч.1 Градостроительного Кодекса Российской Федерации даются разъяснения, в которых указывается, что проведение экспертизы проектной документации стадии «П» необходимо, потому что данная стадия считается основной стадией на которой утверждается этап проектирования складов и производственно-складских комплексов. При положительном заключении экспертизы проектная документация склада переходит на следующий этап проектирования. Этим этапом становится —стадия «Р». Состав и содержание рабочей документации склада определяется заказчиком (застройщиком) в зависимости от степени детализации решений, содержащихся в проектной документации, и указываться в задании на проектирование.

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

Таким образом, попробуем сформулировать ответ на вопрос, чем отличается стадия «Проект» от стадии «Рабочая документация» при проектировании складов:

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

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

• проектная документация — 40%;
• рабочая документация — 60%.

По всем вопросам сотрудничества обращайтесь к специалистам компании по телефону 209-09-40. Ждем заказов!

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

19 Января 2018

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

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

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

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

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

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

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

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

Нормативные технические документы Госстроя СССР, такие, например, как СН 202-62 «Инструкция по разработке проектов и смет для промышленного строительства», СН 202-69 «Инструкция по разработке проектов и смет для промышленного строительства», СН 202-76 «Инструкция по разработке проектов и смет для промышленного строительства», СН 202-81 «Инструкция о со- ставе, порядке разработки, согласования и утверждения проектов и смет на строительство предприятий, зданий и сооружений», СНиП 1.02.01-85 «Инструкция о составе, порядке разработки, согласования и утверждения проектно-сметной документации на строительство предприятий, зданий и сооружений», СНиП 11-01-95 «Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство пред- приятий, зданий и сооружений» последовательно сменяли друг друга на протяжении длительного времени. Их изучение позволяет провести сравнительный анализ действовавших норм. По мнению отдельных специалистов, нормативная база того времени не соответствовала современным потребностям и сдерживала развитие экономики Российской Федерации, что и стало одним из стимулов для проведения реформы технического регулирования в строительной отрасли. Тем не менее анализ СН 202-81 «Инструкции о составе, порядке разработки, согласования и утверждения проектов и смет на строительство предприятий, зданий и сооружений» наглядно показывает актуальность и соответствие этих норм современным требованиям в сфере технического регулирования.

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

Принцип 1

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

Принцип 2

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

Принцип 3

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

Принцип 4

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

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

Принцип 5

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

Принцип 6

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

Сравнительный анализ

В начале восьмидесятых годов ХХ века проектная документация состояла из пяти разделов. К 2016 году количество разделов увеличилось до семнадцати. Для получения адекватной оценки сопоставим требования к составу и содержанию проектной документации на 2017 год и к началу восьмидесятых годов ХХ века. Как уже отмечалось, строительные нормы 1981 года предусматривали в составе проектной документации пять разделов: общая пояснительная записка, технологические решения, строительные решения, организация строительства и сметная документация. К примеру, раздел «Строительные решения» должен был содержать:

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

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

Большое количество разделов и подразделов проектной документации усложняет и удорожает процессы проектирования и экспертизы. Необходимость готовить такое большое количество разделов и подразделов приводит к привлечению множества субподрядных проектных организаций, что отрицательным образом сказывается на качестве проектной документации в целом, так как действия субподрядчиков нередко недостаточно скоординированы генеральной проектной организацией. В СССР проектно-сметная документация, разработанная субподрядными проектными организациями, использовалась генеральной проектной организацией при составлении общей пояснительной записки и других разделов проекта, представляемого на экспертизу и утверждение. Сегодня зачастую вместо монолитного проекта имеется набор слабо увязанных между собой разделов проектной документации, разработанных субподрядными организациями. Появлению в смежных разделах проектной документации проектных решений, не увязанных между собой, способствуют многочисленные дублирующие требования к содержанию разделов проектной документации, установленные Положением. Субподрядные организации, разрабатывая свой раздел, а зачастую отдельную инженерную систему, технологическое или конструктивное решение, не имеют представления об общей концепции развития объекта капитального строительства и о проектных решениях, разрабатываемых иными субподрядными организациями по смежным разделам. Генеральный проектировщик, не обладая достаточным количеством времени, что особенно проявляется при устранении замечаний при прохождении экспертизы, не имеет возможности обработать большое количество разделов и проектных решений, отданных на откуп субподрядным организациям. Своевременность внесения изменений в проект постановления Правительства Российской Федерации «О внесении изменений в постановление Правительства Российской Федерации от 16 февраля 2008 г. № 87» в соответствии с пунктом 15 плана мероприятий («дорожная карта») «Оптимизация требований к составу и содержанию разделов проектной документации объектов капитального строительства», утвержденного распоряжением Правительства Российской Федерации от 29 июня 2013 г. № 1336-р, обусловлена необходимостью корректировки состава разделов проектной документации. Какими могут быть иные возможности оптимизации требований к проектной документации, которые могли бы способствовать совершенствованию правового регулирования градостроительной деятельности и улучшению предпринимательского климата в сфере строительства?

Способы оптимизации

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

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

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

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

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

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

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

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

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

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

Стадия 0.

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

Стадия 1.

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

Стадия 2.

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

Стадия 3.

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

Стадия 4.

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

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

В нормативных документах стран таможенного союза ЕАЭС, таких как Беларусь и Казахстан, также сделан акцент на многостадийность процесса проектирования объектов капитального строительства. Но европейские нормативные документы предполагают более глубокую дифференциацию процесса проектирования, чем стандарты стран таможенного союза ЕАЭС. К тому же Европейский комитет по стандартизации (CEN) не остановился на достигнутом результате и продолжает работу в части структурирования стадийности проектных работ в области капитального строительства. Из национальных стандартов Российской Федерации только ГОСТ Р 55654-2013 (ИСО 16813:2006), являющийся модифицированным по отношению к международному стандарту ISO 16813:2006 «Building environment design – Indoor environment – General principles» с учетом потребностей национальной экономики Российской Федерации и особенностей российской национальной стандартизации, предусматривает выделение четырех стадий процесса проектирования объектов капитального строительства. Положительный опыт использования в европейских стандартах многостадийного проектирования позволяет рассмотреть возможность исключения излишней детализации проектных решений и сокращения разделов проектной документации на момент прохождения экспертизы до количества, достаточного для последующего качественного проектирования и строительства зданий и сооружений с надлежащими параметрами безопасности, надежности и эффективности.

Выводы

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

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

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

Конец эпохи рабочей документации

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

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

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

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

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

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

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

Признак №1: Достоверная смета на основе BIM модели

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

Рис. «Главной причиной перерасходов является недостаток реализма в первоначальной смете» — цитата и изображение из книги «Мегапроекты: История недостроев, перерасходов и прочих рисков строительства»

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

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

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

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

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

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

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

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

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

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

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

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

Признак №2: Договорные отношения с подрядчиками

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

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

Скажем, подрядчик выполняет монтажные работы и сталкивается с ситуацией, что в спецификации не хватает длины кабеля. Если 10 лет назад он докупал необходимый кабель, предъявлял выполненный объем техническому надзору, тот подписывал акты (КС-ки, от словосочетания «капитальное строительство») и подрядчик получал по ним оплату.

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

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

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

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

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

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

Признак №3: «Я не должен думать»

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

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

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

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

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

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

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

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

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

На мой недоуменный вопрос (который был задан, сознаюсь, с изрядным количеством сарказма, который следовал из моего монтажного прошлого) «Что разве сложно это решить по месту?» – он ответил: «Я на площадке не должен думать …».

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

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

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

Признак №4: Убыточность рабочей документации

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

Как же так получается?

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

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

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

Рис. С таким подходом к детализации проектов можно дожить и до такого рода табличек в кафе и ресторанах. (Кадр с Youtube канала Антона Птушкина)

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

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

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

«Верхи не могут…, а низы не хотят…»

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

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

Как же тогда развязать этот клубок проблем, сделав это системно?

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

Девелопер нанимает проектировщика:

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

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

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

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

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

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

Александр Иванов
Руководитель мастерской
ООО «Траст инжиниринг»

Состав документации ¦ УРБАНТЭК

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оформление рабочей и проектной документации.

Оформление проектной и рабочей документации должно соответствовать требованиям ГОСТ Р 21.1101-2013 «Система проектной документации для строительства», а также постановления (от 16 февраля 2008 года) № 87 «О составе разделов проектной документации и требованиях к их содержанию». Чертежи оформляются так же в соответствии с ГОСТ 21.501-2011 и ГОСТ 21.201-2011. Расчеты следует оформлять в соответствии с ГОСТ 2.106-96 ЕСКД п. 13. Нормоконтроль проектной и рабочей документации должен производиться в соответствии с требованиями ГОСТ Р 21.1002-2008. Учет и хранение документации должно производиться в соответствии с ГОСТ Р 21.1003-2009. Вследствие запутанности в системе проектной документации выпущен «Сборник разъяснений требований стандартов системы проектной документации для строительства (СПДС). Вопросы и ответы. Выпуск 2» ОАО «ЦНС», Москва, 2011.

Рекомендуемый состав проекта при использовании свайных фундаментов оговаривается в СП 50-102-2003 приложение Б.

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

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

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

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

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

Размер чертежа не обязательно должен соответствовать стандартным размерам. Если вы делаете рабочую документацию на стройку, то нужно учесть тот факт, что листы А0 физически рассмотреть невозможно, самый оптимальный вариант, это план на формате А1 или разбитый на несколько листов, или увеличенный формат, а все последующие листы армирования элементов, узлы и детали, разрезы размещать последовательно на листах  формата А2, максимум А1. К сожалению не всегда получается так сделать, но при этом все равно не нужно стремиться к обобщению на одном листе формата большее А1 и наоборот разбивать на детали по А4. Для удобства определения формата бумаги при печати чертежей принято под штампом в нижнем правом углу указывать формат (размеры) чертежа.

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

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

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

ПКБ Аксис

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

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

Содержание страницы:

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

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

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

Получается, проектно-сметная документация необходима для решения двух задач:

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

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

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

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

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

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

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

• Особая социальная значимость.
• Расположение объекта на значимой территории.
• Технически сложное сооружение.

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

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

Алгоритм разработки проектной документации имеет следующий вид:

• Выпускается приказ.
• Формируется задание с последующей передачей главному проектировщику.
• Составляется проектная документация с учетом полученных исходных параметров.
• Готовый документ передается для согласования.

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

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

Кто разрабатывает?

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

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

Требования к документам

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

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

• Производственного назначения.
• Непроизводственного назначения.
• Сооружений линейного типа.

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

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

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

Исходные данные

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

• ГПЗУ или проект планирования территории, который будет использоваться для возведения объекта.
• Бумаги, отражающие результаты инженерных изысканий. Если они не подготовлены, требуется задание на их выполнение.
• Техусловие (если обеспечение работы строительного объекта требует технического подключения).

Таким образом, главные исходные данные — это:

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

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

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

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

Ответственность разработчика

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

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

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

план квартиры, помещений, чертежи интерьеров

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

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

 

Зачем необходима проектная документация, план квартиры и чертежи интерьеров?

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

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

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

---

Если требуется свести к минимуму вовлечённость заказчика в процесс реализации проекта, можно заказать АВТОРСКИЙ НАДЗОР. В его состав входят:

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

---

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

 

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

 

 

Обмерочный чертёж:

 

Чертёж потолка гостиной:

 

План напольных покрытий:

 

Детская комната. Развёртка:

 

Ванная комната. Развёртка:

 

Балкон. Схема расположения электрики:

 

Гостиная. Развёртка стен:

 

Прихожая. Развёртка стен:

 

Потолок. План расположения электроприборов

 

Спальня. Разрез потолка:

 

Кухня. Расположение электрики:

 

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему проектная документация важна для управления вашим маркетинговым проектом?

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

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

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

Сделайте больше заметности

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

Обеспечить выполнение требований проекта

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

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

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

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

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

Каковы преимущества проектной документации?

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

Устанавливает и определяет цели вашего проекта

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

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

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

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

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

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

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

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

Дает четкое представление о проекте

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

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

Управляет рисками и проблемами

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

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

Обеспечивает отслеживаемость проекта

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

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

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

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

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

1. Начало проекта

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

Бизнес-пример проекта

Источник: Pingboard

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

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

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

Источник: Everhour

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

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

2. Планирование проекта

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

Иерархическая структура работ

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

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

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

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

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

Журнал рисков и проблем

Журнал рисков и проблем (RAID = риски, действия, проблемы, решения) — это следующий важный шаг, который требуется на этапе планирования проектной документации.

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

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

Источник: pmtips

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

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

3. Реализация проекта

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

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

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

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

Хронология проекта

Источник: Asana

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

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

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

4. Мониторинг и контроль проекта

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

5. Закрытие проекта

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

Заключительный лист проекта

Источник: Project Manager

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

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

Регистр усвоенных уроков

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

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

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

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

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

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

Шаблон бизнес-модели проекта

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

Шаблон устава проекта

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

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

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

Шаблон спецификации требований

Онлайн-шаблон документа со спецификацией требований

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

Шаблон журнала рисков и проблем

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

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

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

Шаблон коммуникационного плана

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

Шаблон временной шкалы проекта

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

Шаблон листа закрытия проекта

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

Шаблон регистра усвоенных уроков

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

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

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

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

1. Заранее оформить документы

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

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

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

2. Сделать ведение документации постоянным процессом

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

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

3. Поделиться, просмотреть и утвердить документы

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

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

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

4.Сохраните и заархивируйте документы

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

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

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

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

Этап файла

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

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

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

Рабочая зона

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

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

TeamGantt

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

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

Smartsheet

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

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

ActiveCollab

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

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

Заключение

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

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

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

Проект

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

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

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

Проект против процесса

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

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

Что такое проект?

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

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

1. Начало проекта

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

2. Планирование проекта

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

3. Выполнение проекта

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

4. Мониторинг и контроль проектов

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

5. Закрытие проекта

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

Что такое процесс?

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

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

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

Различные типы процессов

В своей книге Высокая эффективность за счет управления бизнесом: реализация стратегии в цифровом мире Матиас Кирчмер описывает три типа процессов:

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

В чем разница между проектом и процессом?

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

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

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

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

Вы также можете найти проекты и процессы друг в друге.

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

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

Проект и инструменты процесса

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

Канбан-доска

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

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

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

Список дел

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

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

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

Проект против процесса, откуда этот список?

Диаграмма Ганта

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

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

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

---

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

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

Знаете ли вы, является ли ваша текущая задача частью процесса или проекта?

Ура,

Динни и команда Zenkit

Была ли эта статья полезной? Пожалуйста, оцените это! [Всего: 4 Среднее: 5/5]

В чем разница? PlanPlusOnline.com

Проект против процесса

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссылки по теме:

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

Введение:

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

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

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

Давайте рассмотрим некоторые стандартные определения документации,

Оксфордский словарь говорит: « Документация — это материал, который предоставляет официальную информацию или доказательства или служит в качестве записи, процесс классификации и аннотирования текста »

Merriam Webster определяет: «Документация — это акт или пример предоставления или подтверждения документов »

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

Следовательно, документация — это набор из

Назначение документации

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

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

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

Получается

• проектных ожиданий и целей без изменений;

• Отслеживание

  задач проекта; и

• помогает решать любые проблемы проекта, среди прочего.

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

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

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

Значение документации в управлении проектами:

Источник изображения: https://pxhere.com/en/photo/764428

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже приводится перечень преимуществ проектной документации:

#	Льготы
1	Позволяет устанавливать цели проекта
2	Помогает в планировании проекта
3	Позволяет лучше контролировать статус проекта
4	Облегчает хорошее общение
5	Добавляет управление
6	Подготавливает вас к любым неясным рискам
7	Помогает улучшить планирование и распределение ресурсов
8	Обеспечивает отслеживаемость проекта
9	Сохраняет фокусировку
10	Помогает заручиться поддержкой спонсоров
11	Помогает легко вносить изменения

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

Как это помогает менеджеру проекта?

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

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

Заключение

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

Повысьте уровень успешности ваших проектов — пройдите сертификацию прямо сейчас!

В чем разница между проектом и продуктом?

Открыть изображение в новой вкладке

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

Итак, в чем разница между проектом и продуктом?

Вот определение проекта, предоставленное Институтом управления проектами (PMI):

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

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

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

---

Послушайте Мика Кирстена от автора «Проекта к продукту» в нашем подкасте Agile Amped (который ведет сам Скип Энджел) «От проекта к продуктам».

Слушайте сейчас

---

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

Project vs.Операции — основные отличия от экзамена PMP

Один из студентов программы PMP Coaching Online PMChamp, Джойс недавно задал мне этот вопрос о проектной и оперативной работе,

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

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

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

Различия между проектом и операциями

Что такое проект?

Согласно Руководству PMBOK, шестое издание , проект — это временное усилие, предпринимаемое для создания уникального продукта, услуги или результата.

Пирамида — Пример проекта

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

Временный не значит короткий по своей природе, и это вполне может быть гигантский проект — например, 10-летний проект — например, отправка человека на Луну, отправка любопытства на Марс, строительство Тадж-Махала или пирамид (я посетил удивительные Пирамиды сегодня, так как я нахожусь в Каире на этой неделе, чтобы провести серию корпоративных тренингов в Египте, и это было абсолютно фантастично…)

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

Что такое оперативная работа?

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

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

Рутинная оперативная работа на заводе

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

Ключевые различия между проектами и операциями

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

Операции продолжаются, но проекты временные.

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

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

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

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

Итак, по заданному ранее вопросу… Это поддержка или проектная работа?

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

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

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

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

PMChamp Online PMP Coaching Program отмечает 7 лет успешной работы! Онлайн-обучение PMP

Более 12 860 студентов использовали его для сдачи экзамена PMP. Прочтите несколько историй успеха PMP.

Чего вы ждете? Начните сегодня свое путешествие, чтобы стать сертифицированным менеджером проектов.

Cheers,
Vinai Prakash,
Основатель PMCHAMP PMP Exam Tips

П.С. Вы знаете, как учиться и готовиться к экзамену PMP? Ознакомьтесь с нашим подробным планом исследования PMP — образец предоставлен для вашего использования.

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

Почему вы хотите получить сертификат PMP?

Вопросы работы. Сделать разницу!

Улучшение функции поддержки — это проект?

Все, что нужно знать о составлении технического задания

Этот пост был первоначально опубликован 20 ноября 2018 г. и последний раз обновлялся 18 марта 2021 г.

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

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

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

Нет смысла приукрашивать это: создание СОУ сложно и требует много времени. Но это то, в чем мы вам поможем!

В чем разница между SOW, объемом работ и уставом проекта?

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

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

Вам действительно нужен SOW?

Время аналогии! Однажды дровосека спросили: «Что бы вы сделали, если бы у вас было всего пять минут, чтобы срубить дерево?» Он ответил: «Первые две с половиной минуты я бы точил топор».

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

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

Как и когда писать?

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

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

Вот что должно быть в контрольном списке

:

• Описание / обзор проекта
• Цель и масштабы (почему это происходит, чего это будет достигать и задействованные ресурсы)
• Проектный подход (фазы и задачи)
• Распределение ответственности (укажите, кто отвечает за каждую задачу)
• Результаты и сроки выполнения (график, показывающий, какие сроки являются гибкими, а какие нет; также важно включить показатели производительности, чтобы вы могли решить, был ли результат успешным)
• Необходимые разрешения
• Стоимость (расшифровка сметы и график платежей)
• Общие предположения (что включено, а что нет; также неплохо указать максимальное количество часов, которое вы готовы выделить для согласованного бюджета)
• Глоссарий и приложение (описания результатов и определения терминов)

Эти вещи хорошо включать:

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

Как написать техническое задание

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

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

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

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

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

Изложите основные правила.
Убедитесь, что все знают, чего вы ожидаете.

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

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

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

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

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

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

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

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

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