Техническое задание на создание сайта: шаблон и ключевые разделы

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

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

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

Без ТЗ проект почти всегда уходит в размытые формулировки: «сделайте красиво», «как у конкурентов», «чтобы продавало». На практике это приводит к трём проблемам:

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

Особенно критично это проявляется, когда сайт заказывают у внешней студии, а не собирают своими силами. Я не раз видел, как отсутствие ТЗ превращало проект в бесконечный марафон правок. Документ помогает:

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

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

Когда ТЗ обязательно, а когда можно обойтись коротким брифом

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

Полноценное ТЗ нужно, если:

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

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

Короткого брифа достаточно, если:

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

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

Из чего состоит грамотное техническое задание

Ниже — практическая структура, которую можно брать за основу почти для любого проекта. Я использую её уже несколько лет, адаптируя под конкретные задачи.

1. Общие сведения о проекте

Здесь указывают базовую информацию:

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

Пример цели: «Сайт должен собирать заявки на замер и консультацию для компании по установке кухонь в Москве и области». Казалось бы, мелочь, но версионирование документа спасает, когда правки вносятся на лету и нужно понимать, какая редакция актуальна.

2. Описание задач сайта

Этот раздел отвечает на вопрос: что сайт должен делать. Я всегда прошу заказчика перечислить задачи глаголами — так меньше шансов уйти в абстракцию.

Подходящие формулировки:

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

Чем конкретнее цель, тем проще потом проверить результат. Например, «увеличить конверсию в заявку на 15% за счёт переработки форм» — это уже измеримая задача.

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

Здесь описывают, кто будет пользоваться сайтом:

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

Например, для B2B-сайта аудитория может быть такой:

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

Без понимания аудитории дизайнер может нарисовать «воздушный» интерфейс, который не решает реальных болей посетителей. Я всегда советую добавить в ТЗ хотя бы 2-3 персоны с их типичными сценариями.

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

Один из ключевых разделов. Здесь фиксируют:

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

Для корпоративного сайта это может быть:

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

Для интернет-магазина структура сложнее:

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

Я рекомендую рисовать простую блок-схему — она сразу выявляет пропущенные страницы вроде 404 или результатов поиска.

5. Подробное описание страниц

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

Например, для главной:

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

Такой подход помогает и верстальщику, и контент-менеджеру — все видят единую композицию.

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

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

Сюда входят:

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

Для каждой функции я всегда прошу описать:

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

Без такой детализации форма может отправлять данные «в никуда», а клиент — не получать автоответ.

7. Интеграции

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

Часто нужны:

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

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

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

Я не раз сталкивался с тем, что доступы к CRM лежат на стороне заказчика, а разработчик ждёт их неделями. Поэтому фиксация ответственности — must have.

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

Здесь описывают не «сделайте красиво», а конкретные ориентиры. Абстрактные пожелания гарантируют бесконечные правки.

Что указывать:

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

Полезно отдельно отметить:

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

Я всегда прошу показать 2-3 референса и столько же антипримеров — это быстрее приводит к общему пониманию.

9. Контент и материалы

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

Нужно зафиксировать:

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

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

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

Здесь описывают условия работы сайта. От этого зависит выбор платформы, хостинга и общая стоимость владения.

Ключевые пункты:

• адаптивность;
• кроссбраузерность;
• скорость загрузки;
• SEO-базовая подготовка;
• безопасность;
• резервное копирование;
• доступы;
• хостинг и домен;
• CMS или конструктор;
• ограничения по стеку.

Если сайт будет на WordPress, Bitrix, Tilda или другой платформе, это лучше указать сразу. Иначе подрядчик может заложить другой подход, который не устроит по бюджету или удобству. Я, например, всегда уточняю: нужна ли возможность самостоятельно править контент без программиста — это сразу отсекает чисто самописные решения.

11. Сроки и этапы

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

Типичные этапы:

• аналитика;
• прототип;
• дизайн;
• вёрстка;
• программирование;
• наполнение;
• тестирование;
• запуск.

Я всегда советую закладывать буфер в 15–20% времени на непредвиденные правки — это реалии разработки.

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

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

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

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

Я рекомендую составить чек-лист приёмки и пройти его совместно с подрядчиком — это снимает все вопросы о готовности.

Универсальный шаблон ТЗ на сайт

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

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

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

Шаг 1. Сформулируйте бизнес-цель

Не «сделать сайт», а что он должен дать:

• заявки;
• продажи;
• доверие;
• автоматизацию;
• информационную поддержку.

Цель должна быть измеримой. Например, «получать 50 заявок в месяц через форму обратной связи».

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

Ответьте на вопросы:

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

Я часто прошу заказчика представить одного реального клиента и описать его путь — это даёт больше, чем абстрактные демографические данные.

Шаг 3. Соберите структуру

Сначала список страниц, потом блоки на каждой ключевой странице. Удобно использовать интеллект-карты или простые списки. На этом этапе часто всплывают забытые разделы вроде «Политики конфиденциальности» или «Страницы 404».

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

Не забудьте про мелочи, которые кажутся очевидными, но без них сайт не работает как надо:

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

Я всегда моделирую минимум три сценария: успешная отправка, ошибка валидации, потеря связи — и описываю поведение для каждого.

Шаг 5. Пропишите техническую основу

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

Шаг 6. Добавьте материалы и сроки

Частая причина срыва дедлайна — контент. Если его готовит заказчик, сроки должны это учитывать. Я всегда ставлю контрольную точку: к такому-то числу тексты и фото должны быть переданы, иначе запуск сдвигается.

Шаг 7. Опишите приёмку

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

Типовые ошибки в техническом задании

По моему опыту, вот что чаще всего встречается в «сырых» ТЗ:

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

Особенно опасна последняя ошибка: когда ТЗ пишут маркетологи, оно может быть красивым, но бесполезным для разработки.

Чек-лист перед отправкой ТЗ подрядчику

Проверьте, есть ли в документе:

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

Если хотя бы половины этих пунктов нет, ТЗ ещё сыроватое. Я обычно прохожусь по этому списку вместе с заказчиком перед тем, как отдавать документ в работу.

Когда ТЗ лучше сделать отдельным документом

Отдельное ТЗ особенно полезно в проектах, где:

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

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

FAQ

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

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

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

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

Можно ли скачать шаблон и заполнить его самостоятельно?

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

Что важнее всего в ТЗ?

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

Как понять, что ТЗ хорошее?

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

Вывод

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

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