14 шагов как составить ТЗ на разработку сайта — инструкция, пример и шаблон

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

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

Разбираем, из каких блоков состоит ТЗ на сайт, как правильно писать требования и на чём чаще всего спотыкаются.

Что такое техническое задание на сайт

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

Хорошее ТЗ на разработку сайта отвечает на четыре базовых вопроса:

1. Что мы создаем (тип сайта, разделы, страницы).
2. Зачем (какие бизнес-задачи он решает).
3. Как это должно работать (поведение функций, сценарии пользователей).
4. Когда работа считается завершенной (критерии приемки).

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

Чем ТЗ отличается от брифа и договора

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

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

Кто должен составлять ТЗ на сайт

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

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

Как составить ТЗ на разработку сайта

Ниже — пошаговая инструкция, которая поможет собрать воедино всю необходимую информацию.

Шаг 1. Определите цели сайта и результат

«Увеличить продажи» — это не цель, это желание. Сайт сам по себе ничего не продает, он подводит человека к действию.

Так не стоит: повысим продажи, улучшим имидж.

Так можно: дать клиенту изучить портфолио и оставить заявку на расчёт через форму.

Цели бывают разные: заявки, продажи, PR, запись на услугу, информирование. Главное — понимать, что должен сделать посетитель: позвонить, написать, заполнить форму или нажать «купить».

Шаг 2. Опишите аудиторию и пользовательские сценарии

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

Пример:

• Пользователь: логист небольшой торговой компании.
• Задача: найти поставщика упаковки с доставкой по России.
• Ищет: ассортимент, минимальную партию, условия доставки.
• Целевое действие: скачать прайс-лист и оставить заявку.

Это помогает дизайнеру с интерфейсом, а разработчику — с логикой фильтрации.

Шаг 3. Зафиксируйте границы проекта

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

Входит:

• Проектирование и дизайн 10 страниц.
• Адаптивная вёрстка.
• Установка и настройка CMS.
• Форма заявки с отправкой на почту.
• Базовое наполнение (до 20 товаров).

Не входит:

• Профессиональная фотосъёмка продукции.
• Создание видеороликов.
• Написание уникальных текстов для всех страниц.
• Перевод контента на английский язык.
• Поддержка после гарантийного срока.

Чем четче границы, тем меньше конфликтов на этапе сдачи проекта.

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

Карта страниц — это скелет будущего ресурса. Важно показать иерархию: главная → каталог → категория → карточка товара. Или: главная → услуги → конкретная услуга → контакты.

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

Шаг 5. Опишите функциональные требования

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

Плохо:

Сделать фильтр товаров в каталоге.

Хорошо:

Пользователь каталога должен иметь возможность отфильтровать товары по цене, по бренду и по сфере применения. При этом можно выбрать несколько брендов и комбинировать параметры.  Если ничего не нашлось — выводить понятное сообщение и давать кнопку, чтобы сбросить фильтры одним кликом.  Выбранные параметры должны отображаться в URL (ЧПУ) для возможности поделиться ссылкой на выборку.

Аналогично нужно описывать формы, личные кабинеты и корзины. Не название функции, а правила игры.

Шаг 6. Опишите дизайн и адаптивность

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

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

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

Шаг 7. Определите требования к контенту

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

• Тексты: заказчик предоставляет или пишет подрядчик?
• Фото: используются стоковые, или нужна съемка, или материалы заказчика?
• Каталог: кто заносит 500 позиций товара — заказчик через админку или подрядчик за дополнительную плату?
• Перенос со старого сайта: сохраняются ли старые статьи?

Без этого пункта запуск сайта может затянуться на месяцы.

Шаг 8. Опишите CMS и управление сайтом

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

На основе этого подрядчик предложит решение: WordPress, 1С-Битрикс, Tilda или индивидуальная разработка. В ТЗ важно зафиксировать именно функциональные права администратора: какие есть роли, кто может что редактировать, нужна ли история изменений.

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

Если сайт не подключен к вашим внутренним системам, это просто визитка. Прописывайте любые обмены данными.

Плохо:

Интеграция с CRM.

Хорошо:

При отправке формы «Заказать звонок» необходимо передавать в CRM (Битрикс24) следующие поля: имя, телефон, email (если указан), текст сообщения, адрес страницы (URL), с которого была отправлена форма, UTM-метки (utm_source, utm_medium, utm_campaign). Ответственный менеджер должен получать уведомление в Битрикс24 (чате/ленте). Дублировать заявку на почту info@site.ru.

Уточняйте также необходимость интеграции с 1С, службами доставки, платёжными системами, телефонией.

Шаг 10. Добавьте требования к SEO и аналитике

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

Необходимо как минимум указать:

• Редактирование мета-тегов (Title, Description) и H1 для каждой страницы.
• Человеко-понятные URL (ЧПУ).
• Возможность управлять файлами sitemap.xml и robots.txt.
• Наличие хлебных крошек.
• Простановка canonical адресов.
• Возможность настройки 301-редиректов.
• Заполнение alt-атрибутов у изображений.

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

Подключите системы аналитики: Яндекс Метрику и (или) Google Analytics 4. Укажите, что цели (отправка форм, клики по кнопкам) должны быть настроены.

Шаг 11. Опишите требования к скорости и безопасности

Формулировка «сайт должен быстро работать» не является измеримой. Если вы хотите контролировать производительность, пишите конкретику, но реалистичную: например, «время загрузки первой страницы на десктопе при тестировании из Москвы должно составлять не более 3 секунд по показателю серверного ответа (TTFB)».

По безопасности базовый набор одинаков:

• Работа по протоколу HTTPS.
• Резервное копирование данных (частота не реже раза в сутки).
• Разграничение прав доступа (админ, редактор, контент-менеджер).
• Защита форм обратной связи от спам-ботов (reCAPTCHA или аналог).
• Своевременное обновление ядра CMS и плагинов (если используется open-source).

Шаг 12. Определите сроки и этапы

Не пытайтесь написать сроки сами, если не разбираетесь в разработке. Процесс обычно такой: аналитика, прототип, дизайн, верстка, программирование, наполнение, запуск.

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

Шаг 13. Зафиксируйте критерии приемки

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

Форма сделана правильно, когда:

1. Пользователь забыл заполнить обязательное поле и нажал «Отправить» — система подсвечивает, что не так;
2. Всё заполнено верно — данные без проблем уходят в CRM.
3. Ответственному сотруднику приходит уведомление на email.
4. Пользователь видит сообщение «Спасибо! Заявка отправлена».

Если вы описали это заранее, спора «почему форма работает не так» не будет.

Шаг 14. Опишите порядок внесения изменений

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

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

Как правильно формулировать требования в ТЗ

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

Главный принцип: каждое требование должно позволять ответить «выполнено / не выполнено».

Пример ТЗ на разработку сайта

Чтобы было понятнее, возьмем условный проект: корпоративный сайт компании, занимающейся системами видеонаблюдения.

1. Цель: презентация спектра услуг (установка, обслуживание, продажа оборудования). Получение заявок на выезд инженера и коммерческие предложения.
2. Аудитория: руководители безопасности, директора бизнес-центров, владельцы магазинов.
3. Структура: главная → Услуги (монтаж, обслуживание, продажа) → Бренды (Hikvision, Dahua) → Решения (офисы, склады, магазины) → Проекты → Статьи → Контакты.
4. Основные функции: интерактивная карта выполненных проектов по районам города. Онлайн-калькулятор подбора комплекта (без сохранения данных, расчет в PDF).
5. Форма заявки: поля: Имя, Телефон, Email, Комментарий. Кнопка «Получить КП». После отправки — передача в CRM.
6. CRM: интеграция с amoCRM. Передача данных формы, создание сделки с UTM-метками. Ответственный менеджер назначается автоматически по круговой системе.
7. Контент: заказчик предоставляет тексты и фото. Подрядчик подготавливает графику и иконки.
8. SEO: ЧПУ, настройка мета-тегов, sitemap.xml, canonical на страницы фильтров. Сохранение всех URL старого сайта при переносе.
9. Аналитика: Яндекс Метрика, цель «Отправка формы» типа JavaScript-событие.
10.  Критерии приемки: сайт открывается на мобильных устройствах без горизонтальной прокрутки. Формы корректно передают данные в тестовую воронку CRM. Валидация проходит без ошибок в Консоли разработчика.

Типичные ошибки при составлении ТЗ

1. Абстрактные требования. «Сайт должен быть удобным» — это не задача. Если конкретики нет, программист просто выполнит «как ему удобно», а не как нужно бизнесу.
2. Отсутствие пользовательских сценариев. Часто заказчик описывает желаемый функционал, не связывая его с реальной жизнью клиента. В итоге сайт умеет всё, но пользователь не может найти нужную кнопку.
3. Структура без учёта SEO. Если сайт собирает поисковый трафик, но страницы нарезаны без семантики, после запуска SEO-специалисту придется перекраивать скелет. Дешевле сразу заложить правильную структуру в ТЗ.
4. Не описаны интеграции. «Нужна CRM». В процессе выясняется, что CRM устарела и не имеет API. Или нужно обмениваться не только заявками, но и каталогом. Это меняет бюджет на 30%.
5. Отсутствие границ проекта. Заказчик думает, что «наполнение каталога» входит в разработку, а подрядчик планировал только «создание шаблона карточки». Без фиксации границ конфликт неизбежен.
6. Нет критериев приемки. Если нет чек-листа проверки, подрядчик скажет «всё готово», а заказчик начнет придумывать претензии. Критерии должны быть техническими, а не вкусовыми.
7. Самостоятельный выбор технологий. «Хочу на Битриксе». А если вам нужен лендинг, то это дорого и сложно поддерживать. Доверьте стек подрядчику, описав задачи.
8. Нет процедуры изменений. Новые идеи, пришедшие во время разработки, без фиксации в документе превращают смету в фикцию, а сроки — в бесконечность.

Чек-лист хорошего ТЗ на сайт

Перед передачей документа подрядчику проверьте себя:

• Бизнес-задача понятна и написана языком цифр и действий.
• Целевая аудитория описана через мотивы, а не только через возраст.
• Основные сценарии (как клиент заказывает) проработаны.
• Утверждена карта сайта (вложенность страниц).
• Поведение ключевых функций описано детально (что произойдет при клике).
• Перечислены все CRM, 1С, API и сервисы.
• Определены зоны ответственности (кто готовит тексты и фото).
• Включены требования к SEO и аналитике.
• Сформулированы измеримые критерии приемки.
• Описан порядок внесения дополнительных правок.

Шаблон ТЗ на разработку сайта

Вы можете использовать этот каркас для создания собственного документа:

Техническое задание

1. Информация о компании: сфера, продукт, конкурентные преимущества.
2. Цели проекта: что должен дать сайт бизнесу (заявки, продажи, автоматизация).
3. Целевая аудитория: портреты, сценарии поведения.
4. Границы проекта: что входит и что не входит в разработку.
5. Структура сайта: карта разделов и страниц.
6. Функциональные требования: описание поведения модулей.
7. Дизайн: брендбук, референсы, адаптивность.
8. Контент: источники материалов, ответственные.
9. CMS: требования к управлению, ролям.
10. Интеграции: CRM, 1С, платежи, доставка.
11. SEO: базовые требования, редиректы, микроразметка.
12. Аналитика: Метрика, Analytics, цели.
13. Производительность: целевые показатели скорости.
14. Безопасность: HTTPS, бэкапы, права доступа.
15. Этапы и сроки: дорожная карта.
16. Критерии приёмки: как проверяем результат.
17. Ответственные: контакты от заказчика и подрядчика.
18. Порядок изменений: регламент внесения правок.
19. Приложения: файлы с изображениями, текстами, доступы.

Вывод

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

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