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

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

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

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

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

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

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

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

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

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

На первый взгляд кажется, что ТЗ на сайт должен составлять клиент , потому что он заказывает ресурс и выдвигает требования к нему. На самом деле в процессе должны участвовать оба: клиент озвучивает требования, а исполнитель записывает их конкретно, точно и понятно. Например, клиент говорит, что хочет сайт, адаптированный под всех пользователей, а разработчик прописывает требования к адаптивности под 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.

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

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

При составлении технического задания руководствуются ст. 33 «Правила описания объема закупки» Закона №  44-ФЗ .

В частности, необходимо указать в техническом задании:

1. Общую информацию о закупке.
2. Описание объекта закупки.
3. Требования к объекту закупки.
4. Условия закупки.
5. Особенности отдельных видов закупки.

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

Общая информация о закупке. Этот раздел, как правило, включает в себя:

1. Общие сведения о заказчике (о наименовании, местонахождении, режиме работы).

2. Общие сведения о закупке (о способе определения поставщика в соответствии с ч. 1 ст. 24 Закона №  44-ФЗ , цели закупки согласно ст. 13 Закона №  44-ФЗ , источнике финансирования, нормативно-правовой базе, на основании которой производится закупка).

3. Дополнительные пояснительные сведения.

Описание объекта закупки. Здесь указываются следующие характеристики объекта закупки:

1. Функциональные. Необходимо установить основное назначение объекта закупки и условия его использования по назначению. Функциональное назначение объекта характеризуется, например, такими свойствами, как пищевая ценность (энергетическая, биологическая), эстетические свойства (форма, цвет, запах, совершенство производственного исполнения) и др.
2. Технические. Заказчик может детализировать описание объекта закупки, привести конкретные данные, параметры, исходные и конечные величины, физические величины показателей, описать регламент и порядок действий при поставке товара, выполнении работ, оказании услуг.
3. Качественные. Указывается совокупность свойств, характеристик, признаков товаров, услуг, работ, обусловливающих их способность удовлетворять потребности и запросы заказчика, соответствовать своему назначению и предъявляемым требованиям.
4. Эксплуатационные. Здесь можно прописать характеристики надежности и работоспособности объекта закупки, условия, обеспе-чивающие его эффективную эксплуатацию, к которым относятся в том числе прочность, долговечность, технические параметры, объемно-планировочные, санитарно-гигиенические, экономические и эстетические характеристики. В качестве эксплуатационных характеристик товара можно указать стадию его жизненного цикла использования по назначению.

Отметим, что все вышеперечисленные характеристики объекта закупки являются критерием оценки заявок, окончательных предложений участников закупки (ч. 1 ст. 32 Закона №  44-ФЗ ).

При описании объекта закупки необходимо использовать, если это возможно, стандартные показатели, требования, условные обозначения и терминологию, касающуюся технических и качественных характеристик объекта закупки, установленных в соответствии с техническими регламентами, стандартами и иными требованиями, предусмотренными законодательством РФ о техническом регулировании. К ним относятся ГОСТы, СНиПы и другие нормативно-технические документы.

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

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

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

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

2. В случае, если содержится требование о соответствии поставляемого товара изображению товара, на поставку которого заключается контракт, заказчику необходимо привести изображение поставляемого товара, позволяющее его идентифицировать и подготовить заявку, окончательное предложение (пп. 4 п. 1 ).

3. Поставляемый товар должен быть новым товаром. Это значит, что он не был в употреблении, в ремонте, не был восстановлен, у него не была осуществлена замена составных частей, не были восстановлены потребительские свойства, в случае, если иное не преду-смотрено описанием объекта закупки (пп. 7 п. 1 ).

Условия закупки. В этом разделе следует указывать:

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

2. Сроки поставки товаров, выполнения работ, оказания услуг. Отметим, что согласно п. 2 ст. 42 Закона №  44-ФЗ обязательно нужно проставить сроки завершения работ. Кроме этого, здесь должны быть указаны промежуточные сроки завершения отдельных этапов работ или приведен график оказания услуг, который поможет распределить объем оказываемых услуг по периодам.

3. Информацию о месте, датах начала и окончания, порядке и графике осмотра участниками закупки образца или макета товара, на поставку которого заключается контракт, если заказчик установил требования о соответствии поставляемого товара образцу или макету товара, на поставку которого заключается контракт (пп. 5 п. 1 ст. 33 Закона №  44-ФЗ ).

4. Требования к поставщикам (подрядчикам, исполнителям). Здесь можно прописать требования о наличии лицензии, допуска, разрешения и согласования (п. 1 ч. 1 ст. 31 Закона №  44-ФЗ ). Кроме того, в силу ч. 2 ст. 31 Закона №  44-ФЗ при закупке отдельных видов товаров (работ, услуг) Правительство РФ устанавливает дополнительные требования к участникам закупок, в том числе к наличию финансовых, материальных и трудовых ресурсов для исполнения контракта, опыта работы, связанного с предметом контракта (ч. 2 ст. 31 Закона №  44-ФЗ ).

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

6. Требование к расходам на эксплуатацию товара (ч. 4 ст. 33 Закона №  44-ФЗ ). Оно устанавливается для необходимости обосновать документально расходы, которые будут понесены заказчиком при эксплуатации закупленного товара. Величина расходов отражается в численной форме индивидуально для каждого товара с учетом нормальных эксплуатационных и нагрузочных условий работы. Данное требование является критерием оценки заявок, окончательных предложений участников закупки (ч. 1 ст. 32 Закона №  44-ФЗ ).

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

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

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

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

• о наличии опыта работы к участнику закупки;
• к деловой репутации участника закупки;
• к наличию у участника закупки производственных мощностей, технологического оборудования, трудовых, финансовых и других ресурсов, необходимых для производства товара, поставка которого является предметом контракта, для выполнения работы или оказания услуги, являющихся предметом контракта, за исключением случаев, если возможность установления таких требований к участнику закупки предусмотрена данным законом. Это означает, что не допускается указывать требования, которые могут создать преимущественные условия участия для участников закупки (п. 2 ч. 1 ст. 17 Федерального закона от 26.07.2006 №  135-ФЗ «О защите конкуренции» ).

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

1. Закупка для нужд оборонного заказа. Особенности описания товаров, работ, услуг, входящих в состав государственного оборонного заказа для обеспечения федеральных нужд, могут быть установлены в соответствии с Федеральным законом от 29.12.2012 №  275-ФЗ «О государственном оборонном заказе» (ч. 6 ст. 33 Закона №  44-ФЗ ).

2. Закупка лекарственных средств. При закупке лекарственных средств необходимо отражать следующую информацию (пп. 6 ч. 1 ст. 33 Закона №  44-ФЗ ):

• международные непатентованные наименования лекарственных средств или (при отсутствии таких наименований) химические, группировочные наименования;
• при закупке лекарственных средств, входящих в перечень лекарственных средств, закупка которых осуществляется в соответствии с их торговыми наименованиями, а также при осуществлении закупки лекарственных препаратов согласно п. 7 ч. 2 ст. 83 Закона №  44-ФЗ разрешается указывать торговые наименования этих лекарственных средств. Данный перечень и порядок его формирования утверждаются Правительством РФ;
• предметом одного контракта (одного лота) не могут быть лекарственные средства с различными международными непатентованными наименованиями или (при отсутствии данных наиме-нований) с химическими, группировочными наименованиями при условии, что начальная (максимальная) цена контракта (цена лота) превышает предельное значение, установленное Правительством РФ, а также лекарственные средства с международными непатентованными наименованиями (при отсутствии этих наименований - с химическими, группировочными наименованиями) и торговыми наименованиями.

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

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

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

Чем точнее и корректнее будет составлено ТЗ, тем проще будет и поставщику и самому заказчику.

Техническое задание на закупку должно соответствовать требованиям законодательства. И помимо 44-ФЗ при подготовке ТЗ необходимо учитывать нормативные требования Антимонопольной службы и законодательства о техническом регулировании.

Ведь их нарушение, а также неполное или не конкретизированное описание требуемых услуг или товаров, может привести к подаче нецелевых заявок, а в случае отказа данным поставщикам — к жалобе в ФАС на необоснованное отклонение.

Разработка технического задания по 44-ФЗ

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

Совет: стоит помнить, что излишние требования и конкретизация могут противоречить требованиям 44-ФЗ, поэтому всегда стоит следовать его нормам.

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

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

в какой форме будут проводиться тендеры;

можно ли объединить некоторые лоты в одну закупку или разумнее будет произвести несколько операций;

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

От всех этих нюансов зависит, как именно будет составлен план закупок и план-график соответственно.

Подготовка технического задания

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

Обычно техническое задание закупки содержит следующие пункты:

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

технические характеристики объекта торга;

количество и комплектацию, если речь идет о товаре;

сроки поставки или выполнения работ;

требования с гарантии и безопасности;

условия оплаты и поставки;

другие требования не противоречащие условиям, обозначенными в законе;

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

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

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

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

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

ООО МКК "РусТендер"

Материал является собственностью сайт. Любое использование статьи без указания источника - сайт запрещено в соответствии со статьей 1259 ГК РФ

Павел Молянов

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.

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

Статья будет полезна:

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

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

Что такое техзадание и зачем оно нужно

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

Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.

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

Польза для клиента:

• Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
• Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
• Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
• Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
• Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

Польза для исполнителя:

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

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

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

Техзадание составляет исполнитель

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

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

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

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

Пишите однозначно и точно

Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

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

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

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

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

Поясните сложные термины

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

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

Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

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

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

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

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

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

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.

Объясните, что будет на каждой странице

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

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

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

Распишите сценарии использования сайта

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

• Действие пользователя.
• Ответное действие сайта.
• Результат.

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

Подробнее о сценариях использования читайте в «Википедии ».

Определите, кто отвечает за контент

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

Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.

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

Опишите дизайн (если сможете)

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

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

Вместо вывода: структура техзадания

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

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

• Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
• Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

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

Комментарии разработчиков

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

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

ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

• Информацию о компании и цель сайта.
• Требования к дизайну, цветовую гамму.
• Используемые технологии и CMS.
• Кто занимается контентом - мы или клиент.
• Структуру сайта вплоть до каждой страницы.
• Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.

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

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

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

Как правило, этапу составления технического задания предшествует проведение обследования предметной области, которое завершается созданием аналитического отчета. Именно аналитический отчет (или аналитическая записка) ложится в основу документа Техническое задание.

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

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

Руководствующими стандартами при написании технического задания являются ГОСТ 34.602.89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению» . Первый стандарт предназначен для разработчиков автоматизированных систем, второй для программных средств (разницу между данными сериями мы обсуждали в статье «Что такое ГОСТ»).

Итак, ниже мы представляем список и описание разделов, которые должно содержать техническое задание согласно ГОСТам.

ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению	ГОСТ 34.602.89 Техническое задание на создание автоматизированной системы
1. Введение	1. Общие сведения
2. Основания для разработки
3. Назначение разработки	2. Назначение и цели создания системы
	3. Характеристика объекта автоматизации
4. Требования к программе или программному изделию	4. Требования к системе
4.1. Требования к функциональным характеристикам	4.2. Требования к функциям (задачам), выполняемым системой
	4.1. Требования к системе в целом
	4.1.1. Требования к структуре и функционированию системы
	4.1.3. Показатели назначения
4.2. Требования к надежности	4.1.4. Требования к надежности
	4. 1.5. Требования к безопасности
	4. 1.6. Требования к эргономике и технической эстетике
4.3. Условия эксплуатации	4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
	4. 1.9. Требования к защите информации от несанкционированного доступа
	4. 1.10. Требования по сохранности информации при авариях
	4. 1.11. Требования к защите от влияния внешних воздействий
	4. 1.12. Требования к патентной чистоте
	4. 1.13. Требования по стандартизации и унификации
4.4. Требования к составу и параметрам технических средств	4. 1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
4.5. Требования к информационной и программной совместимости
4.6. Требования к маркировке и упаковке
4.7. Требования к транспортированию и хранению	4. 1.7. Требования к транспортабельности для подвижных систем
4.8. Специальные требования	4. 1.14. Дополнительные требования
	4.3. Требования к видам обеспечения
5. Требования к программной документации	8. Требования к документированию
6. Технико-экономические показатели
7. Стадии и этапы разработки	5. Состав и содержание работ по созданию системы
8. Порядок контроля и приемки	6. Порядок контроля и приемки системы
	7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
	9.Источники разработки

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

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

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

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

Пример:

«В данном документе создаваемая информационная система называется «Единое окно доступа к образовательным ресурсам», сокращенно ЕО.
Систему Единое окно доступа к образовательным ресурсам далее в настоящем документе допускается именовать Единое окно или Система.»

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

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

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

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

Назначение и цели создания системы

Данный раздел документа Техническое задание должен содержать назначение и цели создания системы.

Пример:

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

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

Создание информационной системы «Единое окно» должно обеспечить:

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

Создание Системы позволит сократить эксплуатационные затраты в результате повышения эффективности работы ведомства.»

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

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

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

Пример:

«4.1 Бизнес-процесс «Предоставление информации об образовательных учреждениях Российской Федерации

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

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

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

4.1.1 Регистрация образовательного учреждения в Системе

Регистрация образовательного учреждения Российской Федерации осуществляется ответственным сотрудником учреждения («Постановление Правительства …»).

Процесс регистрации образовательного учреждения включает следующие шаги:

• Автор создает запись об организации;
• Автор заносит данные организации;
• Система проверяет наличие лицензии для данной организации

• Если лицензия существует в базе данных, Система отправляет Автору сообщение об успешной регистрации;
• Если лицензия не найдена в базе данных, Система отправляет сообщение Автору об отсутствии лицензии для данной организации.»

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

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

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

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

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

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

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

Данный раздел технического задания также важен, как и описание функциональных требований, поэтому не следует ограничиваться фразой «Заказчику должна быть предоставлена вся документация согласно ГОСТ 34». Это означает, что вы должны предоставить весь пакет документов включая «Формуляр», «Паспорт» и т.п. Большинство документов из списка, указанного в ГОСТ 34.201-89 не нужны ни вам, ни заказчику, поэтому лучше сразу согласовать список на этапе разработки документа Техническое задание.

Минимальный пакет документов обычно включает:

• Техническое задание;
• Ведомость эскизного (технического) проекта;
• Пояснительная записка к Техническому проекту;
• Описание организации информационной базы;
• Руководство пользователя;
• Руководство администратора;
• Программа и методика испытаний;
• Протокол приемочных испытаний;
• Акт выполненных работ

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

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

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

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

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

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

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

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