Как составить ТЗ на разработку сайта: структура, пример и шаблон

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

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

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

[vue:start]{"text":"Составим ТЗ, чтобы сайт сделали таким, как вы задумали","link":"https://serptop.ru/services/web/tz/"}[vue:end]

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

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

ТЗ нужно обеим сторонам. Заказчику оно помогает:

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

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

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

Чем ТЗ отличается от брифа, прототипа и функциональных требований

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

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

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

Составить ТЗ может заказчик, исполнитель или они вместе. У каждого варианта свои условия.

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

Что бы ни выбрали, заказчик должен подготовить:

• цель сайта и показатель, по которому будет понятно, что цель достигнута;
• описание продукта или услуг, клиентов и того, как они сейчас покупают;
• сайты конкурентов и сайты-примеры с пояснением, что в них нравится и что нет;
• брендбук или логотип, фирменные цвета и шрифты;
• список систем, с которыми должен работать сайт: 1С, CRM (программа, в которой менеджеры ведут заявки и клиентов, например amoCRM или Битрикс24), онлайн-касса, служба доставки;
• имя человека, который согласует решения и будет принимать сайт.

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

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

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

По этим шагам вы подготовите основу ТЗ. Технические решения и условия проверки согласуйте с исполнителем до утверждения документа.

1. Сформулируйте цель. Не «нужен сайт», а «получать заявки на ремонт квартир из Москвы и области» или «продавать запчасти без звонка менеджеру». От цели зависит, какие функции действительно нужны.
2. Опишите аудиторию и сценарии. Запишите, кто приходит на сайт и какую задачу посетитель должен решить. Например: «Прораб с телефона на объекте ищет цемент нужной марки и фасовки и оформляет заказ на доставку». Каждый сценарий потом превращается в требования к страницам и функциям.
3. Соберите структуру. Перечислите разделы и страницы, покажите, как они связаны. Структуру удобно рисовать схемой в Figma, draw.io или на бумаге. Ее согласуют до дизайна. Если позже понадобится новый тип страницы или изменится навигация, макеты могут потребовать доработки.
4. Опишите страницы и функции. Для каждой страницы — какие блоки на ней есть и что они делают. Для функций — что происходит по шагам: что видит пользователь, что получает менеджер, какие данные уходят в CRM.
5. Запишите технические требования. Определите, что сотрудники смогут менять на сайте сами, какие устройства и браузеры нужно поддерживать, с какими системами сайт обменивается данными. Условия проверки скорости, нагрузки и защиты согласуйте с исполнителем. Ниже разобрано, как описать эти требования без технических знаний.
6. Договоритесь о контенте и этапах. Кто пишет тексты, кто готовит фото, к какому этапу материалы должны быть готовы. Без текстов готовый сайт может месяцами ждать запуска.
7. Пропишите критерии приемки. Рядом с каждым важным требованием укажите, как проверить результат. Поставьте дату и номер версии ТЗ. Заказчик и исполнитель подтверждают эту версию способом, предусмотренным договором.

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

Структура ТЗ сайта: какие разделы нужны и какие можно пропустить

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

Если сайт собирает персональные данные, заранее определите цель и основание их обработки, подготовьте политику и требования к формам. Когда обработка основана на согласии посетителя, согласие оформляют отдельно от других сведений и документов, которые посетитель подтверждает или подписывает (152-ФЗ, ст. 9).

Например, для формы, где требуется согласие, в ТЗ записывают: «Галочка согласия изначально не отмечена. Рядом есть ссылка на отдельный текст согласия. Без галочки форма не отправляется; факт получения согласия сохраняется». Состав данных и способ подтверждения согласуйте до разработки.

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

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

Договоры с регистратором домена и хостингом — сервисом размещения сайта — заключает заказчик. В ТЗ указывают, кто получает учетные записи, оплачивает услуги и восстанавливает доступ. Для резервных копий определяют периодичность, место хранения и ответственного за восстановление.

Если сайт собирает персональные данные граждан России, базы данных, где их записывают и хранят, должны находиться в России. Исключения перечислены в законе (152-ФЗ, ст. 18, ч. 5). Учитывайте не только хостинг сайта, но и сервисы форм и CRM, куда поступают данные.

Условия измерения скорости согласуют заранее. В примере ниже используются лабораторная мобильная проверка PageSpeed Insights, то есть тест на смоделированном устройстве и сети, и медиана нескольких запусков — средний по порядку результат. Такое условие стороны выбирают сами, правилом Google оно не является. Проверяют согласованные страницы с готовыми текстами, изображениями и подключенными внешними сервисами.

Какие SEO-требования включить в ТЗ на разработку сайта

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

• Заголовки и описания для поиска. Сотрудник может изменить title и description отдельной страницы в панели управления. При приемке меняет их у тестовой страницы и вместе с исполнителем проверяет результат.
• Доступность страниц поисковым роботам. До запуска тестовую копию закрывают от индексации. При запуске исполнитель проверяет, что важные страницы доступны для поиска, а служебные ограничения сняты. Попадание в выдачу зависит также от поисковой системы.
• Адреса страниц. В ТЗ закрепляют понятные адреса и правила их формирования. Если есть фильтры и сортировка, отдельно определяют, какие варианты должны попадать в поиск, чтобы не создавать множество одинаковых страниц.
• Карта сайта и robots.txt. Исполнитель готовит список страниц для поисковых роботов и правила обхода. При приемке проверяет доступность файлов, состав карты и отсутствие запрета на нужные разделы.
• Перенос старого сайта. Для измененных адресов составляют таблицу «старый URL — новый URL». Исполнитель настраивает постоянные перенаправления (301), а при приемке проверяет каждый адрес из таблицы.

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

Как писать требования в ТЗ, чтобы их можно было проверить

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

Еще несколько правил языка ТЗ:

• одно требование — один пункт с номером. На пункты удобно ссылаться в переписке и при приемке;
• сложные термины поясняйте простыми словами или выносите в глоссарий в конце документа. Заказчик, который не знает слов «CMS» и «адаптивность», не сможет проверить, выполнены ли эти пункты;
• пожелания по дизайну подкрепляйте картинкой: скриншот с пометками объясняет больше абзаца текста;
• не описывайте одно и то же в двух местах. Если требование поменяется, исправят только одно место, и документ начнет противоречить сам себе.

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

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

Критерии приемки превращают ТЗ в чек-лист. По ним заказчик проверяет сайт перед подписанием акта, а исполнитель заранее знает, что будут смотреть. Примеры критериев:

• все страницы из структуры открываются, ссылки в меню ведут на нужные разделы;
• заявка с каждой формы приходит на почту менеджеру и в CRM, у посетителя открывается страница «Спасибо»;
• на экранах и в браузерах из ТЗ нет горизонтальной прокрутки, наложения блоков и обрезанного текста;
• скорость загрузки главной и ключевых страниц проверяют в согласованном режиме PageSpeed Insights, с тем же контентом и внешними сервисами, которые будут на сайте после запуска;
• счетчик Яндекс Метрики установлен, и тестовая заявка, отправленная с принятыми cookie, видна в отчете «Конверсии» как достижение цели. Сами заявки считают по почте или CRM;
• если сайт заменяет прежний, старые адреса из списка в ТЗ открывают соответствующие новые страницы.

До запуска у нового сайта обычно нет статистики реальных посетителей в PageSpeed Insights. Поэтому не требуйте эти данные при приемке. Отклик кнопок и форм, в том числе показатель INP, исполнитель проверяет отдельно по согласованным сценариям. Локальная проверка не заменяет наблюдение за реальными посетителями после запуска.

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

Заказчику стоит проверить сайт и самому. Откройте его на своем телефоне и компьютере. Отправьте тестовую заявку с каждой формы и убедитесь, что она пришла на почту и в CRM. Скорость проверьте в PageSpeed Insights, для этого тестовая копия на время проверки должна открываться без пароля. Расхождения запишите одним списком с номерами пунктов ТЗ и отправьте исполнителю до подписания акта. Сколько дней у заказчика на проверку, тоже лучше записать в ТЗ.

Подписывать акт сразу рискованно. Если договор подряда не устанавливает иное, заказчик, который принял работу без проверки, теряет право ссылаться на недостатки, которые можно было заметить при обычной приемке (ГК РФ, ст. 720, п. 3).

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

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

Переделки на проектах часто начинаются с одних и тех же пробелов в ТЗ. О других промахах при заказе сайта — в статье «15 критических ошибок при заказе сайта».

• Нет цели. Заказчик ждал инструмент для онлайн-продаж, а получил сайт-визитку с новостями. Цель и показатель успеха — первые строки ТЗ.
• Функция названа, но не описана. «Корзина» в ТЗ, а в голове заказчика — промокоды, бонусы и сохранение корзины без регистрации. Каждую функцию описывайте по шагам.
• Лишние функции. Для каждой функции спросите: какую задачу посетителя или сотрудника она решает при запуске? Если ответа нет, перенесите ее в раздел «Следующие этапы». Так блог, форум или личный кабинет «на будущее» не займут бюджет, нужный для первой версии сайта.
• ТЗ не обновляют. Договорились о новой функции в переписке, но не внесли в документ. Через месяц никто не помнит, о чем шла речь. В начале ТЗ ведите таблицу изменений: дата, номер версии, что изменилось, кто согласовал.

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

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

1. Общие сведения

• Проект: корпоративный сайт строительной компании «Пример».
• Цель: получать заявки на расчет стоимости от компаний, которые строят или реконструируют коммерческие здания. Бизнес-цель — не меньше [__] заявок в месяц через три месяца после запуска. При приемке проверяют страницы, работу функций и учет заявок. Кто привлекает посетителей, какой бюджет выделен на продвижение и кто отвечает за число обращений, стороны согласуют отдельно.
• Согласует и принимает работу: [должность, имя].

2. Аудитория и сценарии

• Владельцы и руководители малого и среднего бизнеса, которые ищут подрядчика. С телефона заходит около [__]%.
• Сценарий 1: посетитель смотрит выполненные объекты по типу (склад, офис, торговый центр) и оставляет заявку с карточки объекта.
• Сценарий 2: посетитель прикрепляет к заявке свой проект, менеджер получает заявку с файлом на почту и в CRM и отправляет расчет в течение [__] рабочих дней.

3. Структура

• Главная, «Услуги» (строительство, реконструкция, проектирование — отдельная страница на каждую), «Объекты» с фильтром по типу, «О компании», «Контакты».
• Карточка объекта сверху вниз: название и тип объекта, город и год, площадь, крупные фото, что сделала компания, кнопка «Рассчитать похожий объект», которая открывает форму заявки с уже выбранным типом объекта.

4. Функции

• Форма заявки на расчет: имя, телефон, почта, тип объекта, согласие на обработку персональных данных. Можно приложить [число] файлов в форматах [перечень], каждый до 20 МБ. Заявка и [вложения / ссылки на файлы] уходят на почту [адрес] и в CRM [название]. При неверном формате или размере рядом с полем появляется объяснение.
• Фильтр объектов по типу без перезагрузки страницы.
• Кнопка заявки, кнопка мессенджера [название] и заказ обратного звонка на всех страницах.
• Политику обработки персональных данных и текст согласия готовит заказчик, исполнитель размещает их на сайте отдельными страницами и ставит ссылку на текст согласия в каждой форме.

5. Дизайн

• Цвета и шрифты по брендбуку компании. Сайты-примеры: [ссылка] — нравится подача объектов крупными фото; [ссылка] — нравится короткая форма заявки.

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

• CMS: [название; если не выбрали — «предлагает исполнитель»].
• Без горизонтальной прокрутки на экранах шириной от 360 до 1920 пикселей. Сочетания устройств, ОС и браузеров фиксируют в таблице совместимости; проверяют две последние стабильные версии браузера на дату приемки для каждой согласованной комбинации.
• Главная и страницы услуг [URL] с согласованным контентом и внешними сервисами: в лабораторной мобильной проверке PageSpeed Insights медиана [3–5] запусков дает LCP не больше [__] с (ориентир Google для реальных посетителей – 2,5 с) и CLS не больше [__] (ориентир – 0,1).
• SSL-сертификат, ежедневная резервная копия, счетчик Яндекс Метрики с целью на отправку формы.
• Почту для заявок, тексты страниц и объекты менеджер меняет сам в панели управления. Договоры с хостингом и регистратором домена заключает заказчик, сервер находится в России.

7. Контент

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

8. Этапы, бюджет и гарантия

• Недели [__]: структура и прототипы.
• Недели [__]: дизайн.
• Недели [__]: верстка и программирование.
• Недели [__]: тестирование и приемка.
• Бюджет: [___] ₽.
• Гарантия: [__] месяцев с даты подписания акта исполнитель бесплатно исправляет ошибки: несоответствия этому ТЗ и неработающие согласованные функции.

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

• Все страницы из раздела 3 открываются, ссылки в меню ведут на нужные разделы.
• Тестовая заявка с допустимым файлом 20 МБ приходит на почту [адрес] и в CRM [название] со вложением или ссылкой согласно разделу 4. Посетитель видит страницу «Спасибо». Для файла больше лимита и неподдерживаемого формата появляется объяснение ошибки. Без галочки согласия форма не отправляется.
• Фильтр объектов меняет список без перезагрузки страницы.
• При ширине экрана 360, 768, 1366, 1536 и 1920 пикселей и в браузерах из раздела 6 нет горизонтальной прокрутки и наложения блоков.
• Показатели скорости из раздела 6 выполнены в мобильной проверке PageSpeed Insights.
• Отправка формы видна в отчете «Конверсии» Яндекс Метрики.
• Менеджер сам добавляет объект с фото в панели управления.
• На проверку у заказчика [__] рабочих дней, замечания он присылает одним списком с номерами пунктов ТЗ.

Полностью заполненный пример требования и проверки

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

Требование. В форме «Рассчитать стоимость» обязательны имя и телефон. Посетитель может приложить один PDF-файл размером до 20 МБ. После успешной отправки заявка с файлом появляется в Битрикс24, а посетитель видит страницу «Спасибо». Если файл слишком большой или имеет другой формат, форма показывает причину и сохраняет введенные имя и телефон.

Проверка. Заказчик отправляет заявку с PDF-файлом размером 20 МБ и сверяет имя, телефон и вложение в Битрикс24. Затем пробует прикрепить PDF размером 21 МБ и файл DOCX. Форма должна отклонить оба файла и показать понятное сообщение. Введенные данные остаются в форме.

Требования к согласию на обработку данных задаются отдельным пунктом. Обработку сбоев и защиту формы также согласуют отдельно.

Скачать шаблон ТЗ на разработку сайта

Шаблон Word содержит 17 разделов с полями и подсказками. Если функция не нужна, напишите «Не входит в проект»; если решение не принято — «Уточнить с исполнителем».

Скачать шаблон ТЗ на разработку сайта (DOCX)

Так выглядит первая страница шаблона Word.

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

ТЗ на доработку существующего сайта

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

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

Пример ТЗ на доработку формы

Условная задача. Сейчас заявки с формы «Рассчитать стоимость» приходят только на почту. После изменения каждая успешно отправленная заявка должна также создавать запись в [CRM] с именем, телефоном и названием услуги.

Если CRM недоступна, система сохраняет заявку и уведомляет [ответственного] через [канал]. Повторная отправка выполняется через [__] минут, число попыток — [__]. Эти условия согласуют до начала работ.

Проверка. Отправить тестовую заявку и сверить поля в CRM. Затем вместе с исполнителем проверить сценарий недоступности CRM — заявка сохраняется, уведомление приходит, повторная отправка выполняется по согласованным условиям и не создает дубликат. Адрес страницы и существующий учет заявок в Метрике сохраняются.

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

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

Вопросы о ТЗ на разработку сайта

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

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

Сколько страниц должно быть в ТЗ?

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

Нужно ли составлять ТЗ на сайт по ГОСТ?

Для обычного коммерческого сайта нет. ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы» действует с 1 января 2022 года вместо ГОСТ 34.602-89. По нему пишут ТЗ, если этого требует заказчик, например в госзакупках, или когда сайт — часть большой информационной системы.

Можно ли изменить ТЗ, когда работа уже началась?

Да. Изменение записывают в новую версию документа и согласуют обе стороны. Если оно увеличивает объем работ, меняются сроки и стоимость, и это фиксируют дополнительным соглашением.

Можно ли отдать в студию только бриф, без ТЗ?

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

[vue:start]{"component":"BannerBlog2","topText":"Нужно ТЗ для нового сайта или доработки? Соберем требования, нарисуем прототипы ключевых страниц и пропишем критерии приемки."}[vue:end]