Как подготовить техническое задание на создание сайта

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

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

Зачем вообще нужно ТЗ на сайт

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

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

Хорошее ТЗ нужно, чтобы:

• зафиксировать цели проекта;
• описать функциональность без двусмысленности;
• согласовать объем работ до начала разработки;
• защитить обе стороны от разночтений;
• упростить приемку результата;
• сократить число правок на финальных этапах.

Что обязательно включить в техническое задание

Ниже — базовая структура, которая подходит для большинства сайтов: лендинга, корпоративного сайта, каталога, интернет-магазина, портала или сервиса. Я намеренно даю её с пояснениями по каждому пункту — потому что сухая структура без контекста работает плохо. Важно понимать не только «что писать», но и «зачем это нужно разработчику».

1. Общая информация о проекте

В начале ТЗ дайте короткое описание:

• кто заказчик;
• чем занимается компания;
• зачем нужен сайт;
• кто будет работать над проектом со стороны заказчика и исполнителя;
• есть ли уже домен, хостинг, фирменный стиль, материалы.

Этот блок кажется очевидным, но именно здесь часто всплывают сюрпризы. Например, выясняется, что домен зарегистрирован на бывшего сотрудника, доступов к хостингу нет, а логотип существует только в JPEG 200 на 150 пикселей. Лучше узнать это до старта, а не когда дизайнер уже ждет векторный логотип для макета.

Пример формулировки:

Сайт нужен для привлечения заявок от малого бизнеса в Оренбурге и области. Основная задача — показать услуги, кейсы, стоимость и упростить обращение через форму заявки и мессенджеры.

2. Цели и задачи сайта

Это один из самых важных разделов. Без него разработчик делает «сайт вообще», а не инструмент под задачу. Я не раз сталкивался с ситуацией, когда клиент говорит «нам нужен сайт», а на вопрос «зачем» отвечает «ну, чтобы был». Такой проект почти гарантированно разочарует обе стороны.

Цели могут быть такими:

• получать заявки;
• продавать товары;
• информировать клиентов;
• собирать записи на услугу;
• принимать оплату;
• поддерживать имидж бренда;
• автоматизировать внутренние процессы.

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

• увеличить количество обращений с сайта;
• сократить путь до заявки до 2–3 кликов;
• вывести каталог с фильтрами;
• подключить онлайн-оплату и уведомления менеджеру.

3. Целевая аудитория

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

Укажите:

• возраст;
• географию;
• интересы;
• уровень цифровой грамотности;
• боли и потребности;
• сценарии поведения на сайте.

Пример:

4. Структура сайта

Структура — это карта страниц и логика переходов. Чем точнее она описана, тем проще проектировать прототип и контент. В моей практике структура часто становится первым «моментом истины»: заказчик видит список страниц и понимает, что половину из них он не продумал. Это нормально — лучше осознать сейчас, чем когда верстка уже готова.

В ТЗ стоит указать:

• список страниц;
• что будет в меню;
• какие блоки нужны на каждой странице;
• какие страницы являются обязательными;
• есть ли скрытые страницы;
• как пользователь будет перемещаться по сайту.

Пример структуры для сайта услуг:

• Главная;
• Услуги;
• Портфолио;
• Цены;
• О компании;
• Блог;
• Контакты;
• Политика конфиденциальности;
• Страница 404.

Типичная ошибка

Многие пишут только «главная, услуги, контакты». Этого недостаточно. Исполнителю нужно понимать, что именно будет на странице услуг: список услуг, карточки, фильтр, блоки с преимуществами, формы, FAQ, примеры работ. Без этой детализации верстальщик сделает минимальную структуру, а потом начнутся правки в духе «а добавьте сюда ещё три блока». Каждая такая правка — это время и деньги.

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

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

Примеры функций:

• форма обратной связи;
• онлайн-чат;
• корзина и оформление заказа;
• поиск по каталогу;
• фильтры и сортировка;
• личный кабинет;
• калькулятор стоимости;
• запись на услугу;
• загрузка файлов;
• интеграция с CRM;
• подключение оплаты;
• подписка на рассылку.

Лучше писать в формате:

• что делает пользователь;
• что происходит после действия;
• какие данные должны передаваться;
• какие ограничения есть.

Пример:

При отправке формы заявка должна уходить на email менеджера и в CRM, а пользователь должен видеть сообщение об успешной отправке. Поля: имя, телефон, комментарий. Поле телефона обязательно.

6. Требования к дизайну

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

Лучше указать:

• стиль сайта;
• цветовые предпочтения;
• наличие фирменного стиля;
• примеры сайтов, которые нравятся;
• примеры, которые не нравятся;
• требования к адаптивности;
• уровень визуальной плотности;
• допустимые анимации.

Хорошо работают референсы с пояснениями:

• что нравится в первом сайте;
• что взять из второго;
• что точно не повторять;
• какие ощущения должен вызывать дизайн.

Полезный совет

Если у вас нет готового брендбука, зафиксируйте хотя бы базовые параметры:

• основные и дополнительные цвета;
• шрифты, если они уже выбраны;
• формат изображений;
• стиль иллюстраций и иконок.

Поверьте, дизайнер скажет вам спасибо. Особенно если вы пришлёте не просто «цвета как на старом сайте», а конкретные HEX-коды или хотя бы скриншоты с пометками.

7. Контент: тексты, фото, видео, документы

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

Укажите:

• кто пишет тексты;
• кто подбирает фотографии;
• нужны ли уникальные изображения;
• кто предоставляет видео;
• кто готовит прайс, сертификаты, реквизиты;
• в какие сроки должен быть передан контент.

Таблица для фиксации ответственности

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

8. SEO-требования

Если сайт должен привлекать трафик из поиска, SEO нужно закладывать сразу, а не «потом доработаем». Я видел проекты, где через полгода после запуска выяснялось, что мета-теги не заполнены, ЧПУ не настроены, а скорость загрузки такая, что Google PageSpeed показывает 23 балла из 100. Исправлять это на живом сайте — отдельная боль и бюджет.

В ТЗ стоит описать:

• структуру URL;
• мета-теги;
• заголовки H1–H3;
• микроразметку;
• ЧПУ;
• требования к скорости загрузки;
• адаптивность;
• настройку редиректов;
• карту сайта XML;
• файл robots.txt;
• требования к индексируемым страницам.

Для регионального сайта в России важно отдельно учитывать географию:

• город или область в структуре;
• локальные контакты;
• страницы под услуги по региону;
• упоминания географических ориентиров, если это уместно.

Ошибка

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

9. Технические требования

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

В нем обычно фиксируют:

• CMS или стек разработки;
• хостинг и серверные параметры;
• поддерживаемые браузеры;
• требования к HTTPS;
• безопасность;
• резервное копирование;
• скорость загрузки;
• совместимость с мобильными устройствами;
• интеграции с внешними сервисами.

Пример:

• сайт должен корректно работать в последних версиях Chrome, Safari, Firefox и Edge;
• адаптивная верстка обязательна;
• все страницы должны открываться по HTTPS;
• админка должна позволять редактировать тексты, изображения и мета-теги без программиста.

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

10. Интеграции и внешние сервисы

Если сайт должен работать не сам по себе, а в связке с другими системами, это нужно описать отдельно. Интеграции — это точка, где чаще всего возникают технические сложности и задержки. Потому что одно дело — сверстать форму, и совсем другое — подружить её с CRM, которая живёт на отдельном сервере и имеет свои ограничения по API.

Часто подключают:

• CRM;
• мессенджеры;
• телефонию;
• платежные системы;
• сервисы аналитики;
• email-рассылки;
• онлайн-чаты;
• складские системы;
• 1С.

Для каждой интеграции укажите:

• что именно подключается;
• какие данные передаются;
• кто дает доступы;
• кто отвечает за тестирование;
• что считается корректной работой.

11. Этапы, сроки и результат каждого этапа

Сайт лучше делать поэтапно. Тогда проще контролировать сроки и понимать, где возникла задержка. Без разбивки на этапы проект превращается в чёрный ящик: заказчик ждёт, исполнитель делает, а на середине срока выясняется, что дизайн ещё не согласован, хотя верстка уже должна была начаться.

Обычно этапы такие:

1. аналитика и сбор требований;
2. прототипирование;
3. дизайн;
4. верстка;
5. программирование;
6. наполнение контентом;
7. тестирование;
8. запуск;
9. гарантийная поддержка.

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

12. Критерии приемки

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

Примеры критериев:

• все страницы открываются без ошибок;
• формы отправляют данные;
• сайт адаптирован под мобильные;
• контент отображается корректно;
• основные браузеры поддерживаются;
• скорость загрузки соответствует согласованным требованиям;
• SEO-настройки реализованы;
• доступы переданы заказчику.

Чек-лист приемки

• [ ] Все страницы из ТЗ реализованы;
• [ ] Формы работают и данные доходят;
• [ ] Ошибок верстки на мобильных нет;
• [ ] Изображения не «плывут»;
• [ ] Мета-теги заполнены;
• [ ] Редиректы настроены;
• [ ] Аналитика подключена;
• [ ] Админка понятна и доступна;
• [ ] Резервная копия сделана;
• [ ] Инструкция передана.

Я рекомендую проходиться по этому чек-листу вместе с заказчиком. Это занимает час-два, но снимает все вопросы «а почему это не работает» в будущем.

13. Что приложить к ТЗ

Полезно добавить приложения:

• референсы;
• карту сайта;
• прототипы;
• структуру меню;
• примеры текстов;
• таблицу контента;
• список интеграций;
• гайд по стилю;
• список доступов.

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

Как составить ТЗ на сайт: пошаговый порядок

Шаг 1. Определите цель

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

Шаг 2. Опишите аудиторию

Кто будет пользоваться сайтом и какие задачи решать. Представьте реального человека, который открывает ваш сайт с телефона в перерыве между делами. Что он ищет? Что его раздражает? Что заставит его оставить заявку?

Шаг 3. Составьте структуру

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

Шаг 4. Зафиксируйте функции

Что сайт должен уметь, какие формы, сервисы и интеграции нужны. Пишите сценарии: «пользователь нажимает сюда → происходит это → данные уходят туда-то».

Шаг 5. Опишите контент

Кто делает тексты, фото, видео и в какие сроки. Будьте реалистичны: если у вас нет копирайтера и вы планируете писать тексты сами, заложите на это время и пропишите дедлайны.

Шаг 6. Пропишите дизайн и референсы

Покажите примеры и ограничения. Чем конкретнее — тем лучше. «Нравится навигация как на сайте X, но цветовая гамма как у Y, а карточки услуг не как у Z» — это уже рабочий бриф для дизайнера.

Шаг 7. Добавьте техтребования

CMS, адаптивность, браузеры, безопасность, SEO. Если вы не знаете, какую CMS выбрать — спросите у исполнителя, но зафиксируйте ответ в ТЗ.

Шаг 8. Установите сроки и этапы

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

Шаг 9. Определите критерии приемки

Укажите, что именно должно быть проверено. Вернитесь к чек-листу из раздела 12 и адаптируйте его под свой проект.

Типичные ошибки в ТЗ

Вот что чаще всего портит проект. Я собирал этот список не из книг, а из реальных ситуаций, когда приходилось распутывать проекты на середине срока:

• слишком общие формулировки;
• отсутствие целей;
• нет списка страниц;
• не описаны формы и сценарии;
• не указан ответственный за контент;
• забыты мобильная версия и SEO;
• нет критериев приемки;
• референсы приложены без пояснений;
• не зафиксированы интеграции;
• сроки указаны без этапов.

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

Кому особенно важно делать подробное ТЗ

Подробное ТЗ особенно нужно, если:

• проект дороже обычного лендинга;
• в сайте много функций;
• участвуют несколько подрядчиков;
• есть интеграции с CRM и оплатой;
• сайт делается не на шаблоне;
• запуск влияет на продажи и заявки;
• нужен SEO-результат;
• заказчик хочет контролировать качество и сроки.

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

FAQ

Что делать, если у заказчика нет четкого понимания, какой сайт нужен?

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

Можно ли делать ТЗ в таблице?

Да, если проект небольшой. Для лендинга или простого корпоративного сайта таблицы в Google Sheets часто достаточно. Но для сложного сайта лучше использовать отдельный документ с разделами и приложениями — таблица становится нечитаемой, когда в ней больше пяти вкладок и сотни строк.

Кто должен готовить ТЗ — заказчик или исполнитель?

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

Нужно ли ТЗ для простого лендинга?

Да, но в упрощенном виде. Даже на лендинге важно зафиксировать структуру блоков, тексты, формы и критерии приемки. Без этого вы рискуете получить лендинг, где кнопка «Заказать» ведёт в никуда, а форма не отправляет данные — и узнаете об этом после запуска.

Как понять, что ТЗ получилось хорошим?

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

Вывод

Хорошее техническое задание на сайт экономит деньги, время и нервы. Оно превращает абстрактную идею в понятный план работ: с целями, структурой, функционалом, сроками и критериями приемки. Чем детальнее и честнее прописаны требования на старте, тем выше шанс получить сайт, который действительно решает задачи бизнеса и не требует бесконечных переделок.

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