Как правильно составить техзадание. Основные рекомендации

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

При наличии описания закупаемой продукции в КТРУ заказчик обязан:

описывать объект закупки так, как это предусмотрено КТРУ;
включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).

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

Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:

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

Что указать в техническом задании

общая информация;
информация о закупаемом объекте;
требования к поставщикам;
условия ;
приложения (допускается по усмотрению заказчика).

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

1. Составить список терминов, определений и сокращений, которые будут использоваться в документе.

2. Предоставить полную информацию о заказчике:

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

3. Предусмотреть в информации о закупке сведения:

или нет, а если да — права и обязанности каждого заказчика (ПП от 28.11.2013 № 1088);
централизованная закупка, сведения об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
привлечение экспертов, порядок их работы.

4. Перечислить сведения о госзакупке:

способ определения поставщика (ч. 1 ст. 24);
обоснование выбранного способа определения поставщика (ч. 5 ст. 24).

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

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

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

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

9. Привести желаемые результаты (какую проблему хочет решить заказчик) и цели госзакупки (ст. 13 44-ФЗ).

10. Указать источник финансирования.

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

12. Определить условия госзакупки (ч. 1 ст. 19).

13. Указать наименование и обоснование объекта госзакупки.

14. Максимально точно и детально описать объект госзакупки (ст. 33).

15. Определить экологические особенности закупаемого объекта.

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

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

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

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

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

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

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

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

Образцы техзаданий для товаров, работ, услуг в 2019 году

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

Ниже представлен образец технического задания на поставку товара по 44-ФЗ.

Также образец техзадания на выполнение работ по ФЗ-44 вы можете найти в нашем материале о или системы .

О чём вы думаете, когда видите по городу или на сайтах (в рекламных блоках) баннеры с заголовками: «Сайт за 500 грн.», «Сайт за 1000 руб.»?

Я, как разработчик, долго думала - развод! Но количество подобных объявлений наводит на мысли:

А возможно ли такое вообще?
Какое качество будет у сайта в таком случае?
Можно ли будет его потом продвигать?
Займёт ли он достойные позиции?
Будет ли он удобным и будет ли возможность его редактировать?

Конечно, порой приемлем и простой набор HTML-файлов: если страниц немного, их редко меняют из-за тематики и владелец сайта (или контент-менеджер) знает HTML. А если нет? Если, например, потенциальный владелец ничего не знает об HTML и после того, как получит сайт, не вносит никаких изменений? Обычно мало кто вносит какие-то изменения сразу, ведь всё актуально. Но спустя некоторое время, когда нужно прописать метатеги и обновить какую-либо информацию, оказывается, что сайт статичный и нет редактора, с помощью которого можно менять его содержимое.

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

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

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

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

ТЗ по разработке сайта

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

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

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

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

Десктопная версия

Общая информация

Ширина сайта – 1140 px (пример –vizaua.com).
Шапка и футер растягиваются по ширине экрана и одинаковы для всех страниц.
Семейство шрифтов: Cambria (предпочтительно), Century, Georgia. Можно указать и другие популярные шрифты с засечками.
Размеры шрифтов (для Cambria):
Текст под логотипом в шапке – 15px
Ссылки в шапке – 14px
Текст в футере – 16px

Главная страница – home.png

Текст над строкой поиска – 25px

Текст под строкой поиска – 14px

Описание элементов:

1, 2 – цифры с реальным числом магазинов и отзывов. Можно пересчитывать один раз в 24 часа.
3 – категории. Располагаем вручную в таком порядке, как на макете.
4 – ссылки на магазины. Рядом с названием магазина выводим число отзывов. Если отзывов ещё нет, ничего не выводим.
Под каждой категорией выводим 6 самых популярных по количеству отзывов магазинов. Если в категории есть ещё магазины, на неё ведёт ссылка «Ещё N», где N – число магазинов. Если больше магазинов нет, на категорию ведёт ссылка «Показать всё».
5 – список низкопопулярных категорий. Выводим их тут.

Страница с описанием магазина и отзывами – shop-page.png

Заголовок H1 – 30px
Заголовок H2 – 22px

Описание элементов:
1, 2, 3 – место под рекламные блоки. Нужно отметить это место при вёрстке и закрыть к индексации.
4 – контент страницы. Дизайн меняется таким образом, чтобы все изменения можно было внести глобально, без редактирования каждой страницы по отдельности:
– добавлен серый фон контентного блока;
– добавлен белый border у таблиц (по умолчанию, вроде, нигде не прописывался);
— добавлено место под рекламный блок над отзывами.
5 – заголовок формы. Нужно проставить «Добавить отзыв».
6 – последние отзывы (сквозной блок для постов и категорий). Это примерное отображение, допускается готовый плагин с похожей визуализацией.

Описание элементов:
1,2 – место под рекламные блоки.
3 – контентная часть. Нужно удалить все описания категорий (тексты сохранить в отдельном.doc-файле и загрузить этот файл на сервер).
4 – ссылка на отзывы. Во всех шаблонах ТЗ слово «комментарии» меняем на «отзывы».

Служебная страница – page.png

404 ошибка – 404.png

404 – шрифт 80px
Текст под ним – 20px
Наклонный текст – 15px

Твой сайт плохо ранжируется в Яндексе или Google,
а все усилия по его продвижению не дают нужного эффекта?

Отправь заявку на бесплатную SEO-диагностику и узнай,
что не так с твоим сайтом.

Мобильная вёрстка

Сейчас лучше ставить мобильную вёрстку главной и от неё «плясать». Не зря же вся справка и блог Google пестрят «Mobile first» (сначала мобильные или мобильность). Мы говорим вам об этом с 2014 года (статьи « » и « »).

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

Контактам. Номера телефонов должны быть кликабельными – при нажатии должна открываться панель ввода номера с уже набранным номером и кнопкой вызова.
Меню. Опишите, как оно должно открываться: выезжать сбоку, сверху и т. д.
Не должно быть горизонтальной прокрутки на страницах сайта (это само собой разумеется, но я всё же решила напомнить).

Ниже представлены макеты страниц для отображения сайта на мобильных устройствах (адаптивная вёрстка).

Основные требования:
– меню-бургер – раскрывается вниз при касании значка меню:

– сайдбар опускаем под основной контент.

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

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

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

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

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

Структура технического задания

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

Структура документа ТЗ:

Оглавление
История изменений
Терминология
Общие сведения о проекте (назначение, цели и задачи проекта)
Требования к проекту (функциональные, пользовательские, общие и другие требования)
Требования к видам обеспечения
Требования к документированию
Стадии и этапы разработки
Порядок контроля и приемки проекта
Дополнительные материалы

Рассмотрим подробнее каждый пункт структуры.

Понятно из названия, перечень всех частей технического задания.

2. История изменений

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

3. Терминология

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

4. Общие сведения о проекте

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

5. Требования к проекту

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

требования к функционированию проекта;
требования к надежности;
требования к исполнительному персоналу;
требования к патентной чистоте;
требования к стандартизации;
требования к конфиденциальности;
требование к безопасности;
и другие …

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

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

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

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

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

8. Стадии и этапы разработки

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

9. Порядок контроля и приемки проекта

В этом разделе описывается порядок приема проекта, система тестов.

10. Дополнительные материалы

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

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

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

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

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

Проблема

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

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

Переводим на понятный язык

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

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

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

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

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

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

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

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

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

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы

А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.

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

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.