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

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

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

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

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

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

Чем отличается техзадание от описания объекта заказа

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

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

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

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

Скачать

Требования к техзданию

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

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

В процессе формирования ТЗ специалисты могут воспользоваться всеми открытыми и доступными для пользователей сервисами. К ним относятся:

• ГОСТ Р 7.0.97-2016, включающий требования к оформлению различной документации;
• реестр госзакупок в Единой информационной системе;
• иные источники общедоступных данных.

В техническом задании должны быть прописаны наименование объекта госзаказа, а также основные требования и условия к нему. По ч. 4 ст. 23 44-ФЗ, название предмета заказа приводится на основании действующего каталога товаров, работ, услуг (КТРУ) (утв. ПП РФ № 145 от 06.02.2017).

Изучив искомую позицию в КТРУ, специалист заказчика описывает объект госзаказа в строгом соответствии с конкретной строкой каталога. В случае несовпадения прописанных в КТРУ характеристик и описания заказчика ответственный специалист приводит письменное обоснование, указывая при этом требуемое наименование закупаемого объекта (Правила, закрепленные Постановлением Правительства № 555 от 05.06.2015).

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

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

Как составить техническое задание: пошаговая инструкция

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

1. В первую очередь нужно детерминировать параметры закупки — установить и расшифровать терминологию, которая будет применяться в техническом задании.
2. Составить информационную карту. В этом разделе приводятся общие сведения о заказе — полное или краткое название организации-заказчика, его регистрационные и контактные сведения, организационно-правовая форма, местонахождение, ответственное лицо и его контакты.
3. Внести информацию о самой госзакупке — объект торгов и его обоснование (ст. 33), объем и срок поставки, способ определения поставщика, подрядчика или исполнителя (ч. 1 ст. 24 44-ФЗ), обоснование данного способа. Также нужно указать, является ли данная закупка совместной или нет (ПП РФ № 1088 от 28.11.2013), централизованной, ведет ли заказ уполномоченный орган (ч. 1 ст. 26 44-ФЗ), привлекаются ли экспертные организации или иные специалисты.
4. Прописать все требования к потенциальным поставщикам, участвующим в торгах.
5. Указать особые характеристики, которыми должен обладать исполнитель, — определенные производственные мощности или опыт в исполнении аналогичных контрактов.
6. Отразить специфические условия по заказу, непосредственно связанные с его исполнением, возможные экологические условия (режим работы, производственные требования, особенности, которые могут возникнуть при транспортировке, установке или вводе в эксплуатацию приобретаемой продукции).
7. Отразить основные цели и задачи объявляемой закупки (ст. 13 44-ФЗ).
8. Прописать в задании источник финансирования госзаказа.
9. Определить обязанность поставщика следовать действующему законодательству и нормативно-правовым актам в ходе исполнения госзакупки, отразить нормирование заказа в соответствии с ч. 1 ст. 19 44-ФЗ.
10. Описать порядок поставки (как будет производиться транспортировка, какая будет упаковка и т. д.), сдачи, приемки, установки, необходимость монтажа или демонтажа, ввод в эксплуатацию. Внести требования о гарантии и гарантийном сроке.
11. Подтвердить обязательство о поставке новой продукции (не употреблявшейся ранее) или указать необходимость приобретения иных товаров для нужд заказчика.

Готовый документ может выглядеть так:

Разъяснения по теме

Основные тезисы	Реквизиты документа	Документ
Требование указать в заявке параметры не только самого товара, но и компонентов, которые применяются при его изготовлении (например, химические показатели составных частей, результаты испытаний), считается избыточным.	Письмо от 31.05.2016 № РП/36546/16	Скачать
Отдельные вопросы подготовки технического задания для закупки лекарств по Постановлению Правительства № 1380 от 15.11.2017.	Письмо Минздрава № 418/25-5 от 14.02.2018	Скачать
	Письмо ФАС № АК/12985/18 27.02.2018	Скачать
Объединение в техническом задании лицензируемых и нелицензируемых видов работ может ограничивать число участников закупки.	Письмо ФАС № АЦ/5147/15 от 09.02.2015	Скачать
Требовать указать остаточный срок годности лекарств и медизделий в процентах неправомерно, если это приводит к ограничению конкуренции.	Письмо от № ИА/71717/17 от 18.10.2017	Скачать
Закупать запчасти без работ, для выполнения которых они нужны, нельзя.	Письмо Минфина № 24-02-07/73170 от 07.11.2017	Скачать

 

gozakaz.ru

Как составить ТЗ для программиста

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

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

Или вы хотите создать какой-то уникальный сервис для пользователей.

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

Составление вакансии и ТЗ для программиста

Чтобы оставить объявление о поиске программиста-фрилансера, нужно сузить круг поиска. Для этого пишется объявление такого вида:

Требуется программист, чтобы добавить функцию X на готовый сайт на WordPress.

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

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

1. Сроки, обговоренные с исполнителем, и ситуации, когда дедлайн можно подвинуть.
2. Способ и вариант оплаты. Например, на банковскую карту после принятия заказа.
3. Штрафы и правки.
4. Подробное описание того, как вы видите результат работы.
5. Техническая информация.
6. Тестирование

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

Желаемый результат

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

Допустим, вам нужен сервис проверки орфографии. Опишите все ваши представления:

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

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

Техническая информация

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

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

Идентификация сетевых ресурсов является важным подготовительным этапом перед осуществлением взлома. Если хакер знает, что ваш корпоративный портал работает под управлением IIS 7 под управлением Windows Server 2008, то ему необходимо найти уязвимости, которым подвержены данные программные продукты. Для этого проще всего поискать в базах уязвимостей. В случае если найти ничего не удалось, то особо продвинутый взломщик может попытаться самостоятельно найти «лазейку», собрав у себя точную копию взламываемой системы и попытавшись самостоятельно проанализировать код. «Информационная безопасность: защита и нападение», Бирюков А. А.

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

Программа должна отображаться на странице page.php, а исполнительный файл в файле core.php. Взаимодействие между файлами с помощью ajax. Все обработанные данные нужно записывать в таблицу data_table (My_SQL) со столбцами id, name и url.

Нельзя создавать функции и переменные с названиями: generate, crop и analyze. Иначе возможен конфликт.

Стандарты оформления кода

Разные люди по-разному пишут. Хороший пример – наш блог. В нем несколько авторов, у каждого из которых свой стиль. То же самое и с программистами.

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

Поэтому если над проектом работает несколько человек, нужно составить стандарты оформления кода – что-то вроде редполитики для программистов.

Чек-лист по юзабилити: 200+ пунктов на проверку

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

Переменные можно называть по-разному: $aB, $ab, $a_b, $A и так далее. Если это незначительно, добавлять комментарии критически важно. Без них в коде тяжело ориентироваться, даже если его писали вы, но отложили на неделю.

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

Подключение и тестирование

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

Заключение

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

kak-sostavit-tz-dlya-programmista

texterra.ru

Как создать ТЗ для программиста / Habr

Рекомендации геймдизайнеру от программиста (архитектора).

Вступление

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

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

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

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

Самое важное:

1. Четкое понимание конечного результата. (Контроль качества.)
2. Сроки исполнения.

Зачем нужна документация:

1. Экономия времени на коммуникациях. (Один раз написать, вместо того чтобы 100 раз пересказывать, путаясь в показаниях.)
2. Способ увидеть, как будет выглядеть готовый проект.
3. Анализ и выявление проблем еще на стадии планирования. (Чем раньше будет выявленна архитектурная ошибка — тем дешевле ее исправить)
4. Фиксирование принятых решений. (Точные данные, вместо разрозненных слухов разной степени свежести.)
5. Планирование работ.

Какие бывают документы:

1. Концепция («Про че игра?»)
2. Спецификация (Что мы хотим получить?)
3. Техническое задание (Как это устроено — именно о нем будет идти речь.)
4. План работ (Как мы это будем делать.)

Кто участвует в обсуждении ТЗ:

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

1. Геймдизайнер (Написание документации)
2. Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
3. Программист (Оценка объемов работ.)

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

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

1. Форматирование. (Легко напечатать и приятно читать/держать в руках)
2. Выделение ключевых фраз. (Для чтения документа по диагонали)
3. Составление списков. (Вместо сплошного текста)
4. Разбиение длинных списков по группам. (По три пункта в группе)
5. Многократные повторения. (Избегать ссылок по документу)
6. Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
7. Оглавление, список документов, история изменений. (Для поиска по документации/версиям)

Требования к содержанию ТЗ

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

1. Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
2. Никаких общих слов типа:
   • все возможные варианты
   • карта придумывается компьютером
   • взаимодействие различных объектов
   • после всех действий и т.д.
3. Все названия видов сущностей(классов) должны иметь:
   • русское название (для игрока)
   • английское (для кода)
   • краткое описание (расшифровка/подсказка/комментарий)
4. Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
5. Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
6. Все что можно измерить, должно быть измерено.
   • размеры картинки в пикселях и байтах
   • количество столбцов и клеток в таблице
   • количество символов в текстовом поле
   • количество оружия на уровень
   • время сессии и т.д.

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

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

1. Гибкость системы к изменениям. (Динамические требования.)
2. Автоматический сбор данных об ошибках. (Обратная связь.)
3. Простота запуска и настройки заказчиком. (Демонстрация результата.)

Первый этап написания ТЗ:

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

1. База данных (метаданные)
   • список типов объектов
   • характеристики объектов
   • связь/зависимость между объектами
2. Бизнес-процессы (полный игровой цикл)
   • список процессов (сценарии работы)
   • список функционала (что должен уметь)
   • список ожидаемых изменений (что вообще может быть)

Второй этап написания ТЗ:

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

1. Интерфейс (визуальная часть)
   • список экранов игры с названиями (или группы элементов)
   • список элементов на каждом экране с названиями и текстом подсказок
   • описание поведения элементов (подмигивание, подсказка, блокирование, всплывающие диалоги и т. д.)
2. Админка (управление)
   • сервер (жизненные/системные показатели )
   • игровой контент(распродажи, квесты, монстры, вещи, магазины, дроп, локации и т.д.)
   • игровые данные(контент генерируемый игроками)
   • статистика и отчеты (какую статистику нужно собирать?)

Третий этап написания ТЗ:

Как мы собираемся это все делать.

1. Исследование необходимых технологий
   • Список требований к каждой технологии
   • Описание тестов/демонстрации работы каждой технологии
   • Список будущих требований/возможных проблем (что дальше?)
2. Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
3. Список небходимых инструментов для работы с контентом (редактор карт, админка квестов, ).
4. Расстановка приоритетов по задачам.
5. Требования к первой работающей сборке (что должен уметь первый прототип).
6. Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)

Сопровождение документации

1. Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
2. Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
3. Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
4. Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
5. После каждого цикла планирования — проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно.)
6. Составить список неудобных вопросов. Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
7. Предоставлять краткие инструкции конечным исполнителям. Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
8. Признак мастерства: каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.

Срезание углов

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

1. Проект в 2-3 месяца.
2. Команда из 2-3 человек.
3. Ограниченный бюджет. (Он всегда ограничен)
4. Нет требований к документации. (Никто не знает как надо делать)
5. От нее нет никакой пользы. (Никогда не использовали документацию)

Однако следует помнить: разработка документации занимает 40% всех усилий. И определяет на 90% вероятность успешного завершения разработки проекта.

Первые шаги

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

habr.com