Что такое ТЗ и как правильно составить техническое задание

Чем ТЗ отличается от брифа и проектного задания

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

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

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

Документы дополняют друг друга: бриф задаёт контекст, ТЗ фиксирует требования, проектное задание связывает всё в рамках проекта.

Кто готовит и согласует ТЗ

Роли: заказчик, исполнитель, совместная работа

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

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

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

Как закрепить ТЗ в договоре и управлять изменениями

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

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

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

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

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

Цель и ожидаемый результат

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

Пример: не «разработать сайт», а «запустить сайт для онлайн-продажи курсов с каталогом, корзиной и оплатой». Чем конкретнее формулировка цели и инструкция, тем проще будет оценить результат на этапе приёмки.

Требования и функциональность

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

Требования делят на обязательные и желательные. Обязательные влияют на приёмку — без них проект не считается выполненным. Желательные реализуют при наличии времени и бюджета.

Ограничения и допущения

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

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

Критерии приёмки и способы проверки

Критерии приёмки фиксируют, при каких условиях работа считается выполненной. Без них оценка результата становится субъективной.

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

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

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

Пошаговый алгоритм составления ТЗ

Сбор вводных и контекста проекта

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

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

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

Описание требований и приоритизация

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

Затем требования приоритизируют. Один из рабочих подходов — разделение на три группы:

• Обязательные: без этого работа не принимается
• Важные: влияют на качество и ценность результата
• Желательные: реализуют при наличии ресурсов

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

Финальная проверка и утверждение

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

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

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

Шаблоны и примеры ТЗ для разных задач

ТЗ для маркетинга и рекламных активностей

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

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

Пример структуры ТЗ на кампанию:

• Цель: привлечение заявок по цене не выше N рублей
• Аудитория: описание сегментов и географии
• Площадки: Поиск, Рекламная сеть Яндекса, конкретные форматы объявлений
• Бюджет и сроки
• KPI: количество заявок, стоимость клика, конверсия

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

Когда ТЗ включает продвижение нескольких продуктов, регионов или сегментов аудитории, специалист использует Мастер кампаний или Единую перформанс-кампанию — они позволяют создавать отдельные кампании с разными настройками и KPI под каждую задачу.

Чётко прописанное ТЗ для рекламы сокращает время на согласование, ускоряет запуск кампаний и позволяет объективно оценивать результат на основе заранее согласованных критериев.

ТЗ для дизайна

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

Основные блоки ТЗ для дизайна:

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

ТЗ для разработки/IT

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

Ключевые разделы:

• Описание системы и её назначение
• Функциональные требования: что система должна делать
• Нефункциональные требования: скорость, нагрузка, безопасность
• Интеграции с внешними сервисами
• Требования к документации и поддержке

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

Частые ошибки в ТЗ

Слишком общие формулировки и «хочу красиво»

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

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

Нет критериев приёмки и ответственности сторон

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

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

Несогласованность требований и отсутствие истории правок

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

Все изменения в документе фиксируют с датой и версией. История правок помогает понять, на каком этапе появилось то или иное требование и кто его инициировал.

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

Можно ли менять требования по ходу работ?

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

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

Как понять, что ТЗ достаточно полное?

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

Другой подход: пройти по каждому требованию и проверить, можно ли его проверить объективно. Если ответа нет — требование сформулировано недостаточно конкретно.

Что делать, если подрядчик не понимает ТЗ?

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

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

Заключение

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

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

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