Как составить техническое задание на разработку сайта

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

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

В реальной студийной практике ТЗ становится документом, который одновременно читают дизайнер, верстальщик, бэкенд-разработчик, SEO-специалист и контент-менеджер. Если в нем указано, что форма заявки передает данные в CRM и дублируется на почту, — никто не будет спорить после сдачи, нужна ли эта интеграция. Поэтому ТЗ выгодно всем.

Чем оно помогает:

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

С чего начать: сначала цель, потом детали

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

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

Что нужно определить в начале

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

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

Из чего состоит сильное ТЗ

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

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

Как собрать требования без хаоса

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

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

Пошаговый алгоритм

1. Определите цель сайта и ключевой KPI: заявки, продажи, подписки, записи, звонки. Без цифровой метрики будет сложно оценить результат.
2. Изучите конкурентов: какие разделы у них есть, как устроены формы, CTA-кнопки, навигация и контент. Отмечайте не только сильные, но и откровенно слабые места — их вы будете обыгрывать.
3. Опишите целевую аудиторию: возраст, география, уровень технической подготовки, типовые возражения и ожидания от продукта.
4. Составьте список задач, которые должен решать сайт, в порядке приоритета — от критичных до «хорошо бы».
5. Согласуйте структуру и список страниц до начала прототипирования.
6. Зафиксируйте функционал каждой страницы: что именно делает пользователь и как система реагирует.
7. Пропишите технические и SEO-требования.
8. Добавьте критерии приемки и порядок согласования, иначе финальный этап превратится в хаос.

Что обязательно указать в ТЗ

1. Описание проекта

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

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

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

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

Пример для корпоративного сайта:

• Главная
• Услуги (с подстраницами конкретных услуг)
• Портфолио / кейсы
• О компании
• Блог
• Контакты
• Политика конфиденциальности

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

3. Функционал

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

Правильный подход выглядит так:

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

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

4. Дизайн и требования к интерфейсу

Дизайн в ТЗ — это не художественное описание, а система ограничений и ориентиров. Я всегда прошу клиента показать не только то, что нравится, но и то, что категорически не подходит, — это уменьшает шанс ухода в «красиво, но не то».

В разделе прописываем:

• референсы: сайты, которые нравятся как ориентир по стилю или структуре;
• решения, которые исключены (например, «не использовать анимированные слайдеры на главной»);
• стилистика: деловой минимализм, живой анимационный, строгий корпоративный;
• цветовая палитра и шрифты, если они уже закреплены в бренде;
• поведение интерфейса на мобильных устройствах: мобильная версия или адаптивная верстка, приоритетные элементы и блоки.

Как описывать требования к контенту

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

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

Что стоит прописать

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

Технические требования: без них сайт быстро начнет «сыпаться»

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

Что включить

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

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

Вместо «сайт должен быть быстрым» пишем измеримые ориентиры. Хороший пример:

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

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

SEO-блок в ТЗ: что важно не забыть

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

Что обычно описывают

• человекопонятные URL (ЧПУ);
• структуру заголовков H1–H3;
• шаблоны Title и Description с возможностью ручного редактирования для каждой страницы;
• управление индексацией служебных страниц;
• наличие sitemap.xml и robots.txt, генерируемых автоматически;
• канонические URL, если есть риск дублей;
• разметку Schema.org для товаров, статей, хлебных крошек, если она нужна;
• требования к скорости загрузки и мобильной версии.

Сроки, этапы и приемка

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

Удобная схема этапов

1. Сбор и согласование требований.
2. Прототипирование ключевых страниц.
3. Дизайн.
4. Верстка.
5. Программирование функционала.
6. Наполнение контентом.
7. Тестирование.
8. Запуск на боевом домене.

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

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

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

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

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

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

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

Мини-шаблон, с которого можно начать

Если вы впервые пишете ТЗ, этот каркас поможет быстро собрать осмысленный документ без пробелов:

1. Общая информация

Название проекта, заказчик, цель сайта, тип сайта, гео, язык.

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

Кто пользователь, его потребности, типовые возражения.

3. Структура

Список страниц и схема переходов.

4. Функционал

Что делает пользователь и как система на это реагирует.

5. Дизайн

Стиль, примеры, ограничения, адаптивность.

6. Контент

Какие материалы нужны, кто их предоставляет, в какие сроки.

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

CMS, хостинг, безопасность, скорость, браузеры, устройства.

8. SEO

Мета-теги, URL, индексация, микроразметка, скорость.

9. Этапы и сроки

Что и когда делается с точками согласования.

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

Как понять, что работа выполнена.

FAQ

Что важнее в ТЗ: дизайн или функционал?

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

Можно ли сделать ТЗ на 1–2 страницы?

Только для очень простого проекта, например, одностраничного лендинга с типовой механикой. Для корпоративного сайта, магазина или сервиса такого объема не хватит: останутся незакрытые сценарии и риск недопонимания.

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

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

Нужно ли включать SEO в ТЗ?

Обязательно, если сайт планируется продвигать в поиске. Базовые SEO-параметры, встроенные на этапе проектирования, обходятся в разы дешевле, чем обратная переделка уже готового проекта.

Что делать, если требования меняются по ходу проекта?

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

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