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

Залог успеха разработки в первую очередь зависит от технического задания. Как же составить хорошее ТЗ на разработку? Что оно должно в себя включать? Обязательно ли писать его самостоятельно? Мы решили детально разобрать ТЗ и прояснить все непонятные моменты.

Почему ТЗ — это важно

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

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

В статье я расскажу:

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

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

ТЗ — это ваша гарантия

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

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

Первый сценарий — это работа с недобросовестным подрядчиком, когда он делает «тяп-ляп».

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

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

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

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

ТЗ — это фундамент вашего приложения

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

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

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

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

Как правильно оформить техническое задание для дизайнера? Просто о сложном

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

Например, вы указываете в ТЗ, что хотите использовать определённую базу данных для хранения информации, а также описываете логику хранения этих данных.
В процессе разработки ТЗ часто дополняется. В какой-то момент разработчики понимают, что согласованный способ хранения данных ненадежен, невозможен или неудобен — в общем, можно сделать лучше. Однако, в ТЗ уже прописаны требования к хранению данных. Составляя ТЗ вы не учли некоторые детали, и теперь, чтобы продолжить разработку, нужно согласовывать дополнительные документы с уточнениями к ТЗ. Всё это растягивает время разработки, а значит и стоимость (если вы работаете по модели Time Material (почасовая ставка), помните пословицу «Время — деньги», а вместе с ней запомните — «Рассеянный делает одну работу дважды».

ТЗ позволяет сокращать расходы

Представьте, что на разработку приложения выделено 5 миллионов. Вы присылаете ТЗ некоторому количество разработчиков и получаете оценку в 7-8 миллионов.

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

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

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

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

Обязательно ли делать ТЗ своими силами

Как сказал Майкл Францезе: «Делайте то, что у вас лучше всего получается, а остальное перепоручите соответствующим специалистам.»

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

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

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

Как должно выглядеть ТЗ

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

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

Раздел Общие сведения

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

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

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

1. Реквизиты исполнителя и заказчика.
2. Сроки начала и окончания проекта (вплоть до разбивки по этапам).
3. Опишите требования, которые не касаются разработки приложения.

Цели и назначение проекта.

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

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

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

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

Что такое назначение? Назначение заключается в том, как будет использоваться продукт.

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

1. Цель — это то, зачем нужен проект и какую роль он будет выполнять.
2. Назначение — это то, как потом мы будем его использовать.

Раздел Требования к системе в целом

1. Требования к защите от влияния внешних воздействий
2. Требования к патентной чистоте
3. Требования к стандартизации и унификации
4. Дополнительные требования
5. Требования к функциям и задачам системы
6. Требования к видам обеспечения

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

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

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

Показатели назначения

Ранее мы уже разобрали, что такое назначение. Давайте разберём это простыми словами на примере.

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

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

Цель добавили просто для того, чтобы вы точно не перепутали эти определения. На неё можно не обращать внимание.

1. Создать систему регистрации / авторизации, верификации, заполнения профиля
2. Создать систему поиска пары
3. Разработать и внедрить игры в приложение.
4. Разработать систему подбора игроков.
5. Добавить функционал общения во время игры.
6. Создать систему матчей (совпадение лайков профилей) в игре и вне игры.
7. Создать чат

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

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

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

Показатели надёжности

1. приложение должно выдерживать одновременно более N тысяч пользователей, при этом не тормозить,
2. приложение должно хранить данные пользователя в БД на отдельном сервере,
3. если система по разным причинам перестала работать (что-то с хост-машиной, либо сбой в системе), то она должна перезапуститься автоматически в течение 10 минут
4. система не должна быть нагружена более чем на 80 процентов, при превышении лимита нужно закрывать доступ новым пользователям, чтобы снизить нагрузку;

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

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

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

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

1. какие характеристики серверов или ПК должны быть,
2. как они должны работать,
3. как предотвращать перегрузки,
4. как обслуживать эти сервера,
5. какая ОС должна быть на сервере и т.д;

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

Замудренная формулировка, не правда ли? На самом деле здесь всё просто.

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

На примере страницы регистрации, описание UX выглядит примерно так.

Для начала напишем какие элементы находятся на этой странице.

1. Поле ввода логина
2. Поле ввода емейла
3. Поле для ввода пароля
4. Чекбокс подтверждения обработки персональных данных.
5. Кнопка Зарегистрироваться
6. Кнопка Вернуться на главную

Теперь опишем расположение этих элементов.

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

В дальнейшем UX описание понадобится дизайнеру для создании макета, а разработчикам для вёрстки.

Требования к транспортабельности для подвижных АС

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

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

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

1. кто будет обслуживать сервера,
2. как часто их нужно обслуживать,
3. каким образом это делать,
4. как всё настроить и всё в таком духе;

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

Требования к защите информации от несанкционированного доступа

1. кому предоставлены доступы,
2. к каким разделам предоставлены доступы,
3. кто может изменить все креды,
4. как быть, если кто-то извне вошёл в систему,
5. как заблокировать подозрительного пользователя,
6. кто и при каких условиях может изменять параметры доступа,
7. какие требования к аутентификации,
8. как запретить вход в систему сторонним лицам, даже при наличии кредов;

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

Требования по сохранности информации при авариях

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

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

Требования к защите от влияния внешних воздействий

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

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

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

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

Этот раздел носит юридический характер. Давайте кратко и для общего познания обговорим, что это такое.

Патентная чистота — это исключительные права на ваше приложение, которые еще называются «интеллектуальной собственностью».

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

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

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

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

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

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

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

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

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

1. нужно реализовать систему безопасности в приложении по ГОСТу,
2. разработка должна проводиться по методологии waterfall,
3. корпоративная система должна быть построена по методологии ERP 2;

Дополнительные требования

В разделе фиксируется всё, что не касается предыдущих и следующих разделов.

1. какой уровень владения ПК должен быть у пользователя, чтобы он комфортно мог использовать систему,
2. список ролей в системе (сюда можете просто добавить список, а их описание будет в функциональных требованиях к продукту),
3. требования к контурам — это техническая информация. Обычно контуры делятся на dev, prod, или dev, test, prod. Кому как удобно;

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

Мы всё ближе к функциональным требованиям! Потерпите ещё чуть-чуть.

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

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

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

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

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

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

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

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

1. математическое обеспечение,
2. информационное обеспечение,
3. лингвистическое обеспечение,
4. программное обеспечение системы,
5. техническое обеспечение,
6. требования к метрологическому обеспечению,
7. организационное обеспечение,
8. методическое обеспечение,
9. требования к численности и квалификации персонал;

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

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

1. как организовано хранение данных (какую информацию будем сохранять в базу данных и в какие поля её записывать),
2. как построена взаимосвязь между компонентами системы (например, после успешного оформления покупки, компонент, отвечающий за оплату, тыкает компонент корзины, что покупка совершена успешна и можно её очистить.),
3. как компоненты приложения связаны с внешними сервисами и как они должны обмениваться информацией. Например, после успешной оплаты, отвечающий за это компонент передает информацию во внешний сервис, который занимается рассылкой SMS, чтобы тот в свою очередь выслал код подтверждения обратно в систему и пользователю для получения товара)

Лингвистическое обеспечение — это перечень всех технологий, которые будут использоваться: языки программирования (C#, TypeScript), базы данных (mongoDB, SQL Lite), библиотеки (React, Angular)

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

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

Вот ещё один пример. Вам нужно шифровать данные, тогда укажите ПО, с помощью которого нужно это делать (например, Валидата).

Техническое обеспечение — это требования к серверу или ПК, на котором будет работать ПО

Например, технические характеристики серверов, если это веб-приложение, или технические характеристики компьютера, на котором будет работать десктопное приложение.

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

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

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

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

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

Методическое обеспечение — сюда входит техническая и пользовательская документация. По необходимости может быть создан документ «пользовательские сценарии».

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

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

Пользовательские сценарии — это описание действий пользователя. Т.е. описывается порядок действий пользователя.

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

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

1. навык владения компьютером (допустим, десктоп приложение на Linux, а пользователь никогда не работал в этой ОС)
2. умение работать с Excel (допустим, рекламная система умеет импортировать .csv формат для управления ставками в поисковой рекламной кампании. Для корректного импорта, нужно создать определенные поля с ключевыми словами, где для ключевого слова прописать специальную формулу с помощью которой система поймёт, какую ставку выставить. Пользователь может не знать, как оформлять документ так, чтобы система его поняла.),
3. умение администрировать операционную систему (допустим, разработано сложное ПО, для перезапуска которого нужно использовать командную строку);

Если у вас предусмотрен регламент работы пользователей в системе, то зафиксируйте его здесь.

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

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

В этом разделе описываются все функции системы. Уделите разделу особое внимание. Не забудьте перечитать его в своём ТЗ несколько раз.

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

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

1. Описание функционала постранично.
2. Описание системы, используя метод логического разделения функций.

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

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

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

1. Выйти — выход из системы.
2. Помощь — открытие страницы с пользовательской документацией.
3. Войти в ЛК — переход на страницу с личным кабинетом.

1. Проект — указывается название проекта. По нажатию на название пользователь переходит на страницу с проектом.
2. ID — указывается идентификатор проекта.
3. Статус — Активен / Неактивен
4. Настройки проекта — кнопка настроек для проекта. По нажатию открывается новая страница с настройками проекта
5. Экспорт отчёта — кнопка выгрузки отчёта. По нажатию на кнопку всплывает модальное окно (о нём писать здесь не нужно, т.к. это может быть отдельная крупная модалка)

1. Какие роли нужны, а также какие возможности доступны для каждой из ролей.
2. Нужна ли мультиязычность

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

Пример разделения функций. Функция регистрации выполняет цель добавления пользователя в систему.

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

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

1. [Название функции/страницы]
2. [Краткое описание]
3. [Элементы на экране]
4. [Детальное описание возможностей функции]
5. [Список функций, взаимодействующих с ней]

Виды и состав испытаний системы

1. как сдаём проект,
2. как оцениваем его,
3. как делим работу на этапы,
4. при каких условиях проводим тестирование. Например, на dev ветке — сайт доступен только для разработчиков, или на prod — сайт доступен к использованию всеми пользователями,
5. когда планируем графики релизов;

Резюмируем. В этом разделе фиксируем все организационные моменты, которые касаются управления разработкой проекта.

Общие требования к приёмке работ

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

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

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

Статус приёмочной комиссии

1. ФИО и должности тех, кто будет принимать каждый этап. Не забудьте обосновать, почему именно они должны принимать сдачу (какое отношение имеют к проекту),
2. ФИО и должность ответственного лица, который будет принимать проект полностью,
3. список сотрудников, которые будут сдавать проект. (обычно это тестировщик, менеджер проекта и аналитик);

Финальная реплика

Вот вы и дочитали статью до конца. Я очень надеюсь, что статья поможет вам в написании ТЗ. Как и обещал, шаблон ТЗ вы можете скачать, нажав СЮДА. Желаю вам удачи в написании крепких ТЗ и в поиске подходящего вендора!

Источник: spark.ru

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

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

Что такое техническое задание и где оно используется

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

Термин «техническое задание» — не единственно возможный, а лишь наиболее часто используемый. Другие допустимые названия: «техническая часть», «спецификация», «проектно-сметная документация» и т.п. Федеральный закон от 5.04.2013 № 44-ФЗ раздел документации о закупке, в котором заказчик описывает объект закупки, определяет как «описание объекта закупки».

Независимо от употребляемого термина, важно, чтобы требования к закупаемым товарам, работам и услугам были конкретными, понятными и не противоречили законодательству — 44-ФЗ, 223-ФЗ и 135-ФЗ.

Техническое задание используется:

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

В соответствии с ч. 2 ст. 33 Федерального закона от 05.04.2013 № 44-ФЗ в техническом задании должны быть указаны показатели, позволяющие определить соответствие закупаемых товаров, работ, услуг установленным заказчиком требованиям. При этом указываются максимальные и (или) минимальные значения таких показателей, а также значения показателей, которые не могут изменяться.

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

33 также сказано, что есть показатели, которые не могут изменятся.

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

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

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

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

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

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

Есть ряд исключений, когда слова «или эквивалент» не пишутся:

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

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

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

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

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

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

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

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

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

В документацию о закупке нельзя включать следующие требования:

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

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

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

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

Антимонопольное законодательство

В ст. 17 Федерального закона от 26.07.2006 № 135-ФЗ говорится, что при проведении торгов, запроса котировок цен на товары, запроса предложений запрещаются действия, которые приводят или могут привести к недопущению, ограничению или устранению конкуренции. Это следующие действия:

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

По материалам журнала Контур

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

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

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

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

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

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

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

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

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

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

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

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

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

Опишите сайт

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• На какой CMS должен находиться сайт — Вордпресс, Джумла, Модэкс и так далее
• Какой язык программирования можно использовать — 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.

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

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

Что собой представляет ТЗ

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

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

Техзадание может оформляться в свободном виде. Но положения документа не должны вступать в противоречие с ФЗ №44 от 5 апреля 2013 года. То есть в ТЗ не может содержаться запрет на работу с ФЛ и ИП. Законом о госзакупках оговорено, что государственные контракты должны быть доступными для всех.

В техзадании содержится информация об объекте закупки. Требования к ее изложению оговорены в статье 33 ФЗ №44:

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

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

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

Техзадание формируется со следующими целями:

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

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

Этапы формирования ТЗ

Создание ТЗ подразделяется на эти этапы:

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

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

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

ВНИМАНИЕ! В ТЗ ни в коем случае не может содержаться данных о производителях. В обратном случае задание будет неправомерным.

Важность точного составления ТЗ

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

Какие сведения не входят в ТЗ

В техзадание не может входить эта информация:

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

Если производится закупка медикаментов или оборонных объектов, задание должно отвечать требованиям, сформулированным в статье 44 ФЗ №44.

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

ТЗ составляется стороной заказчика. Кому доверить эту работу? Составлением документа должен заниматься сотрудник, разбирающийся в юридическом аспекте дела. В частности, он должен хорошо знать именно ФЗ №44 и ГК РФ. Доверить оформление задания можно штатному юристу или стороннему специалисту.

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

На чем основываться при составлении ТЗ

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

• Антимонопольные принципы, содержащиеся, в том числе, в ФЗ №44.
• Рекомендации, содержащиеся в других актах.

При составлении техзадания можно ориентироваться на эти акты:

• Отраслевые нормы.
• Технико-технологические положения.
• Государственные стандарты.
• Методические рекомендации министерств.

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

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

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

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

1. Описание закупаемого объекта должно быть объективным. Оно может включать в себя только технические, функциональные, эксплуатационные и качественные характеристики. Запрещено прописывать товарные знаки, фирменные наименования, сведения о производителе и тому подобную информацию. Если включение таких сведений крайне необходимо, то они должны сопровождаться пометкой «или эквивалент». Только так удастся обеспечить здоровую конкуренцию.
2. При составлении описания разрешено пользоваться только терминологией, предусмотренной техническими регламентами, действующими в соответствии с законодательством РФ.
3. В описание закупаемого объекта разрешено включать чертежи, фотографии, эскизы, результаты тестовых испытаний и подобную информацию.
4. Если в техническом задании предусматривается предоставление поставщиком образца закупаемого товара, то в документации должны присутствовать время и место осмотра образца.
5. При закупке лекарственных препаратов заказчик должен указывать непатентованные наименования, признанные во всем мире. Если такие наименования отсутствую, то прописываются химические или группировочные наименования.

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

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

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

1. Сведения о заказчике. Прописываются реквизиты организации, место нахождения, график работы.
2. Информация о проводимой закупке. Целесообразно указывать полное наименование закупаемого объекта, способ определения победителя, источник финансирования. В этот же раздел можно включить данные об используемых терминах и сокращениях.
3. Описание закупаемого объекта. Оно оформляется по правилам, установленным статье 33 44-ФЗ.
4. Заказчик имеет возможность установить требования к упаковке товара и безопасности объекта закупки.
5. Прописываются сроки поставки товара или оказания услуг.
6. Указывается требуемый гарантийный срок. Он может составлять несколько дней, месяцев или лет.
7. При необходимости заказчик может прописать требования по сервисному обслуживанию, монтажу и наладке, обучению сотрудников грамотной эксплуатации поставляемого товара.

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

Какие сведения запрещено включать в ТЗ

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

• Требования к конкретному производителю товара и стране происхождения.
• Ссылки на конкретные товарные знаки без указания о возможности поставки эквивалента.
• Прописывать требования, которые присущи только одному товару.

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

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

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

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

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

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

Требования к техническому заданию по 44 ФЗ

За основу можно принять официальное издание Единой системы документации национальных стандартов.

Основное назначение ТЗ — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с каталогом товаров, работ, услуг (ч. 4 ст. 23). Каталог утвержден Постановлением Правительства от 8.02.2017 № 145.

При этом с 1 марта 2017 года правила формирования и ведения действуют только в отношении лекарственных препаратов. В отношении других товаров, работ, услуг они будут применяться только с 1 октября 2017 года. Основополагающим документом является Общероссийский классификатор продукции по видам экономической деятельности (ОКПД2).

16. Уточнить объем закупаемых товаров, а также периодичность и срок поставки.

17. Определить гарантийный срок и объем предоставляемых гарантий.

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

19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.

20. Определить расходы на эксплуатацию.

21. Определиться, нужны ли монтаж и наладка.

22. Установить порядок поставки и приемки.

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

Техническое задание, образец по ФЗ 44

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

Как составить техническое задание по 44-ФЗ

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

Основные этапы составления технического задания

Составление ТЗ состоит из трех этапов.

Этап 1-й, подготовительный.

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

Этап 2-й, основной.

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

Разъяснения по вопросу можно найти в письме Минэкономразвития РФ № 28и-2790 от 10.12.2014 года.

2. Эксплуатационные свойства

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

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

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

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

Краткая характеристика

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

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

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

В качестве источников следует рассматривать официальные акты. В числе таковых:

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

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

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

Требования к форме и содержанию технического задания

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

• организационная форма;
• наименование;
• место расположения.

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

1) Место исполнения контракта

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

• точный адрес;
• четкие территориальные границы.

Такое условие позволит потенциальным участникам объективно оценить свои возможности.

2) Гарантии

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

3) Прочие характеристики

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

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

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

Запреты! Не допускается объединение в одной закупке разнородных материальных благ. Так, например, заказчик не вправе предусматривать в техническом задании одновременное оказание услуг по охране объекта и сервисному обслуживанию. Подробное разъяснение по вопросу содержат письма РФ № АЦ/20578/14 от 21.05.2014 года и Минэкономразвития РФ № Д28и-442 от 10.03.2015 года. При размещении комплексного заказа объект следует разбивать на отдельные лоты.

Источник: ev-lux.ru