Техническое задание на сайт: структура, шаблон и разбор ошибок

Зачем нужно ТЗ на самом деле

ТЗ обычно объясняют бюрократически: «чтобы все понимали, что делаем». Это правда, но не главное. Настоящий смысл документа коммерческий: он определяет границу между «доработкой по гарантии» и «новой задачей за отдельные деньги». Всё, что описано в ТЗ и сделано иначе, подрядчик обязан исправить бесплатно. Всё, что в ТЗ не описано, вы будете оплачивать дополнительно — и это будет справедливо, потому что исполнитель этого не оценивал.

Из этого следует простой критерий качества: ТЗ хорошее не тогда, когда оно толстое, а тогда, когда по нему можно вынести однозначное решение в споре. Возьмите любую строку и спросите себя: если результат мне не понравится, смогу ли я показать пальцем на этот пункт и сказать «здесь написано иначе»? Если формулировка допускает две трактовки, она бесполезна для спора, а значит бесполезна вообще. Половина типовых ТЗ, которые ходят по рынку, состоит именно из таких строк.

Второй эффект ТЗ — сравнимость оценок. Когда пять подрядчиков считают по одному и тому же документу, разброс цен падает с пятикратного до полуторакратного, потому что все оценивают один объём. Без ТЗ вы получаете пять предложений на пять разных проектов и выбираете, по сути, наугад. Это одна из немногих ситуаций, когда потраченная на документ неделя измеримо экономит сотни тысяч рублей.

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

Структура ТЗ: одиннадцать разделов и что в них пишут

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

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

Раздел про интеграции почти всегда написан слишком коротко. Фраза «интеграция с CRM» не является требованием: требованием является описание того, какие данные, в какую сторону, в каком формате, с какой периодичностью и что делать при ошибке. Хорошая проверка: сможет ли разработчик по вашему тексту написать контракт обмена, не задавая вопросов. Если нет — раздел не готов, и разница между двумя трактовками этого пункта легко составляет несколько недель работы.

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

Заполненный пример: корпоративный сайт производственной компании

Ниже — фрагмент реального по формату ТЗ на корпоративный сайт среднего размера: производственная компания, 24 страницы, каталог продукции без онлайн-оплаты, две формы, интеграция с 1С и CRM. Это тот уровень детализации, при котором подрядчики дают сравнимые оценки, а споры на приёмке становятся редкими. Полный документ такого проекта занимает 15–25 страниц; здесь показаны ключевые формулировки из каждого раздела.

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

Отдельно стоит раздел про то, чего в проекте нет. Список исключений экономит больше споров, чем список требований: он снимает ожидания, которые никто не проговорил вслух. Фразы вроде «личный кабинет клиента в объём не входит», «мультиязычность не входит, предусмотрена архитектурная возможность добавить», «наполнение блога после запуска не входит» стоят одну строку каждая и закрывают целые категории конфликтов на приёмке.

• Цель: 60 заявок в месяц с органического трафика через 6 месяцев после запуска; вторая цель — сократить долю телефонных запросов спецификаций на 40%.
• Аудитория: снабженцы промышленных предприятий (70%), проектировщики (20%), дилеры (10%); основной сценарий — найти позицию, скачать спецификацию, отправить запрос цены.
• Структура: 24 страницы — главная, 6 услуг, каталог с 12 карточками продукции, о компании, производство, сертификаты, контакты, блог, политика конфиденциальности, согласие на обработку данных.
• Главная страница: первый экран с оффером и формой, блок из 4 преимуществ с цифрами, 6 услуг плиткой, 3 кейса с результатами, карта производства, форма запроса.
• Функциональность: каталог с фильтрами по 5 параметрам, поиск по названию и артикулу с подсказками от 3 символов, скачивание PDF-спецификаций, 2 формы с валидацией и согласием на обработку данных.
• Интеграции: выгрузка номенклатуры и наличия из 1С раз в час по REST в формате JSON, при недоступности 3 попытки с интервалом 5 минут и письмо ответственному; заявки уходят в CRM с UTM-метками, ответственный за настройку на стороне 1С — ИТ-отдел заказчика.
• Нефункциональные требования: LCP не более 2,5 с на мобильном 4G для 10 самых посещаемых страниц, 200 одновременных пользователей без деградации, HTTPS, защита форм от ботов, ежедневное резервное копирование с хранением 30 дней, база с персональными данными на сервере в РФ.
• Браузеры и устройства: две последние версии Chrome, Safari, Firefox, Edge и Яндекс.Браузера; проверка на iPhone от 12-й модели, Android от 11-й версии, экранах от 360 px.
• Контент: заказчик передаёт тексты 24 страниц и 40 фотографий до согласованной даты; при задержке срок проекта сдвигается на срок задержки, что фиксируется письмом.
• Дизайн: фирменные цвета и шрифты из брендбука 2024 года, три референса в приложении, запрет на стоковые фотографии людей, утверждает директор по маркетингу, включено 2 круга правок на макет.
• Не входит в объём: личный кабинет клиента, онлайн-оплата, мультиязычность (предусмотрена архитектурная возможность добавить), наполнение блога после запуска, мобильное приложение.
• Приёмка: чек-лист из 40 пунктов, соответствие макетам с допуском в 2 px, проверка на 5 устройствах, срок приёмки заказчиком — 5 рабочих дней с мотивированным отказом или молчаливым согласием.

Как писать критерии приёмки, которые можно проверить

Проверяемый критерий устроен всегда одинаково: в нём есть измеряемая величина, порог, условия измерения и инструмент. «Сайт должен быстро грузиться» не содержит ни одного из четырёх элементов, поэтому спорить по нему можно бесконечно: у подрядчика на офисном интернете и на десктопе всё летает, у вас на телефоне в метро — нет, и оба правы. «LCP не более 2,5 секунды на мобильном 4G для десяти самых посещаемых страниц по данным PageSpeed Insights» спора не порождает.

Второй приём — переводить качественные требования в сценарные. Вместо «удобная форма заявки» пишется последовательность: пользователь заполняет 4 поля, при ошибке видит подсказку под конкретным полем, после отправки видит подтверждение, заявка приходит в CRM с UTM-метками в течение 30 секунд, на почту отправителя приходит письмо. Каждый шаг этой цепочки проверяется одним действием, а вся цепочка целиком описывает то, что вы на самом деле имели в виду под словом «удобная».

Третий приём — назначать инструмент проверки прямо в критерии. Соответствие макету проверяется наложением с допуском в пикселях, скорость — конкретным сервисом на конкретных URL, нагрузка — нагрузочным тестом с указанным числом виртуальных пользователей, доступность — автоматическим аудитом плюс проверкой клавиатурной навигации. Когда инструмент назван в ТЗ, приёмка перестаёт быть обсуждением вкусов и становится процедурой на два часа.

ТЗ для Fixed Price и для Agile — разные документы

Fixed Price требует максимальной детализации, потому что фиксированная цена возможна только при фиксированном объёме. Здесь ТЗ описывает каждый экран, каждое поле, каждую интеграцию и каждый критерий приёмки, потому что всё, что не описано, станет предметом торга. Такое ТЗ занимает 20–40 страниц для среднего сайта, пишется две-четыре недели и стоит денег. Оно оправдано, когда требования устоялись, а бюджет утверждён и не может расти.

Agile и Time & Material работают иначе: детально описывается только ближайшая часть работы, а дальний горизонт остаётся на уровне целей и границ. Документ выглядит как видение продукта плюс приоритизированный список историй пользователей с критериями приёмки на две-три ближайшие итерации. Это не «ТЗ попроще», это другой инструмент: он оптимизирован под ситуацию, когда часть требований станет понятна только после того, как пользователи потрогают первую версию.

Подробное ТЗ иногда прямо вредит. Оно бесполезно, когда продукт исследовательский и половина гипотез отвалится после первых пользователей; когда рынок меняется быстрее, чем идёт разработка; когда объём работ меньше месяца и написание документа сопоставимо по стоимости с самой работой. В этих случаях детализация превращается в дорогой способ зафиксировать предположения, которые окажутся неверными, а потом ещё и платить за изменение зафиксированного.

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

Семь ошибок, которые порождают дополнительные счета

Первая и самая дорогая — ТЗ без метрик. Если в документе не написано, зачем делается проект и по каким числам будет считаться успех, любое решение по ходу принимается по вкусу, а не по цели. На такой проект невозможно ни принять решение о приоритетах, ни отказаться от лишней функции: аргумента «это не помогает нашей цели» просто не существует, потому что цель не сформулирована.

Вторая — «и так понятно». Всё, что кажется очевидным заказчику, очевидно только внутри его отрасли и его компании. Что происходит с заявкой после отправки, кто отвечает клиенту, нужно ли хранить историю запросов, что делать с товарами, которых нет в наличии, — на каждый такой вопрос у вас есть готовый ответ, а у разработчика нет. Незаданный вопрос всегда получает случайный ответ, и переделка стоит дороже, чем одно предложение в ТЗ.

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

Пятая — интеграции без контракта обмена. Шестая — отсутствие политики правок: не написано, сколько итераций включено и что происходит с седьмой, поэтому каждая правка становится предметом переговоров. Седьмая — нет раздела о том, что в проект не входит; именно этот раздел закрывает больше всего конфликтов на приёмке, потому что снимает ожидания, которые никто не проговорил вслух, но каждый держал в голове.

• Нет метрик — нечем обосновать ни один приоритет и ни один отказ от функции.
• «И так понятно» — незаданный вопрос всегда получает случайный ответ.
• Семь согласующих без владельца документа — обтекаемые формулировки вместо решений.
• Нет владельца контента — сроки срывает не код, а тексты и фотографии.
• Интеграция описана одной строкой — разница трактовок стоит недели.
• Не описана политика правок — каждая итерация становится переговорами.
• Нет раздела «не входит в объём» — ожидания всплывают на приёмке.

Кто должен писать ТЗ

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

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

Третий вариант — независимый аналитик или консультант, не участвующий в разработке. Максимальная объективность и максимальная цена: отдельная работа на 1–3 недели. Оправдан на проектах от миллиона рублей, где цена ошибки в требованиях сопоставима со стоимостью аналитики, а также в ситуациях, когда внутри компании нет согласия о том, что вообще нужно делать. IT-консалтинг в Veltos.Tech начинается от 50 000 ₽, и типичный формат здесь — именно предпроектная аналитика с ТЗ на выходе.

Честный вывод, который редко произносят подрядчики: платная предпроектная аналитика почти всегда дешевле плохого ТЗ. Неделя или три работы аналитика стоят заметно меньше, чем 30–50% удорожания проекта, которое стабильно возникает, когда требования выясняются по ходу. И у этой работы есть побочная выгода: результат аналитики принадлежит вам и остаётся полезным, даже если вы в итоге выберете другого исполнителя.

Частые вопросы

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

• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.
• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.

Читать дальше

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