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

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

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

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

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

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

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

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

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

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

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

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

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

Опишите сайт

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сроки : до 15.09.2018.

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

Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с (ч. 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 вы можете найти в нашем материале о или системы .

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

1.Электроснабжение

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

2.Главный распределительный щит (ГРЩ)

Предусмотреть устройство необходимого количества ГРЩ. Каждое ГРЩ должно иметь две главные секции шин с авто­ матическими выключателями. Между секциями предусмот­ реть секционный выключатель.

Технические характеристики ГРЩ определить проектом, ис­пользовать комплектующее оборудование фирмы ИЭК либо иное сертифицированное.

Шкафы ГРЩ-0,4 кВ должны быть одно- или двухстороннего обслуживания (уточнить проектом). В каждом ГРЩ (ВРУ) необходимо предусмотреть резерв 15% автоматических вы­ключателей отходящих линий и резерв 15% свободного места для возможной установки дополнительного оборудования (автоматических выключателей и т.д.).

3.Учет электроэнергии

Коммерческий учет электроэнергии предусмотреть на ввод­ных панелях ГРЩ расчетными трехфазными счетчиками.

4.Электрические групповые щиты

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

Разработать щиты аварийного освещения (ЩАО). Щиты должны комплектоваться контакторами, управление освеще­нием с помощью кнопок и выключателей. Разработать щиты электроснабжения силовых розеток и ра­бочего освещения (ЩРО).

Разработать щиты электроснабжения арендных площадей (ЩРА).

Разработать щиты электроснабжения компьютерных розеток (ЩК) для офисных помещений.

Разработать щиты электроснабжения технологического обо­рудования (ЩС).

Щиты (оболочки) предусмотреть производства Schneider Electric и ИЭК.

Коммутационно-защитную аппаратуру предусмотреть производства Schneider Electric и ИЭК.

5. Магистральные кабельные трассы

Магистральные кабельные трассы выполнить стальными горячеоцинкованными кабельными полками лестничного типа и листовыми кабельными лотками или проволочными лотка­ми.

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

Питающие магистральные линии выполнить кабелем с ПВХ изоляцией. Кабели проложить открыто по кабельным полкам. Питающие кабели (до распределительных щитов) должны иметь запас по пропускной способности 10-15%. Все металлические кабельные конструкции заземляются

6. Электропроводка

Для электропроводки применить кабели с ПВХ изоляцией с медными жилами. Кабели прокладывать:

Скрыто в ПВХ трубах за подвесными потолками;

Скрыто в ПВХ трубах в штрабах с последующей задел­ кой;

Открыто по кабельным полкам;

Открыто в декоративных кабель-каналах и плинтусах (офисные помещения).

Тип прокладки кабеля в помещении определить в соответ­ствии с эскизным проектом. Электропроводку выполнить сменяемой.

7. Электроустановочные и электромонтажные изде­лия

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

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

8. Электроосвещение

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

Напряжение сети общего освещения - 380/220 В, напряжение на светильниках - 220 В, напряжение ремонтного освещения -36 В.

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

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

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

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

Использовать светильники производства "Световых технологий”.

Электроустановочные изделия - производства Schneider Electric и ДКС.

Кабеленесущие системы – ДКС.

9.Электроснабжение противопожарных систем

Электроснабжение систем пожарной сигнализации, системы дымоудаления и подпора воздуха предусмотреть от секции АВР ГРЩ, либо от двух от двух вводов (по месту предусмотреть установку устройства АВР).

Взаиморезервируемые кабели противопожарных систем про­ложить по разным трассам.

10.Заземление

Применить систему заземления типа TN-C-S. В качества заземляющего устройства использовать железобе­тонное основание здания (при необходимости выполнить наружный контур молниезащиты из полосы 5x40). Проектом предусмотреть систему уравнивания потенциалов.

11.Молниезащита

Молниезащиту здания выполнить согласно РД 34.21.122-87.

12.Трансформаторная подстанция и ГРЩ

Предусмотреть встроенную трансформаторную подстанцию.

Принять следующее оборудование:

распределительное устройство высокого напряжения – марки RM-6 производства Schneider Electric;

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

трансформаторы – сухие марки Trihal производства Schneider Electric.

2 голоса

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

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

План действий по работе с заказчиком

Вы находите клиента. Он готов заплатить деньги, а вы приступить к работе. С чего же начать и как действовать?

  • Первое общение.

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

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

  • Подготовка и первый бриф.

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

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

  • Составление и подписание технического задания.

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

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

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

  • Разработка и прием.

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

Чего не должно быть в ТЗ, а что там быть обязано

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

Вы сами знаете в каком стиле и что должно быть нарисовано. Перед вами стоит задача: улучшить узнаваемость бренда или мотивировать на отдых в таком-то месте. Как вы будете реализовывать эту задачу – ваши проблемы. Не хватало еще, чтобы заказчик учил вас код писать и рассказывал какими инструментами пользоваться.

Пусть в вашем ТЗ будет фраза: «Все, что не оговорено выполняется на усмотрение исполнителя». И не обязательно делать эту строчку маленьким шрифтом. Пусть думает заранее, а не начинает мечтать, когда проект уже готов. Конечно же, небольшие изменения вы можете и должны внести. Хорошая репутация – залог будущих клиентов, но иногда заказчик может так достать своими пожеланиями, что жить не захочется.

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

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

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

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

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

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

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

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

Выглядит оно так:

  1. Глоссарий
  2. Общие положения
  3. Предмет разработки
  4. Назначение документа
  5. Требования к графическому дизайну сайта
  6. Требования к дизайну сайта
  7. Порядок утверждения дизайн-концепции
  8. Функциональные требования
  9. Требования к представлению сайта
  10. Требования к системе управления сайтом
  11. Требования к разделению доступа
  12. Требования к видам обеспечения
  13. Требования к информационному обеспечению
  14. Требования к программному обеспечению
  15. Требования к техническому обеспечению
  16. Требования к лингвистическому обеспечению
  17. Требования к эргономике и технической эстетике
  18. Требования к приемке-сдаче проекта
  19. Требования к наполнению информацией
  20. Требования к персоналу
  21. Порядок предоставления дистрибутива
  22. Порядок переноса сайта на технические средства заказчика

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

Глоссарий

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

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

Общие положения

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

Предмет разработки

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

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

Назначение документа

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

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

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

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

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

Порядок утверждения дизайн-концепции

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

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

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

Будьте внимательны. Это важный пункт, в котором лучше написать больше. Например, у вас должен быть раздел «Похожие новости». Что вы будете делать: прописывать алгоритм, который будет вычислять какие статьи наиболее близки по теме, дадите список последних пяти статей, добавленных на сайт, или у автора текста будет возможность вставить ссылки в этот блок самостоятельно?

Требования к представлению сайта

  1. Структура сайта: описываем какие категории (рубрики) будут на сайте.
  2. Главная страница: лучше всего со схематической картинкой и описанием основных элементов.
  3. Внутренние страницы: тоже что и в предыдущем пункте. Схема и описание внутренних страничек.

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

Требования к системе управления сайтом

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

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

Требования к разделению доступа

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

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

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

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

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

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

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

Требования к программному обеспечению

  1. Тут речь идет о хостинге или серверах. Так как мой блог ориентирован на создателей, которые работают на Таймвебе (https://timeweb.ru ) – все очень просто. Если вы не из «наших», то нужно смотреть на технические характеристики. Например, кто-то очень умный делает крутой сайт, а потом пытается подключить его к хостингу, а технические характеристики настолько завышены, что ни один хостинг в России не справляется. Пункт нужный, но не для новичков в сфере разработки.
  2. Здесь мы описываем будет ли портал иметь мобильную версию, адаптирован под портативные устройства или сможет открываться только через Google Chrome, а любые искривления в других браузерах нас вообще не волнуют.

Требования к лингвистическому обеспечению

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

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

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

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

Требования к наполнению информацией

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

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

Требования к персоналу

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

Порядок предоставления дистрибутива

Что вы отдадите заказчику, когда работа будет выполнена: логин, пароль, туда-сюда.

Набиваем цену технического задания

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

В этом документе должно впечатлять все! Если вы собираетесь переслать его для предварительного ознакомления по почте, то обязательно используется формат PDF. И клиенту вероятно не захочется мучить себя правками и о вас он будет думать, как о профессионале. Мелочь, а значительная. Для преобразования вордовского документа можно использовать сервис https://smallpdf.com/ru/ .

Не забудьте вставить фоном логотип собственной компании или вашего бренда, а также вставить контакты. Быстро и качественно их можно оформить на сайте https://logaster.ru .

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

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

СКАЧИВАЕМ ШАБЛОН ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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