Что такое техническое задание и как его составить – Как составить ТЗ: подробная инструкция по созданию технического задания | Дропшиппинг

Содержание

Как написать техническое задание: практические советы и рекомендации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПОДПИСАТЬСЯ НА НАШ YOUTUBE КАНАЛ

ПОДПИСАТЬСЯ НА НАШ VIULY КАНАЛ

Тут дают 10 токенов VIU за подтвержденую регистрацию

Вступить в закрытый Телеграм Чат

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

Рубрики:

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

Май 28, 2014 3:02 дп

Если Вам понравился опубликованный материал – поделитесь им с Вашими друзьями:

ЗАЧЕМ ВАМ НУЖНО ТЕХНИЧЕСКОЕ ЗАДАНИЕ?

Часто ли у Вас перед началом работы просят показать техническое задание или заполнить бриф?

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

Люди порой субъективны в вопросах подобным: “нравится –не нравится”, “красиво – не красиво”.

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

И этот способ – Техническое задание или бриф.

Что такое техническое задание (ТЗ)?

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

Какое позиционирование бренда?
Кто Ваша целевая аудитория?
Каковы конкурентные преимущества Вашего товара или услуги?

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

Для чего нужно техническое задание (ТЗ)?

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

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

Как ТЗ экономит Ваши время и деньги?

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

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

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

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

Какие пункты при составлении ТЗ являются ключевыми?

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

1) Указать вид и сферу деятельности компании. Для этого достаточно ответить на следующие вопросы:- в чем уникальность вашего бренда?- в чем преимущество перед конкурентами?- для какой аудитории предназначен ваш продукт?

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

3) Прислать примеры, которые нравятся или не нравятся Вам. Напишите, что именно Вас привлекает / не привлекает в них.

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

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

Как быть, если у Вас нет времени составлять ТЗ?

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

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

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

spark.ru

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

Техническое задание: что из себя представляет

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

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

При описании в документации о закупке заказчик должен руководствоваться следующими правилами, установленным 44-ФЗ:

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

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

Тендерный эксперт Олег Бируля расскажет, на что обратить внимание заказчику при составлении технического задания. Смотрите отрывок из вебинара «Правила составления технических заданий в рамках закона 44-ФЗ и требования к их содержанию».

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

Что запрещено включать в объект закупки

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

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

Указание ГОСТов и техрегламентов

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

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

Пример
1. В соответствии с СанПин 2.4.1.1249-03 площадь озеленения территории дошкольного образовательного учреждения должна составлять не менее 50%, заказчик может предусмотреть озеленение не менее 60% территории.

2. В восстановительные соки допускается добавление лимонной кислоты в дозировке не более 3 г/л (в соотв. с тех. регламентом). Заказчик может уточнить этот показатель, уменьшив ее содержание, например, до 2 г/л. Если заказчик ссылается на ГОСТ, который содержит в себе диапазонные значения, то лучше эти значения отдельно расписать, чтобы уже участник в своей заявке нам показал конкретное значение из этого диапазона ГОСТа.

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

В случае отсутствия ГОСТов, Технических регламентов товар, для которого существует функционирующий рынок заказчик может сформировать описание на основании данных производителей, качественных показателей, которые необходимы заказчику, данных поставщиков о характеристиках товара по причине отсутствия установленных ГОСТов, стандартов и технических регламентов для данного объекта закупки (Письмо Минэкономразвития России от 03.08.2016 № ОГ-Д28-9745).

В случае если ГОСТы являются устаревшими, то следует применять данный номер ГОСТа, но в действующей редакции (с иным индексом после номера)».

Характеристики ТРУ

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

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

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

Как через техническое задание заказчик может ограничить конкуренцию?

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

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

Что запрещено включать в один лот?

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

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

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

Курсы повышения квалификации в Школе электронных торгов — это профессиональная переподготовка для поставщиков и заказчиков по 44-ФЗ и 223-ФЗ. Онлайн, с экспертами.

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

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

Типичные нарушения заказчика при составлении технического задания

Нарушение 1: неясные формулировки, значения

Из описания объекта закупки должно быть однозначно понятно, что заказчик собирается закупить. Требования к показателям характеристик (min, max или точные значения) следует указывать недвусмысленно, предельно понятно и доступно. Согласно ч. 1 и ч. 2 ст. 33 документация должна содержать требования, которые позволяют установить подходят ли предлагаемые товары, (работы или услуги) заказчику. Не следует использовать термины наподобие «не хуже», «не слабее» и тому подобные, это не объективное описание. Что для заказчика лучше, а что хуже, поставщик не обязан знать или угадывать.

Характеристики объекта закупки, например, могут выглядеть так:

«Требования к товару. Товар (далее — мебель) должен соответствовать ГОСТ 16371-2014 «Мебель. Общие технические условия» (введен в действие Приказом Росстандарта от 15.06.2015 № 683-ст), ГОСТ 26800.1-86 «Мебель для административных помещений. Функциональные размеры столов». Наименование товара — стол эргономичный. Размер, Ш x Г x В (ширина, глубина, высота): — минимальные значения — 100 x 100 x 71,5 см; — максимальные значения — 165 x 110 x 71,5 см. При этом высота не подлежит изменению. Цвет: коричневый. Требования к столешнице: Материал — высококачественная МДФ, толщина: минимальное значение — 12 мм, максимальное значение — 35 мм. Облицовка — ПВХ-пленка. Столешница должна быть эргономичной и иметь плавные края. В столешнице должно быть предусмотрено отверстие для проводов с заглушкой.»

Бывает, что заказчики ошибаются при указании требований диапазонными значениями. Например, «ширина более 360 мм и менее 214 мм». Иногда при описании объекта закупки не учитываются собственные инструкции по подготовке заявок: «В случае, если присутствует слово «диапазон», «в пределах», то поставщику необходимо предоставить диапазон значений ниже установленного заказчиком». Каким образом это понимать в случае температурного диапазона непонятно.

Достаточно часто заказчики переписывают с государственных стандартов все подряд характеристики, при этом товар не может обладать всеми требуемыми характеристиками одновременно. Например, что касается подвижности и жесткости бетона ГОСТ 7473-2010. Бетон может быть либо жестким (Ж), либо подвижным (П). Это взаимоисключающие характеристики. Однако, заказчики умудряются вписать в техзадание и то и другое: жесткость Ж1-Ж4; подвижность П1-П4. Материала с такими характеристиками не может быть. И это является нарушением ч. 2 ст. 33 44-ФЗ.

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

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

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

Нарушение 2: ссылка на ГОСТ без какого-либо описания

Ещё одно распространённое нарушение — это перечисление в техническом задании ГОСТ, без привязки к конкретным товарам. Позиция ФАС в этой ситуации такова, что подобное описание объекта закупки не позволяет идентифицировать каждый товар, и не позволяет потенциальному поставщику подготовить заявку должным образом. 

Нарушение 3: отсутствие фразы «или эквивалент»

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

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

Ещё несколько рекомендаций при составлении техзадания по 44-ФЗ

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

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

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

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

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

 Какие ещё требования важно указать в техзадании:

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

Главные правила

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

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

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

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

Вопрос: Нужно приобрести прибор для научных исследований к уже имеющейся системе из 3-х приборов одного производителя. Необходимо полное совмещение всего в работе. Эквивалент не желателен. Можно не писать эквивалент и указать производителя? Система тонко настраиваемая и дорогая.
Ответ: Если Ваш случай подходит под «…за исключением случаев несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком…) – можно, в других случаях — нельзя.

Вопрос: Можно ли в техзадании по капремонту указать узкие показатели, например, цвет стен с конкретным колером, приложить пример композиции из гипсокартона на потолке, конкретную коллекцию плитку без эквивалента, ссылаясь на эстетические предпочтения?
Ответ: При формировании технического задания заказчики должны руководствоваться требованиями статьи 33 Закона № 44-ФЗ. Цвет стен — это выбор заказчика, это его потребность, не ограничивающая число поставщиков. Макет, эскиз композиции из гипсокартона на потолке — это также потребность заказчика, все исполнители смогут повторить приведённый в документации макет. Коллекция плитки без эквивалента — это нарушение пункта 1 статьи 33 Закона № 44-ФЗ: «Документация о закупке может содержать указание на товарные знаки в случае, если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент».

school.kontur.ru

Образец формы технического задания по 44-ФЗ в 2019 году

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

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

Основные требования к техническому заданию

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

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

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

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

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

Организации-заказчику запрещается предъявлять к ТРУ и информации о них такие требования, которые приводят к ограничению количества участников торгов, за исключением тех ситуаций, когда не имеется другого способа, обеспечивающего более точное и четкое описание характеристик ОЗ (п. 1 ч. 1 ст. 33 44-ФЗ).

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

При отсутствии ГОСТов и регламентов на товары, работы, услуги, для которых существует функционирующий рынок, заказчик вправе разработать описание на основании сведений производителей и иных качественных показателей, которые необходимы для конкретного предмета заказа (Письмо Минэкономразвития России № ОГ-Д28-9745 от 03.08.2016).

В том случае, если ГОСТ необязательный, но он указан в ТЗ тендера, он становится обязательным для обеих сторон контракта.

Далее представим образец формы технического задания по 44-ФЗ.

Скачать

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

Нормативными источниками для формирования ТЗ могут выступать:

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

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

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

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

Сведения об организации-заказчике. Его юридический и фактический адрес, координаты для связи, банковские реквизиты и коды по Общероссийскому классификатору.
Сведения о заказе. В техническом задании надлежит указать полное наименование предмета торгов с указанием всех используемых терминов, способ проводимой закупки (ч. 1 ст. 24 44-ФЗ), обоснование способа определения поставщика (ч. 5 ст. 24), источник финансирования.
Описание ОЗ.
Требования к упаковке товара и безопасности объекта заказа.
Сроки поставки ТРУ.
Гарантийный срок.
Условия по сервисному обслуживанию, монтажу, пусконаладочным работам, обучению сотрудников грамотной эксплуатации поставляемой продукции (при необходимости).

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

На первом, подготовительном, этапе необходимо определить потребность в приобретаемых ТРУ, рассчитать и обосновать НМЦК, описать предмет заказа.

Второй этап — основной. Во время данного этапа организация-заказчик детерминирует основные качественные и количественные характеристики ТРУ, оговаривает условия и регламент поставки продукции, а также параметры заполнения первых частей заявок, проверяет заполненные параграфы ТЗ.

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

Кто должен составлять Техническое задание? / Sandbox / Habr

До вчерашнего вечера я был точно уверен, что Техническое задание на разработку сайта пишет исполнитель. С одной стороны это правильно, ведь все, что заказчик знает — это то, что ему нужен сайт. Какой сайт, как он будет выглядеть, как будет работать — ответы на данные и миллион подобных вопросов исполнитель пытается вытянуть из заказчика по средствам брифа.
Стандартная схема при таком подходе выглядит так:
1) заказчик говорит, что хочет сайт, примерно обрисовывает суть, задачи ресурса;
2) исполнитель дает заказчику бриф с большим количеством конкретных вопросов, которые помогают лучше понять суть задачи и составить Техническое задание;
3) исполнитель составляет ТЗ в соответствии с брифом, согласовывает с заказчиком;
4) в соответствии с ТЗ исполнитель разрабатывает сайт.

Логично

Совершенно логичная схема с одной стороны. Заказчику не приходится задумываться о глобальных вопросах мироздания, он сваливает все задачи на исполнителя.
Будучи на стороне исполнителя я даже не думал усомниться в верности отработанной схемы, пока не встретился со своим старым другом и не поговорил с ним по душам за кружкой пива.
Слово за слово, разговор зашел о технических заданиях и о том, кто должен их составлять. По мнению друга, ТЗ составляется третье стороной, которая не заинтересована в выигрыше ни заказчика, ни исполнителя, но, при этом, компетентна в вопросах обоих сторон. Все мои аргументы привели в тупик. Я начал сомневаться в верности схемы, и вот почему:
1) исполнитель берет деньги за составление ТЗ;
2) исполнитель ставит задачу таким образом, как ему будет проще и выгоднее;
3) исполнитель старается прикрыть каждый кусочек своей попы, исписать десятки листов бумаги, взять за это большую сумму денег и в дальнейшем прикрываться данной бумажкой.

Все сводится к тому, что исполнитель составляет ТЗ исключительно в своих интересах, при этом умудряясь навязать заказчику свою точку зрения.

Так ли это плохо?

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

Исполнитель — сторона, непосредственно заинтересованная в выполнении задачи с меньшими трудозатратами за большие деньги. Интересы исполнителя, в большинстве случаев, прямо противоположны интересам заказчика. Исполнитель знает и на чем можно сэкономить, как выполнить работу более оптимально.
Аналогичная ситуация с домом, только теперь исполнитель составляет ТЗ. В итоге получаем подробнейший документ на 50 листах, в деталях описывающий весь процесс разработки дома. Казалось бы — ребята профи, так все четко и понятно расписали. Я, не думая, читаю, вроде все понятно — и окна прямоугольные, и стены толстые с утеплителем, и полы с гидроизоляцией, и джакузи, и душевая кабина — “Зачем она мне? Ладно, пусть будет, круто же”. В результате, дом выглядит потрясающе, все четко, профессионально, качественно.
Я счастлив. Ровно до тех пор, пока не приходит друг, разбирающийся в строительстве. И тут я понимаю, что оказался полнейшим лохом: “Сколько ты за это отдал? Да ладно!!! У меня на складе аналогичная в пять раз дешевле. А это тебе зачем? Ты же никогда этим не занимался! А это уже давно устарело, есть более лучшие и современные образцы.”
Кто виноват в данном случае? Ребята молодцы, все сделали четко, правильно, профессионально, я сам на это подписался, значит я виноват? Но я то откуда знать мог?

Может стоило позвать друга до начала стройки?

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

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

Возможно ли это?

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

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

habr.com

Как правильно написать ТЗ на систему или доработку системы 1С / Habr

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

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

Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.

Итак, приступим.

Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:

Формы ввода информации

Контрольные процедуры

Модель данных

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

Формы вывода информации

Давайте отдельно рассмотрим каждую категорию.

Формы ввода информации

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

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

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

Контрольные процедуры

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

В эту категорию попадают:

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

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

Модель данных

Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.

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

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

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

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

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

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

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

Формы вывода информации

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

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

Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.

***

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

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

P.S. Ну разве что у Вас работает не настоящий программист 1С. Может он лучше пишет на python?