Пример тз форма оплаты. Как подготовить техническое задание на выполнение работ

Настройки

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

1. Назначение
2. Область действия
3. Определения, акронимы и сокращения
4. Ссылки
5. Краткий обзор

2. Общее описание

1. Взаимодействие продукта (с другими продуктами и компонентами)
2. Функции продукта (краткое описание)
3. Характеристики пользователя
4. Ограничения
5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
2. Функциональные требования
3. Требования к производительности
4. Проектные ограничения (и ссылки на стандарты)
5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
6. Другие требования

4. Приложения
5. Алфавитный указатель

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

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

Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
(читать вместе с комментариями)
Примеры ТЗ и другой документации по разработке АС для МЭР
ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
Шаблоны документов для бизнес-аналитиков из

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

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

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

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

разработке приложений;
проектировании дома;
написании текстов и другие.

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

Как составить техническое задание: структура ТЗ на сайт

Прежде чем приступать к работе:

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

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

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

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

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

Опишите сайт

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

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

Расскажите о структуре

Без представления о структуре невозможно разработать нормальный сайт. Распишите, какие страницы будут на сайте, и покажите уровни их вложенности. Сделать это можно разными способами:

Схемой
Таблицей
Списком

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

Пример простейшей структуры в виде блок-схемы

Опишите, что будет на каждой из страниц

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

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

Пример прототипа главной страницы сайта: все просто, удобно, понятно

Выдвините требования к дизайну

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

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

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

Опишите требования к инструментам, коду, хостингу, домену

Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими - нет. Опишите отдельным блоком:

На какой должен находиться сайт - Вордпресс, Джумла, Модэкс и так далее
Какой язык программирования можно использовать - PHP, JavaScript, HTML, другие
На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
Какую программную платформу можно использовать - .NET, OpenGL, DirectX
И так далее

Если клиент не понимает ничего в используемых терминах - объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне.ru от домена в зоне.com. Вместе составьте требования так, чтобы они устроили клиента.

Уточните требования к работе сайта

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

Приемлемую для вас скорость загрузки сайтов или стандартное значение - 1–5 секунд
Кроссбраузерность - распишите, в каких браузерах сайт должен открываться
Адаптивность - укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
Устойчивость к нагрузкам - сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки

Распишите сценарии работы сайта

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

Пример простейшего сценария работы сайта

Уточните, кто занимается контентом.

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

- не меньше 95% по Адвего, Текст.ру, Контент.Вотч
Тошноте (заспамленности)- не более 10% по Адвего иди 65% по Текст.ру
Баллам по Главреду - не менее 6,5 или 7 баллов

Конечно, разные сервисы - не панацея, но они минимизируют риск того, что он будет «водянистым» или переспамленным. Кроме того, так появляются точные критерии оценки качества текстов.

Укажите сроки

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

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

Запомните: в каждом ТЗ должны быть несколько основных блоков:

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

Пример составления ТЗ на программное обеспечение

Нужно создать ПО. Технические требования - ниже.

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

Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:

Линк
Название статьи
Лид-абзац

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

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

Сроки : до 15.09.2018.

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

ШАБЛОН ТЕХНИЧЕСКОГО ЗАДАНИЯ на примере отдела сервисное обслуживание

ООО «Компания-разработчик»

УТВЕРЖДАЮ

Автоматизированная система «Сервисное обслуживание»

наименование вида АС

Отдел Сервисного обслуживания ЗАО «Солнечные окна»

наименование объекта автоматизации

«Сервис»

сокращенное наименование АС

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

На 16 листах

Действует с 01.06.2009

СОГЛАСОВАНО

Руководитель: начальник отдела АС

ООО «Компания-разработчик»

Личная подпись

Расшифровка подписи

1. Общие сведения 3

1.1. Полное наименование системы и ее условное обозначение: 3

1.2. Шифр темы или шифр (номер) договора: 3

1.3. Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты: 3

1.4. Перечень документов, на основании которых создается система, кем и когда утверждены эти документы: 3

1.5. Плановые сроки начала и окончания работы по созданию системы: 3

1.6. Сведения об источниках и порядке финансирования работ: 3

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

2. Назначение и цели создания АС 3

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

2.2. Цели создания системы 4

2.2.1. Бизнес-цели: 4

2.2.2. Критерии успеха: 4

2.2.3. Факторы бизнес-риска: 4

3. Характеристика объектов автоматизации 4

3.1. Краткие сведения об объекте автоматизации 4

3.2. Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды 5

4. Требования к системе 5

4.1. Требования к системе в целом 5

4.1.1. Требования к структуре и функционированию системы 5

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

4.1.3. Требования к надежности 6

4.1.4. Требования безопасности 6

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

4.1.6. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы 7

4.2. Требования к функциям (задачам), выполняемым системой 7

4.2.1. Языковая поддержка 7

4.2.2. Требования пользователей к системе 7

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

4.3.1. Информационное обеспечение 9

4.3.2. Лингвистическое обеспечение 9

4.3.3. Программное обеспечение 9

4.3.4. Техническое обеспечение 9

5. Состав и содержание работ по созданию системы 10

6. Порядок контроля и приемки системы 10

6.1. Виды, состав, объем и методы испытаний системы и ее составных частей (виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему) 10

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

7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие 11

7.1. Технические мероприятия 11

7.2. Организационные мероприятия 12

8. Требования к документированию 12

9. Источники разработки 13

Лист согласований 13

1. Общие сведения

1.1. Полное наименование системы и ее условное обозначение:

Автоматизированная система «Сервисное обслуживание», «Сервис».

1.2. Шифр темы или шифр (номер) договора:

(номер договора заказчика и разработчика).

1.3. Наименование предприятий (объединений) разработчика и заказчика (пользователя) системы и их реквизиты:

ООО «Компания разработчик»: (реквизиты) – далее Исполнитель.

Банк: (реквизиты).

1.4. Перечень документов, на основании которых создается система, кем и когда утверждены эти документы:

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

1.5. Плановые сроки начала и окончания работы по созданию системы:

(по плану-графику)

1.6. Сведения об источниках и порядке финансирования работ:

Согласно договору на разработку АС

Работы по созданию АС производятся и принимаются поэтапно.

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

2. Назначение и цели создания АС

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

АС предназначена для работы сотрудников отдела «Сервисного обслуживания» компании ЗАО «Солнечные окна».

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

2.2. Цели создания системы

2.2.1. Бизнес-цели:

Бизнес-цель 1. Уменьшить среднее время обработки заявки от клиента менеджера отдела сервисного обслуживания до 10 минут после ввода в действие новой АС.

Бизнес-цель 2. Уменьшить сроки выполнения гарантийных/не гарантийных услуг до 3-5 дней в течение 3 месяцев после ввода в действие новой АС.

Бизнес-цель 3. Увеличить прибыль организации на 30% в течение 12 месяцев после ввода в действие новой АС.

2.2.2. Критерии успеха:

Критерий успеха 1. Все сотрудники отдела сервисного обслуживания в течение 2 месяцев после ввода в действие системы должны перейти на работу с новой АС.

Критерий успеха 2. Увеличение числа дополнительных услуг на 50% в течение 6 месяцев после ввода в действие новой АС.

2.2.3. Факторы бизнес-риска:

Фактор бизнес - риска 1. Не все сотрудники отдела «Сервисное обслуживание» готовы перейти к работе с новой АС. Потребуется переобучение персонала.

Фактор бизнес - риска 2. Возможна реструктуризация отдела «Сервисное обслуживание», изменение функций сотрудников и сокращение штата сотрудников.

3. Характеристика объектов автоматизации

3.1. Краткие сведения об объекте автоматизации

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

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

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

Менеджер отдела планирует выезд бригад на объект (составляет маршрутный план на определенную дату – около 1 часа), заполняет «Дефектную ведомость» - 20-30 минут и передает ее технологу отдела.

Технолог согласно «Дефектной ведомости» формирует расходную накладную.

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

Бизнес-процессы работы отдела представим с помощью диаграмм IDEF0 (рис. 1).

Рис. 1 – Деятельность отдела «Сервисное обслуживание»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Техзадание должно быть тесно взаимосвязано с инструкцией по заполнению заявки.
Все термины, которые включены в техническое задание, должны быть упорядочены, а инструкция по составлению заявок должна легко читаться и адекватно восприниматься потенциальным поставщиком. При этом судебная практика расценивает заявки, затрудняющие восприятие и не содержащие соответствие объекта закупки и инструкции по формированию заявок, как ограничивающие конкуренцию.
Специалисту надлежит указывать, когда значение диапазонного показателя не должно изменяться. Диапазонные показатели должны быть максимально приближены к реальности. Заказчик может определить диапазонный показатель как набор из минимального и максимального значений, а участник заказа выбирает конкретное значение в указанных рамках. Либо же заказчик должен определить, что значение диапазонного показателя не может изменяться, а потенциальный поставщик указывает в заявке диапазон в неизменном виде. Ошибки при установлении диапазонных показателей сводятся к неправильному или недостаточно четкому выбору между указанными альтернативами. При этом вариант «по умолчанию» — это первый вариант, когда участнику закупки нужно указать в заявке конкретное значение показателя.
Все альтернативные значения показателей должны быть реальными.
По общему правилу не стоит устанавливать требование о соответствии техническим условиям, это также признается судами ограничением конкуренции.
Если заказчик устанавливает требования к цветовым характеристикам товара, то они должны быть обоснованными и целесообразными.
Запрещается устанавливать требования к участнику заказа и его ресурсам (ч. 3 ст. 33).
Запрещается закупать ТРУ, которые не соблюдают законодательные требования к энергоэффективности. Это грозит заказчику штрафными санкциями. Если в заказе присутствует необходимость изображения или эскиза, то лучше его предоставить в составе ТЗ.

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