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

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

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

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

Из чего состоит ТЗ?

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

Общие сведения (описание)

Здесь указываются:

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

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

• Подготовительный этап;
• Проработка концепции сайта;
• Проектирование;
• Создание дизайн-макета;
• Разработка дизайна страниц;
• Вёрстка;
• Программирование;
• Наполнение контентом;
• SEO-оптимизация;
• Тестирование;
• Запуск.

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

Назначение и цели

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

Назначение сайта . Каких целей созданием сайта необходимо достичь? Для чего он нужен, какие задачи решает?

• Реклама и привлечение новых клиентов;
• Поддержка заказчиков и партнёров;
• Демонстрация выполненных работ;
• Ознакомление со списком услуг;
• Создание и поддержание имиджа компании.

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

Целевая аудитория . Кто будет пользоваться сайтом, для кого он создаётся?

• Веб-мастера, блогеры;
• Владельцы интернет-магазинов;
• Владельцы информационных порталов;
• Рекламные студии;
• Представители присутствующих в онлайн-пространстве фирм и компаний.

Требования

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

Тип . К какой категории принадлежит веб-ресурс?

• Посадочная страница;
• Сайт-визитка;
• Корпоративный сайт;
• Информационный портал;
• Интернет-магазин.

Требования к оформлению . Они могут быть следующего вида:

• Сайт должен быть минималистичным и при этом отражать род деятельности компании.
• Основные цвета: зелёный и белый, по брендбуку или на усмотрение дизайнера.
• В оформлении нельзя использовать анимацию, всплывающие окна, Flash-элементы, дизайнерские излишества.
• Нельзя использовать шрифты с засечками (можно применять стандартные: Verdana, Arial, Tahoma и т. д.). Кегль должен обеспечивать максимальное удобство чтения (12-16 пт.).

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

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

• Русский;
• Английский;
• Эсперанто.

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

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

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

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

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

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

• Главная страница
• Услуги

• Копирайтинг
• Рерайтинг
• SEO-коперайтинг
• Корректура
• Транскрибация
• Контент-менеджмент
• Контент-маркетинг

• Портфолио
• О нас
• Контакты

Сделайте и краткое описание каждой страницы, дайте определения. Например, что подразумевается под страницей «Контакты»? Она должна содержать адрес, телефон и электронную почту в текстовом виде? Или там должна присутствовать форма обратной связи? А может, нужно встроить код Яндекс Карт? Или же на странице контактов должно размещаться всё перечисленное, да ещё и ссылки на представительства в социальных сетях?

Желательно контент или хотя бы его наброски приготовить еще до начала работ с подрядчиком. Это будет способствовать более эффективной коммуникации.

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

Описание разделов сайта

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

Главная страница . Формулировка задачи может быть в следующем виде.

Основная часть главной страницы должна быть выполнена в виде Landing Page . На ней сверху вниз должны располагаться следующие элементы:

• Шапка - логотип, название фирмы;
• Меню навигации;
• Информация об акциях и скидках;
• Кнопка заказа;
• Рекламный текст;
• Блок с пятью лучшими работами и ссылкой на раздел портфолио;

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

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

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

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

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

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

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

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

8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.

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

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

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

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

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

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
• Правила составления Software requirements specification (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из

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

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

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

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

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

Конструкторское бюро

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

Для чего нужно техническое задание

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

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

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

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

Разработка технического задания

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

Наличие бороды необязательно

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

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

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

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

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

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

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал . Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Примеры технического задания

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

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

ТЗ на разработку интернет магазина

ТЗ на разработку мобильного приложения

ТЗ на сайт

ТЗ на сервисы/обновления

Если нужно больше образцов, просто погуглите.

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

Вот так надо

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

Например для задачи “Кнопка лайк на сайте”:

1. Описание: необходимо создать кнопку “Лайк” на нашем сайте.
2. Назначение и цели: вовлечение пользователей, выдача/рейтинг материалов по кол-ву лайков.
3. Требования: дизайн такой (пример: ссылка на что-то похожее), функционал (любой пользователь может оценить картинку и поставить лайк, система сайта учитывает кол-во лайков и меняет выдачу материалов), технологии (доступно на desktop и mobile версиях сайта).
4. Описание работ: нарисовать 3 варианта макетов для кнопок (дата готовности: 01.10.17), разработать систему выдачи материалов по лайкам (дата: 14.10.17), тестирование функции (дата: 16.10.17), релиз (дата: 17.10.17)
5. Приемка работ: пользователь нажимает на кнопку лайк, система засчитывает нажатие, выдача материалов меняется.
6. Приложения: эскизы, наброски, примеры проектов, где работает похожая функция.

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

Ну вот

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

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

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

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

Суть и понятие ТЗ заключается в следующем:

• Определение четких критериев выполнения работ по целям, задачам, срокам, результатам и т.д. Благодаря этому можно на любом этапе работ определить ошибки и устранить недочеты;
• Регулирование ответственности сторон, т.к. документ согласован и обоюдно принят. Иногда каждый этап работ согласовывается отдельно, чтобы в результате ошибок была четко определена степень вины каждой стороны, и в соответствии с этим распределены суммы убытков;
• Составляется на основе четких расчетов и научных исследований, поэтому практически исключает «провальность» мероприятий;
• Пишется в доступной форме, без использования сложной профессиональной терминологии, что делает его понятным простому обывателю. Это очень важный пункт, потому что несоблюдение определенных норм из-за недостатка информации, может повлечь санкции со стороны надзорных органов, ведь «незнание не освобождает от ответственности».

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

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

Со стороны заказчика:

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

Со стороны исполнителя:

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

С обеих сторон:

• Сократить количество неточностей и ошибок;
• Прийти к общему виду готового объекта;
• Совершить согласование работ после каждого пункта.

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

Структура и как правильно составить

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

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

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

Обратите внимание! Если индивидуальные разработки позволят улучшить показатели эффективности объекта, то их нужно согласовать с Госстандартом РФ и получить разрешение на применение. Но здесь речь не идет о тех требованиях, которые касаются охраны здоровья и природы, а также отвечают за безопасность – их менять нельзя!

Структура и состав документа будут утверждаться на основе типа проектируемой продукции. Но, в общем, ТЗ должно содержать следующую информацию:

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

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

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

Образец формы

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

№	Перечень требований и основных данных	Описание
1.	Основа для создания и проектирования	Целевая программа на федеральном уровне Программа субъектов РФ Программа муниципалитетов Создание по решению Президента РФ, правительства РФ и других уполномоченных органов По инициативе компании-застройщика
2.	Разновидность постройки	Новое строение Реконструируемое Предназначенное для капитального ремонта или текущего
3.	Этапы проектирования	Здесь перечисляются стадии работ по проектированию: создание проекта требуемая документация рабочий макет эскизный макет и т.д.
4.	Рассматриваемые варианты работ	Прописывается информация о работах для сравнения или проводимых конкурсах по выбору проектных решений
5.	Финансовые источники	Средства из федерального бюджета Регионального Муниципального Внебюджетные средства
6.	Условия работ, требующие особого внимания	Описать такие условия или дать рекомендации по их преодолению
7.	Технические параметры объекта	Предоставляется подробная информация о возможностях здания, назначения, технических характеристиках (этажность, кол-во подъездов) и т.д. Все что требуется для понимания социально- экономической значимости
8.	Данные по встроенным помещениям	Если площади жилых домов планируется частично отдать под общественные или другие организации, то этот пункт нужно заполнить
9.	Качественные показатели здания, говорящие об экологической безопасности, конкурентоспособности и целесообразности	Здесь указываются все данные о постройке технически значимых объектов производства, размещения его отдельных блоков, технологии их постройки, расстановки оборудования
10.	Требования по используемым материалам и правильным размещениям площадей разного назначения сооружения	Прописываются данные по правильному размещению отдельно взятых площадей, а также описывается материал работ, который более эффективен в том или ином участке
11.	Требования по архитектурно- культурным работам	Описывается планируемые работы по благоустройству прилежащих территорий
12.	Требования инженерно- технического плана	Описать системы вентиляции, канализации, водопровода и пр.
13.	Требования по стадийному вводу в эксплуатацию объекта	Указывается информация по каждому объекту комплекса, его отдельных частей. Необходима информация по срокам, условиям сдачи и вводу в эксплуатацию
14.	Требования по разработке природоохранных мер	Здесь описывается влияние объекта постройки на экологическую обстановку и окружающую среду
15.	Требования по предоставлению условий для отдельных групп граждан	Данные по элементам конструкций, предназначенных для инвалидов, стариков и детей.
16.	Требования по безопасности и охране труда	Расписываются материалы по теме охраны труда и здоровья работников будущего строения. Подходит для зданий промышленного назначения.
17.	Требования по санитарно- эпидемиологическим нормам	Описать документы для проверяющих организаций: Роспотребнадзор, СЭС и т.д.
18.	Требования по противопожарной безопасности	Описание соответствия номам пожарной безопасности
19.	Требования по материалам для демонстрации	Заполняется в случае использования 3D макетов и презентаций
20.	Дополнительные требования	Специальные требования, внесенные самим заказчиком по необходимости, но в рамках существующих норм

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