Техническое задание

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

Рекомендуем прочитать: «Источники пассивного дохода: как и на чем зарабатывать деньги”

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

Для чего ТЗ заказчику?

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

Рекомендуем прочитать: «Психология цвета: какой цвет и что означает в рекламе”

Для чего ТЗ исполнителю?

В первую очередь, это ваш ориентир на то, что нужно сделать. Часто заказчики что-то додумывают в процессе разработки, стараясь навязать Вам выполнение лишних задач. Вы хотите работать бесплатно? Уверен, что нет. Уточняйте, что сумма, оговорена в самом начале, касалась исключительно объема работ указанного в техническом задании. Все что более – оплачивается отдельно. Также при сдаче проекта вы сможете отчитаться по поставленным задачам и их выполнению. Я не раз сталкивался с моментами, когда заказчик не хотел принимать работу, аргументируя неполным ее выполнением. Но поднимания первоначальное ТЗ оказывалось, что тех задач, о которых шла речь, вообще никто не ставил. Еще раз акцентирую внимание – не работайте без ТЗ, ведь мнение заказчика может менять чаще чем погода, и Вам придется все десятки раз переделывать тратя свое время, и не получая за это дополнительную оплату.

С чего начать составление грамотного технического задания

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

  • Общие положения технического задания

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

Рекомендуем прочитать: «Что такое вендинговый бизнес и как его начать?”

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

  • Цели проекта

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

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

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

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

Рекомендуем прочитать: «Как составить правильный бизнес план: пошаговые рекомендации”

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

  • Сроки

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

  • Отчетность

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

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

  • Ответственность

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

Рекомендуем прочитать: «На что обратить внимание при составлении бизнес плана для игровой комнаты”

Как составить техническое задание: советы из личного опыта

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

  1. Техническое задание должно быть детальное. Не бойтесь описывать каждый элемент, каждый пункт, каждую кнопку. Все-все-все максимально детально пишите. Не бойтесь показаться дотошным. Уж лучше что-то несколько раз повторить и разжевать, нежели потом доделывать, доплачивать, дорабатывать. Последнее техническое задание, которое я писал, касалось разработки сайта. Это был большой информационный проект. Сначала разработали дизайн, а потом на его основе описывал функциональное задание для программистов. Так вот, все ТЗ получилось на 54 страницы А4 11 шрифтом. Техническое задание шло как дополнение к основному договору, который тоже был на 7 страниц. Но хочу сказать, что даже в таком детальном ТЗ не все смог учесть, ведь в процессе разработки подписывали еще три дополнительных соглашения, которыми я вносил определенные корректировки в первоначальный вариант задания.
  2. Техническое задание должно быть четкое. Не нужно никакой воды. Все по делу. Если пишите о срока, то конкретную цифру, если о функционале, то перечень нужных вам функциональных решений и т.д.
  3. Ваше техническое задание – это не догма, а лишь один из возможных вариантов исполнения задач. Скажу честно, я не специалист в программировании. Да, я могу продумать структуру проекта, его функционал, какие-то технические решения, но всегда, составляя окончательный вариант ТЗ, советуюсь с исполнителями. Они могут что-то увидеть, высказать свое мнение, подсказать оптимальное решение исполнение.

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

С уважением проект Анатомия Бизнеса

Рубрики:

  • Познавательно

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»
Как говорится — «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.

Проблема

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

Переводим на понятный язык

1) ТехЗадание — оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура — это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами — любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом — это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.
2) Собственно из первого пункта логично вытекает и новый — сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» — официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? — Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы

А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:
1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? — В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей — но не вместо четкой постановки задачи, а уже после нее.
3) Так может оно мне такое и не нужно? — Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть — куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты — то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.

Что такое, зачем нужны технические задания и технические условия для государственного оборонного заказа. Требования к участникам ГОЗ по качеству продукции и лицензии Минпромторга на ВВТ. Теория, практика вопроса.

Техническое задание и технические условия

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

Теория

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

1.1. Техническое задание

В ходе описания объекта закупки (разработки ТЗ) заказчик должен руководствоваться статьей 33 Федерального закона от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд».

В части опытно-конструкторских работ (ОКР) техническое задание формируется в соответствии с государственным военным стандартом ГОСТ РВ 15.201 «Система разработки и постановки продукции на производство. Военная техника. Тактико-техническое (техническое) задание на выполнение опытно-конструкторских работ».

Согласно п. 3.1.19 ГОСТ РВ 15.201-2003, техническое задание на выполнение ОКР – исходный документ, утверждаемый заказчиком ОКР, который:

— устанавливает комплекс требований к создаваемым самостоятельным частям (СЧ) изделий военной техники (ВТ) или комплектующим изделиям межотраслевого применения (КИМП);

— утверждает требования к содержанию, объему, срокам выполнения ОКР.

1.2. Обеспечение качества продукции для Гособоронзаказа

Требования к обеспечению качества на всех стадиях жизненного цикла военной продукции содержатся в государственном военном стандарте ГОСТ РВ 0015-002 «Система разработки и постановки на производство военной техники. Системы менеджмента качества. Общие требования».

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

— к качеству, характеристикам товара, работ, услуг;

— к безопасности, функциональным характеристикам (потребительским свойствам) товара;

— к размерам, упаковке, условиям отгрузки товара, результатам работ;

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

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

В соответствии с п. 8 ст. 12 Федерального закона «О лицензировании отдельных видов деятельности» от 04.05.2011 № 99-ФЗ в перечень видов деятельности, на которые требуются лицензии, входят разработка, производство, испытание, установка, монтаж, техобслуживание, ремонт, утилизация, реализация вооружения и военной техники, а также разработка, производство, испытание, хранение, реализация, утилизация боеприпасов и пиротехнических изделий. Участниками ГОЗ могут быть только предприятия, внедрившие и сертифицировавшие систему менеджмента качества в соответствии с ГОСТ РВ 0015-002, что согласно Постановлению Правительства РФ № 581 от 13.06.2012 обязательно для получения лицензии Минпромторга.

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

Согласно пп. 3.1-3.2 межгосударственного стандарта 2.114-95 «Единая система конструкторской документации. Технические условия» ТУ – документ, который разрабатывается по решению разработчика (изготовителя) или по требованию заказчика (потребителя) продукции. ТУ – неотъемлемая часть комплекта конструкторской или другой тех. документации на продукцию. При отсутствии документации ТУ должны содержать полный комплекс требований к продукции, ее изготовлению, контролю, приемке. Разрабатываются на один конкретный объект (изделие, материал, вещество, пр.), но существует практика разработки групповых ТУ одновременно на несколько объектов. Формируются и действуют для конкретного производителя товара, не могут распространяться на всех производителей товаров такого вида.

Практика

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

  1. Получение лицензии Минпромторга в качестве исполнителя ВВТ и утверждение документации на выпуск ВВТ через проведение государственного испытания. Испытание рассчитано на экспериментальное измерение фактических (достигнутых) характеристик, свойств испытываемого образца вооружения, военной техники, определение степени соответствия созданного (произведенного, отремонтированного) образца ВВТ техническому заданию, полученному от заказчика, или ТУ. Вариант наиболее полноценный, однако требует значительных затрат (в т.ч. временных) на прохождение всей процедуры.
  2. Получение лицензии Минпромторга в качестве соисполнителя ВВТ по тех. документации основного исполнителя. Минус этого более простого решения заключается в возможном несоответствии полученной утверждённой документации, которая изначально ориентирована на другой контракт, ТЗ закупки.
  3. Получение заключения о том, что продукция не относится к ВВТ. Это даёт предприятию возможность выпускать продукцию без специального разрешения (лицензии Минпромторга).

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

С уважением,
команда ИСУ

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

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

ТЗ на СКС разрабатывается на систему целиком или как на некоторую часть в составе другой системы. Дополнительно может быть разработано ТЗ на части СКС. В таких ситуациях на основании ГОСТ 34.201-89, пункт 1.2 достаточно часто практикуется название этого документа как частное техническое задание (ЧТЗ).

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

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

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

ТЗ в общем случае содержит следующие разделы:

· общие сведения;

· назначение и цели создания (развития) системы;

· характеристика объекта;

· технические требования к телекоммуникационным и прочим параметрам системы;

· состав и содержание работ по созданию системы;

· порядок контроля и приемки;

· требования к составу и содержанию работ по подготовке здания и внешних коммуникаций к вводу СКС в действие;

· требования к документированию;

· источники разработки.

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

В процессе разработки технического задания проекту присваивается шифр в соответствии с ГОСТ 34.201-89.

Add a Comment

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