что включает в себя техническое задание на проектирование
Как писать ТЗ: инструкция по составлению грамотного техзадания
Что такое техническое задание
Техническое задание — это то, с чего начинается качественный функциональный продукт. По крайней мере, если таковым является само ТЗ. Если документ будет составлен непрофессионально и без должного внимания, результат окажется соответствующим.
Учитывая характер целевой аудитории блога и общие тренды, скорее всего, имеет смысл описывать технические задания конкретно на цифровые продукты. Во многом так и будет, но нельзя забывать, что и самые обычные, «аналоговые», продукты тоже требуют документации. Они требовали её ещё до появления самого интернета. Поэтому для расширения кругозора и для пользы представителей нецифровых отраслей, стоит приводить отсылки и к оффлайн-проектам.
Для чего нужно техническое задание?
Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.
Фактически это инструкция для разработчиков, конструкторов и других непосредственных создателей конечного продукта. Но по сути техническое задание, определяя жёсткие требования к каждой детали, делает сотрудничество заказчика и исполнителя безопаснее и комфортнее.
Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.
Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно.
Техническое задание — основа как простых односложных продуктов, так и высоконагруженных систем. В каждом случае сценарии функционирования должны быть предусмотрены. Любое действие пользователя должно быть предугадано, и ответом на него должен быть полезный результат.
Именно для того, чтобы работа с конечным продуктом вызывала положительный отклик пользователя и решала его задачи, необходимо проработать идею и детали проекта на самой ранней стадии.
Кто должен составлять техническое задание
Чтобы понять, как составить техзадание, важно определиться с тем, кто именно это будет делать. На этот вопрос нет однозначного ответа — ТЗ для задачи может составить заказчик или исполнитель, в отдельных случаях — это совместная работа.
Заказчик
В этом случае исполнитель будет четко понимать, что и когда ему потребуется делать. В результате получится точно рассчитать стоимость работ и срок, отведенный на их выполнение. Однако иногда составитель ТЗ не понимает того, что именно должен предоставить им исполнитель, из-за чего с составлением ТЗ возникают проблемы.
Исполнитель
Исполнитель, занимающийся составлением ТЗ, присылает заказчику бриф с вопросами по задаче. Так специалист выясняет цель работы и свою пользу для клиента. После этого проходит интервью, и в режиме диалога стороны уточняют рабочие нюансы. Исполнитель изучает конкурентов и целевую аудиторию, чтобы добавить эту информацию в техническое задание.
Такой способ составления ТЗ удобен, когда заказчик полностью доверяет исполнителю, а исполнитель достаточно компетентен, чтобы разобраться в задаче самостоятельно.
Совместно
Совместное формулирование ТЗ начинается с того, что заказчик озвучивает исполнителю требования относительно будущего задания. Подрядчик, в свою очередь, предлагает, как улучшить проект, и только после этого составляется техническое задание. Этот способ, как и предыдущий, работает на доверии, этичности и профессионализме сторон.
Как составить техническое задание
Главные требования к техническому заданию — это продуманность и полнота. Так как составители не всегда способны им следовать, были разработаны общие стандарты разработки ТЗ.
В вакансиях на должность системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Из названия легко понять, что это общегосударственные стандарты, образцы разработки технических заданий на территории России.
Эти два ГОСТа имеют отношение только к программным комплексам — к сайтам, приложениям и системам автоматизации. Другие ТЗ придется писать по совершенно другим правилам.
ГОСТ 19 был введён в 1980 году. Учитывая, что основные принципы программного обеспечения почти не поменялись, документ еще не утратил своей актуальности. Это можно сравнить со строительством зданий: меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.
Согласно тексту Постановления, согласно которому принят данный стандарт, назначение его следующее: «Устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения».
Само техническое задание должно содержать следующие пункты:
Более новый стандарт — ГОСТ 34, но он новее всего на 10 лет. То есть, введён с 1 января 1990 года.
Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».
Текст технического задания строится по структуре:
Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.
ISO/IEC/IEEE 29148
Разработанный Международной организацией по стандартизации ISO, данный современный стандарт пригоден для использования помимо всего прочего в международных проектах.
Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.
По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.
SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.
Общая схема строится следующим образом:
Порядок документирования требований
Выйдем немного за пределы тематики и скажем несколько слов о том, из чего состоит весь процесс документального сопровождения продукта. Ведь он не ограничивается техническим заданием. Сложность сопроводительной документации растёт вместе со сложностью и масштабом продукта.
Разработка лендинга на Тильде или запуск таргетированной рекламы Вконтакте радикально отличаются от создания высоконагруженной биллинговой системы банка. Если первые два продукта способен создать один человек, то последний может потребовать команды из нескольких десятков специалистов из многих областей.
В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.
Бриф обращён к заказчику и не предполагает жёстких финальных требований или детального описания результата. Выверенной должна быть только структура опросника. В него могут входить такие пункты, как:
Вопросов на которые отвечает заказчик, может быть до 20–30, но не более, иначе это становится большой нагрузкой. Задача брифа в том, чтобы получить общее направление для обсуждения.
Такой опрос удобно разместить на сайте, если он не сложный. Его можно запрограммировать или дать ссылку на Google формы. Либо просто разместите кнопку обратного звонка, чтобы задать вопросы и проконсультировать клиента прямо в режиме реального времени по телефону.
Виджет обратного звонка, как инструмент, подходит не только для созвонов с партнерами, но и для клиентского сервиса. Это всплывающее окно предлагает указать контактный номер,по которому перезвонит сотрудник поддержки. С виджетом обратного звонка от Calltouch вы можете собирать заявки даже в нерабочее время, а также записывать и тегировать звонки.
Виджет обратного звонка для сайта
Технико-коммерческое предложение
Здесь речь заходит о действительно крупных проектах. В противном случае нецелесообразно прилагать излишние усилия к созданию подобных документов.
ТКП разрабатывается в рамках маркетинговых мероприятий, когда продукт предлагается потенциальным заказчиком. Если у вас есть собственная концепция, готовая к внедрению или масштабированию, на её основе можно сделать предложение.
Документ содержит не просто идею и общее описание, но некоторые технические подробности. На их основе заказчику удобнее принимать решение, так как он сразу может увидеть, насколько характеристики продукта согласуются с той инфраструктурой, которая есть в наличии.
Бесполезно предлагать промышленные системы вентиляции маленьким кофейням. В других случаях помещение может отвечать требованиям, но электроснабжение окажется несовместимым с требованиями оборудования по питанию.
Технические требования
Если в ТКП требования приводятся самые основные, для ознакомления, то при заинтересованности заказчика с ним составляются уже более детализированные перечни требований.
Техническое задание
Собственно, предмет статьи. Предварительные сведения даны в предыдущих пунктах, а ценные советы ждут вас в следующем разделе.
Технический проект
Этап «живого» проектирования продукта. Здесь начинаются активные действия по разработке решений согласно ТЗ. В ходе работы уточняются и проясняются отдельные нюансы, требования, доработки.
В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).
Эксплуатация
Важно помнить, что после сдачи проекта стороны распределяют между собой обязанности по поддержанию работоспособности системы. Это тоже должно быть прописано — например, в техническом задании, если не предусмотрено другого порядка.
Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.
Когда условия работы или технологии модифицируются, приходится вносить правки в документы и внедрять изменения в продукт.
Рекомендации по составлению ТЗ
Правильное ТЗ составляют по универсальному шаблону. Он формируется из следующих элементов.
Дайте подрядчику общую информацию
Подрядчик должен понимать, чем занимается компания и кто ваша целевая аудитория. Так исполнитель сможет глубже вникнуть в поставленную задачу и избежать элементарных ошибок. При озвучивании идеи важно отметить конкурентные преимущества и особенности проекта.
Покажите конкурентов
ТЗ должно содержать ссылки на похожие проекты с дополнительным описанием. Это поможет исполнителю оценить удачные примеры чужих разработок и избежать характерных проблем при реализации. Кроме того, выявление чужих особенностей позволяет создать собственное уникальное решение.
Распишите сценарии использования продукта
Сценарий нужен для понимания принципа работы продукта. Например, если область работы касается IT, сценарий отвечает на вопрос «Как будет вести себя пользователь?» и дает понимание главных функций сайта.
Ведите историю правок
В начале документа создайте таблицу со столбцами “дата”, “описание”, “автор”. В ней записывается история изменений документа, благодаря которой легко понять, на каком этапе возникло то или иное требование, дополнение, противоречие.
Составляйте список терминов и сокращений
Это правило грамотного подхода к формированию документа. Основной текст предваряется словарём, в котором записаны специальные термины, не являющиеся общеупотребимыми. Особенно уделите внимание тем аббревиатурам и словам, которые применяются только в данному проекту.
Прописывайте каждую деталь
Сайт — это не только код, но и мощности, на которых он работает. В первую очередь, определите, на каком сервере будет размещён сайт, какие у него параметры: ёмкость, оперативная память и другие.
Пропишите периодичность и порядок оплаты сервера — передаст ли заказчик обязанность бухгалтерии или же вы будете получать ежемесячную абонентскую плату, из которой сами должны распределять средства на те или иные нужды.
Позаботьтесь о пользователях. Продумайте, какими браузерами и устройствами они пользуются, какое у них разрешение. Адаптируйте сайт, если речь идёт о нём, под различные технические характеристики устройств.
Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.
Опишите требования к проверке проекта
На этапе составления техзадания продумайте чек-лист, по которому заказчику будет понятна степень успешности реализованного проекта. Так можно быстро оценить проделанную работу и не забыть о значимых нюансах.
Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch. Он формирует отчет о результатах рекламных кампаний: сколько было звонков и заявок, и сколько из них привели к оформлению заказа. Вам не придется высчитывать KPI — итоги работы наглядно отражены в личном кабинете.
Сквозная аналитика
Когда ТЗ не нужно
Техническое задание требуется не каждому продукту. Иногда достаточно предпроектного исследования, чтобы изучить потребности клиентов вместе с аналитиком. После этого следует решать, есть ли необходимость в ТЗ.
Зачастую более гибкие методологии, работающие на создание продукта, позволяют успешно и оперативно использовать ресурсы компании. Например, сначала формируется маленький прототип, который тестируют, и на основании обратной связи от клиентов корректируют до полноценного продукта.
Выводы
Техническое задание — важный этап подготовки к работе над проектами. Его составление помогает заказчику сформулировать суть задачи, а исполнителю дает понять, как ее выполнить. Составить ТЗ может заказчик, исполнитель или заказчик вместе с исполнителем. Выбор варианта сотрудничества зависит от сложности работ и навыков специалиста.
Руководство по подготовке проектной документации для объектов капитального строительства производственного и гражданского назначения
Настоящее «Руководство по подготовке проектной документации для объектов капитального строительства производственного и гражданского назначения» направлено на создание единой организационно-технологической системы подготовки проектной документации, в соответствии с Градостроительным кодексом Российской Федерации [1], Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании» [2], Федеральным законом от 30 декабря 2009 г. №384-Ф3 «Технический регламент о безопасности зданий и сооружений» [3].
Настоящий Стандарт, являясь документом добровольного применения, устанавливает организационно-технический порядок осуществления работ в области архитектурно-строительного проектирования, соблюдения технологии проектирования, предусматривающей необходимую последовательность выполнения отдельных разделов и видов проектных работ, взаимоувязку проектных решений, контроль качества работ в процессе проектирования и согласования.
Соблюдение требований настоящего Стандарта обеспечивает выполнение требований «Положения о составе разделов проектной документации и требованиях к их содержанию» утвержденного постановлением Правительства РФ от 16 февраля 2008 г. № 87. [8].
Документ позволяет каждому проектировщику, являющемуся участником процесса подготовки проектной документации получить информацию:
Стандарт позволяет каждому участнику процесса подготовки проектной документации определить свое место в технологической цепочке архитектурно-строительного проектирования по подготовке проектной документации, понять последовательность и порядок выполнения работ, а именно:
Проектная деятельность является составной частью градостроительной деятельности по развитию территорий, в том числе городов и поселений, осуществляемой в виде территориального планирования, градостроительного зонирования, планировки территорий, инвестиционного, технологического и архитектурно-строительного планирования.
Архитектурно-строительное проектирование осуществляется путем подготовки проектной документации, применительно к объектам капитального строительства и их частям, строящимся, реконструируемым в границах принадлежащего застройщику земельного участка, а так же в случаях проведения капитального ремонта объектов капитального строительства, если при его проведении затрагиваются конструктивные и другие характеристики надежности и безопасности таких объектов.
Проектная документация представляет собой документацию, содержащую материалы в текстовой форме и в виде карт (схем), и определяющую архитектурные, функционально-технологические, конструктивные и инженерно-технические решения для обеспечения строительства, реконструкции объектов капитального строительства, их частей, капитального ремонта, если при его проведении затрагиваются конструктивные элементы здания или сооружения.
2. Нормативные ссылки
В настоящем «Руководстве по подготовке проектной документации для объектов капитального строительства производственного и гражданского назначения» использованы нормативные ссылки на следующие законодательные акты, стандарты и классификаторы:
3. Исходные и разрешительные документы
В случае, если подготовка проектной документации осуществляется физическим или юридическим лицом на основании договора с застройщиком или техническим заказчиком, застройщик или технический заказчик обязан предоставить такому лицу следующие исходные документы (п. 6 ст. 48 [2]):
Для подготовки проектной документации на объект капитального строительства необходимы следующие исходные данные (п. 10, п.п.б [8]):
4. Термины и определения
В настоящем Стандарте используются следующие термины и определения:
5. Предпроектные проработки
По объектам капитального строительства, расположенным в особо значимых местах застройки и имеющим ключевое значение в организации застройки территорий, архитектурное и объемно-планировочное решение которых требует профессионального и общественного обсуждения, а также по объектам технически и технологически сложным и не имеющим аналогов, проводятся предпроектные проработки, определяемые как Этап 1 «Поиск и принятие концептуальных объемно-планировочных и архитектурных решений, согласованных с требованиями действующих нормативных документов. Согласование принятых решений в установленном заданием на проектирование порядке» на стадии «Предварительные решения проектной документации».
На стадии «Предварительные решения проектной документации» определяются основные архитектурные, конструктивные, технологические и инженерные решения по объекту. В том числе определяется набор вспомогательных зданий и сооружений, необходимый для функционирования объекта.
«Предварительные решения проектной документации» должны быть официально согласованы застройщиком (техническим заказчиком), государственными, муниципальными и иными органами, если это требование и перечень согласующих органов заложено в задании на проектирование. Целью разработки этих документов является определение архитектурной и объемно-планировочной концепции объекта, получавшей положительные решения заказчика, государственных, муниципальных и иных органов, градостроительного Совета и профессионального общественного обсуждения.
Технологический процесс подготовки проектной документации по разделам на Этапе 1 «Поиск и принятие концептуальных объемно-планировочных и архитектурных решений, согласованных с требованиями действующих нормативных документов. Согласование принятых решений в установленном заданием на проектирование порядке» на стадии «Предварительные решения проектной документации», приведен в Приложении 11-10. Таблица 1 ТХ-ПР.
6. Задание на проектирование
Подготовка проектной документации для объектов капитального строительства осуществляется на основании задания застройщика или технического заказчика, (при подготовке проектной документации на основании договора), результатов инженерных изысканий, градостроительного плана земельного участка, в соответствии с требованиями технических регламентов, техническими условиями, разрешением на отклонение от предельных параметров разрешенного строительства, реконструкции объектов капитального строительства, (ч. 11 ст. 48 (п. 6 ст. 48 [2]).
Задание на выполнение работ по подготовке проектной документации для объектов капитального строительства составляется застройщиком (техническим заказчиком).
Задание на проектирование неотъемлемая часть договора подряда, утверждаемая застройщиком (техническим заказчиком), определяющая характер и объем подготавливаемой проектной документации и иные требования к ней. Правовой основой для подготовки задания на проектирование являются положения ст. 759 [1], устанавливающие, что:
Задание на проектирование объекта капитального строительства должно включать (п. 14 разд. III [8]):
Для некоторых объектов капитального строительства со специальной технологией задание на проектирование готовится на основании технологического задания, подготовленного эксплуатирующими организациями и утвержденного застройщиком (техническим заказчиком).
Задание на проектирование должно содержать перечень национальных стандартов и сводов правил, которыми должны руководствоваться разработчики проектной документации и в результате применения которых на обязательной основе обеспечивается соблюдение требований Федерального закона [5].
Кроме того, задание на проектирование может содержать перечень национальных стандартов, сводов правил и иных регламентирующих и рекомендательных документов, которые могут применяться на добровольной основе. Перечень нормативных документов обязательного и добровольного применения следует оформлять в виде приложения к заданию на проектирование. Необходимость разработки требований к содержанию разделов проектной документации, наличие которых не является обязательным в соответствии с постановлением Правительства РФ [7], определяются по согласованию между проектной организацией и застройщиком (техническим заказчиком) и устанавливаются заданием на проектирование.
Форму и содержание задания на проектирование приведены в Приложениях: 1-6, 2-6, 3-6, 4-6.
7. График выполнения проектных работ
Неотъемлемой частью договора на подготовку проектной документации является Календарный план подготовки проектной документации. (Приложение 67. Таблица 1).
На основании Календарного плана подготовки проектной документации руководителем проекта (ГИП, ГАП) разрабатывается подробный график подготовки проектной документации, который согласовывается руководителями подразделений (исполнителями), участвующими в подготовке проектной документации и утверждается руководителем проектного предприятия (подразделения).
График подготовки проектной документации предназначен для установления общих сроков начала и окончания проектирования объекта и его отдельных разделов, сроков промежуточной передачи заданий между исполнителями разделов, определения продолжительности проектных работ, последовательности и взаимной увязки разделов проектной документации.
В процессе оперативного управления ходом проектирования график подготовки проектной документации позволяет осуществлять контроль за исполнением установленных сроков проектирования и регулировать соблюдение технологической последовательности выполнения работ по подготовке проектной документации.
При составлении графика и относительной трудоемкости этапов подготовки проектной документации, необходимо учитывать функциональное назначение, расположение объекта капитального строительства в особо значимых местах застройки, а также техническую и технологическую сложность объектов. Относительную трудоемкость этапов подготовки проектной документации, выраженную в процентах от общего срока проектирования, рекомендуется принимать следующую:
Пример оформления Календарного плана и Графика подготовки проектной документации приведен в Приложении 6-7. Таблицы 1, 2,3,4.
Перечень и состав заданий руководителя проекта, разработчикам разделов проектной документации приведен в приложениях: Приложение 7-9. Таблица 1. и Приложение 9-10. Таблица 1.
Перечень и состав заданий начальников отделов (групп) руководителю проекта (ГИПу, ГАПу) и разработчикам разделов проектной документации приведен в Приложениях: Приложение 10-10. Таблица 1., Приложение 11-10. Таблица 1., Приложение 12-10. Таблица 1., Приложение 13-10. Таблица 1., Приложение 14-10. Таблица 1., Приложение 15-10. Таблица 1., Приложение 16-10. Таблица 1.
Перечень и состав заданий разработчиков разделов проектной документации приведен в приложениях: Приложение 10-10. Таблицы 2,3,4,5,6., Приложение 1110. Таблицы 1,2,3,4., Приложение 12-10. Таблицы 2,3., Приложение 13-10. Таблица 2., Приложение 14-10. Таблица 2., Приложение 15-10. Таблица 2., Приложение 1610. Таблицы 2,3.
На основе Графика подготовки проектной документации может быть выполнен полистовой график с указанием исполнителей по каждому виду работ или листу, срокам разработки каждого вида работ или листа. (Пример приведен в Приложении 6-7. Таблица 3).
8. Договор на выполнение работ по подготовке проектной документации
Выполнение работ по подготовке проектной документации, которые оказывают влияние на безопасность объектов капитального строительства, могут осуществлять только индивидуальные предприниматели или юридические лица, имеющие выданное саморегулируемой организацией Свидетельство о допуске к соответствующим проектным работам, привлекаемые застройщиком или уполномоченным им лицом, техническим заказчиком, на договорной основе.
Отношения между застройщиком (техническим заказчиком) и привлекаемыми на договорной основе регулируются ст. 758-762 [1].
По договору подряда на выполнение проектных работ проектная организация (подрядчик) обязуется по заданию заказчика разработать проектную документацию, а заказчик обязуется ее принять и оплатить. Подрядчик обязан:
Подрядчик не вправе передавать техническую документацию третьим лицам без согласия заказчика.
Подрядчик по договору подряда на выполнение проектных работ гарантирует заказчику отсутствие у третьих лиц права воспрепятствовать выполнению работ или ограничивать их выполнение на основе подготовленной подрядчиком технической документации.
В договоре должны указываться начальный и конечный сроки выполнения работ. По согласованию между сторонами в договоре могут быть предусмотрены так же сроки выполнения отдельных этапов работы (промежуточные сроки). Все эти сроки принимаются в соответствии с графиком выполнения работ.
Договором могут предусматриваться случаи и порядок изменения начального и конечного сроков выполнения работ.
В договоре должна указываться цена выполнения работы и способы ее определения. Цена работы определяется путем составления сметы. В случаях, когда работы выполняются в соответствии со сметой, составленной подрядчиком, смета приобретает юридическую силу и становиться частью договора подряда с момента утверждения ее заказчиком.
Сметы на проектные работы составляются в соответствии с порядком, установленным справочниками базовых цен на проектные работы в строительстве для объектов соответствующего назначения. Этими же справочниками устанавливается относительная стоимость разделов проектной документации (процент от общей цены).
В случае отсутствия соответствующих справочников базовых цен, стоимость работ может быть установлена по фактическим трудозатратам.
9. Описание технологической последовательности подготовки проектной документации
Технологическая последовательность подготовки проектной документации состоит из 6-ти этапов:
Выдача проектной документации заказчику выполняются в следующей технологической последовательности: 1. Отдел комплектации и выпуска проектов комплектует, оформляет и переплетает проектную продукцию. оформляет накладные документы и отправляет проект заказчику.**. 2. Финансовая служба проектной организации оформляет акты приема- передачи проектной продукции и подписывает их у заказчика. 3. Отдел комплектации и выпуска проектов передает руководителю проекта полный комплект оформленной проектной документации для передачи документации в технический архив организации для регистрации и хранения.
** В состав проектной документации, направляемой заказчику, не включаются расчеты строительных конструкций, технологических и инженерных решений. Данные расчеты хранятся в архиве проектной организации и представляются заказчику или органам экспертизы по их требованию.
10. Таблицы технологической последовательности
Этапность и технологическая последовательность подготовки проектной документации, порядок выдачи заданий разработчиками разделов проектной документации друг другу приведены в Приложении 8-10. Таблицы 1,2.
Перечень и состав заданий руководителя проекта, разработчикам разделов проектной документации приведен в Приложении 9-10. Таблица 1.
Перечень и состав заданий начальников отделов (групп) руководителю проекта (ГИПу, ГАПу) и разработчикам разделов проектной документации приведен в Приложениях: Приложение 10-10. Таблица 1., Приложение 11-10. Таблица 1., Приложение 12-10. Таблица 1., Приложение 13-10. Таблица 1., Приложение 14-10. Таблица 1., Приложение 15-10. Таблица 1., Приложение 16-10. Таблица 1.
Перечень и состав заданий разработчиков разделов проектной документации приведен в приложениях: Приложение 10-10. Таблицы 2,3,4,5,6., Приложение 1110. Таблицы 1,2,3,4., Приложение 12-10. Таблицы 2,3., Приложение 13-10. Таблица 2., Приложение 14-10. Таблица 2., Приложение 15-10. Таблица 2., Приложение 1610. Таблицы 2,3.
11. Контроль качеств
11.1 Общие положения
Контроль качества является неотъемлемой частью разработки проектной документации и ее завершающим этапом.
Контроль качества работ по подготовке проектной документации для строительства, реконструкции и капитального ремонта объектов капитального строительства, включая работы, которые оказывают влияние на безопасность объектов капительного строительства, рекомендуется осуществлять на следующих этапах:
Рекомендуемая периодичность осуществления контроля качества проектных работ:
11.2 Предпроектный контроль
До заключения контракта руководитель проекта (ГИП, ГАП) определяет соответствие уровня возможностей предприятия предполагаемому для исполнения заданию на проектирование, а именно:
Результат предпроектного контроля оформляется руководителем проекта (ГИПом, ГАПом), в виде служебной записки на имя руководителя предприятия для принятия решения о заключении контракта и планирования мер по его исполнению.
11.3 Текущий контроль
Осуществляется руководителем проекта (ГИПом, ГАПом), назначенным Приказом по предприятию для руководства проектными работами для конкретного объекта капстроительства.
Документация передаётся на текущий контроль для подписания в графах «Проверил» после получения подписей разработчиков смежных разделов (подразделов) в боковых дополнительных графах «Согласовано».
В случае выявления нарушений в расчетах, оформлении чертежей и т.д. или Несоответствия принятых проектных решений действующим нормативным документам, техническим регламентам и заданию на проектирование, руководитель проекта ГИП (ГАП) или руководитель группы выдаёт разработчику перечень замечаний со сроками их исправлений, и уведомляет руководителя предприятия служебной запиской о нарушениях имеющих системный характер для принятия корректирующих действий.
Нормоконтроль осуществляется в соответствии с разделом 12 настоящего «Руководства по подготовке проектной документации для объектов капитального строительства производственного и гражданского назначения».
11.5 «Выходной» контроль
«Выходной» контроль осуществляется рабочей комиссией в составе руководителя проекта ГИПа (ГАПа), руководителей отделов (групп), других специалистов, назначенных распоряжением руководителя предприятия, с целью определения готовности результатов работ, выполненных работниками предприятия и субпроектировщиками, для предъявления заказчику.
Результат проверки выполненных работ оформляется протоколом производственного совещания, содержащим вывод о соответствии выполненных работ требованиям действующих норм, технических регламентов, содержанию контракта и о необходимости доработки.
В случае положительного решения рабочей комиссии о готовности разделов (подразделов) или проектной документации в целом, для предъявления Заказчику, руководитель предприятия (главный инженер, исполнительный директор) ставит свою утверждающую подпись на титульных листах соответствующих разделов и подразделов, а руководитель проекта (ГИП, ГАП) подписывает в пояснительной записке заверение, о том, что проектная документация разработана в соответствии с заданием, техническими регламентами и т.п.
Решение о направлении проекта Заказчику принимается руководителем проекта по результатам выходного контроля. Замечания Заказчика (экспертизы) должны устраняться в соответствии с действующими нормативными документами, при этом изменения, вносимые в проектную документацию, подлежат нормоконтролю.
12. Нормоконтроль проектной документации
Настоящий раздел Руководства по подготовке проектной документации для объектов капитального строительства производственного и гражданского назначения устанавливает задачи, порядок проведения и содержание нормоконтроля проектной документации для строительства объектов капитального строительства, а также ответственность и права специалиста, осуществляющего нормоконтроль. Раздел обеспечивает реализацию окончательного контроля готовой проектной продукции, предусмотренного стандартом организации СТО-04006399-06-2005 и п.8.2.3. ГОСТ ISO 9001-2011.
Раздел включает требования ГОСТ Р 21.1002-2008 и дополняет их в части обеспечения качества, рассматривая нормоконтроль как один из видов контроля в системе менеджмента качества.
На основании настоящего раздела должен быть разработан и принят документ системы менеджмента качества (СМК) третьего уровня, предназначенного для проведения контроля на завершающем этапе разработки проектной документации на соответствие установленным требованиям нормативных документов, регламентирующих состав, комплектацию и оформление проектной продукции.
12.2 Область применения
12.2.1 Требования раздела распространяется:
12.3 Применяемые термины и сокращения
12.3.1 Применяемые в настоящем документе термины соответствуют ГОСТ ISO 9001-2011, а также терминологии, применяемой в отечественной нормативной документации, регламентирующей область проектно-изыскательской деятельности.
12.3.2 Применяемые сокращения:
12.4.1 Руководство организации несет ответственность за уровень компетенции, объективности и подготовки специалиста, назначенного выполнять функции лица, осуществляющего нормоконтроль.
12.4.2 Главный инженер организации несет ответственность:
12.4.3 Руководители проектных подразделений несут ответственность за организацию выполнения работ, установленных настоящей РИ, в рамках своего подразделения.
12.4.4 Руководитель проекта (ГИП, ГАП) несет ответственность за проведение нормоконтроля всех видов проектной документации, выполняемой по договору, руководителем работ которого он является.
12.4.5 Специалист, осуществляющий нормоконтроль, несет ответственность за:
12.5 Описание выполняемых действий
12.5.1 Задачи нормоконтроля:
12.5.1.1 Основными задачами нормоконтроля являются:
12.5.1.2 Нормоконтроль должны осуществлять высококвалифицированные специалисты, утвержденные приказом или распоряжением руководства организации.
12.5.1.3 Не допускается осуществление нормоконтроля специалистами, которые участвовали в разработке проверяемой документации или подчинены лицам, заинтересованным в результатах проверки.
12.5.2 Порядок проведения нормоконтроля:
12.5.2.1 Документы предъявляют на нормоконтроль на завершающем этапе проектирования при наличии всех установленных подписей, кроме подписи руководства подразделения. Документы предъявляют на нормоконтроль комплектно. Независимо от того, разрабатывается ли документация вручную или на ПЭВМ, документы предъявляют только в подлинниках (или копиях с подлинников).
12.5.2.3 При проведении проверки специалист, осуществляющий нормоконтроль, должен руководствоваться только установленными требованиями действующих документов.
12.5.2.4 Предъявленная на нормоконтроль документация должна быть зарегистрирована в «Карточке учета документации и регистрации и несоответствий» при проведении нормоконтроля. Форма карточки приведена в 12-Приложении 5.
12.5.2.5 Документы, не подписанные нормоконтролером, не должны приниматься техническим архивом (на учет, хранение и тиражирование) и не подлежат передаче Заказчику.
12.5.2.6 Исправление ошибок по замечаниям специалиста, осуществившего нормоконтроль, связанных с нарушением установленных требований, является обязательным.
12.5.2.7 Исправление подписанных подлинников документов, без ведома специалиста, осуществившего нормоконтроль, не допускается.
12.5.2.8 Специалист, осуществляющий нормоконтроль, не проводит экспертизу технических решений, не проверяет расчеты, размерные «цепочки» и др. технические данные, являющиеся обоснованием принятых технических решений.
12.5.2.9 Специалисты, не назначенные руководством или участвующие в разработке документа, не имеют право подписывать документы за нормоконтролера.
12.5.2.10 Разногласия между разработчиками документации и специалистом, осуществляющим нормоконтроль, разрешает главный инженер организации.
Специалист, осуществляющий нормоконтроль, проверяет правильность внесенных изменений в соответствии с содержанием «Разрешения на внесение изменений» и подписывает подлинник документа в дополнительных графах основной надписи, отведенных для согласования.
Для осуществления проверки и учета возможных замечаний руководства организации, нормоконтроль проводят до подписания руководством и после. В этом случае специалист, осуществляющий нормоконтроль, визирует документ карандашом на поле для подшивки до его подписания первым руководителем или главным инженером. После подписания документа руководством организации нормоконтролер, проставляет свою подпись в подлиннике, а карандашную визу убирает.
В остальных случаях специалист, осуществляющий нормоконтроль, ставит свою подпись после подписания документа всеми лицами, участвующими в разработке.
12.5.2.12 Специалист, осуществляющий нормоконтроль, наносит в проверяемой документации в местах, подлежащих исправлению, пометки карандашом в виде условных обозначений, которые он снимает при подписании документа. В карточке регистрации несоответствий по форме, приведенной в 12-Приложении 5 против каждой пометки кратко и ясно излагает содержание замечаний и предложений.
12.5.3 Содержание нормоконтроля
12.5.3.1 Нормоконтролю подлежат:
12.5.3.2 Специалист, осуществляющий нормоконтроль проектной документации проверяет:
12.5.3.3 Средняя норма проверки документов специалистами, осуществляющими нормоконтроль за 8-часовой рабочий день (независимо от специализации), составляет 80-100 листов, приведенных к формату А4. Нормы проверки Разрешений на внесение изменений должны быть такими же, как и для документов, на которые эти Разрешения выполняют. При необходимости проведения нормоконтроля документов в подлинниках и оригиналах, норма проверки соответственно увеличивается.
В эту норму не входит время, затрачиваемое на:
12.5.3.4 Специалист, осуществляющий нормоконтроль, проводит анализ несоответствий, обнаруженных при проверке документа, и результаты анализа (по форме, приведенной в 12-Приложении 6), ежемесячно передает в службу качества.
12.5.4 Права специалиста, осуществляющего нормоконтроль. Специалист, осуществляющий нормоконтроль имеет право:
12.6 Записи по качеству
Результаты управления процессами, описанными в разделе 12.5, обеспечивающие нормоконтроль проектной документации, должны подтверждаться соответствующими данными по установленной форме. Регистрацию записей по качеству следует осуществлять с учетом требований процедуры СМК-ДП-02/05.
13. Согласование проектной документации
Проектная документация утверждается застройщиком или техническим заказчиком. В случаях, предусмотренных статьей 49 ГК № 190-ФЗ, застройщик или технический заказчик до утверждения проектной документации направляет ее на экспертизу. При этом проектная документация утверждается застройщиком или техническим заказчиком при наличии положительного заключения экспертизы проектной документации, (п. 15 ст. 48 [2]).
Не допускается требовать согласование проектной документации, заключение на проектную документацию и иные документы, не предусмотренные настоящим Кодексом, (п. 16 ст. 48 [2]).
Согласование инженерно-технических и объемно-планировочных решений проектной документации перед выдачей проектной документации заказчику производится в следующих случаях:
14. Выдача проектной документации заказчику
Копии текстовых и графических материалов проектной документации, а также отчетной технической документации по инженерным изысканиям брошюруют в тома сложенными на формат А4 по ГОСТ 2.301. (п.8.1 [40]).
Под брошюровкой понимается размещение материалов проектной документации в переплетах или твердых папках с легкоразъемными креплениями (замками), (п.8.1 [40]).
Копии документов рабочей документации для передачи заказчику комплектуют в папки полистно сложенными на формат А4, как правило, отдельно по разделам проектной документации, (п.8.2 [40]).
Правила оформления сброшюрованной документации приведены в п. 8 ГОСТ Р 21.1101.2013 [40].
Если это оговорено заданием на проектирование, то наряду с выдачей заказчику документации на бумажном носителе, также выдается документация в электронном виде.
Руководитель проекта (ГИП, ГАП) формирует полный комплект проектной документации, а также материалов отчетно-технической документации по инженерным изысканиям на электронном носителе в форматах, определенных заданием на проектирование.
Документацией, выданной заказчику в электронном виде, могу считаться только сканированные текстовые и графические материалы проектной документации с подписями руководителей и исполнителей в штампах, или проектная документация в электронном виде заверенная электронной подписью. Проектная документация в электронном виде формируется в папки, в которые помещаются полистовые файлы, аналогично сброшюрованным томам, Заказчику выдается проектная документация в количестве, определенном заданием на проектирование.
Выдачу проектной документации заказчику осуществляет Отдел механизации и выпуска проектов на основании указаний руководителя проекта (ГИПа, ГАПа). Отдел механизации и выпуска проектов комплектует, оформляет и переплетает проектную документацию, оформляет накладные документы и отправляет проектную документацию заказчику.
Финансовая служба проектной организации оформляет акты приема-передачи проектной продукции и подписывает их у заказчика.
Отдел механизации и выпуска проектов передает руководителю проекта (ГИПу, ГАПу) полный комплект проектной документации, состоящий из сброшюрованных в тома текстовых и графических материалов проектной документации, а также материалов отчетно-технической документации по инженерным изысканиям для передачи в архив.
15. Порядок внесения изменений в проектную документацию
Изменением документа, ранее переданного заказчику, является любое исправление, исключение или добавление в него каких либо данных без изменения обозначения этого документа.
Обозначение документа допускается изменять только в случае, если разным документам ошибочно присвоены одинаковые обозначения или в обозначении документа допущена ошибка.
Внесение изменений в расчеты не допускается, (п.7.1.2 [40]).
Если изменение документа неприемлемо, то должен быть выпущен новый документ с новым обозначением, (п.7.1.3 [40]).
Любое изменение в документе, вызывающее какие-либо изменения в других документах, должно одновременно сопровождаться внесением соответствующих изменений во все взаимосвязанные документы, (п.7.1.4 [40]).
Общий порядок и правила внесения изменений в проектную документацию регламентирован п.7 «Правила внесения изменений» ГОСТ Р 21.1101.2013. [40].
Особенности внесения изменений в проектную документацию регламентированы п.7.4 ГОСТ Р 21.1101.2013. [40].
16. Передача проектной документации в архив
Передача проектной документации в архив осуществляется руководителем проекта (ГИПом, ГАПом) по завершению 6-го этапа «Выдача проектной документации заказчику» технологического процесса подготовки проектной документации по разделам. Руководитель проекта (ГИП, ГАП) обязан передать в архив полный комплект проектной документации, как на бумажном, так и на электронном носителях.
Руководитель проекта ГИП, ГАП), для передачи в архив проектной документации, формирует полный комплект проектной документации, состоящий из сброшюрованных в тома текстовых и графических материалов проектной документации, а также материалов отчетно-технической документации по инженерным изысканиям. Под брошюровкой понимается размещение материалов проектной документации в переплетах или твердых папках с легкоразъемными креплениями (замками).
Проектная документация в электронном виде формируется в папки, в которые помещаются полистовые файлы, аналогично сброшюрованным томам,. Передачу проектной документации в архив, руководитель проекта (ГИП, ГАП) осуществляет по описи передаваемой документации.