Половина конфликтов между заказчиками и разработчиками начинается с одной фразы: «Мы же обсуждали, что это будет работать по-другому». Обсуждали — да, записали — нет. Техническое задание решает именно эту проблему: фиксирует, что именно будет сделано, как это будет работать и что считать готовым результатом.
В этом гайде — полная структура ТЗ с разбором каждого раздела, типичные ошибки с примерами «как не надо» и «как правильно», и ответ на вечный вопрос: кто должен писать ТЗ — заказчик или подрядчик.
Что такое ТЗ и когда оно реально нужно
Техническое задание — это документ, который описывает что должна делать система, а не как она устроена внутри. ТЗ отвечает на вопрос «что мы строим», а не «из чего мы строим». Архитектура, выбор фреймворков, структура базы данных — это задача разработчиков, не ТЗ.
Хорошее ТЗ выполняет три функции:
Когда ТЗ НЕ нужно
Честно: не всегда. Вот ситуации, когда подробное ТЗ — лишняя трата времени:
MVP-проекты до 500К. Когда вы проверяете гипотезу, а не строите enterprise-систему. Здесь достаточно user stories + прототипа в Figma. Развёрнутое ТЗ на 40 страниц для MVP — это 2–3 недели работы аналитика. За это время можно уже написать MVP. Подробнее о том, сколько стоит MVP и полноценный продукт — в нашей статье про стоимость мобильного приложения.
Работа по Agile с продуктовой командой. Если у вас есть выделенная команда, product owner и двухнедельные спринты — backlog заменяет ТЗ. Требования формируются итеративно, а не описываются заранее на год вперёд.
Типовые проекты. Интернет-магазин на готовой платформе, лендинг, корпоративный сайт на CMS — здесь достаточно брифа с описанием страниц и контента.
Правило: ТЗ нужно, когда проект стоит от 500К и/или длится дольше 2 месяцев, есть нетиповая бизнес-логика, и у заказчика и разработчика разные представления о результате. Чем дороже проект — тем дороже обходится недопонимание.
Структура хорошего ТЗ: 14 разделов
Частые ошибки при составлении ТЗ
Ошибка 1: описание решения вместо проблемы
Плохо: «На главной странице разместить слайдер с 5 баннерами, которые переключаются каждые 4 секунды, с анимацией fade-in».
Хорошо: «На главной странице — блок с текущими акциями (до 5 одновременно). Администратор управляет содержимым через админку. Посетитель видит акции без скролла».
Почему: в первом случае вы навязали конкретную реализацию (слайдер), хотя задачу «показать акции» можно решить лучше — карточками, каруселью, видео. Описывайте что нужно, а не как это делать.
Ошибка 2: неизмеримые требования
Плохо: «Система должна быть быстрой и удобной».
Хорошо: «Время загрузки любой страницы — не более 2 секунд при скорости интернета 10 Мбит/с. Ключевое действие (создание бронирования) — не более 3 кликов от главной страницы».
Почему: «быстро» и «удобно» — субъективные понятия. Для одного 3 секунды — быстро, для другого — медленно. Цифры убирают субъективность.
Ошибка 3: ТЗ на 100 страниц для проекта на 500К
Реальный случай: компания потратила 3 месяца и 400К на написание ТЗ для проекта стоимостью 1.2 млн. К моменту, когда ТЗ было готово, бизнес-требования уже изменились. Пришлось переписывать треть документа.
Правило: стоимость ТЗ — 5–10% от стоимости проекта. Для проекта на 1 млн — ТЗ за 50–100К (1–2 недели аналитика). Для проекта на 5 млн — ТЗ за 250–500К (3–4 недели).
Ошибка 4: забыть про edge-кейсы
Плохо: «Пользователь оплачивает заказ картой».
Хорошо: «Пользователь оплачивает заказ картой. Если оплата не прошла — показываем ошибку и предлагаем повторить или выбрать другой способ. Если оплата прошла, но товар закончился — автоматический возврат в течение 24 часов, уведомление на email. Если пользователь закрыл страницу во время оплаты — заказ резервируется на 30 минут».
Почему: основной сценарий описывают все. Ошибки и исключения — единицы. А именно на edge-кейсах ломается большинство систем.
Ошибка 5: не описать, что НЕ входит в проект
Заказчик ожидал мобильное приложение в комплекте с веб-платформой — «ну это же очевидно». Разработчик считал, что scope — только веб. Раздел «Ограничения и допущения» предотвращает такие конфликты.
Ошибка 6: описывать в одном месте, а потом противоречить в другом
Раздел 4: «Пользователь авторизуется по email и паролю». Раздел 9, сценарий: «Пользователь входит через SMS-код». Когда ТЗ пишется 3 недели разными людьми — противоречия неизбежны. Поэтому перед финализацией нужна сквозная вычитка: один человек читает весь документ от начала до конца и проверяет на внутренние конфликты.
Ошибка 7: не приоритизировать требования
Когда в ТЗ 80 функций и все помечены как «обязательные» — это не ТЗ, а список пожеланий. Используйте приоритизацию MoSCoW: Must have (без этого система не имеет смысла), Should have (важно, но можно запуститься без этого), Could have (хорошо бы), Won't have (не в этом релизе). Это помогает вписать проект в бюджет: если денег хватает только на Must + Should — остальное идёт в следующую итерацию.
Чек-лист: как проверить качество ТЗ
Прежде чем подписывать ТЗ и начинать разработку, пройдитесь по этим 10 пунктам:
Кто должен писать ТЗ?
Короткий ответ: подрядчик (студия, разработчик), но при активном участии заказчика.
Длинный ответ: ТЗ — это перевод бизнес-требований на язык разработки. У заказчика есть экспертиза в бизнесе (он знает процессы, боли, пользователей), у подрядчика — экспертиза в технологиях (он знает, что реализуемо, что дорого, где подводные камни).
ТЗ, написанное только заказчиком, содержит бизнес-требования без технической проработки — получается «хотелка». ТЗ, написанное только разработчиком без погружения в бизнес — техническая фантазия, оторванная от реальности.
Оптимальный процесс:
Сколько стоит написать ТЗ
(сайт, лендинг, MVP)
(веб-платформа, CRM)
(маркетплейс, ERP)
Что входит: серия интервью с заказчиком, анализ бизнес-процессов, описание функциональных и нефункциональных требований, прототипы ключевых экранов (Figma), карта интеграций, декомпозиция на этапы с оценкой.
Что получаете: документ в 15–60 страниц (в зависимости от проекта), кликабельный прототип, детальную смету на разработку.
Важно: если студия предлагает «бесплатное ТЗ» — скорее всего, это бриф на 2 страницы, а не полноценное техническое задание. Настоящее ТЗ требует 1–4 недель работы аналитика. За бесплатно такую работу никто не делает — стоимость просто включена в цену разработки (и вы за неё заплатите, не зная об этом).
Наш шаблон ТЗ
Мы подготовили шаблон технического задания, который используем на своих проектах. Это не пустая рыба из интернета — это рабочий документ, который мы адаптировали за годы разработки ПО для десятков клиентов.
Что внутри:
14 разделов с инструкциями по заполнению и примерами для каждого блока. Чек-лист проверки ТЗ — 25 пунктов, по которым можно оценить полноту и качество документа. Примеры формулировок — как описывать функции, роли, интеграции, нефункциональные требования.
Чтобы получить шаблон ТЗ — оставьте заявку, укажите «Шаблон ТЗ» в сообщении. Отправим на email в течение рабочего дня. Это бесплатно и без обязательств.
Если у вас уже есть представление о проекте, но нет ресурсов на написание ТЗ — мы можем взять эту задачу на себя. Проведём интервью, опишем требования, создадим прототипы и подготовим документ, по которому можно сразу начинать разработку.
FAQ
Можно ли начать разработку без ТЗ?
Можно — если проект стоит до 300–500К и занимает 4–6 недель. Для MVP часто достаточно user stories + прототипа. Но для проектов от 1 млн отсутствие ТЗ — это русская рулетка: может повезти, а может стоить дополнительных 30–50% бюджета на переделки.
Чем ТЗ отличается от брифа?
Бриф — это 2–5 страниц с общим описанием задачи: кто вы, что хотите, какой бюджет, какие сроки. Бриф заполняет заказчик за 1–2 часа. ТЗ — это 15–60 страниц с детальным описанием каждой функции, сценариев, интеграций, ограничений. ТЗ пишет аналитик за 1–4 недели. Бриф — вход в проект. ТЗ — основа для оценки и разработки.
Нужно ли описывать дизайн в ТЗ?
Да, но не макеты — а UX-требования. «Ключевое действие — не более 3 кликов», «Интерфейс должен работать на экранах от 320px», «Навигация как у Notion — боковая панель + поиск». Визуальный дизайн — это отдельный этап (UI), который идёт после утверждения ТЗ.
Можно ли менять ТЗ в процессе разработки?
Можно и нужно — бизнес-требования не стоят на месте. Но каждое изменение должно проходить через формальный процесс: описание изменения → оценка влияния на сроки и бюджет → согласование → внесение в ТЗ. Без этого процесса scope crawl (ползучее расширение) съест бюджет и мотивацию команды.
Какой формат лучше для ТЗ?
Для документа — Google Docs или Notion (совместное редактирование, комментарии, история версий). Для прототипов — Figma. Для сценариев — Miro (user flow диаграммы). Формат PDF — только для финальной версии, которая подписывается сторонами. В процессе работы документ должен быть «живым» — с возможностью комментировать и вносить правки.
ТЗ по ГОСТу — это нужно?
ГОСТ 34.602-89 описывает структуру ТЗ для автоматизированных систем. Он написан в 1989 году и содержит 30 разделов, включая «характеристику объекта автоматизации» и «сведения об условиях эксплуатации». Для государственных заказов и тендеров — да, нужно следовать ГОСТу. Для коммерческих проектов — нет. Современное ТЗ должно быть понятным обеим сторонам, а не соответствовать стандарту 37-летней давности.
Сколько времени действует ТЗ?
Практически: 3–6 месяцев. После этого бизнес-требования, рыночная ситуация и технологии меняются настолько, что ТЗ нуждается в актуализации. Если ТЗ написали, а к разработке приступили через 8 месяцев — пересматривайте документ перед стартом.
Если вы планируете проект и хотите начать с правильного ТЗ — свяжитесь с нами. Мы проведём бесплатную консультацию, поможем определить scope и предложим формат работы.