Как составить ТЗ на разработку: шаблон для заказчика 2026

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

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

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

Без ТЗ типичный сценарий выглядит так: заказчик говорит «сделайте интернет-магазин», разработчик делает каталог с корзиной, заказчик видит результат и вспоминает про программу лояльности, многоуровневые скидки и интеграцию с 1С — которые «само собой разумелись». Доработки стоят столько же, сколько первоначальный проект, только оба злятся друг на друга.

ТЗ не нужно быть романом. Документ на 20-30 страниц с чёткими требованиями лучше, чем 200 страниц неструктурированного текста. Задача ТЗ — убрать неоднозначность, а не продемонстрировать масштаб мышления.

Структура хорошего ТЗ

Универсальная структура, которая работает для большинства проектов:

Цель и контекст проекта
Целевая аудитория и сценарии использования
Функциональные требования
Нефункциональные требования
Интеграции с внешними системами
Прототипы и макеты (или требования к ним)
Критерии приёмки
Ограничения: технологии, бюджет, сроки

Каждый раздел должен отвечать на конкретный вопрос. «Цель проекта» — не «создать современный удобный сайт», а «перевести 60% входящих заявок с телефона на онлайн-форму к 1 сентября 2026».

Описание целей и задач проекта

Хорошая цель измерима. Плохая цель: «улучшить пользовательский опыт». Хорошая цель: «снизить время оформления заказа с 12 минут до 3 минут».

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

Пример для корпоративного портала: «Сейчас менеджеры принимают 120 заказов в день по email, каждый занимает 20 минут на обработку. После запуска портала клиенты оформляют заказы самостоятельно, менеджер тратит 3 минуты на подтверждение. Цель — снизить трудозатраты менеджеров на обработку заказов на 70%.»

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

Функциональные требования

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

Инструмент для структурирования — User Story: «Как [роль], я хочу [действие], чтобы [результат]». Например: «Как закупщик, я хочу видеть историю заказов за любой период, чтобы сформировать отчёт для финансового директора».

Несколько правил для функциональных требований:

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

Расставляйте приоритеты по методу MoSCoW: Must have (без этого продукт не работает), Should have (важно, но можно запустить без этого), Could have (хорошо бы, но не критично), Won’t have now (сознательно оставляем за скобками).

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

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

Производительность. Страница каталога загружается не дольше 2 секунд при одновременной работе 500 пользователей. Это конкретное число — разработчик знает, под что проектировать архитектуру.

Доступность. Uptime 99.9% — это примерно 8 часов простоя в год. 99.5% — это уже 44 часа. Для B2B-портала, который работает в рабочее время, разница может быть некритична. Для круглосуточного сервиса — существенна.

Совместимость. Какие браузеры и устройства поддерживаем. Если ваша аудитория — бухгалтеры в офисе, можно написать Chrome/Edge последних двух версий. Если это публичный сервис — добавьте Safari и мобильные.

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

Безопасность. Минимум: HTTPS, валидация всех входных данных, защита от SQL-инъекций и XSS, хранение паролей через bcrypt. Для проектов с персональными данными — требования по 152-ФЗ.

Прототипы и макеты

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

Три уровня детализации:

Вайрфреймы (wireframes). Чёрно-белые схемы расположения элементов. Делаются за 2-3 дня, достаточны для согласования структуры и навигации. Инструменты: Figma, Balsamiq, даже нарисованные от руки сканы.

Кликабельный прототип. Вайрфреймы с навигацией — можно перемещаться между экранами. Позволяет проверить пользовательский путь: как клиент идёт от поиска товара до оформления заказа.

Дизайн-макеты. Готовые экраны со стилями, цветами, шрифтами. Нужны для согласования визуала до верстки. Если у вас есть брендбук — дайте его дизайнеру на старте, а не после того, как он уже нарисовал 30 экранов.

В ТЗ укажите: кто делает прототипы (разработчик или заказчик), какой уровень детализации нужен и на каком этапе.

Критерии приёмки

Критерии приёмки — список условий, при соответствии которым заказчик подписывает акт. Без этого раздела «готово» означает разное для разных людей.

Пример критерия: «Пользователь регистрируется по email, получает письмо с подтверждением в течение 2 минут, активирует аккаунт по ссылке». Это можно проверить, и результат однозначен.

Плохой критерий: «Сайт работает корректно». Что такое «корректно» — каждый понимает по-своему.

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

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

Ошибка 1: Описание интерфейса вместо требований. «Кнопка «Добавить в корзину» находится справа от фотографии товара» — это не требование, а решение. Требование: «Пользователь добавляет товар в корзину, не уходя со страницы каталога». Как разместить кнопку — вопрос дизайнера.

Ошибка 2: Отсутствие приоритетов. Когда все требования одинаково важны, при нехватке времени разработчик сам решает, что делать. Иногда это не то, чего ожидал заказчик.

Ошибка 3: Технические решения вместо задач. «Сделать на React» — если вы не понимаете разницы между React и Vue, не пишите это в ТЗ. Укажите требования к производительности и поддержке, а стек выберет разработчик.

Ошибка 4: Игнорирование пограничных случаев. Что происходит, если пользователь добавил товар в корзину, а он закончился на складе? Что если оплата прошла, но заказ не создался? Эти сценарии нужно описывать в ТЗ — иначе разработчик решит их по-своему, и его решение может не совпасть с вашим.

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

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