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

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

Постановление Правительства РФ от 03.06.2013 N 470 «О внесении изменений в некоторые акты Правительства РФ»

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

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

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

Постановление Правительства РФ от 05.03.2007 №145 (ред. от 09.04.2021) «О порядке организации и проведения государственной экспертизы проектной документации и результатов инженерных изысканий»

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

---

Вопрос от 23.03.2018:

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

Ответ: Порядок осуществления государственного строительного надзора установлен постановлением Правительства Российской Федерации от 01.02.2006 № 54 «О государственном строительном надзоре в Российской Федерации» (далее — Постановление № 54).

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

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

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

Дополнительно сообщаем, что в соответствии с требованиями части 3.5 статьи 49 «Градостроительного кодекса Российской Федерацию) от 29 декабря 2004 г. № 190-ФЗ, подтверждением того, что изменения, внесенное в проектную документацию после получения положительного заключения экспертизы проектной документации, не затрагивают конструктивные и другие характеристики безопасности объекта капитального строительства, является заключение органа исполнительной власти или организации, проводивших экспертизу проектной документации, в которую внесены изменения. При этом подготовка указанного заключения осуществляется в порядке, установленном федеральным органом исполнительной власти, осуществляющим функции по выработке и реализации государственной политики и нормативно-правовому регулированию в сфере, строительства, архитектуры, градостроительства.

Минстроем России подготовлен Приказ «О подготовке заключения о признании проектной документации модифицированной проектной документацией» (далее — Приказ), который до настоящего времени не прошел государственную регистрацию в Министерстве юстиции Российской Федерации

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

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

---

Вопрос:

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

Ответ: Пунктом 1 Положения о проведении проверки достоверности определения сметной стоимости объектов капитального строительства, строительство которых финансируется с привлечением средств федерального бюджета, утвержденного постановлением Правительства Российской Федерации от 18.05.2009 г. № 427, регламентирован порядок проведения проверки достоверности определения сметной стоимости объектов капитального строительства, финансирование строительства, реконструкции или технического перевооружения (если такое перевооружение связано со строительством или реконструкцией объекта капитального строительства) которых планируется осуществлять полностью или частично за счет средств федерального бюджета.

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

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

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

Минстрой разъясняет: Повторная экспертиза проектной документации

Письмо Минстроя России от 03.10.2014 N 21302-СТ/06 «О направлении проектной документации и (или) результатов инженерных изысканий для проведения государственной экспертизы»

---

МИНИСТЕРСТВО СТРОИТЕЛЬСТВА И ЖИЛИЩНО-КОММУНАЛЬНОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ

ПИСЬМО от 3 октября 2014 г. N 21302-СТ/06

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

В силу пункта 44 Положения об организации и проведении государственной экспертизы проектной документации и результатов инженерных изысканий, утвержденного постановлением Правительства Российской Федерации от 5 марта 2007 г. N 145, проектная документация и (или) результаты инженерных изысканий направляются повторно для проведения государственной экспертизы при внесении изменений в проектную документацию, получившую положительное заключение государственной экспертизы, в части изменения технических решений, которые влияют на конструктивную надежность и безопасность объекта капитального строительства.

По мнению Департамента, обоснованное решение о влиянии изменений на конструктивную надежность и безопасность объекта принимает застройщик (технический заказчик) по представлению лица, осуществляющего подготовку проектной документации, которое в соответствии с частью 5 статьи 48 Градостроительного кодекса Российской Федерации (далее — Кодекс) несет ответственность за качество проектной документации и ее соответствие требованиям технических регламентов.

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

Директор Департамента государственных услуг в строительстве и разрешительной деятельности С.Г.ТИТОВА

---

Письмо Минстроя России от 18.10.2018 N 42269-ОД/08 «По вопросу внесения изменений в проектную документацию»

---

МИНИСТЕРСТВО СТРОИТЕЛЬСТВА И ЖИЛИЩНО-КОММУНАЛЬНОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ

ПИСЬМО от 18 октября 2018 г. N 42269-ОД/08

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

Согласно статье 2 Федерального закона от 27 декабря 2002 г. N 184-ФЗ «О техническом регулировании» под безопасностью продукции и связанных с ней процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации понимается состояние, при котором отсутствует недопустимый риск, связанный с причинением вреда жизни или здоровью граждан, имуществу физических или юридических лиц, государственному или муниципальному имуществу, окружающей среде, жизни или здоровью животных и растений. Особенности технического регулирования в области обеспечения безопасности зданий и сооружений устанавливаются Федеральным законом от 30 декабря 2009 г. N 384-ФЗ «Технический регламент о безопасности зданий и сооружений» (далее - Технический регламент).

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

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

Федеральным законом от 3 августа 2018 г. N 342-ФЗ «О внесении изменений в Градостроительный кодекс Российской Федерации и отдельные законодательные акты Российской Федерации» (далее — Федеральный закон N 342-ФЗ) с 1 июля 2019 года уточняется состав проектной документации объектов капитального строительства, содержание разделов которой приведено в соответствие законодательству о техническом регулировании.

Также Федеральным законом N 342-ФЗ одновременно с признанием утратившими силу частей 3.5 — 3.7 статьи 49 Градостроительного кодекса Российской Федерации (далее — Кодекс) внесены изменения в часть 11 указанной статьи Кодекса, согласно которой порядок проведения государственной экспертизы проектной документации и государственной экспертизы результатов инженерных изысканий, негосударственной экспертизы проектной документации и негосударственной экспертизы результатов инженерных изысканий, устанавливается Правительством Российской Федерации, в том числе в случае внесения изменений в проектную документацию.

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

При этом, необходимо отметить, что в соответствии с частью 55 статьи 26 Федерального закона N 342-ФЗ в случае, если до дня официального опубликования Федерального закона N 342-ФЗ в отношении проектной документации, в которую после получения положительного заключения экспертизы проектной документации внесены изменения, не затрагивающие конструктивных и других характеристик безопасности объекта капитального строительства, получено положительное заключение, предусмотренное частью 3.5 статьи 49 Кодекса (в редакции, действовавшей до дня официального опубликования Федерального закона N 342-ФЗ), проведение экспертизы такой проектной документации не требуется.

Следует обратить внимание на то, что в соответствии с пунктом 2 Правил подготовки нормативных правовых актов федеральных органов исполнительной власти и их государственной регистрации, утвержденных постановлением Правительства Российской Федерации от 13 августа 1997 г. N 1009, письма федеральных органов исполнительной власти не являются нормативными правовыми актами.

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

Заместитель директора Департамента градостроительной деятельности и архитектуры О.А.ДАШКОВА

Негосударственная экспертиза проектной документации: виды и объекты

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

Экспертизе, согласно ст. 49 ГрК РФ, подлежат:

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

Предмет экспертизы

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

1. Требованиям, установленным техническими регламентами (в том числе санитарным требованиям)
2. Требованиям, существующим в области:

• Экологии и защиты окружающей среды
• Госохраны объектов культурного наследия
• Пожарной и промышленной безопасности
• Ядерной и радиационной безопасности
• Требованиям в иных областях

Результатам инженерных изысканий.

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

Виды экспертизы проектной документации

Экспертиза может быть:

1. В зависимости от обязательности:
   • Обязательная: требуется вне зависимости от желания застройщика
   • Необязательная: непроведение экспертизы не препятствует строительству, при этом застройщик вправе направить документацию на экспертизу по собственной инициативе
2. В зависимости от лиц, которые ее проводят:

• Государственная: проводится уполномоченными государственными органами или созданными ими бюджетными/автономными учреждениями;
  Порядок ее проведения регулируется Постановлением Правительства № 145 от 05.03.2007
• Негосударственная: проводится специально аккредитованными частными организациями
Порядок ее проведения регулируется Постановлением Правительства № 272 от 31.03.2012

Случаи, когда экспертиза не требуется

Проектная документация не всегда должна проходить экспертизу. Случаи, когда ее проводить не нужно, перечислены в п. 2 и п. 3 ст. 49 ГрК РФ. Однако п. 2.1 и п. 2.2 ст. 49 ГрК РФ устанавливают исключение: экспертиза обязательна, если определенные объекты, указанные в п. 2:

1. Предполагается разместить в пределах охранных зон трубопроводов
2. Относятся к объектам массового пребывания людей

О том, требуется ли экспертиза в вашем случае, можно проконсультироваться у специалистов «ПромМаш Теста».

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

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

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

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

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

Объекты государственной экспертизы

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

К таким объектам относятся:

1. Объекты, указанные в п. 5.1 ч.1 ст. 6 ГрК РФ
2. Объекты, достоверность расчета сметной стоимости которых требуется проверить согласно требованиями ГрК РФ (кроме линейных объектов, а также сооружений на них, предназначенных для подключения объектов к газораспределительным сетям)
3. Объекты, включенные в культурное наследие (если работы по их сохранению затрагивают конструктивные и иные характеристики, влияющие на надежность и безопасность)
4. Объекты, строительство/реконструкцию которых планируется проводить в пределах особо охраняемых природных территорий
5. Объекты размещения отходов/обезвреживания отходов

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

Негосударственная экспертиза

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

В договоре определяются:

• Порядок представления документов для проведения экспертизы
• Порядок устранения замечаний, выявленных в представленных документах
• Срок проведения экспертизы
• Цена услуги

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

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

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

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

Свидетельство об аккредитации компании «ПромМаш Тест»

Об организации | ГБУ НСО Государственная вневедомственная экспертиза Новосибирской области (ГБУ НСО «ГВЭ НСО»)

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

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

Согласно части 1 статьи 3 Градостроительного кодекса Российской Федерации (далее — ГрК РФ) законодательство о градостроительной деятельности состоит из ГрК РФ, других федеральных законов и иных нормативных правовых актов Российской Федерации, а также законов и иных нормативных правовых актов субъектов Российской Федерации.
Частью 3 статьи 3 ГрК РФ предусмотрено, что законы и иные нормативные правовые акты субъектов Российской Федерации, содержащие нормы, регулирующие отношения в области градостроительной деятельности, не могут противоречить этому Кодексу.
В соответствии с частью 1 статьи 49 ГрК РФ проектная документация объектов капитального строительства и результаты инженерных изысканий, выполненных для подготовки такой проектной документации, подлежат экспертизе, за исключением случаев, предусмотренных частями 2, 3, 3.1 и 3.8 настоящей статьи. Экспертиза проектной документации и (или) экспертиза результатов инженерных изысканий проводятся в форме государственной экспертизы или негосударственной экспертизы. Застройщик или технический заказчик по своему выбору направляет проектную документацию и результаты инженерных изысканий на государственную экспертизу или негосударственную экспертизу, за исключением случаев, если в соответствии с настоящей статьей в отношении проектной документации объектов капитального строительства и результатов инженерных изысканий, выполненных для подготовки такой проектной документации, предусмотрено проведение государственной экспертизы.
В соответствии с частью 2 статьи 49 ГрК РФ экспертиза не проводится в отношении проектной документации следующих объектов капитального строительства:
1) объекты индивидуального жилищного строительства, садовые дома;
2) жилые дома с количеством этажей не более чем три, состоящие из нескольких блоков, количество которых не превышает десять и каждый из которых предназначен для проживания одной семьи, имеет общую стену (общие стены) без проемов с соседним блоком или соседними блоками, расположен на отдельном земельном участке и имеет выход на территорию общего пользования (жилые дома блокированной застройки), в случае, если строительство или реконструкция таких жилых домов осуществляется без привлечения средств бюджетов бюджетной системы Российской Федерации;
3) утратил силу. — Федеральный закон от 03.08.2018 N 340-ФЗ;
4) отдельно стоящие объекты капитального строительства с количеством этажей не более чем два, общая площадь которых составляет не более чем 1500 квадратных метров и которые не предназначены для проживания граждан и осуществления производственной деятельности, за исключением объектов, которые в соответствии со статьей 48.1 настоящего Кодекса являются особо опасными, технически сложными или уникальными объектами;
5) отдельно стоящие объекты капитального строительства с количеством этажей не более чем два, общая площадь которых составляет не более чем 1500 квадратных метров, которые предназначены для осуществления производственной деятельности и для которых не требуется установление санитарно-защитных зон или для которых в пределах границ земельных участков, на которых расположены такие объекты, установлены санитарно-защитные зоны или требуется установление таких зон, за исключением объектов, которые в соответствии со статьей 48.1настоящего Кодекса являются особо опасными, технически сложными или уникальными объектами;
6) буровые скважины, предусмотренные подготовленными, согласованными и утвержденными в соответствии с законодательством Российской Федерации о недрах техническим проектом разработки месторождений полезных ископаемых или иной проектной документацией на выполнение работ, связанных с пользованием участками недр.
В соответствии с частью 3 статьи 49 ГрК РФ Экспертиза проектной документации не проводится в случае, если для строительства или реконструкции объекта капитального строительства не требуется получение разрешения на строительство. Экспертиза проектной документации не проводится в отношении разделов проектной документации, подготовленных для проведения капитального ремонта объектов капитального строительства.
Федеральным законом от 03.08.2018 N 342-ФЗ «О внесении изменений в Градостроительный кодекс Российской Федерации и отдельные законодательные акты Российской Федерации» пункт 3.3. статьи 49 Градостроительного кодекса РФ был изложен в новой редакции, которая с 1 января 2019 г. устанавливает требование об обязательном проведении государственной экспертизы по объектам капитального строительства, указанным в частях 2 и 3 данной статьи, в случае, если сметная стоимость строительства, реконструкции, капитального ремонта объектов капитального строительства в соответствии с требованиями ГрК РФ подлежит проверке на предмет достоверности её определения.
В соответствии с подп. 1 п. 3.3. ст. 49 ГрК РФ проектная документация объектов капитального строительства, указанных в части 2 настоящей статьи, проектная документация, указанная в части 3 настоящей статьи, и результаты инженерных изысканий, выполненных для подготовки такой проектной документации, подлежат государственной экспертизе в случаях, если сметная стоимость строительства, реконструкции, капитального ремонта объектов капитального строительства в соответствии с требованиями настоящего Кодекса подлежит проверке на предмет достоверности её определения.
Из вышеизложенного следует, что в отношении проектной документации объектов капитального строительства, указанных в части 2, и проектной документации, указанной в части 3 статьи 49 ГрК РФ, подпунктом 1 п. 3.3. ст. 49 ГрК РФ предусмотрено проведение обязательной экспертизы проектной документации при наличии следующего условия: в случае проведения проверки достоверности сметной стоимости.
В соответствии с частью 2 пункта 8.3. ГрК РФ сметная стоимость строительства, финансируемого с привлечением средств бюджетов бюджетной системы Российской Федерации, средств юридических лиц, созданных Российской Федерацией, субъектами Российской Федерации, муниципальными образованиями, юридических лиц, доля в уставных (складочных) капиталах которых Российской Федерации, субъектов Российской Федерации, муниципальных образований составляет более 50 процентов, подлежит проверке на предмет достоверности её определения в ходе проведения государственной экспертизы проектной документации, в том числе — на предмет её непревышения над укрупнённым нормативом цены строительства в случаях, установленных Правительством Российской Федерации. При проведении капитального ремонта объектов капитального строительства указанная сметная стоимость подлежит такой проверке в случаях, установленных Правительством Российской Федерации.
В соответствии с требованиями, установленными частью 2 статьи 8.3 ГрК РФ, проведение проверки достоверности определения сметной стоимости строительства, реконструкции, капитального ремонта объектов капитального строительства осуществляется в соответствии с Положением о проведении проверки достоверности определения сметной стоимости строительства, реконструкции, капитального ремонта объектов капитального строительства, работ по сохранению объектов культурного наследия (памятников истории и культуры) народов Российской Федерации, финансирование которых осуществляется с привлечением средств бюджетов бюджетной системы Российской Федерации, средств юридических лиц, созданных Российской Федерацией, субъектами Российской Федерации, муниципальными образованиями, юридических лиц, доля Российской Федерации, субъектов Российской Федерации, муниципальных образований в уставных (складочных) капиталах которых составляет более 50 процентов, утверждённым Постановлением Правительства Российской Федерации от 18.05.2009 № 427 (далее – Положение).
В Положении определены случаи, когда сметная стоимость капитального ремонта объектов капитального строительства подлежит проверке на предмет достоверности её определения. В обязательном порядке проверка проводится – при капитальном ремонте, если такой ремонт включает работы, установленные п. 1(1) Положения:
а) замену и (или) восстановление всех видов строительных конструкций (за исключением несущих строительных конструкций) или замену и (или) восстановление всех строительных конструкций (за исключением несущих строительных конструкций) в совокупности с заменой отдельных элементов несущих строительных конструкций на аналогичные или иные улучшающие показатели таких конструкций элементы и (или) восстановление указанных элементов;
б) замену и (или) восстановление всех видов систем инженерно-технического обеспечения или всех видов сетей инженерно-технического обеспечения;
в) изменение всех параметров линейного объекта, которое не влечёт за собой изменение класса, категории и (или) первоначально установленных показателей функционирования такого объекта и при котором не требуется изменение границ полосы отвода и (или) охранной зоны такого объекта.
Проверка может быть проведена в инициативном порядке – когда капитальный ремонт не включает работы, указанные в пункте 1(1) Положения, но решение о проведении проверки сметной стоимости капитального ремонта объектов капитального строительства принято в порядке в соответствии с пунктом 1(2) данного Положения:
руководителем (уполномоченным руководителем в установленном порядке заместителем руководителя или должностным лицом, уполномоченным руководителем на распределение лимитов бюджетных обязательств) главного распорядителя средств федерального бюджета — в отношении объектов федеральной собственности, главного распорядителя средств бюджета субъекта Российской Федерации — в отношении объектов государственной собственности субъектов Российской Федерации, главного распорядителя средств местного бюджета — в отношении объектов муниципальной собственности;
руководителем юридического лица, созданного Российской Федерацией, субъектом Российской Федерации, муниципальным образованием, юридического лица, доля Российской Федерации, субъекта Российской Федерации, муниципального образования в уставном (складочном) капитале которого составляет более 50 процентов, — в отношении объектов такого юридического лица, капитальный ремонт которых осуществляется без привлечения средств бюджетов бюджетной системы Российской Федерации;
руководителем юридического лица, не являющегося государственным или муниципальным учреждением, государственным или муниципальным унитарным предприятием, — в отношении объектов такого юридического лица, капитальный ремонт которых финансируется с привлечением средств бюджетов бюджетной системы Российской Федерации.
Обращаем внимание на то, что обязанность по проведению государственной экспертизы, предусмотренная императивной нормой подп. 1 п. 3.3. ст. 49 ГрК РФ, не обусловлена причинами и не зависит от того, в обязательном или инициативном порядке проводится проверка определения достоверности сметной стоимости, в частности, капитального ремонта объектов капитального строительства.
В соответствии с Приказом Министерства Строительства Новосибирской области № 254 от 24.07.2017г. «О проведении проверки достоверности определения сметной стоимости строительства, реконструкции, капитального ремонта объектов капитального строительства, финансирование которых осуществляется с использованием средств областного бюджета Новосибирской области» проведение в соответствии с требованиями с ч. 2 ст. 8.3 ГрК РФ проверки достоверности определения сметной стоимости строительства, реконструкции, капитального ремонта объектов капитального строительства, финансирование которых осуществляется с использованием средств областного бюджета Новосибирской области (далее — проверка достоверности определения сметной стоимости), осуществляется в соответствии с Положением, утверждённым Постановлением Правительства Российской Федерации от 18.05.2009 № 427. Подведомственным государственным учреждением, уполномоченным на проведение проверки достоверности определения сметной стоимости, является Государственное бюджетное учреждение Новосибирской области «Государственная вневедомственная экспертиза Новосибирской области» (далее — ГБУ НСО «ГВЭ НСО»).
На основании изложенного следует обратить также внимание на то, что ГБУ НСО «ГВЭ НСО» является уполномоченным органом на проведение проверки достоверности определения сметной стоимости в отношении строительства, реконструкции, капитального ремонта лишь объектов капитального строительства. При этом планируемый капитальный ремонт должен соответствовать признакам, указанным в пунктах 14.2. и 14.3. ст. 1 ГрК РФ. Проводить проверку достоверности определения сметной стоимости в отношении иных работ (либо по работам на объектах, не относящихся к объектам капитального строительства, либо по работам, не относящимся к капитальному ремонту, например: ремонт, текущий ремонт, и т.п.) ГБУ НСО «ГВЭ НСО» не уполномочено.

 

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

Варианты ответов

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

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

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

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

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

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

С 04 августа вступили в силу изменения в Градостроительный кодекс Российской Федерации

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

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

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

Положения ГрК РФ, регламентирующие основания и порядок признания проектной документации модифицированной проектной документацией, признаны утратившими силу.

Согласно части 7 статьи 49 ГрК РФ срок проведения государственной экспертизы не должен превышать 42 рабочих дня (вместо 60 дней), продление срока экспертизы возможно по заявлению застройщика (технического заказчика) не более чем на 20 рабочих дней (вместо 30 дней).

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

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

Такими критериями являются:

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

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

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

Кроме того, внесенные в ГрК РФ изменения исключают необходимость подготовки проектной документации для капитального ремонта объектов капитального строительства (за исключением проведения капитального ремонта за счет бюджетных средств), в таком случае проектная документация должна готовиться в объеме сметы на строительство) (часть 12.2 статьи 48 ГрК РФ).

Отдельные положения Федерального закона от 03.08.2018 № 342-ФЗ подлежат вступлению в силу с 01.01.2019 и 01.07.2019. Например, с 01.01.2019 вступят в силу положения ГрК РФ, в соответствии с которыми изменится предмет экспертизы проектной документации, будет отменена обязательность проведения экспертизы проектной документации, подготовленной для проведения капитального ремонта автомобильных дорог общего пользования, с 01.07.2019 будут уточнены требования к составу и содержанию разделов проектной документации и др.

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

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

Ответы экспертов

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

30 ноября 2020 в 10:00

Имеются противоречия в нормах и правилах о проведении государственной экспертизы проектной документации и инженерных изысканий в отношении объектов газораспределительных сетей давлением до 0,6 мПа (3-й класс опасности в соответствии ФЗ-116, приложение 2, пункт 4, не располагается в ООПТ, не задевает объекты культурного наследия), строительство которых будет осуществляться за счет бюджетных средств субъекта РФ.

• Согласно части 3 статьи 49 Градостроительного кодекса РФ, Экспертиза проектной документации не проводится в случае, если для строительства или реконструкции объекта капитального строительства не требуется получение разрешения на строительство.
• Согласно Постановлению Правительства РФ от 3 декабря 2014 г. N 1300, «Об утверждении перечня видов объектов, размещение которых может осуществляться на землях или земельных участках, находящихся в государственной или муниципальной собственности, без предоставления земельных участков и установления сервитутов», части 1 «Подземные линейные сооружения, а также их наземные части и сооружения, технологически необходимые для их использования, для размещения которых не требуется разрешения на строительство», разрешение не требуется.
• Согласно Технического регламента о безопасности сетей газораспределения и газопотребления, утвержденного Постановлением Правительства РФ от 29.10.2010 N 870 при проектировании (включая инженерные изыскания) сетей газораспределения и газопотребления проводится государственная экспертиза проектной документации и результатов инженерных изысканий, однако Решением Верховного Суда РФ от 13.04.2016 N АКПИ15-1534 подпункт «б» пункта 12, подпункт «а» пункта 88, пункт 91 признаны частично недействующими, в части исключающей использование негосударственной экспертизы проектной документации.
• При этом, согласно пункту 2 части 5 статьи 49 и части 2 статьи 8.3 Градостроительного кодекса РФ, сметная стоимость строительства, финансируемого с привлечением средств бюджетов бюджетной системы РФ подлежит проверке на предмет достоверности ее определения в ходе проведения государственной экспертизы проектной документации.

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

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

---

---

По теме этого документа

Как протестировать приложение без требований?

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

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

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

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

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

Также читают:

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

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

Это все препятствия, которые мы, тестировщики, должны смело преодолевать и успешно преодолевать.Но как именно, правда?

Вот 3 основных метода тестирования приложения без требований:

Метод № 1:

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

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

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

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

Метод № 2:

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

При этом необходимо учитывать следующие аспекты:

• Приложение может содержать ошибки — поэтому, если после регистрации система напрямую перейдет на Экран 1 (определенный гипотетический экран для нашего примера) — Никогда не предполагайте, что это правильное поведение.Также, если поле принимает буквенно-цифровые символы и является номером телефона — вопрос, который следует принять, и убедитесь, что вы не принимаете приложение как предоставленный пример ожидаемой функциональности.

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

Метод № 3:

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

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

Теперь применим методы к примеру:

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

Применить метод № 1:

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

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

• Элементы могут быть добавлены в корзину после просмотра или поиска
• После добавления товаров в корзину список товаров должен обновиться.
• Пользователь должен иметь возможность продолжать покупки даже после добавления нескольких товаров в корзину
• Добавление одного и того же элемента дважды приведет к увеличению количества добавленных элементов
• Товар можно обновить
• Вещи снимаются
• Общая сумма должна быть эквивалентна сумме всех добавленных цен
• Налоги следует рассчитывать на основе введенного почтового индекса
• Стоимость доставки должна быть добавлена ​​соответственно

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

Применить метод № 2:

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

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

Теперь у тестеров действительно есть несколько вопросов, например:

1. Что произойдет, если я поставлю символ в поле суммы?
2. Когда мне добавлять слишком много элементов?
3. Какого максимума нет.из предметов это можно взять? И т. Д.

Применить метод № 3 :

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

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

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

Об авторе: Этот полезный пост написан членом нашей команды STH Свати С.

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

Важность проектной документации в управлении проектами [Обновлено]

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

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

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

ТЭО

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

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

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

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

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

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

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

Рабочий план / смета

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— это стандартная рабочая процедура для системы.

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

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

БЕСПЛАТНЫЙ курс

: Введение в CAPM®

Станьте CAPM® с этим курсом для FREEEnrol Now

Передаточный документ

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

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

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

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

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

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

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

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

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

24 ноября 13:59 2015 г. by Наталья Василина Распечатать эту статью

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

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

Какие требования плохие?

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

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

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

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

Подробнее о QATestLab

Похожие сообщения:

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

— обзор

7.2.5.1 Мышление об общих ИТ-службах

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

Википедия.

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

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

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

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

9021 9021 Аналитика Дизайн приложения Разработка 341 DWD / BI

ИТ-проекты компании	Проект 1	Проект 2	Проект 3….	… ..Проект N
Корпоративные ИТ-услуги (репрезентативная подгруппа)
Идентификация и уточнение информационных потребностей
Исходная система Обратное проектирование			Разработка модели (логическая и физическая)
Оценка архитектуры данных
Проектирование и разработка интеграции данных
Соблюдение политики управления данными
Словарь данных и управление метаданными
Идентификация и управление основными данными
Предоставление данных
Подключение к данным
Сквозная поддержка SDLC для проектов Disaster Recovery			902 / Другие хранилища данных
Архивирование для хранилищ данных

В левом столбце перечислены все различные типы ИТ-услуг, доступных для ИТ-проектов, включая проекты бизнес-аналитики.Треугольники используются для обозначения двух ИТ-ресурсов; №1 — разработчик моделей данных и №2 — разработчик интеграции данных. Мы видим, что разработчик моделей данных назначен на три проекта, а разработчик интеграции данных — на два проекта. Если выяснится, что разработчик моделей данных распределен по слишком большому количеству проектов или если его или ее навыки требуются одновременно для двух или более разных проектов, то выпуск модели данных будет отложен для одного или нескольких проектов. Существует зависимость между моделями данных и проектами интеграции данных, поэтому, если модель данных откладывается, разработчик интеграции данных может быть не в состоянии начать или завершить свою работу вовремя.Затем эта задержка каскадно распространяется на остальную часть или жизненный цикл проекта. В более широком смысле, существует множество таких зависимостей между различными ИТ-службами в течение типичного жизненного цикла проекта, поэтому, если какая-либо одна или несколько служб не обладают достаточной мощностью, или если службы оптимизируются ради них самих, или если люди, предоставляющие услуги не являются надежными исполнителями, тогда проекты откладываются. Еще больше усложняет ситуацию то, что количество людей, необходимых для данного проекта, будет варьироваться в зависимости от проекта, а необходимые услуги также будут зависеть от проекта.Эти факторы затрудняют планирование и ограничивают способность руководителей проектов контролировать ресурсы, необходимые для выполнения работы.

Мы использовали простой пример. Представьте себе сложность попытки согласовать ИТ-ресурсы в десятках или сотнях проектов. Согласно подходу общих служб, инициатива бизнес-аналитики и ее проекты будут одним из многих клиентов. Соответственно, скорость, с которой может развиваться проект бизнес-аналитики, зависит от наличия нужных ИТ-специалистов, которые могут одновременно обслуживать несколько проектов.Темп также будет зависеть от того, как разные люди подходят к своей работе. Например, менеджер по разработке моделей данных может стремиться к созданию «организации моделирования данных мирового класса» и не желать, чтобы разработчики моделей данных принимали правило 80–20 для проекта бизнес-аналитики. В более широком смысле, все менеджеры ИТ-услуг могут пытаться оптимизировать свои функции, а не оптимизировать график или техническую производительность любого конкретного проекта. Это похоже на то, что все учителя дают большие домашние задания, потому что каждый считает свой предмет самым важным, и они не координируют / не заботятся о координации, чтобы избежать несправедливого негативного воздействия на учеников.

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

7.2.5.2 Передовые методы разработки ИТ-проектов и проектов бизнес-аналитики различаются

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

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

•

избыточных затрат на работу, которая не требуется для эффективных и высококачественных результатов разработки бизнес-аналитики;

•

задержки в графике из-за выходов на этап и проверок документации, которые не соответствуют передовым практикам.

•

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

•

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

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

7.2.5.3 Что оптимизируется?

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

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

Тестирование без требований или функциональных требований Документ

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

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

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

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

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

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

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

Что нужно сделать перед началом теста

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

1. Знайте свою команду — Хорошая практика — знать не только разработчиков проекта, но и бизнес-аналитиков, владельцев продуктов, менеджеров проектов, графических дизайнеров, руководителей тестовых модулей и всех ваших коллег, участвующих в тестировании.Знание людей, участвующих в проекте, поможет вам связаться с нужным человеком в то время, когда это необходимо, и это более необходимо, когда нам не хватает документации.
2. Частое взаимодействие — Помимо запланированных встреч, хорошо иметь регулярное взаимодействие с участниками. Один из способов получить информацию — это записать все возникающие у вас вопросы, а затем обсудить их по электронной почте или в чате. Имейте в виду, что тестировщики должны четко понимать, что они должны тестировать.Предварительное уточнение предположений также поможет устранить любые неполадки, выявленные на более поздних этапах выполнения. Взаимодействие не должно ограничиваться только этапом понимания требований, но и проактивность тестировщиков требуется на каждом этапе.
3. Изучите другие артефакты — Спецификации функциональных требований или требований к программному обеспечению — это лишь один из нескольких документов, подготовленных на этапе разработки программного обеспечения. Наличие проектной документации не менее полезно, поэтому проверьте, доступны ли каркасы или макеты.Другими полезными ресурсами могут быть бизнес-требования, варианты использования, потоки процессов или техническая документация.

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

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

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

1. Контрольный список функциональности — Контрольный список идентифицированных компонентов будет работать как документ объема тестирования. Используйте то же самое для распределения работы и отслеживания в команде.
2. Использование тестировщиков, основанных на опыте — Самый ценный шаг в этом общем процессе тестирования без требований — наличие в команде опытных тестировщиков.Их опыт имеет значение не только для общего опыта в этой области, но и наиболее важен опыт в предметной области. Знания помогут в выявлении пробелов в построенной системе, а также в наставничестве других членов команды. Если по какой-либо причине опытный тестировщик недоступен для помощи во время выполнения теста, попросите его помочь на этапе понимания и сбора требований.
3. Выполните исследовательское тестирование — Исследовательское тестирование является наиболее подходящим для этого типа требований.Знания и опыт помогают определить условия, в которых система может работать не так, как ожидалось, и этим областям тестирования уделяется больше внимания. Когда нет никаких формальных шагов тестирования, система требует, чтобы кто-то пришел и протестировал вход и выход. Многие потоки тестирования генерируются случайным образом. Тестировщик планирует протестировать путь A, но, столкнувшись с проблемой, он также решает выбрать путь B, поэтому многие сценарии могут быть сгенерированы спонтанно.

Наконец

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

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

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

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

От подавленности к ясности

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

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

Что происходит, так это то, что вы полностью подавлены и не двигаетесь вперед.

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

Вы знаете, что я нашел наиболее полезным в этом процессе?

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

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

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

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

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

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

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

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

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

Скачать мой трекер действий для Excel

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. Реестр рисков

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

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

Следует ли вам вести журнал рисков? Абсолютно! Если у вас еще нет шаблона, получите мой шаблон реестра рисков.

9. Информационный план проекта

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

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

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

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

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

10. Объем работ (техническое задание)

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

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

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

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

11. Счетчик запросов на изменение

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

Примеры:

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

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

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

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

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

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

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

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

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

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

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

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

Адриан Ноймайер

Привет! Я Адриан, основатель Tactical Project Manager. Я создал сайт, чтобы помочь вам довести ваши проекты до успеха. В прошлом я работал менеджером ИТ-проектов 10 лет.

Больше сообщений

Не пропустите эти другие статьи

Какая документация по ИТ-проекту мне действительно нужна?

».

Оставить комментарий Отменить ответ

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

Имя

E-mail

Сайт

Меню

Поиск:

Название документа	Что это?	Когда это нужно?
Концептуальное предложение	Объясняет «необходимость» проекта и поиск спонсора для проекта.	Этот документ используется, когда необходимо объяснить «почему» стратегические цели не достигаются или когда необходимо улучшить выполнение миссии.
Устав проекта	Объясняет объем, цели, роли и полномочия в отношении проекта. Это создано спонсором проекта.	Этот документ обычно требуется, если проект проходит тщательную процедуру утверждения.
Заявление о масштабах проекта	Объясняет предполагаемые результаты проекта и описывает конкретную команду, которую собирают для проекта.	Этот документ нужен всегда, потому что он закладывает основу проекта.
План управления проектом	Документирует предположения и решения при планировании, способствует обмену информацией между заинтересованными сторонами, документирует утвержденный объем, стоимость и базовые планы графика.	У большинства проектов должен быть план проекта; однако, в зависимости от проекта, он может быть очень подробным или очень простым, или любой степени между ними. Руководители проекта хотят создать этот документ как «план» проекта.
Иерархическая структура работ	Разбивает проект на отдельные действия.	Все проекты должны иметь WBS с описанием каждого действия, назначенных ресурсов и временных рамок для завершения.
План управления рисками	Предвидит риски, оценивает воздействия и определяет ответы на проблемы.	Этот документ рекомендуется для наиболее дорогостоящих и подробных проектов, чтобы помочь смягчить проблемы до того, как они возникнут. Этот документ может быть включен в План управления проектом.
План управления изменениями	Документирует формальный процесс любых изменений в объеме проекта, которые могут или не могут повлиять на график.	Это рекомендуется для всех проектов, чтобы гарантировать, что все заинтересованные стороны понимают процесс, если изменение необходимо для успеха проекта. Это также помогает уменьшить сползание прицела. Этот документ может быть включен в План управления проектом.
План управления коммуникациями	Описывает типы связи (электронная почта, мобильный телефон и т. Д.).) и с кем нужно связаться и когда с ним следует связаться.	Большинство проектов должны включать эту информацию; однако это не должно быть очень сложным и может быть включено в план управления проектом.
План управления персоналом	Описывает роли и может включать в себя конкретный персонал, необходимый для успешного завершения проекта.	Большинство проектов должны включать эту информацию; однако это не должно быть очень сложным и может быть включено в план управления проектом.
План обеспечения качества (ОК)	Описывает, как конечный продукт был проверен и протестирован перед поставкой, чтобы убедиться, что он соответствует требованиям проекта и / или ожиданиям заказчика.	Рекомендуется для большинства проектов; однако детали можно отрегулировать в соответствии с проектом. Это может быть включено в план управления проектом.
План управления затратами	Предоставляет подробную информацию о затратах при управлении бюджетом и затратами проекта.	Большинство проектов должны включать эту информацию; однако это не должно быть очень сложным и может быть включено в план управления проектом.
План управления закупками	Показывает, как элементы, необходимые для проекта (оборудование / программное обеспечение и т. Д.), Будут закуплены, кем и когда. В этом плане также можно описать процесс закупок.	Этот документ нужен только для более сложных проектов, когда приобретается несколько товаров, и есть необходимость отслеживать эти покупки.Это не должно быть очень сложным и может быть включено в план управления проектом.
Документ бизнес-процесса	Подробно описывает последовательность бизнес-процессов, связанных с проектом.	Этот документ может быть основой для объема работ, включенных в качестве требований, и даже может быть основой для учебных материалов. Решение о необходимости этого зависит от менеджера проекта и заинтересованных сторон.
Документ с требованиями к системе (SRD)	Подробно перечисляет все требования, необходимые разработчикам для создания системы, отвечающей потребностям клиента.	Этот документ всегда нужен для ИТ-проектов. (См .: «Требуются ли требования при покупке ИТ-продуктов?», «Что требуется для вашей системы?» И «Центр знаний