Инструкция о том, как написать ТЗ

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

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

Что такое техническое задание?

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

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

Зачем нужно ТЗ

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

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

Каким должно быть ТЗ

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

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

  • Нужно написать небольшой текст на тему «Душевые кабины». Текст должен быть для людей. Без переспама.

А кто-то описывает все в деталях и структурирует каждый аспект:

  • Нужно написать текст на тему «Душевые кабины» объемом 3500 знаков. Уровень спама – до 55%, уровень воды не более 18%, уникальность – от 90%. Слово «душевые» использовать не более 15 раз. Избегать стоп-слов (и, или, но, а).

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

Технические характеристики

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

В случае с текстами сюда можно отнести:

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

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

  • выбор системы управления данными (WordPress, Joomla и т.п.),
  • выбор фреймворков (React, Angular и т.п.),
  • количество всплывающих окон,
  • ширину контентной части страницы,
  • расположение форм обратной связи в приложении,
  • дополнительные функции.

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

Маркетинговые характеристики

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

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

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

Заказчик рассказывает о целевой аудитории и ее особенностях. Задача исполнителя – воспользоваться этой информацией и сделать итоговый проект/текст наиболее привлекательным для указанной ЦА.

Этапы работы

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

  1. Этап разработки идей и дополнение существующего плана действий.
  2. Демонстрация первого прототипа.
  3. Приемка первой тестовой версии продукта.
  4. Тестирование функциональности.
  5. Разработки дизайна.
  6. А/Б-тестирование визуальных компонентов и CTA-элементов.

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

Другие аспекты

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

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

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

Срок выполнения работы тоже приписывается заранее, как и общий бюджет проекта. 

Примеры ТЗ

Рассмотрим два абстрактных примера технического задания в том виде, в котором они часто встречаются.

Для разработчиков

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

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

Текст ТЗ может содержать более конкретную информацию об имеющихся функциях:

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

Также в ТЗ можно внести требования к дизайну и оформлению кода:

  • Цвет подзаголовков берем из макета (#CD6326).
  • Списки должны быть оформлены в формате ul > li > a.
  • Блочные структуры должны быть реализованы с помощью свойства селекторов flex.

Отдельно можно указать технические средства, используемые в работе:

  • Работа должна быть доступна в репозитории my-new-project.
  • Каждое изменение должно сопровождаться отдельным коммитом.
  • В качестве базы данных используется технология MongoDB.

Для копирайтеров

Текст на тему «Стоит ли использовать WordPress в 2020 году?».

Общие требования к тексту:

  1. Статья должна быть поделена на части. Каждый подзаголовок отделяет один логический блок.
  2. В тексте необходимо использовать одну таблицу и минимум один список.
  3. Между списками, таблицами, цитатами и подзаголовками должно быть расстояние минимум в 400 знаков.
  4. В тексте должны быть подзаголовки второго уровня, минимальный промежуток между подзаголовками – 750 символов, максимальный – 900 символов.
  5. Ключевые фразы должны быть использованы столько раз, сколько указано в скобках рядом со словом.
  6. Ключевые фразы должны быть равномерно распределены по тексту. Расстояние между ключевыми фразами не менее 1000 знаков. Первое ключевое слово должно использоваться в первом абзаце.

Объем текста: от 10 000 знаков.

Примерная структура текста:

  1. Что такое WordPress.
  2. Основные преимущества WordPress.
  3. Сравнение WordPress с другими CMS.

Ключевые фразы:

  • WordPress (8)
  • Темы для ВордПресс (1)
  • CMS WordPress (2)
  • Для разработчиков (1)
  • Для новичков (2)
  • Как установить на сайт WordPress (1)
  • Joomla (2)
  • Drupal (1)
Читайте также:  Что нужно для привлечения внимания в рекламе?

Вместо заключения

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

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

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

Что такое техническое задание

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

Это не ТЗ, а поручение Сходи, купи хлеба
Вот это ТЗ Мне нужен хлеб:

  • Купи его до 19:00 сегодня.
  • Мне нужен хлеб из пекарни около дома.
  • Хлеб должен быть весом от 200 до 300 г.
  • Он должен быть либо из ржаной, либо из гречневой муки.

Другой хлеб мне не нужен.

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

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

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

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

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

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

Устоявшейся практики нет — как договоритесь с подрядчиком.

Заказчик делает сам

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

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

Совместная работа

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

Техзадание полностью делает исполнитель

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

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

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

Универсального решения нет, но лучше доверять составление ТЗ представителю подрядчика — специалист лучше знает, как должен работать его проект.

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

Сколько стоит заказать ТЗ

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

Основатель компании по разработке информационных систем Work Solutions Максим Мул при заказе ТЗ рекомендует ориентироваться на 10-20 % от общей стоимости разработки продукта.

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

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

Если речь про IT-задачи, например, интеграцию между информационными системами, внедрение CRM, разработку дополнительного функционала ПО или приложения по API, то не стоит рассчитывать на ТЗ стоимостью меньше 50 000 руб., считает гендиректор компании «Информатика и Сервис» Владимир Севрук.

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

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

Платные подробные ТЗ применяют и в других сферах. Например, в архитектурной фотографии. У нас есть более сложная форма ТЗ — мы называем ее «сценарий». Для сценария мы проводим предварительные съемки, прописываем и согласовываем все ракурсы с заказчиком, прорабатываем целевую аудиторию и рассчитываем тайминг каждого кадра с учетом движения солнца. И все это ещё до начала чистовой работы.

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

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

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

Пишите однозначно

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

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

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

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

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

Дайте подрядчику общую информацию

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

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

Расскажите подрядчику, какие задачи будет решать IT-решение. Это может быть увеличение прибыли, повышение узнаваемости бренда, лояльности пользователей. Уточните, кто будет пользователями продукта, их социальные и поведенческие характеристики, например, пол, возраст, интересы, семейное положение, потребности — это нужно, чтобы корректно и эффективно сформулировать функциональные требования к продукту.

Помогите разобраться в терминах и нюансах

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

Покажите конкурентов

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

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

Уточните важные технические требования

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

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

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

Распишите сценарии использования продукта

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

  • Плохо — «Требование 1. На сайте есть корзина, пользователь по дополнительному запросу может получить список дополнительных товаров». В этом случае непонятно, что и как должно работать.
  • Хорошо — «Когда пользователь заходит в корзину, сайт показывает ему всплывающий баннер. На этом баннере должны быть товары, которые могут пригодиться покупателю. Он может одним кликом добавить любой товар к заказу. Или закрыть окно». В этом случае понятно, как работает сценарий использования корзины и блока с кросс-товарами.

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

  • действие пользователя;
  • ответ сайта;
  • если пользователь делает так, то сайт делает так;
  • если пользователь делает по-другому, то сайт отвечает так.

Опишите требования к проверке проекта

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

Например, для интернет-магазина это может быть:

  • Буду проверять корректное отображение в браузерах Chrome, Firefox, Mozilla трех последних версий.
  • Отображение на экранах мобильника с разрешением 320 px на 480 px, монитора с разрешением 1024 px на 802 px, большого монитора с разрешением…
  • Скорость разгрузки по сервису такому-то не больше 1 секунды.

Чем подробнее и длиннее чек-лист, тем лучше.

Двигайтесь от общего к частному

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

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

Шаблоны и примеры ТЗ

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

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

Если планируете заказать IT-продукт, можно использовать за основу госстандарты. Например:

  • ГОСТ 34. Это еще советская разработка сбора требований для создания автоматизированных систем. Не готовый шаблон, но много вопросов к заказчику, которые помогут структурировать пожелания.
  • IEEE 29148-2011 — стандарт разработки сложных систем, в которых есть вопросы о требовании к функциям, а также рекомендация описать условия программного окружения, то есть платформ, которые будут работать вместе с вашим продуктом.
  • Rational Unified Process — продвинутая спецификация для разработки требований к IT-продуктам. Много внимания отводится вариантам использования.

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

Когда ТЗ не нужно

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

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

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

Вместо ТЗ выгоднее сначала сделать предпроектное обследование, изучить реальные потребности клиентов, вместе с аналитиком подрядчика. А затем решать, нужно ли ТЗ вообще. Может быть, выгоднее и эффективнее выполнять бизнес-задачу. Действуя небольшими итерациями в 1-2 недели, анализируя результат и постепенно дополняя требования.

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

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

Техническое задание: нюансы и советы

Чтобы в результате закупки получить именно то, что необходимо, заказчики составляют техническое задание (ТЗ). Однако порой перед ними стоит нелегкая задача: подробно составить описание объекта закупки, при этом не нарушив антимонопольного законодательства.

Сложности составления ТЗ

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

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

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

Распространенные нарушения при составлении ТЗ

Использование неточных формулировок

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

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

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

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

Нарушения, связанные с ГОСТами

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

Нередко заказчики просто перечисляют в ТЗ номера ГОСТов, при этом не указывая, к каким объектам они относятся. ФАС считает, что это мешает поставщику составить заявку правильно, ведь подобное описание не позволяет идентифицировать товар.

Отсутствие упоминания об эквиваленте

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

Советы специалистов

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

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

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

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

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

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

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

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

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

О чем еще не следует забывать:

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

Имеем ли мы право в ТЗ на закупку запчастей указать, что они должны быть оригинальными?

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

Нужно ли в техническом задании указывать идентификационный код закупки?

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

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

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

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

Ссылка на основную публикацию