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

Содержание

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


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

Чего не следует допускать при разработке ТЗ?

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

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


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

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

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

Как избежать ошибок при составлении ТЗ: маленькие хитрости

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

Руководствоваться нужно следующими правилами:

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


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

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

Составление грамотного ТЗ подразумевает полное погружение в тему, знание всех её аспектов и тонкостей. Техническое задание – в первую очередь ряд требований. Оно должно давать ответ на конкретный вопрос: какие задачи должно решать изделие? Детали проекты продумываются для мелочей. Формулируются все требования подробно, но без воды, лишней информации. Это сведет к минимуму вероятность ошибок, неточностей.

Наши преимущества

Большой накопленный опыт

Профессиональное и быстрое оформление технической документации по стандартам.

Проекты любой сложности

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

Ответственный подход к работе

Ценим время и деньги клиента, выполняем взятые обязательства.

Полный цикл разработки документации

Изделие возможно изготовить на любом современном производстве.

Наши клиенты

Ошибки составления ТЗ

Как правильно составить техническое задание копирайтеру

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

  • Автор прислал совсем не такой текст, как ожидалось.
  • Нет ключей.
  • Статья переспамлена.
  • Ключевые фразы не так вставлены.

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

Типовые ошибки заказчиков при формировании технических заданий

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

Наиболее частые ошибки ТЗ

Спамность

Пример задания: требуется в 2000 символов вместить 14 раз ключи со словом «экзема». Это явный переспам, за который будет ответственен копирайтер.

Срочность

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

Мало вводных данных

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

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

Правильный пример, когда составитель ТЗ к основному заданию прикладывает дополнительное, в котором даёт ссылки на статьи, ему нравящиеся.

Самые распространённые типовые ошибки заказчиков при формировании технических заданий

Многословность и путаность

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

Зачем несколько раз писать об одном и том же? Например, указывать уникальность и объём, если они в обязательном порядке проставляются в специальных полях?

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

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

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

Шаблонность

Забавное ТЗ, составленное по шаблону, где перечислены пункты, не имеющие отношение к конкретному заказу.

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

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

По мнению заказчиков, авторы не знают:

  • Что текст пишется для людей.
  • Состоит из небольших абзацев.
  • В нём желательны подзаголовки и списки.

Если автор не проверит текст на уникальность и не подгонит её под нужные параметры, указанные заказчиком, статья автоматически будет отклонена во время сдачи. Для чего писать: «Проверка уникальности обязательна»? А вот сервис для проверки вполне логично указать.

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

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

Совет для «Я». Формулируйте задание ясно и предельно лаконично. Если исполнителю потребуется что-то уточнить, ответьте на его вопросы. Не стоит из одного ТЗ в другое переносить ненужные простыни текста, написанного практически не осмысленно. Тогда вместо 2-3 заявок сотни хороших авторов, которым лень читать бредовые ТЗ, изъявят желание написать статью. Будет из кого выбирать.

Читайте статьи для заказчиков на проекте «Работа копирайтером»:

 

6 типичных ошибок при заключении договоров на разработку ПО / Habr

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

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

Предыстория


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

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

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

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

Выявленные ошибки


Первая ошибка – обтекаемо сформулирован предмет договора. Но был сформулирован следующим образом «…Заказчик поручает, а Исполнитель принимает на себя обязательства по поставке и внедрению программного обеспечения 1С: Предприятие 8 согласно Приложения №2…». Приложение 2 содержало мало конкретики, по форме это была спецификация с указанием видов работ и трудозатрат по ним. Каждая из сторон по-своему трактовала предмет договора. Компания исполнитель понимала под этим доработку стандартной конфигурации 1С: Предприятие под задачи заказчика, ее настройку и внедрение. Заказчик видел то, что будет произведена установка и настройка 1С: Предприятие без какой-либо ее модификации. Он исходил из буквального значения слов и выражений зафиксированных в договоре, такой же точки зрения придерживался суд, игнорируя факт создания составного программного продукта в рамках выполнения обязательств по договору.

Немного судебной практики:

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

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


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

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

Четвертая ошибка – исполнитель согласился на требования заказчика внести ряд условий в договор явно не выгодных для себя, но поскольку сроки поджимали и представители заказчика не хотели договариваться по условиям договора руководство ИТ компании приняло решение пойти по пути наименьшего сопротивления. Напомню, это был конец 2014 г., санкции, отсутствие других заказов и т.д, картина типичная для многих небольших ИТ компаний, которые хватаются за любую работу и руководствуются принципом «главное начать, а там просмотрим». Условия договора были сформулированы таким образом, что за каждый день просрочки выполнения работ исполнитель должен был выплатить крупную неустойку. Через некоторое время размер неустойки вырос до такого уровня, что рентабельность проекта стала практически нулевой и неуклонно стремилась стать минусовой. Этому способствовала слабая организация работ внутри проекта, и неспособность оперативно справиться с возникшими проблемами проекта из-за нехватки ресурсов, которые были рассчитаны исходя из прогнозируемого по условиям договора объема работ, и не были рассчитаны на его увеличение. С учетом кабальных условий приходилось идти на компромисс с заказчиком и выполнять все его пожелания. Также ситуация усугубилась за счет того, что для продолжения проекта требовалось внешнее финансирование, привлечение которого было сильно затруднено.

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

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

Немного судебной практики:

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

Постановление Федерального арбитражного суда Московского округа от 17 мая 2013г. по делу N А40-102005/12-57-977 отказывая истцу в удовлетворении его требований, суд указал на:

• предусмотренную договором простую письменную форму документооборота между сторонами;
• отсутствие условий о возможности исполнения договора по электронной переписке;
• отсутствие ссылок на электронные адреса, определяемые сторонами в качестве допустимых для передачи какой-либо информации;
• невозможность установить принадлежность адреса ответчику и его сотрудникам;
• адрес электронной почты зарегистрирован на домене kameya.ru, который является доступным для использования неограниченным кругом лиц.
Постановлением ФАС дальневосточного округа от16.11.12 №Ф03-5177/2012 был отклонен довод Истца о передаче спорных претензий ответчику по электронной почте. Причинами такого вывода суда послужили как не предоставление доказательств согласования сторонами использования электронных документов в претензионном порядке по спорному договору так и тот факт, что передача претензий по электронной почте не свидетельствует об их получения истцом.

В заключении


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

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

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

Хитрости госзаказчика: техническое задание | zakupkihelp.ru

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

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

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

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

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

Как поступить если Вы столкнулись с данной проблемой?

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

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

Еще запомните один очень важный момент — никогда не звоните заказчику по телефону, отправляйте официальный письменный запрос, на который заказчик ОБЯЗАН ответить в установленный срок.

Если представленные заказчиком ответы на Ваш запрос не прояснили ситуацию или заказчик отказывается дать развернутый ответ, то можно обратиться с жалобой в территориальное Управление Федеральной Антимонопольной Службы РФ (УФАС РФ) на соответствующие нарушения требований 94-ФЗ. В качестве подтверждения своих доводов можно приложить официальные ответы заказчика.

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

На этом все. Желаю Вам удачи и новых побед!

хитрости госзаказчика

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

 

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

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

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

 

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

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

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

 

Терминология техзадания

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

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

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

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

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

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

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

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

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

 

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

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

 

Сведения о закупке

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

 

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

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

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

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

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

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

 

Как оформить тз и донести суть исполнителю — Netpeak Blog

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

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

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

Каждая задача — решение вопроса

Не знаете, какую проблему решаете — техзадание будет наполнено противоречивой информацией.

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

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

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

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

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

Разработка смысловых блоков

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

Например, SEO-специалисту часто приходится писать техническое задание для формирования фильтров интернет-магазинов. Это сложно: нужно создать страницы с контентом и UTM-метками, учесть, как эти страницы будут оптимизированы.

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

1. Вводная часть.
Общее описание и оглавление. Что нужно будет сделать.

2. Внешний вид фильтров.
Как фильтры должны выглядеть в дизайне сайта.

3. Требования к страницам.
3.1. Подробное описание принципов формирования URL.
3.2. Требования к страницам фильтров.
В частности, следует написать о предоставлении возможности редактирования тегов, метатегов, публикации текстов и внедрении атрибута canonical.

4. Формирование метатегов.
Детальное описание алгоритма, по которому нужно формировать метатеги с учетом последовательности выбора фильтров.

5. Рекомендации по размещению текстов на страницах фильтров.

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

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

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

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

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

В тексте не должно быть вводных слов, метафор и отступлений от темы. Всё четко и по делу.



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

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

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

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

Ранее мы уже рассказали, как сделать красивый скриншот.

Для проектирования примеров интерфейсов можно использовать сервис Moqups.

Вставляйте скриншоты и макеты в техзадание в виде картинок, а не ссылок на картинки.

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

Выводы

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

Как только вы составили техзадание, обязательно спросите себя: «Всё ли в нём будет понятно исполнителю?». Наконец, попросите исполнителя прочитать техзадание и поинтересуйтесь, все ли ему понятно.

Если у вас есть идеи и дополнения, жду в комментариях.

Добавить комментарий

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