Техническое задание

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

Раздел «что в проект не входит» стоит вынести отдельно, потому что он защищает обе стороны. Большинство конфликтов на коммерческих проектах возникают не из-за плохо описанной функции, а из-за функции, которую заказчик считал очевидной, а подрядчик — не входящей в объём: мультиязычность, выгрузка в маркетплейс, вторая роль администратора, миграция старых данных. Записанное «в первую версию не входит» стоит одной строки, а незаписанное — двух недель спора и испорченных отношений.

Для российских проектов есть отдельный слой формальностей. При работе с госзаказчиками и в тендерах ТЗ часто должно соответствовать ГОСТ — 34.602 для автоматизированных систем или 19.201 для программ, — и это меняет структуру документа, а не только его оформление. Для коммерческих проектов гост не обязателен, но требования к содержанию те же: рабочее ТЗ на веб-приложение обычно занимает 20–40 страниц и стоит отдельных денег, потому что это результат аналитики, а не пересказ пожеланий.

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

Смежные термины

• DiscoveryDiscovery — предпроектное исследование на 1–3 недели, в котором формулируют задачу, изучают пользователей и конкурентов, описывают сценарии и ограничения, а на выходе получают прототип, техническое задание и оценку с обоснованной вилкой вместо цифры из воздуха.
• ВайрфреймВайрфрейм — черновая схема экрана без цвета, шрифтов и картинок: на ней фиксируют состав блоков, их приоритет и переходы между экранами, чтобы договориться о логике интерфейса до того, как начнётся дорогая отрисовка.
• Fixed Price и Time and MaterialFixed Price и Time and Material — две модели контракта: в первой зафиксированы объём, срок и цена, а риск с надбавкой за него лежит на подрядчике; во второй оплачивается фактически потраченное время по ставке, а объёмом управляет заказчик.
• Продуктовый бэклогПродуктовый бэклог — упорядоченный по приоритету список всего, что может быть сделано в продукте: он не является планом с датами, постоянно пересматривается, и за порядок в нём отвечает один человек — владелец продукта.
• MVPMVP — первая версия продукта с одним сценарием, доведённым до конца: её выпускают за 4–8 недель, чтобы проверить спрос на реальных пользователях и оплатах, а не на опросах, и решить, стоит ли вкладываться дальше.

Услуги по теме

• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
• Аудит сайта: технический, SEO и UXПрежде чем менять дизайн, увеличивать бюджет на рекламу или писать техподдержке «сайт стал хуже работать», разберитесь, что на самом деле происходит. Аудит — это один отчёт, который сводит техническое состояние, SEO и юзабилити в список: что горит, что важно, а что можно не трогать.
• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.

Почитать подробнее

• Техническое задание на сайт: структура, шаблон и разбор ошибокТЗ — это не бюрократия, а рычаг: всё, что не соответствует заданию, подрядчик исправляет бесплатно. Разбираем структуру по разделам, показываем заполненный пример для корпоративного сайта и объясняем, как писать критерии приёмки, которые можно проверить.
• Как выбрать подрядчика на разработку: чек-лист вопросов и красные флагиПрактическое руководство по выбору подрядчика: кому подходит фрилансер, а кому интегратор, какие 25 вопросов задать на первом созвоне, как проверить кейсы в портфолио и что обязательно должно быть в договоре.
• Сколько стоит разработка сайта в 2026: разбор сметы по строкамРазбираем смету на разработку сайта построчно: сколько стоит аналитика, дизайн, вёрстка, бэкенд и интеграции, какие расходы всегда появляются после запуска и на чём можно сэкономить без последствий.