Как составить ТЗ на сайт или приложение в 2026 году: шаблон из 7 разделов и примеры
- Техническое задание на сайт или приложение состоит из семи разделов: цель и показатель успеха, пользователи и роли, функции и сценарии, нефункциональные требования, ограничения и интеграции, этапы с результатами, критерии приёмки.
- Требование в ТЗ годится, если его можно проверить: вместо «быстрый сайт» пишут порог, например основной контент страницы появляется не дольше чем за 2,5 секунды у 75% визитов.
- Чаще всего забывают офлайн-режим, права доступа по ролям, восстановление пароля, уведомления, обработку ошибок и требования 152-ФЗ, если сайт собирает имена и телефоны.
- ГОСТ 34.602-2020 действует с 1 января 2022 года и рассчитан на автоматизированные системы; для сайта или приложения он обязателен, только если его требует заказчик.
- Для первой оценки DNA Team готовое ТЗ не нужно: хватит цели, списка функций и интеграций, предложение с этапами и бюджетом приходит через 2 дня.
Семь разделов ТЗ с примерами, как переписать расплывчатое требование в проверяемое, какие требования забывают чаще всего, нужен ли ГОСТ и чек-лист перед отправкой подрядчику.
Дмитрий Забавин, сооснователь и CFO DNA Team. Обновлено 9 октября 2026 года.
Техническое задание на сайт или приложение собирают из семи разделов. Это цель с измеримым показателем, пользователи и роли, функции и сценарии, нефункциональные требования, ограничения и интеграции, этапы с результатами, критерии приёмки. Каждое требование формулируют так, чтобы его можно было проверить при сдаче работы.
Что такое техническое задание и чем оно отличается от брифа?
Техническое задание (ТЗ) это документ, по которому подрядчик оценивает, разрабатывает и сдаёт сайт или приложение. В нём записано, что должен уметь продукт, при каких условиях он работает и как заказчик поймёт, что работа сделана.
Бриф короче и отвечает на другой вопрос: что нужно бизнесу. Для первой оценки его обычно хватает.
| Бриф | Техническое задание | |
|---|---|---|
| Кто пишет | заказчик | аналитик вместе с заказчиком и командой разработки |
| Объём | 1–2 страницы | от нескольких страниц до отдельного документа на каждый модуль |
| Что внутри | цель, аудитория, примеры, бюджет, сроки | требования, сценарии, интеграции, этапы, критерии приёмки |
| Для чего | первая оценка и выбор подрядчика | точная смета, разработка и приёмка |
| Когда | до переговоров | после разговора с подрядчиком, до старта разработки |
С точки зрения финансового директора ТЗ это прежде всего основа сметы. Если требование в документ не попало, его нет и в цене, и при фиксированном бюджете спорить о нём придётся уже после оплаты. В DNA Team цену фиксируют до старта, и меняется она, только если заказчик расширит задачу. Граница «расширил или нет» проходит как раз по тексту ТЗ.
Из каких 7 разделов состоит ТЗ на сайт или приложение?
Шаблон ниже подходит и для корпоративного сайта, и для мобильного приложения, и для личного кабинета. В каждой строке пример формулировки, которую можно взять за образец.
| № | Раздел | Что в нём написать | Пример формулировки |
|---|---|---|---|
| 1 | Цель и показатель успеха | зачем продукт бизнесу и по какой цифре вы поймёте, что он работает | «доля заявок, оформленных без звонка менеджеру, не ниже 60% через три месяца после запуска» |
| 2 | Пользователи и роли | кто пользуется продуктом и что каждому разрешено | «гость смотрит каталог; клиент оформляет заказ и видит историю; менеджер меняет статусы; администратор управляет пользователями» |
| 3 | Функции и сценарии | что продукт умеет, по шагам, с приоритетом | «клиент повторяет прошлый заказ из истории в два нажатия; приоритет: обязательно в первой версии» |
| 4 | Нефункциональные требования | скорость, нагрузка, безопасность, устройства, доступность | «приложение показывает каталог без интернета и отправляет заказ после восстановления связи» |
| 5 | Ограничения и интеграции | с какими системами обмен, какие технологии и законы задают рамки | «новые заказы уходят в 1С каждые 5 минут, остатки приходят обратно раз в час» |
| 6 | Этапы и результаты | что сдаётся после каждого этапа | «этап 2: кликабельный прототип всех экранов клиента, согласованный заказчиком» |
| 7 | Критерии приёмки | по каким проверкам работу принимают | «все сценарии из раздела 3 проходят на последних версиях iOS и Android, критических ошибок ноль» |
Цифры в примерах условные. Подставьте свои. Важна форма. В каждой формулировке есть субъект, действие и условие, которое проверяется без спора.
Приоритет у функций в разделе 3 нужен, чтобы бюджет можно было подогнать под первую версию. DNA Team просит заказчиков размечать каждую функцию одним из трёх ярлыков: «обязательно в первой версии», «желательно», «можно позже». Когда смета выходит выше бюджета, обсуждают, какие функции из второй и третьей группы перенести на потом.
С чего начать, если ТЗ пишете впервые?
Начинают с цели и с того, как сейчас устроен процесс, который продукт должен изменить. Дизайн и выбор технологий идут позже.
- Запишите цель одной фразой с цифрой. «Сократить ручной ввод заказов» превращается в «через месяц после запуска 90% онлайн-заказов попадают в учётную систему без участия менеджера».
- Опишите текущий процесс. Кто сейчас делает работу, в какой программе, сколько это занимает, где теряются данные. Подрядчик часто находит упрощение именно здесь.
- Перечислите пользователей и роли. Для каждой роли: что видит, что может менять, что ей запрещено.
- Соберите функции списком и расставьте приоритеты. Сначала всё, что приходит в голову, потом разметка «обязательно, желательно, позже».
- Выпишите все системы, с которыми нужен обмен. CRM, 1С, платёжный сервис, телефония, склад. Отметьте, есть ли у них документация API и кто даст доступ.
- Добавьте примеры. Ссылки на сайты и приложения с пояснением, что именно в них нравится: «фильтр каталога как здесь», а не «сделайте похоже».
- Обсудите черновик с подрядчиком до финальной версии. Разработчик сразу скажет, какое требование дорогое, какое противоречит другому, а какое закрывается готовым модулем.
Шаги 1–5 дают материал для разделов о цели, ролях, функциях и интеграциях. Нефункциональные требования, этапы и критерии приёмки удобнее дописывать вместе с подрядчиком: он знает, какие пороги проверяются и какие промежуточные результаты бывают в его процессе. По тем же шагам DNA Team проходит первый созвон с заказчиком, он длится 30 минут.
Как написать требование, которое можно проверить?
Проверяемое требование содержит число, перечень или порог. Оценочные слова вроде «удобный», «быстрый», «современный» каждый понимает по-своему, поэтому при приёмке они превращаются в спор.
| Расплывчато | Проверяемо |
|---|---|
| Сайт должен быстро загружаться | основной контент страницы появляется не дольше чем за 2,5 секунды у 75% визитов, отдельно на мобильных и компьютерах |
| Интерфейс отзывчивый | реакция на нажатие не дольше 200 миллисекунд у 75% визитов |
| Удобный личный кабинет | в кабинете клиент видит статус заказа, скачивает счёт и акт, меняет адрес доставки |
| Интеграция с CRM | заявка с формы попадает в CRM за 1 минуту с полями: имя, телефон, источник, текст обращения |
| Надёжная авторизация | вход по телефону и коду из SMS, после 5 неверных кодов вход блокируется на 15 минут |
| Поддержка всех устройств | все сценарии раздела 3 проходят в двух последних версиях Chrome, Safari, Яндекс Браузера и Firefox |
Пороги скорости в таблице не придуманы. Google считает хорошим время появления основного контента (LCP) до 2,5 секунды, а время реакции на действие пользователя (INP) до 200 миллисекунд. Мерить оба показателя web.dev советует по 75% визитов, отдельно для мобильных и компьютеров. Эти цифры можно переносить в ТЗ без изменений, и подрядчик проверит их стандартными инструментами.
Сценарии пишите по схеме «исходная ситуация, действие, результат». Например: «клиент авторизован и у него есть хотя бы один завершённый заказ; клиент нажимает “Повторить”; в корзине появляются те же товары по текущим ценам, недоступные помечены». По такой фразе тестировщик сразу составляет проверку.
Какие требования в ТЗ забывают чаще всего?
Чаще всего забывают то, что не видно на макетах: поведение без интернета, права доступа, служебные сценарии и требования закона. Работа от этого не исчезает. Её оплатят позже, отдельной строкой.
- Офлайн-режим. Для приложения IDG Deco, каталога лакокрасочной продукции для консультантов в магазинах, работа без интернета была обязательным требованием: в торговых залах связь плохая. Приложение показывает 200+ продуктов офлайн и синхронизирует данные при подключении (кейс на dnateam.ru). Если такое требование появится после разработки, переделывать придётся хранение данных и синхронизацию.
- Роли и права. В портале Kaspersky Brand Portal для 4 000+ сотрудников из 34 офисов авторы загружают и обновляют материалы, а читатели только смотрят. Удалённый доступ с домашних компьютеров при этом должен был соответствовать требованиям службы безопасности компании. Такие правила пишут в ТЗ отдельной таблицей «роль и действие».
- Служебные сценарии. Восстановление пароля, смена телефона, удаление аккаунта, письма и push-уведомления, экран «нет связи», сообщение о неудачной оплате.
- Админка. Кто и как меняет тексты, цены, баннеры и статусы без программиста.
- Перенос данных. Каталог, клиентская база, история заказов из старой системы: в каком формате их отдадут и кто их чистит.
- Персональные данные. Если сайт собирает имена и телефоны, по 152-ФЗ согласие на обработку оформляют отдельно от других документов (часть 1 статьи 9), а политику обработки персональных данных публикуют на сайте (часть 2 статьи 18.1). Форму согласия и страницу политики вписывают в ТЗ сразу: после запуска это уже доработка с отдельной оценкой.
- Аналитика. Какие события считать: отправка формы, оформление заказа, звонок с сайта.
Нужен ли ГОСТ 34.602-2020 для ТЗ на сайт или приложение?
Для коммерческого сайта или приложения ГОСТ не обязателен: национальные стандарты в России применяются добровольно, если иное не установлено законом (часть 1 статьи 26 закона 162-ФЗ «О стандартизации»). Работать по ГОСТ приходится, когда этого требует заказчик, обычно государственный или крупная компания, и стандарт вписан в договор.
ГОСТ 34.602-2020 называется «Техническое задание на создание автоматизированной системы». Он действует с 1 января 2022 года, заменил ГОСТ 34.602-89 и распространяется на автоматизированные системы. Стандарт задаёт состав, содержание и оформление ТЗ на создание, развитие или модернизацию такой системы.
Если ГОСТ требуют, работа над содержанием не меняется: цели, роли, функции, интеграции, этапы и критерии приёмки всё равно нужны, меняется оформление. Когда ГОСТ не требуют, оформлять по нему ТЗ на лендинг или витрину ради солидности нет смысла. Объём работ от этого не изменится, а документ станет длиннее.
Как проверить ТЗ перед отправкой подрядчику?
Перед отправкой ТЗ прогоняют по списку: есть ли все семь разделов, проверяемы ли формулировки, не противоречат ли требования друг другу. Пробел, найденный на этом шаге, закрывают одной правкой документа.
Иллюстрация: чек-лист технического задания рядом с макетами сайта и приложения; перед отправкой подрядчику ТЗ проверяют по списку.
- У цели есть цифра и срок, по которым через несколько месяцев можно сказать, достигнута ли она.
- У каждой роли перечислено, что она видит и что может менять.
- У каждой функции стоит приоритет.
- В тексте нет слов «удобный», «быстрый», «современный», «интуитивный» без числа или перечня рядом.
- Описаны служебные сценарии: восстановление пароля, уведомления, ошибки оплаты и связи.
- Перечислены все интеграции, у каждой указаны направление обмена, частота и наличие документации.
- Есть требования к скорости, устройствам и браузерам, к работе без интернета, если она нужна.
- Учтены персональные данные: форма согласия и страница политики.
- У каждого этапа указан результат, который можно показать.
- Критерии приёмки привязаны к сценариям и проверяются без участия автора ТЗ.
- Требования не противоречат друг другу и бюджету.
- Назван человек со стороны заказчика, который отвечает на вопросы и принимает работу.
Последний пункт кажется формальным, но без него проект встаёт на любом вопросе: подрядчик ждёт ответа, а ответить некому.
Что делать, если ТЗ не готово, а оценка нужна сейчас?
Для первой оценки готовое ТЗ не нужно. DNA Team разбирает задачу на первом созвоне на 30 минут по цели, списку функций и интеграциям, а предложение с этапами и бюджетом присылает через 2 дня. Заявку читает лично CEO, ответ приходит в течение 2 рабочих часов.
Для сложного продукта, где требования ещё складываются, DNA Team предлагает два этапа. Сначала проектирование с фиксированной ценой на 6–7 недель. Потом разработку считают по документации, которая получилась на проектировании, в трёх вариантах: лёгкая первая версия, рабочая версия и полная реализация. Аналитика, проектирование и подготовка технических заданий входят в разработку сайта под ключ, так что писать ТЗ самому перед обращением необязательно.
Базовые цены DNA Team: простой сайт 500 тыс. – 1 млн ₽, корпоративный сайт 1–2 млн ₽, веб-приложение, портал или личный кабинет от 1 млн ₽, мобильное приложение 2–3 млн ₽. Первый релиз от 2 месяцев.
Как ТЗ превращается в цену и почему сметы двух подрядчиков расходятся, разобрано в статье о том, сколько стоит разработка сайта, приложения или ИИ-решения. Какие вопросы задать подрядчику до договора, собрано в чек-листе выбора подрядчика.
Что происходит с ТЗ после старта разработки?
После старта ТЗ остаётся рабочим документом: по нему сдают этапы, а каждое новое требование оформляют как изменение объёма с отдельной оценкой. Устные договорённости в чате «добавьте ещё кнопку» стоит сразу переносить в документ.
Порядок изменений лучше записать в договор заранее: кто предлагает изменение, кто оценивает его в часах и деньгах, кто подписывает. При фиксированной цене так новую функцию добавляют без конфликта. Новое требование оценивают отдельно, и заказчик решает, брать его в текущую версию или перенести на следующую.
Демо сайта или приложения в DNA Team появляется через 4–8 недель после старта. Это первый момент, когда ТЗ сверяют с живым продуктом. Расхождение, найденное на демо, исправить проще, чем после запуска, когда на продукт уже завязаны пользователи и данные.
Об авторе. Дмитрий Забавин, сооснователь и финансовый директор (CFO) DNA Team. Сооснователь стартапов CoActivity и LookLink, по образованию специалист по информационной безопасности (Санкт-Петербургский политехнический институт). DNA Team (dnateam.ru) основана в 2015 году, разрабатывает веб-сервисы, мобильные приложения и ИИ-решения и усиливает ИТ-команды компаний специалистами. Среди проектов: веб-портал для «Лаборатории Касперского», аналитический портал для вокзалов РЖД, спецпроекты для Aviasales, приложение с аудиогидом для Эрмитажа. 1-е место в Рейтинге Рунета 2026 среди компаний по аутстаффингу Санкт-Петербурга.
Услуга по теме: Создание сайтов
Источники и методика
- Пороги скорости: документация Google на web.dev, Largest Contentful Paint и Interaction to Next Paint.
- Стандарт: карточка ГОСТ 34.602-2020 в каталоге gostinfo.ru, статус «действует»; добровольность стандартов по статье 26 Федерального закона № 162-ФЗ «О стандартизации в Российской Федерации».
- Персональные данные: Федеральный закон № 152-ФЗ «О персональных данных», часть 1 статьи 9 и часть 2 статьи 18.1.
- Кейсы: страницы IDG Deco и Kaspersky Brand Portal на dnateam.ru.
- Цены, сроки, порядок оценки и фиксации цены DNA Team: страницы услуг создания сайтов, корпоративных сайтов, веб-разработки и разработки мобильных приложений, внутренний справочник фактов компании.
Внешние источники и страницы dnateam.ru открыты и сверены 8 октября 2026 года. Шаблон из семи разделов и примеры формулировок составлены по практике DNA Team.
Частые вопросы
Обязательно ли писать ТЗ самому перед обращением к подрядчику?
Нет. Для первой оценки хватит брифа: цель, список функций, интеграции, желаемый срок. Полное техническое задание обычно пишет аналитик подрядчика вместе с заказчиком на этапе проектирования. В DNA Team подготовка ТЗ входит в разработку сайта под ключ, а предложение по брифу приходит через 2 дня.
Сколько страниц должно быть в ТЗ на сайт?
Число страниц ничего не говорит о качестве ТЗ. Документ достаточен, когда подрядчик может оценить объём, не додумывая ключевое: есть цель, роли, функции с приоритетами, интеграции, нефункциональные требования, этапы и критерии приёмки. Для лендинга это несколько страниц, для портала с личными кабинетами отдельные документы по модулям.
Нужен ли ГОСТ 34.602-2020 для ТЗ на сайт?
Для коммерческого сайта или приложения ГОСТ 34.602-2020 не обязателен: национальные стандарты применяются добровольно. Стандарт действует с 1 января 2022 года и рассчитан на автоматизированные системы. По нему пишут ТЗ, когда этого требует заказчик, обычно государственный или крупная компания.
Чем ТЗ отличается от брифа?
Бриф описывает задачу бизнеса: цель, аудиторию, бюджет, сроки, примеры. Его хватает для первой оценки и выбора подрядчика. Техническое задание описывает продукт: роли, сценарии, интеграции, нефункциональные требования, этапы и критерии приёмки. По ТЗ составляют точную смету, ведут разработку и принимают работу.
Можно ли менять ТЗ после начала разработки?
Да, через порядок изменений, записанный в договоре: новое требование оценивают отдельно, и заказчик решает, брать его в текущую версию или перенести. В DNA Team цена фиксируется до старта и меняется, только если заказчик расширит задачу.