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

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

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

Когда ко мне приходит предприниматель с запросом «сделайте сайт», первый вопрос всегда один: «А зачем он вам?» С этого и начинается нормальное ТЗ. Документ нужен не для галочки — он реально экономит деньги и нервы на дистанции.

Хорошее ТЗ:

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

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

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

Нет универсального лекала «пиши ТЗ на 50 страниц всегда». Степень детализации зависит от сложности проекта. Я обычно оцениваю так:

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

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

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

1. Цель проекта

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

Хорошие формулировки цели:

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

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

2. Описание аудитории

У сайта всегда есть живой пользователь, и если не понимать, кто он, структура получится абстрактной. Я обычно прошу заказчика описать не абстрактную «ЦА 25–45 лет», а конкретный портрет: кто этот человек, с какой болью он приходит, что его тормозит, что должно случиться после его визита.

Что фиксируем в ТЗ:

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

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

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

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

Пример нормальной структуры:

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

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

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

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

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

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

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

Сюда относятся:

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

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

Как правильно собирать информацию для ТЗ

Сильное ТЗ редко пишется с нуля за один присест. Обычно это пошаговая сборка, где каждый этап добавляет слой конкретики. Вот проверенная последовательность.

Шаг 1. Определить бизнес-задачу

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

Хорошие формулировки:

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

Плохие формулировки (которые я регулярно слышу и сразу перевожу в конкретику):

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

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

Шаг 2. Собрать примеры

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

Полезно сразу разложить по трём категориям:

• что берём за ориентир;
• что точно не повторяем;
• какие решения адаптируем под наш проект.

Без такой сортировки референсы превращаются в хотелки «вот тут как у Apple, а тут как у Slack, а цвета как у конкурента», и собрать из этого связную картину невозможно.

Шаг 3. Составить карту страниц

На этом этапе формируется логика сайта. Я всегда советую сначала сделать простую схему на бумаге или в Miro, а уже потом переходить к деталям.

Пример маршрутов:

Главная → Каталог услуг → Страница услуги → Форма заявки
Главная → Блог → Статья → Подписка
Главная → Контакты → Карта → Форма связи

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

Шаг 4. Описать сценарии пользователя

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

Типовой сценарий:

1. Пользователь попадает на главную.
2. Понимает, что компания решает его задачу.
3. Переходит в раздел услуги.
4. Сравнивает условия.
5. Оставляет заявку.
6. Получает подтверждение на почту или в мессенджер.

Если сценарий не описан, на этапе вёрстки выяснится, что кнопка «Оставить заявку» зарыта в подвале, а пользователь до неё просто не доскролливает.

Шаг 5. Зафиксировать ограничения

Ограничения не менее важны, чем пожелания. Без них проект плывёт по срокам, бюджету и объёму. В ТЗ нужно обязательно указать:

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

Пункт про контент особенно важен: если на старте не зафиксировать, что текстов нет и их будет писать заказчик, разработка встанет колом на этапе наполнения. Я это проходил десятки раз.

Что должно быть в ТЗ по разделам

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

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

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

2. Состав сайта

Для каждого раздела прописываем: название страницы, URL-логику (если уже определена), назначение, обязательные блоки, дополнительные элементы, состояние по умолчанию и состояния ошибок. Последний пункт часто игнорируют, а потом удивляются, что 404 выглядит как пустой экран.

3. Контент

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

4. Дизайн

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

5. Техническая часть

Описываем: CMS или стек разработки, хостинг и домен, интеграции, аналитику, формы, уведомления, CRM, платёжные системы, антиспам-защиту, SSL, резервное копирование. Чем подробнее здесь, тем меньше сюрпризов на этапе деплоя.

6. SEO и аналитика

Если сайт должен привлекать органический трафик, требования к SEO закладываются в ТЗ, а не прикручиваются потом. Нужно указать: ЧПУ, мета-теги, заголовки H1–H6, микроразметку, карту сайта, robots.txt, редиректы, оптимизацию изображений, подключение аналитики, цели и события. Без этого получится сайт, который «есть, но его никто не видит».

7. Тестирование и приемка

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

Этот блок — ваша страховка на финише. Без него приёмка превращается в бесконечный спор «работает/не работает».

Пример удачной структуры ТЗ

Для наглядности собрал частые грабли по разделам в таблицу:

Какие ошибки чаще всего ломают проект

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

1. Слишком общее описание

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

2. Отсутствие границ проекта

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

3. Игнорирование мобильной версии

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

4. Неопределённость по контенту

Очень частая проблема: разработка готова, а текстов, фото и документов нет. Запуск переносится на неопределённый срок. Лучше сразу зафиксировать: кто готовит контент, к какому сроку, в каком формате, кто согласует. Это снимает главный стоп-фактор на финише.

5. Отсутствие критериев приёмки

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

Как написать ТЗ, если вы не технарь

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

Что делать

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

Чего не делать

• не писать расплывчато;
• не подменять требования словами «на усмотрение разработчика», если вам важен конкретный результат;
• не прятать важные условия в переписке в мессенджере;
• не считать, что «и так понятно» — практика показывает, что «понятно» у каждой стороны своё.

Полезный приём

Когда сложно сформулировать требование, я рекомендую задать себе три вопроса:

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

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

Мини-чек-лист перед передачей ТЗ в разработку

Перед тем как отправлять документ исполнителю, пробегитесь по этому списку — он спасает от 80% типовых проблем:

• Цель сайта сформулирована в одном-двух предложениях.
• Понятна целевая аудитория — не «все», а конкретный портрет.
• Перечислены все страницы, включая служебные.
• Описаны основные сценарии пользователя.
• Зафиксированы формы и их поведение.
• Указаны интеграции.
• Есть требования к адаптиву.
• Продуманы SEO-основа и аналитика.
• Определено, кто даёт контент и в какие сроки.
• Описаны критерии приёмки.
• Указано, что не входит в объём работ.

Шаблонный каркас ТЗ

Этот каркас можно адаптировать под любой проект — от лендинга до веб-сервиса:

1. Общая информация о проекте
2. Цели и задачи сайта
3. Целевая аудитория
4. Структура сайта
5. Описание страниц
6. Функциональные требования
7. Требования к дизайну
8. Контент и материалы
9. Интеграции и технические требования
10. SEO-требования
11. Тестирование и приемка
12. Этапы работ и сроки
13. Ограничения и допущения

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

Как проверить, что ТЗ действительно хорошее

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

Проверочные вопросы к самому себе:

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

Если на половину вопросов ответ «нет» — возвращайтесь к документу и докручивайте.

Вывод

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

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

FAQ

Что делать, если я не знаю, как правильно составить ТЗ?

Начните с трёх вещей: цель сайта, список страниц и основные действия пользователя. Этого уже достаточно, чтобы собрать первый рабочий вариант и передать его на оценку разработчику. Остальное докрутите в диалоге.

Можно ли обойтись без ТЗ?

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

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

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

Насколько подробным должно быть ТЗ?

Достаточно подробным, чтобы по нему можно было оценить работу, начать разработку и принять результат без догадок. Для лендинга это может быть 3–5 страниц, для интернет-магазина — 15–20, для сложного сервиса — и 30+.

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

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