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

При разработке любого проекта. Как оформляется этот документ? Об этом будет рассказано в статье.

Техническое задание - что это такое?

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

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

Зачем техническое задание заказчику?

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

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

Зачем техническое задание исполнителю?

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

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

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

Начало составления документа

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

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

Требования и сроки

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

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

Ответственность и отчетность

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

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

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

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

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

Просто стоит запомнить несколько простых правил:

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

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

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

2 голоса

Доброго времени суток, уважаемые читатели. Работать над созданием сайта с заказчиком всегда трудно. Клиент, как правило, хочет либо «что-то крутое», либо «ничего необычного, пусть будет как у всех». Абстрактные понятия, согласитесь. Если это ваш первый заказ, то вы даже можете обрадоваться подобным словам: «Круто, мне дают свободу творчества, я могу сделать все что пожелаю». Скажу по опыту, ничего подобного!

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

План действий по работе с заказчиком

Вы находите клиента. Он готов заплатить деньги, а вы приступить к работе. С чего же начать и как действовать?

• Первое общение.

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

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

• Подготовка и первый бриф.

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

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

• Составление и подписание технического задания.

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

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

Однажды мне очень повезло. Прежде чем прийти на встречу клиент изучил вопрос, и сам составил не только грамотное ТЗ, но и художественное задание. То есть литературное и подробное описание как оно все должно выглядеть. Моему удивлению не было предела, на что он ответил: «Я считаю, что заказчик сам в первую очередь должен знать, чего хочет, а не мучать специалистов». К сожалению, это редкость, поэтому нам приходится задавать вопросы, прописывать и утверждать.

• Разработка и прием.

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

Чего не должно быть в ТЗ, а что там быть обязано

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

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

Пусть в вашем ТЗ будет фраза: «Все, что не оговорено выполняется на усмотрение исполнителя». И не обязательно делать эту строчку маленьким шрифтом. Пусть думает заранее, а не начинает мечтать, когда проект уже готов. Конечно же, небольшие изменения вы можете и должны внести. Хорошая репутация – залог будущих клиентов, но иногда заказчик может так достать своими пожеланиями, что жить не захочется.

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

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

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

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

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

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

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

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

Выглядит оно так:

1. Глоссарий
2. Общие положения
3. Предмет разработки
4. Назначение документа
5. Требования к графическому дизайну сайта
6. Требования к дизайну сайта
7. Порядок утверждения дизайн-концепции
8. Функциональные требования
9. Требования к представлению сайта
10. Требования к системе управления сайтом
11. Требования к разделению доступа
12. Требования к видам обеспечения
13. Требования к информационному обеспечению
14. Требования к программному обеспечению
15. Требования к техническому обеспечению
16. Требования к лингвистическому обеспечению
17. Требования к эргономике и технической эстетике
18. Требования к приемке-сдаче проекта
19. Требования к наполнению информацией
20. Требования к персоналу
21. Порядок предоставления дистрибутива
22. Порядок переноса сайта на технические средства заказчика

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

Глоссарий

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

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

Общие положения

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

Предмет разработки

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

Задумайтесь, каким образом клиент будет зарабатывать деньги, какова его цель. Если это интернет-магазин, то он должен заниматься продажами, если корпоративный сайт, то здесь любят красивую фразу: «повышение лояльности к бренду», информирование о деятельности компании и так далее.

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

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

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

Требования к графическому дизайну сайта

Требования к дизайну сайта

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

Порядок утверждения дизайн-концепции

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

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

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

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

Требования к представлению сайта

1. Структура сайта: описываем какие категории (рубрики) будут на сайте.
2. Главная страница: лучше всего со схематической картинкой и описанием основных элементов.
3. Внутренние страницы: тоже что и в предыдущем пункте. Схема и описание внутренних страничек.

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

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

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

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

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

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

Требования к видам обеспечения

Требования к информационному обеспечению

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

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

Вы обязуетесь выложить изображения только в формате gif или jpg, а страницы не будут превышать определенного веса. Кстати, отличный пункт. Потом, если заказчик выпучит глаза и скажет, что ему нужно что-то другое, можно показать этот пункт и сказать: «Ну вы же сами про вес подписали, ничего не знаю, все это невозможно!».

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

Требования к программному обеспечению

1. Тут речь идет о хостинге или серверах. Так как мой блог ориентирован на создателей, которые работают на Таймвебе (https://timeweb.ru ) – все очень просто. Если вы не из «наших», то нужно смотреть на технические характеристики. Например, кто-то очень умный делает крутой сайт, а потом пытается подключить его к хостингу, а технические характеристики настолько завышены, что ни один хостинг в России не справляется. Пункт нужный, но не для новичков в сфере разработки.
2. Здесь мы описываем будет ли портал иметь мобильную версию, адаптирован под портативные устройства или сможет открываться только через Google Chrome, а любые искривления в других браузерах нас вообще не волнуют.

Требования к лингвистическому обеспечению

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

Требования к эргономике и технической эстетике

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

Требования к приемке-сдаче проекта

Требования к наполнению информацией

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

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

Требования к персоналу

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

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

Что вы отдадите заказчику, когда работа будет выполнена: логин, пароль, туда-сюда.

Набиваем цену технического задания

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

В этом документе должно впечатлять все! Если вы собираетесь переслать его для предварительного ознакомления по почте, то обязательно используется формат PDF. И клиенту вероятно не захочется мучить себя правками и о вас он будет думать, как о профессионале. Мелочь, а значительная. Для преобразования вордовского документа можно использовать сервис https://smallpdf.com/ru/ .

Не забудьте вставить фоном логотип собственной компании или вашего бренда, а также вставить контакты. Быстро и качественно их можно оформить на сайте https://logaster.ru .

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

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

СКАЧИВАЕМ ШАБЛОН ТЗ

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

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

Как подготовить ТЗ по 44-ФЗ

Общие правила составления технического задания по 44-ФЗ, а точнее правила описания объекта закупки установлены ст. 33 Закона о контрактной системе. Приведем основные:

• описание объекта закупки должно носить объективный характер. Не допускаются двусмысленности и разночтения;
• ТЗ по 44-ФЗ содержит в себе функциональные, технические и иные характеристики, которые требуются от поставляемого товара (либо произведенных работ);
• форма техзадания должна быть нейтральной: не допускается включение в описание товарных знаков, фирменных названий, патентов, названий стран-производителей продукции. Можно использовать указание на товарный знак при условии сопровождения его словами «или эквивалент» либо в том случае, когда приобретаются запчасти и расходные материалы к оборудованию;
• при необходимости снабжается спецификациями, чертежами, требованиями к упаковке и т.д.

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

Какие ошибки в ТЗ можно исправить на разных стадиях закупки

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

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

Правила написания технического задания по 44-ФЗ

Выше мы привели общие требования, сейчас остановимся на нюансах. В силу п. 4 ст. 23 44-ФЗ название объекта закупки должно быть указано в соответствии с каталогом товаров, работ, услуг. КТРУ утвержден постановлением Правительства РФ от 08.02.2017 № 145. Если описание продукции отличается от того, что указано в каталоге техническое задание по 44-ФЗ в 2019 году должно включать в себя письменное обоснование этого.

При формировании надо также обращать внимание на коды ОКДП, относящиеся к закупке, проверить их корректность и соответствие этим кодам поставляемой продукции. В некоторых случаях большое значение имеют ГОСТы, СНИПы, СанПиНы. Например, может быть закреплено требование в ТЗ по 44-ФЗ знать ГОСТ 34 и ГОСТ 19. (ГОСТ 34 используется в заданиях на разработку автоматизированных систем, а ГОСТ 19 – на разработку программного обеспечения).

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

Включает ли подготовка технического задания по 44-ФЗ цену? Как правило, расчет начальной цены контракта делается отдельным документом. Включать НМЦК в техзадание или нет, решает госзаказчик.

Правила составления ТЗ по 44-ФЗ

У контрактных управляющих нередко возникает вопрос: кто делает техническое задание по 44-ФЗ? Нередко его составление требует специальных знаний, которыми управляющие не владеют. Поэтому заполнение осуществляется заинтересованными подразделениями заказчика. Контрактные управляющие лишь проверяют его на соблюдение норма законодательства.

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

Кто подписывает техническое задание по 44-ФЗ? Как правило, руководитель организации либо уполномоченное им лицо. Стоит ответственно отнестись к подготовке ТЗ по 44-ФЗ, т.к. изменить его не всегда возможно. В силу ч. 7 ст. 95 изменение ТЗ при выполнении госконтракта в части изменения вида работы, товара, услуги допускается только в том случае, если будут поставлены работы, товары, услуги, обладающие лучшим качеством, характеристиками, по сравнению с теми, что были указаны в первоначальном ТЗ. Как избежать ошибок при работе с техзаданием, разберем на свежих решениях ФАС

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

Можно ли при покупке легкового автомобиля ОКПД2-29.10.22.000 написать конкретную марку (Шкода) со словами эквивалент?

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

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

Ответ. Смотрите ответ на первый вопрос. Вы вправе указать конкретную марку автомобиля, только сопроводив такое указание словами «или эквивалент». Попытка закупить конкретную марку автомобиля без обоснования - нарушение принципа конкуренции контрактной системы.

Если при поставке легкового автомобиля в ТЗ в предмете закупки мы ставим легковой автомобиль и прописываем технические характеристики только одного авто. Это правильно?

Ответ. Нет, это неправильно. Указывать конкретные характеристики, под которые подходит только одна марка и модель автомобиля - нарушение закона о конкуренции и правил описания объекта закупки. Вы рискуете в случае проверки быть оштрафованными по части 4.1 статьи 7.30 КоАП.

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

Если товар входит в КТРУ, то можно ли дополнить техническое задание требованиями ГОСТов? Только при наличии обоснования? Обоснование дополнительных характеристик можно размещать только в ТЗ или ещё и в плане-графике?

Ответ. Любое дополнение позиции КТРУ производите только с обоснованием. Укажите, почему вы дополняете описание из каталога. Такие требования указаны в п. 5 и 6 Правил использования КТРУ (утв. Постановлением Правительства от 08.02.2017 № 145). Также отразите всю дополнительную информацию сверх информации из позиции КТРУ во всех плановых документах.

Скажите, если есть смета (как обоснование НМЦК) на тек. ремонт вентиляцию, там есть материалы (короба металлические) нужно к ним подписывать «или эквивалент»?

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

Должно ли наименование объекта закупки полностью совпадать с ОКПД2 или допустимо использовать более детальное наименование объекта закупки?

Ответ. Если ваш объект закупки есть в КТРУ, используйте наименование продукции из классификатора ОКПД2. Не отклоняйтесь от стандартного наименования и описания закупаемого товара.

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

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

При благоустройстве дворовых территорий нужно ли прописывать в ТЗ малые архитектурные формы? Они указаны в проекте, какие нужны.

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

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

Тип, материал, высота от земли, способ крепления/установки (закапывается в землю или имеет свой собственный фундамент), цвет ограды - все это важные ключевые характеристики МАФ. Об этих характеристиках должны знать участники закупки, если, конечно, вы действительно хотите получить то, что заложено в проект, а не «что-то типа того» - что завалялось у поставщика на складе.

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

Если в приказе по нормированию не предусмотрен МФУ, только принтер и сканер. Можно ли купить МФУ?

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

Оригинальный картридж во-первых не портит технику, подлежит неоднократной заправке, а неоригинальные картриджи - одноразовые. Где экономия?

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

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

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

Если в КТРУ название товара, например: Бензин автомобильный АИ-92 экологического класса не ниже К 5, то так и писать это название в плане закупок, плане –графике, документации и т.д. или же можно написать, например Бензин АИ-92?

Ответ. В плановых документах наименования объектов закупок пишите в полном соответствии с названиями из КТРУ.

P.S. Не совсем по теме, но все-таки: в ближайшее время план закупок будет отменен. Следите за новостями и статьями на портале.

Кто проверит, что оборудование новое?

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

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

Если в проекте контракта цена с НДС, а участник работает без НДС, надо ли писать протокол разногласий?

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

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

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

Можно ли в названии закупки писать: «Поставка программного обеспечения Microsoft Windows 10 Pro»?

Ответ. Общее правило по Закону № 44-ФЗ. Так как операционная система Windows 10 является зарегистрированным торговым знаком корпорации Microsoft, по общему правилу при описании объекта закупки следует добавлять слова «или эквивалент». А объект закупки назвать «Поставка неисключительных прав на использование программного обеспечения (операционной системы)». Эквивалентами в данном случае станут ОС того же производителя Windows 7 и Widows 8.1. - это более старые и более дешевые аналоги, обладающие однако тем же функционалом и поддерживающие работу с любыми программами, которые могут быть у заказчика, в том числе с самыми современными.

Ремарка. Отечественные аналоги (все они на основе Linux, если не ошибаюсь) менее эффективны и не могут обеспечить качественную и корректную работу с современным ПО и оборудованием, имеющимся у заказчика. Сам Linux менее дружелюбен для непрофессионального пользователя, сложен в освоении, несовместим с некоторыми программами. Обучение работе с Linux обойдется гораздо дороже покупки Windows 10, то есть покупка Linux будет крайне неэффективной.

Практика. Однако в ЕИС можно найти много закупок, где в названии указано только «Поставка ПО Microsoft Windows 10 Pro» и в документации не говорится об эквивалентности. Судя по всему, эти закупки проходят без проблем и не привлекают внимание контролеров. Дело в том, что эквивалентность больше касается торговой марки в целом, а не различных версий внутри этой торговой марки. Контролеры тоже понимают, что Windows - оптимальный вариант для пользователей. Кроме того, что тоже важно, Microsoft поддерживает, но больше не производит новые лицензии на Windows 7 и Widows 8.1. (но в продаже они еще будут долго). То есть Microsoft Windows 10 - самая современная + единственная актуальная, а значит и самая эффективная ОС для абсолютного большинства пользователей (MacOS не в счет, компьютеры Apple при схожем функционале в разы дороже). Рано или поздно Windows 7 и Widows 8.1 производитель прекратит поддерживать и обновлять; останется только один актуальный продукт Windows 10, домашняя и профессиональная версии.

Итог. Хотя указание в названии объекта закупки «Поставка программного обеспечения Microsoft Windows 10 Pro» формально противоречит требованиям закона, практика показывает, что подобные закупки проводят довольно часто. Указание Windows 10 Pro и требует обоснования из серии «желания идти в ногу со временем»:

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

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

Можно ли требовать соответствие товаров национальным (региональным) стандартам и требованиям, не обязательным в России? Или соответствие требованиям необязательных, коммерческих сертификаций?

Ответ. Такие требования вы можете указать в документации, только если обоснуете их необходимость для своих нужд. Это прямо указано пункте 2 части 1 статьи 33 Закона № 44-ФЗ. По общему правилу заказчики используют показатели, требования, условные обозначения и терминологию, которые предусмотрены техническими регламентами и документами (ГОСТами), применяемыми в национальной системе стандартизации, принятые в соответствии с законодательством РФ о стандартизации (там же: п. 2 ч. 1 ст. 33 Закона № 44-ФЗ).

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

Какие права имеет Исполнитель, если после подписания ГК, выясняется, что при требовании изготовить бланк «график» тиражом 1млн, выясняется что этот тираж включает 500 тыс разных видов этого графика, что в десятки раз увеличило себестоимость услуг?

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

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

Без тех. задания можно проводить котировку?

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

Можно в ТЗ не указывать конкретный ГОСТ, только условие о соответствии действующему ГОСТУ?

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

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

По умолчанию добросовестные заказчики, которые не хотят запутать поставщиков, указывают обозначение ГОСТа (то есть его номер) и наименование ГОСТа. Например:

1. ГОСТ 10015-87 Бумага гуммированная для переводных изображений;
2. ГОСТ 10119-2007 Консервы из сардин атлантических и тихоокеанских в масле

Помните, что корректное название и актуальность ГОСТов вы всегда можете найти проверить на официальном сайте Ростстандарта → www.gost.ru

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

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

Технические условия регистрируют конкретные производители на конкретные товары. Поэтому указывать в техническом задании реквизиты ТУ недопустимо. Но иногда ТУ носят обязательный характер, в таких случаях их можно указывать в техзадании. Например, если закупают вещевое обеспечение для нужд силовых органов. Когда в описании объекта закупки используют ТУ, ФАС проверит, есть ли они в открытом доступе. Если указываете конкретные реквизиты ТУ в документации, опубликуйте их в ЕИС.

Имеем ли мы право указывать в спецификации конкретный товар или как в ТЗ только характеристики?

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

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

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

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

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

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

Если наименование объекта закупки «Трактор Беларус-8.1» без указания эквивалент, а в техзадании указано «эквивалент» - нарушение?

Ответ. Здесь и нарушение (хотя и не большое) и нестыковка. Указывая конкретную марку трактора без указания слов «или эквивалент» и без обоснования, что вам необходима эта конкретная модель трактора, вы нарушаете пункт 1 части 1 Закона № 44-ФЗ. Правила описания объекта закупки действуют по умолчанию на всю документацию, а не только на техническое задание (которого может не быть вовсе, или которое может называться по-другому).

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

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

Указали, что футбольная форма нужна Nike или эквивалент, в ТЗ указали обязательным условием: по технологии Dri-Fit (которые есть только у формы Nike). Нарушение ли это?

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

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

Если отбросить рекламные словечки, типа «уникальная структура» (в единственном экземпляре что ли?), мы увидим, что в сухом остатке речь идет о простом полиэстере и ткани из микрофибры с повышенным влагоотделением, влагоиспарением.

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

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

Почему мы ОБЯЗАНЫ покупать совместимые картриджи, если мы хотим использовать ТОЛЬКО оригинал? Ссылку на нормативку можно?

Ответ. Вы не обязаны закупать только совместимые картриджи. Но ваши желания должны быть в рамках закона, по которому вы работаете: по закону вы обязаны соблюдать принцип конкуренции. Конкретно - первое предложение п. 1 ч. 1 ст. 33 Закона № 44-ФЗ. Также помните, что обеспечение конкуренции - один из принципов, на которых основывается контрактная система в сфере закупок (статья 6 и статья 8 Закона 44-ФЗ).

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

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

Каким образом практически можно понудить поставщика аналоговых картриджей в период гарантийного срока произвести ремонт оргтехники за свой счет в случае ее поломки?

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

Имеет ли право заказчик установить требование в тех.задании свыше гарантии, установленной производителем? (производитель дает 12 мес., а заказчик хочет поставить не менее 36 мес.).

Ответ. Да, если не ограничите конкуренцию. Многие магазины электроники предлагают дополнительные услуги по повышенной гарантии, стоит такая услуга 5-15% от стоимости товара. В маркетинге и продажах такие услуги (зачастую навязываемые) называют «расширением чека». Помните, что дополнительные гарантия – это увеличившиеся риски поставщика понести возможные затраты на гарантийный ремонт, это стоит учитывать при обосновании НМЦК.

В описание объекта закупки Заказчик устанавливает так же требования к гарантийному сроку при поставке товара (ст. 33 Закона 44-ФЗ). Часть 5 статьи 6 Закона от 7.02.1992 № 2300-1 «О защите прав потребителей» гласит, что Изготовитель (исполнитель) вправе устанавливать на товар (работу) гарантийный срок, а также вправе принять обязательство в отношении недостатков товара, обнаруженных по истечении установленного им гарантийного срока (дополнительное обязательство). Установление гарантийного срока – это право изготовителя (продавца), а не обязанность и законом не ограничивается возможность установления также различных гарантийных сроков.

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

Вес пачки бумаги д.б. 2,24532кг, при взвешивании всегда меньше (с учетом обертки пачки), что делать, отклонять?

Ответ. Надо смотреть документацию. Судя по всему, принимать… Но это не точно… Вы установили требование к весу пачки бумаги с точностью до сотой доли грамма (!) . Как вы это обосновали? Как вы высчитали этот вес с такой точностью? На основе взвешивания пачки из прошлой партии? Или посчитали вес одного листа из расчета количество листов в листе 1 кв. м. (около 16), а затем перемножили на количество листов в пачке? Даже две одинаковые пачки бумаги из одной коробки по весу будут различаться на пару-тройку процентов и это нормально и допустимо. И это все по-прежнему по ГОСТу.

Ни ГОСТ, ни КТРУ не содержит требования к весу пачки бумаги, он говорит о весе листа такой бумаги площадью 1 кв. метр - 80 грамм (самая распространенная и стандартная офисная бумага), 100 грамм и т.д. в зависимости от плотности, которая требуется. То есть в ГОСТе вес упаковочной бумаги не учитывается в принципе.

Таким образом, заказчик уже установил требование, которое не регламентирует ГОСТ (это уже повод для жалобы со стороны участников). А с учетом точности веса до сотой доли грамма это требование крайне жесткое…

Корректное измерение веса бумаги по ГОСТу должно выглядеть примерно так: заказчик должен вскрыть пачку наугад и наугад вытащить оттуда 17 листов бумаги. Затем заказчик должен обрезать некоторые и склеить листы так, чтобы получился один большой квадратный лист со сторонами равными 1 м. Взвесить этот лист и вычесть массу потраченного клея. Результат должен равняться 80 грамма +/- 3 грамма. Согласитесь, что для такого нужны крайне точные, чуть ли не ювелирные весы. Кроме того, результат все равно нельзя считать репрезентативным, так как такой лист площадью 1 кв.м. измеряют на специальных испытаниях. И испытания эти проводят также по ГОСТ Р ИСО 536-2013 «Бумага и картон. Определение массы»… В несколько этапов, определенными методами, с несколькими пробами, обработать результаты по спецметодике…

В ГОСТе сказано, что в зависимости от качества бумаги вес листа площадью 1 кв. м. имеет допуск на отклонение. Например, бумага класса «С» имеет предельный допуск на отклонение по весу +/- 3 грамма, то есть в любом случае это целых 2,4%. Это приблизительный арифметический расчет. Его нельзя назвать абсолютно корректным, т.к. требуется проводить измерения по методике, описанной в ГОСТе (см. пример выше).

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

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

1.Электроснабжение

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

2.Главный распределительный щит (ГРЩ)

Предусмотреть устройство необходимого количества ГРЩ. Каждое ГРЩ должно иметь две главные секции шин с авто­ матическими выключателями. Между секциями предусмот­ реть секционный выключатель.

Технические характеристики ГРЩ определить проектом, ис­пользовать комплектующее оборудование фирмы ИЭК либо иное сертифицированное.

Шкафы ГРЩ-0,4 кВ должны быть одно- или двухстороннего обслуживания (уточнить проектом). В каждом ГРЩ (ВРУ) необходимо предусмотреть резерв 15% автоматических вы­ключателей отходящих линий и резерв 15% свободного места для возможной установки дополнительного оборудования (автоматических выключателей и т.д.).

3.Учет электроэнергии

Коммерческий учет электроэнергии предусмотреть на ввод­ных панелях ГРЩ расчетными трехфазными счетчиками.

4.Электрические групповые щиты

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

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

Разработать щиты электроснабжения арендных площадей (ЩРА).

Разработать щиты электроснабжения компьютерных розеток (ЩК) для офисных помещений.

Разработать щиты электроснабжения технологического обо­рудования (ЩС).

Щиты (оболочки) предусмотреть производства Schneider Electric и ИЭК.

Коммутационно-защитную аппаратуру предусмотреть производства Schneider Electric и ИЭК.

5. Магистральные кабельные трассы

Магистральные кабельные трассы выполнить стальными горячеоцинкованными кабельными полками лестничного типа и листовыми кабельными лотками или проволочными лотка­ми.

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

Питающие магистральные линии выполнить кабелем с ПВХ изоляцией. Кабели проложить открыто по кабельным полкам. Питающие кабели (до распределительных щитов) должны иметь запас по пропускной способности 10-15%. Все металлические кабельные конструкции заземляются

6. Электропроводка

Для электропроводки применить кабели с ПВХ изоляцией с медными жилами. Кабели прокладывать:

Скрыто в ПВХ трубах за подвесными потолками;

Скрыто в ПВХ трубах в штрабах с последующей задел­ кой;

Открыто по кабельным полкам;

Открыто в декоративных кабель-каналах и плинтусах (офисные помещения).

Тип прокладки кабеля в помещении определить в соответ­ствии с эскизным проектом. Электропроводку выполнить сменяемой.

7. Электроустановочные и электромонтажные изде­лия

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

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

8. Электроосвещение

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

Напряжение сети общего освещения - 380/220 В, напряжение на светильниках - 220 В, напряжение ремонтного освещения -36 В.

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

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

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

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

Использовать светильники производства "Световых технологий”.

Электроустановочные изделия - производства Schneider Electric и ДКС.

Кабеленесущие системы – ДКС.

9.Электроснабжение противопожарных систем

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

Взаиморезервируемые кабели противопожарных систем про­ложить по разным трассам.

10.Заземление

Применить систему заземления типа TN-C-S. В качества заземляющего устройства использовать железобе­тонное основание здания (при необходимости выполнить наружный контур молниезащиты из полосы 5x40). Проектом предусмотреть систему уравнивания потенциалов.

11.Молниезащита

Молниезащиту здания выполнить согласно РД 34.21.122-87.

12.Трансформаторная подстанция и ГРЩ

Предусмотреть встроенную трансформаторную подстанцию.

Принять следующее оборудование:

распределительное устройство высокого напряжения – марки RM-6 производства Schneider Electric;

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

трансформаторы – сухие марки Trihal производства Schneider Electric.

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

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

Создан 05.02.2005 11:41:19

Твой мир пуст...

Кто печаль твою разделит?

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

Вернемся к вопросу. При «раскладке» получается:

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

Третий - самый сложный. Ответы на указанные вопросы появятся в ходе изложения.

Цели и задачи статьи

Цель статьи - облегчить жизнь совсем уж начинающим техписам.

Задачи статьи:

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

История

Все, что когда-либо производилось, производится и будет производиться, делится (условно, разумеется) на:

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

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

Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор - «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» - 100-процентная автоматизация.

История, леденящая душу

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

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

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

Побагровел царь - что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная.). Схватили мужика опричники, да долбанули по буйной его головушке топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата...

Выводы

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

Издавались Указы, Распоряжения - «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).

Равноправия нет и сейчас - кто платит, тот и заказывает музыку. А платит заказчик.

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

Современное состояние

И было придумано то, что сделали танк...

из серии «Армейские приколы»

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

Может быть, все было иначе, но танк, в целом, получился хорош - что подтверждается и представителями ГОССТАНДАРТа, и отзывами опытных разработчиков.

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

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

Для маааааааленького техписа, работающего на Большого Босса, разработка технического задания есть:

• средство заработать себе «таки на покушать»;
• способ показать, что техпис - не тварь дрожащая, а право имеет - способ вырасти в глазах Большого Босса.

Крайнее утверждение - палка о трех концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.

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

Считаем, что первый вопрос (в первом же приближении) закрыт.

ГОСТы на технические задания

Куст есть совокупность веток, произрастающих из одной точки.

Военная мудрость

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

Примечания:

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

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

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

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

Потребовалось разработать техническое задание на изделие - пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001 - кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо - открываем ГОСТ 34.602-89. На - ГОСТ 19.201-78.

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

Практические приемы

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

Самый первый прием - создание документа с ГОСТированной структурой разделов. Если Боссом поставлена задача разработки технического задания, положим, на автоматизированную систему, скачивается ГОСТ 34.602-89 в виде -файла, затем просто открывается вордом и в формате dot.

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

Примечание от 25.12.2011 г. - На Ростехрегулирования (protect.gost.ru) не так давно стали публиковать официальные версии ГОСТов, правда, далеко не в редактируемом формате...

Детализация

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

Вспомним родительское - «пока ты не разложишь все по-полочкам, «ничего у тебя не получится (мама)» или «ни хрена у тебя не выйдет (папа)». И мама, и папа, безусловно, были и остаются бесконечно правы. Несложную задачку по физике решить невозможно, пока векторы сил не будут разбросаны по осям. Тройной интеграл взять невозможно, пока не будут поочередно взяты интегралы по dx, dy и dz. За исключением случая, когда «интеграл настолько прост, что взять его можно даже без dx».

Произвольно выбранная цитата из ГОСТ 34.602-89:

Для системы приводят требования к применению в системе, языков взаимодействия и технических средств системы, а также требования к и декодированию, к языкам -, средствам описания (объекта автоматизации), к способам организации [из п. 2.6.3.3 ГОСТ 34.602-89]

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

4.3.2.1 Требования к лингвистическому обеспечению системы

4.3.2.1.1 Требования к применению в системе языков программирования высокого уровня

(текст требования)

4.3.2.1.2 Требования к языкам взаимодействия пользователей и технических средств системы

(текст требования)

4.3.2.1.3 Требования к кодированию данных

(текст требования)

4.3.2.1.4 Требования к декодированию данных

(текст требования)

4.3.2.1.5 Требования к языкам ввода-вывода данных

(текст требования)

4.3.2.1.6 Требования к языкам манипулирования данными

(текст требования)

4.3.2.1.7 Требования к средствам описания предметной области (объекта автоматизации)

(текст требования)

4.3.2.1.8 Требования к способам организации диалога

(текст требования)

Увеличился объем технического задания? А стоит ли экономить бумагу? Имеется и еще одна военная мудрость, как бы грубо и двусмысленно она ни звучала: «больше бумаги - чище з@@@@ца». Требования к лингвистическому обеспечению стали выглядеть понятнее?

Примечание - Термины «понятность», «» (understandability) фигурируют сразу в нескольких ГОСТах. Вот квинтэссенция - «совокупность чего-то, характеризующая затраты усилий человека на понимание логической концепции этого чего-то».

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

Детализация, детализация и еще раз детализация. До приемлемого (атомарного) уровня.

Шаблонное построение фраз

Следует взять на вооружение тот факт, что в каждом вопросе (правильно поставленном) - половина ответа. Допустим, необходимо сформулировать текст подпункта «Требования к применению в системе ». Итак:

4.3.2.1 Требования к применению в системе языков программирования высокого уровня

В системе должны быть (именно должны - это же!) применены перечисленные ниже языки программирования высокого уровня:

• язык C++;
• язык Pascal;
• и т.д.

Для тех, кто не прочувствовал, как построить фразу, слева приведена схема ее построения.

4.1.2 Требования к численности и квалификации персонала системы и режиму его работы

(детализируем - создаем подпункты 4.1.2.1, 4.1.2.2 и 4.1.2.3)

(правильно формулируем текст подпункта - отвечаем на вопрос, каким требованиям должна удовлетворять численность персонала)

Численность персонала должна удовлетворять требованиям :

• быть достаточной для реализации автоматизированных () системы во всех режимах работы системы;

4.1.2.2 Требования к квалификации персонала

Квалификация персонала должна обеспечивать эффективное функционирование технических и системы во всех режимах работы системы»

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

4.1.2.3 Требования к режиму работы персонала

Режим работы персонала - трехсменный круглосуточный.

В подразделе предусмотрен также порядок подготовки персонала, контроля знаний и навыков. О составе - ни слова. И это правильно. Состав персонала, деление его на оперативный (), ремонтный и пр., определяется при проектировании системы. Хотя никто не может запретить добавить в техническое задание Требования к составу персонала. Пожалуй, не стоит.

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

Формализация при подготовке текста технического задания

Возможно Двести Вариантов

Один из двухсот вариантов расшифровки аббревиатуры «ВДВ»

Вернемся к примеру из предыдущего подраздела статьи.

4.1.2.1 Требования к численности персонала

Численность персонала должна удовлетворять требованиям:

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

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

Можно добавить - «численность персонала уточняется на «Технический проект»». Большой Босс будет поражен такой осведомленностью техписа (даже если и сам ни черта не знает) в части стадий и автоматизированных систем. А если устно предложить Боссу добавить (потом) в к проекту фразу - «на основе опыта более сотни ранее разработанных подобных систем численность персонала должна составлять 10 штатных единиц» - Босс будет сражен наповал. Можно смело готовить Приказ о назначении техписа на должность системного аналитика (которая также отсутствует в общероссийском классификаторе). Или ждать, что подкинут дополнительную работенку, раз такой умный.

Примечание от 17.04.2018 г. - В ОКПДТР должность технического пейсателя тоже отсутствует. А должность укладчика текста так и осталась с прежних времен

Штампы и унификация при подготовке текста технического задания

Вы, бабы, красивы,

А я - без прикрас

Но, все же, мужчины

Уходят от вас...

Ю. Рыбчинский, «Две сестры»

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

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

Наименование изделия - преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту - Изделие ).

И, в тексте - Изделие, Изделие, Изделие...

Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС - автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту - Система ).

И, в тексте - Система, Система, Система... Программа, Программа, Программа...

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

Примечание от 05 февраля 2010 г. - При автоматизированной разработке техдокументации с применением single source приемлем как вариант со всякими склонениями-спряжениями, так и без них. К примеру, можно единожды создать переменную <ЗАО «Заказчик»> и вставлять в требуемые топики библиотеки документов - так иногда бывает удобнее.

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

• назначение системы - система предназначена для решения перечисленных ниже задач:
  • задачи такой-то (первой);
  • задачи сякой-то (второй);
  • и так далее.
• цели создания системы - целями создания системы являются :
  • увеличение скорости...;
  • повышение точности...;
  • уменьшение издержек...;
  • снижение потребления...;
  • улучшение показателей...;
  • и так далее.

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

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

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

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

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

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

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

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

Итак, пример.

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

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

И из предыдущего подраздела:

• должны быть ...;
• должна удовлетворять требованиям ..

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

Перечни и нумерация разделов

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

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

Случай первый.

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

• автоматизированной функции добавления записей в таблицы базы данных;
• автоматизированной функции удаления записей из таблиц базы данных;

Случай второй.

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

1. автоматизированной функции добавления записей в таблицы базы данных;
2. автоматизированной функции удаления записей из таблиц базы данных;
3. автоматизированной функции сортировки записей в таблицах базы данных...;»

Отличия, казалось бы, невелики. Но!

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

Во втором случае, всего-навсего - «методика проверки выполнения п. 4.3.2.1(1) технического задания».

В, в первом случае - «требования технического задания к выполнению автоматизированной функции добавления записей в таблицы базы данных выполнены». Во втором случае - «требования п. 4.3.2.1(1) технического задания выполнены». Есть разница?

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

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

а) функция такая-то;

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

Чуть-чуть о. Если в ТЗ имеется подраздел «Метрологическое обеспечение...», то метрологическая экспертиза должна быть проведена по полной программе. Если указанный подраздел отсутствует, то метрологическая экспертиза сводится к проверке сокращений согласно ГОСТ 8.417. И только.

Связка «общие сведения, назначение и состав» в техническом задании

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

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

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

2.1 Назначение системы

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

Система должна обеспечивать решение (возможность решения) перечисленных ниже задач:

1. задачи сбора данных с каких-то, допустим, датчиков;
2. задачи обработки, хранения, отображения и пр. в центре сбора.

Вот и все. Немного фантазии, и раздел готов:

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

1. 1-й уровень - уровень сбора данных ;
2. 2-й уровень - уровень консолидации данных (централизованная обработка, хранение и пр.).

Снова оба зайца - и наповал. И уровни иерархии перечислены, и степень централизации. А что дальше?

2.1.1 Уровень сбора данных

2.1.1.1 Общие сведения

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

2.1.2.2 Назначение

Уровень сбора данных предназначен (еще один штамп):

1. для передачи данных каких-то датчиков уровню консолидации по запросу (инициативе) крайнего (последнего);
2. для протоколирования передачи данных в журнале событий (а если по ГОСТу, то в);
3. еще для чего-то.

2.1.2.3 Состав

В состав уровня сбора данных должны входить:

1. датчики такие-то;
2. датчики еще какие-то.

В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание - древовидное и иерархическое.

2.2.2.3.1 Датчики такие-то

2.2.2.3.1.1 Общие сведения (о таких-то датчиках)

2.2.2.3.1.2 Назначение (таких-то датчиков)

2.2.2.3.1.3 Состав (таких-то датчиков)

Главное - вовремя остановиться.

Предостережение

При разработке и наибольший интерес представляют перечисленные ниже:

• прежде всего - . Для таким является;
• , например и;
• , например;
• и, например;
• ряд других.

Не следует особенно увлекаться подобными «тематическими» ГОСТами, содержащими очень уж конкретные требования к. Характерная ошибка начинающих - «каналы связи должны удовлетворять требованиям ГОСТ такому-то». Это фатальная ошибка. Известно, что приемке-сдаче работ по созданию системы, изделия, программного изделия всегда предшествует проведение.

Допустим, Большой Босс, пораженный глубокими познаниями техписа, доверился оному, читать ничего не стал и черканул на титульном листе технического задания утверждающую (под УТВЕРЖДАЮ, в правом верхнем углу титульного листа). Заказчик, с гнусной ухмылкой, аккуратно поставил свою (под УТВЕРЖДАЮ, в левом верхнем углу). Все, техническое задание и внести в него или возможно только по дополнительному соглашению с заказчиком. Вот тут-то техпис и попал.

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

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

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

Короче, писать надо примерно так, русским по белому:

«В качестве каналов связи могут быть применены (использованы):

1. каналы связи -;
2. каналы операторов сотовой связи;
3. каналы операторов спутниковой связи;
4. коммутируемые телефонные линии общего пользования;
5. объекта заказчика;
6. и так далее»

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

Заключение

Итак, вспомним еще разок ключевые моменты:

1. подготовка технического задания импортом электронной версии требуемого ГОСТа;
2. детализация - дробление больших по объему разделов технического задания на короткие простые подразделы;
3. шаблонное построение предложений в разделах (подразделах и пр.) технического задания так, чтобы «в ответе оказывалась половина вопроса»;
4. формализация содержимого тех разделов, где невозможно (или) давать конкретику;
5. применение штампов;
6. применение перечней (маркированных или нумерованных списков);
7. применение связки «общие сведения, назначение и состав»;
8. минимальное применение «тематических» ГОСТов.

В заключении можно дать ряд дополнительных советов:

• отыскать «рыбу» технического задания и, после критического ее осмысления, позаимствовать содержимое подходящих разделов (только не с известного всем ресурса закупки.гов.ру - там лежит чушь полнейшая);
• пользоваться документами;
• без стеснения задавать вопросы.