Как подготовить техническое задание на проектирование: структура, содержание и типичные ошибки

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

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

Зачем нужно ТЗ и что без него происходит

Формально ТЗ выполняет три функции одновременно:

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

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

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

Что собрать до написания задания

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

1. Цель проекта. Что должно получиться в итоге: здание, реконструкция, инженерная система, перепланировка, программный продукт? Для чего это нужно бизнесу или вам лично?
2. Исходные данные об объекте. Для строительства — документы на землю, градостроительный план, результаты изысканий (если есть), сведения о существующих зданиях и сетях. Для реконструкции — техпаспорт, обмеры, данные о состоянии конструкций.
3. Целевые параметры. Площадь, этажность, вместимость, мощность, производительность — те измеримые характеристики, от которых зависит масштаб решений.
4. Бюджетные рамки. Хотя бы ориентировочный диапазон стоимости строительства или внедрения. Он влияет на класс решений, которые проектировщик будет закладывать.
5. Требования регуляторов. Категория объекта, необходимость экспертизы, особые условия участка (охранная зона, санитарные нормы, историческая среда).
6. Стадийность. Нужна ли только стадия «проектная документация», полный цикл до рабочей документации или сопровождение авторским надзором.

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

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

Единого утверждённого шаблона ТЗ на проектирование не существует — форма свободная. Однако устойчивый набор разделов сложился в практике и закрывает практически все потребности. Рекомендуемый каркас выглядит так:

1. Общие сведения

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

2. Цель и назначение

Короткий раздел, но самый важный по смыслу. Опишите, зачем создаётся объект и как он будет использоваться. Формулировка «складской комплекс на 20 машиномест погрузки с круглосуточным режимом» даёт проектировщику несравнимо больше, чем «склад». Именно цель определяет компромиссы между стоимостью, сроками и характеристиками.

3. Исходные данные

Перечислите всё, что у вас есть: правоустанавливающие документы, топосъёмка, геология, существующие сети, предыдущие проекты. Укажите, какие данные предоставляете вы, а какие должен собрать исполнитель. Это ключевой пункт для распределения ответственности.

4. Основные технико-экономические показатели

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

5. Состав проектных работ

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

6. Особые требования и ограничения

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

7. Порядок сдачи-приёмки

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

8. Сроки и этапность

График с контрольными точками: например, эскизный вариант — через N недель, корректировка после замечаний, выпуск полного комплекта. Реалистичность сроков лучше обсудить с потенциальными исполнителями до подписания договора.

Пример структуры ТЗ в сжатом виде

Раздел ТЗ	Что фиксирует	Типичная ошибка при заполнении
Общие сведения	Объект, адрес, стороны, основания	Неточное описание местоположения и границ участка
Цель и назначение	Зачем нужен объект, режим использования	Подмена цели перечислением желаемых решений
Исходные данные	Документы, изыскания, существующие сети	Не разграничено, кто собирает недостающие данные
Технико-экономические показатели	Площадь, мощности, нагрузки	Цифры взяты «с потолка», без связи с бюджетом
Состав работ	Стадии, разделы, экспертиза	Не указано, входит ли сопровождение экспертизы
Особые требования	Ограничения, стандарты, предпочтения	Устные договорённости, не попавшие в текст
Приёмка и сроки	Формат результата, график, замечания	Нет критериев, по которым результат считается принятым

Как формулировать требования, чтобы их нельзя было исказить

Качество ТЗ определяется не объёмом, а проверяемостью формулировок. Сравните два варианта:

• «Предусмотреть современное энергосберегающее решение» — неисполнимо проверить, любой вариант подойдёт.
• «Удельное теплопотребление здания не должно превышать значения, соответствующего классу энергоэффективности B по действующей методике; выбор класса подтвердить расчётом» — есть измеримый критерий приёмки.

Полезные правила формулировок:

• Пишите через результат, а не через способ. Задача проектировщика — найти решение; ваше дело — описать, каким оно должно быть по свойствам. Жёстко диктовать конструктивные детали стоит только там, где у вас есть обоснованные причины.
• Каждое требование — измеримое или проверяемое. Площадь, нагрузка, класс, срок, формат файла. Если проверить нельзя, требование превратится в предмет торга.
• Разделяйте «обязательно» и «желательно». Помечайте приоритеты, чтобы исполнитель понимал, чем можно пожертвовать при конфликте требований.
• Не оставляйте ссылок на устные договорённости. Всё обсуждённое на встречах переносите в текст или в приложения.
• Указывайте источник каждого нормативного требования. Если вы требуете что-то сверх норм, так и пишите: «по требованию заказчика» — иначе возникнет путаница с ответственностью за соответствие.

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

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

Задача	Заказчик	Исполнитель
Правоустанавливающие документы на участок	Да	—
Инженерные изыскания	По договорённости	Часто исполнитель
Технические условия на подключение к сетям	Обычно заказчик	Может по доверенности
Разработка проектной документации	—	Да
Прохождение экспертизы и устранение замечаний	По договорённости	Чаще исполнитель
Согласования с соседями и службами	Определяется договором	Определяется договором

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

Типичные ошибки заказчиков

• Требования противоречат друг другу. Например, минимальный бюджет и максимальная площадь при жёстком сроке. Проектировщик обязан сообщить о конфликте, но лучше выявить его самому на этапе ТЗ.
• Копирование чужого ТЗ без адаптации. Шаблон из другого проекта тащит за собой нерелевантные требования и упускает ваши особенности.
• Избыточная детализация решений. Когда заказчик прописывает марку каждого кабеля и узел каждой балки, он фактически берёт на себя ответственность за проект — и лишает исполнителя возможности предложить более экономичный вариант.
• Отсутствие критериев приёмки. Формулировка «полный комплект документации» без перечня разделов позволяет сдать формально неполный результат.
• Игнорирование бюджета. Если не назвать ориентир стоимости реализации, проектировщик заложит решения, которые потом окажутся нереализуемыми.
• Незакреплённая процедуру изменений. Обязательно опишите, как вносятся изменения в ТЗ: письменно, с оценкой влияния на срок и цену. Иначе каждая правка станет бесплатной для вас и невыгодной для исполнителя — либо наоборот.

Пошаговый порядок подготовки

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

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

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

Перед утверждением пройдитесь по короткому чек-листу:

• Можно ли по каждому требованию однозначно определить, выполнено оно или нет?
• Для каждого раздела работ указан ожидаемый результат?
• Разграничена ответственность за исходные данные и согласования?
• Указаны форматы и комплектность передаваемых материалов?
• Есть ли процедура изменения ТЗ и оценки её влияния на сроки и стоимость?
• Все устные договорённости отражены в тексте?
• Требования не противоречат действующим нормам и друг другу?

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

Особенности разных типов проектирования

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

Сценарии действий в зависимости от ситуации

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

Что делать дальше

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

Частые вопросы

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

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

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

Можно ли менять ТЗ после начала работ? Да, но только письменно и с оценкой влияния на сроки и стоимость. Процедуру изменений стоит предусмотреть в самом задании.

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