Техническое задание (ТЗ)
Техническое задание — документ, фиксирующий требования к продукту: что делаем, как должно работать, в какие сроки и за какие деньги. Защищает заказчика и исполнителя от разночтений и споров по объёму работ.
Определение технического задания
Техническое задание (ТЗ) — документ, который описывает, что именно должно быть сделано в проекте: функции, дизайн, технические требования, сроки и критерии приёмки. Это договорённость между заказчиком и исполнителем, переведённая из устных пожеланий в проверяемые пункты. ТЗ отвечает на вопрос «что считается выполненной работой» и служит точкой опоры при спорах: если функция описана — её делают, если нет — это доработка за отдельные деньги.
Без ТЗ проект движется на словах, и через месяц стороны вспоминают договорённости по-разному. Заказчик считает, что «личный кабинет само собой входил», исполнитель — что речь шла только о форме заявки. ТЗ снимает эти конфликты заранее. Для государственных проектов структура ТЗ регламентирована ГОСТ 34.602, для коммерческой веб-разработки используют упрощённые, но столь же конкретные форматы.
Зачем нужно ТЗ и как оно работает
ТЗ выполняет четыре функции: фиксирует объём, защищает обе стороны, служит основой оценки сроков и бюджета, помогает новым участникам команды войти в проект. Грамотное ТЗ — обязательный этап серьёзной разработки сайта и тем более комплексной разработки, где цена ошибки в требованиях измеряется неделями переделок. Часто составление ТЗ предваряет аудит текущей ситуации и целей бизнеса.
| Без ТЗ | С ТЗ |
|---|---|
| Объём работ плавает, растёт стихийно | Объём зафиксирован, доработки оплачиваются отдельно |
| Сроки и бюджет — пальцем в небо | Оценка опирается на конкретные пункты |
| Споры «вы обещали» без доказательств | Спор решается ссылкой на пункт документа |
| Новый разработчик не понимает проект | Документ вводит в курс за час чтения |
Важный принцип: ТЗ описывает «что» и «как должно работать», а не «как программировать». Выбор технологий и архитектуры остаётся за исполнителем, если иное прямо не оговорено. Перегружать ТЗ техническими деталями реализации так же вредно, как недописывать функции.
Структура и разделы ТЗ
Состав зависит от масштаба, но базовый каркас одинаков для большинства веб-проектов.
| Раздел | Что описывает |
|---|---|
| Цели и задачи | Зачем проект, какую проблему бизнеса решает |
| Целевая аудитория | Кто пользователи, их сценарии и устройства |
| Функциональные требования | Перечень функций: каталог, корзина, личный кабинет |
| Структура и навигация | Карта страниц, разделы, связи между ними |
| Дизайн-требования | Стиль, брендбук, референсы, адаптивность |
| Технические требования | Нагрузка, интеграции, хостинг, браузеры |
| Сроки и этапы | Декомпозиция работ, контрольные точки, приёмка |
Для гибких (Agile) проектов вместо громоздкого монолитного ТЗ часто используют набор пользовательских историй (user stories) формата «как пользователь, я хочу..., чтобы...». Но даже там критерии приёмки каждой истории должны быть конкретны и проверяемы.
Как писать ТЗ: пример и метрики качества
Качество ТЗ измеряется однозначностью формулировок. Плохой пункт: «сайт должен быстро загружаться». Хороший: «время загрузки главной страницы — не более 2,5 секунды по метрике LCP на мобильном 4G». Первый невозможно проверить, второй — да.
Мини-кейс: компания заказала интернет-магазин по устной договорённости без ТЗ. Через полтора месяца возник спор: заказчик ждал интеграцию с 1С и личный кабинет, исполнитель закладывал только каталог и корзину. Проект встал, бюджет вырос на 40%, сроки сдвинулись на 6 недель. На следующем проекте составили ТЗ на 18 страниц с перечнем из 47 функциональных требований и критериями приёмки — спорных ситуаций не возникло, проект сдали в срок, а разница в оценке между подрядчиками сократилась с двукратной до 15%. Затраты на ТЗ (около 5% бюджета) окупились предсказуемостью.
Связанные концепции
- Прототип — визуализирует требования ТЗ в виде кликабельной схемы экранов до начала разработки.
- Wireframe — каркас страниц, который часто прикладывают к ТЗ как наглядную структуру.
- Целевая аудитория — раздел ТЗ, задающий сценарии и требования к интерфейсу под конкретных пользователей.
- UX — пользовательские сценарии из ТЗ ложатся в основу проектирования удобства интерфейса.
- Скоуп проекта — зафиксированный в ТЗ объём работ; его изменение оформляется отдельным соглашением.
Частые ошибки
- Размытые формулировки — «удобный», «современный», «быстрый» без чисел нельзя проверить и принять.
- Пропуск критериев приёмки — не описано, как понять, что функция готова; приёмка превращается в спор.
- ТЗ диктует реализацию — заказчик прописывает, на каком фреймворке писать, связывая руки исполнителю без причины.
- Отсутствие раздела об интеграциях — забыли про 1С, CRM или оплату, и это всплывает в середине проекта.
- ТЗ без сценариев пользователя — есть список функций, но не описано, как человек ими пользуется, и логика разваливается.
Частые вопросы
Кто должен писать техническое задание?
Идеальный вариант — совместно: заказчик формулирует бизнес-цели и пожелания, исполнитель переводит их в технические требования и оценивает реализуемость. На практике ТЗ чаще пишет исполнитель или аналитик на стороне агентства после серии встреч и аудита, а заказчик согласовывает. Заказчик, который пишет ТЗ в одиночку, рискует упустить технические нюансы; исполнитель в одиночку — неверно понять бизнес-задачу.
Сколько стоит составление ТЗ?
Для лендинга или небольшого сайта ТЗ часто входит в стоимость проекта и занимает несколько дней. Для крупного продукта составление ТЗ — отдельный этап, который оценивают в 30 000–200 000 ₽ или 5–10% бюджета проекта. Эти деньги окупаются: детальное ТЗ снижает риск переделок, делает оценку точнее и убирает споры. Экономия на ТЗ обычно оборачивается перерасходом на стадии разработки.
Что делать, если требования меняются по ходу проекта?
Изменения нормальны, но их оформляют отдельно. Новое требование фиксируют как дополнение к ТЗ с пересмотром сроков и бюджета — это называется управлением изменениями (change request). Так обе стороны понимают, что доработка влияет на оценку. В Agile-подходе изменения закладываются в процесс: бэклог пересматривают каждый спринт, но при этом фиксируют объём текущей итерации.
Чем ТЗ отличается от договора?
Договор — юридический документ об обязательствах сторон, оплате, ответственности и сроках. ТЗ — техническое приложение к нему, описывающее, что конкретно делается. Обычно ТЗ прикладывают к договору как приложение, и тогда оно получает юридическую силу: невыполнение пункта ТЗ становится нарушением договора. Без привязки к договору ТЗ — рабочий документ, но не основание для претензий в суде.
Нужно ли ТЗ для небольшого лендинга?
Даже для лендинга стоит зафиксировать хотя бы краткое ТЗ на 1–2 страницы: структура блоков, какие формы, куда уходят заявки, требования к адаптивности, сроки. Это занимает немного времени, но снимает типовые споры «а где блок отзывов» и «почему форма шлёт не в ту почту». Чем меньше проект, тем короче ТЗ, но совсем без зафиксированных требований работать рискованно для обеих сторон.
Что важнее в ТЗ — детали или гибкость?
Баланс. Слишком детальное ТЗ сковывает и устаревает к моменту реализации, слишком общее не защищает от споров. Правило: жёстко фиксируют то, что критично для бизнеса (функции, интеграции, сроки, критерии приёмки), и оставляют свободу в деталях реализации, которые лучше знает исполнитель. Для динамичных проектов выбирают Agile-формат с пользовательскими историями вместо громоздкого монолитного документа.