Коротко
Техническое задание на разработку сайта — документ, в котором описано, что именно должно быть сделано: цели сайта, структура, функции, требования к дизайну, контенту, CMS, интеграциям и приёмке. Оно нужно, чтобы заказчик и разработчик одинаково понимали результат, а смета и сроки опирались на конкретный список работ, а не на общее «сделать хороший сайт».
Писать техническое задание на создание сайта не обязательно самому с нуля. Владелец бизнеса лучше всех знает цели, аудиторию и процессы, а разработчик переводит их в структуру, функции и технические требования. Ниже — структура документа, образец разделов, типичные ошибки и чек-лист.
| Раздел ТЗ | Что в нём описывают | Кто обычно заполняет |
|---|---|---|
| Цели и аудитория | Зачем сайт, кто клиенты, какие действия нужны | Заказчик |
| Структура | Разделы, страницы, шаблоны страниц | Совместно |
| Функции | Формы, каталог, фильтры, корзина, личный кабинет | Совместно |
| Дизайн | Стиль, референсы, адаптивность, брендбук | Заказчик и дизайнер |
| Техника | CMS, хостинг, интеграции, скорость, безопасность | Разработчик |
| Контент | Кто готовит тексты, фото, товары | Заказчик |
| Приёмка | Критерии готовности, тестирование, сроки | Совместно |
Основная мысль
Хорошее техническое задание описывает не пожелания, а проверяемый результат: каждую страницу, функцию и интеграцию можно по нему оценить, реализовать и принять без споров о том, «что имелось в виду».
Большинство конфликтов между заказчиком и исполнителем возникает не из-за плохой работы, а из-за разного понимания задачи. Заказчик ждал фильтр по десяти параметрам, а разработчик заложил три. Заказчик думал, что тексты напишет исполнитель, а исполнитель ждал их от заказчика. Любую из этих ситуаций закрывает одна строка в ТЗ.
При этом ТЗ не должно превращаться в стопку страниц общих слов. Фразы «современный дизайн», «удобная навигация», «быстрая загрузка» ничего не требуют. Вместо них нужны конкретные формулировки: какие блоки на странице, какие поля в форме, каким порогам скорости должен соответствовать сайт.
Объём документа зависит от проекта. Для лендинга достаточно нескольких страниц, для интернет-магазина с обменом 1С и личным кабинетом ТЗ может занимать десятки страниц.
Зачем нужно техническое задание на разработку сайта
Даже небольшой проект без ТЗ рискует затянуться и выйти дороже, чем планировалось. Документ решает несколько задач одновременно.
Что даёт ТЗ заказчику
- Точную смету. Цена считается по конкретному списку работ, а не «на глаз».
- Сравнимые предложения. Разные исполнители оценивают один и тот же объём, и их цены можно сопоставить.
- Контроль сроков. Понятно, из каких этапов состоит работа и что сдаётся на каждом.
- Основание для приёмки. Если что-то не сделано, это видно по документу.
Что даёт ТЗ разработчику
- Понятный объём, который можно спланировать.
- Защиту от бесконечных доработок «в рамках проекта».
- Возможность заранее выявить сложные места: интеграции, нестандартные функции, миграцию данных.
Подробнее о том, как объём работ влияет на бюджет, — в статье сколько стоит разработка сайта.
Структура технического задания на создание сайта
Ниже — разделы, которые стоит включить в ТЗ для большинства коммерческих сайтов. Для лендинга часть из них сокращается до пары строк, для магазина или портала каждая раздувается в отдельную главу.
1. Общая информация
Название компании, сфера деятельности, контактное лицо, домен, существующий сайт, если он есть. Кратко — что продаёт компания и в каком регионе работает.
2. Цели и задачи сайта
Какие действия должны совершать посетители: оставлять заявки, звонить, покупать, регистрироваться. Какие задачи решает сайт для бизнеса: привлечение клиентов из поиска и рекламы, снижение нагрузки на менеджеров, приём заказов, информирование партнёров.
3. Целевая аудитория
Кто клиенты, что для них важно при выборе, с каких устройств они заходят, какие вопросы задают менеджерам. Этот раздел помогает дизайнеру и автору текстов, а разработчику подсказывает, что важнее: мобильная версия, сложный фильтр или быстрый заказ в один клик.
4. Структура сайта
Карта разделов и страниц. Удобно оформлять деревом или таблицей: раздел, подразделы, тип страницы. Для каждого типа страницы — шаблон со списком блоков.
5. Функциональные требования
Все функции, которые должен выполнять сайт: формы, калькуляторы, каталог и фильтры, корзина, оплата, доставка, личный кабинет, поиск, многоязычность, подписки. Для каждой функции — поведение, поля, уведомления и получатели.
6. Требования к дизайну
Стиль, фирменные цвета и шрифты, брендбук, сайты-референсы с пояснением, что в них нравится. Требования к адаптивности: на каких ширинах экрана проверяется сайт.
7. Технические требования
CMS, хостинг, версия PHP, требования к скорости и безопасности, резервному копированию, SEO-настройкам, аналитике.
8. Интеграции
Обмен с 1С, CRM, платёжными системами, службами доставки, телефонией, сервисами рассылок. Для каждой — направление данных и частота обмена.
9. Контент
Кто готовит тексты, фото, товары, в каком формате передаются данные, нужен ли перенос со старого сайта.
10. Этапы, сроки и приёмка
Этапы работ, что сдаётся на каждом, как проводится тестирование, какие критерии считаются выполнением.
Техническое задание на дизайн сайта
Раздел о дизайне часто пишут хуже всего: «хотим красиво и современно». Дизайнеру такие формулировки не помогают, и макеты приходится переделывать по несколько раз.
Что включить
- Фирменный стиль. Логотип в векторе, цвета, шрифты, брендбук, если он есть.
- Референсы. Три–пять сайтов с пояснением, что именно нравится: цветовая гамма, подача каталога, оформление карточки, анимации.
- Антиреференсы. Что точно не нужно — это экономит круги правок не меньше, чем референсы.
- Список макетов. Какие страницы рисуются отдельно: главная, раздел услуг, услуга, каталог, карточка товара, корзина, контакты, статья блога.
- Мобильные версии. Для каких страниц нужны отдельные макеты мобильной версии.
- Число итераций. Сколько кругов правок входит в стоимость.
Как описать референс
Ссылка на сайт без комментария почти бесполезна: дизайнер не знает, что именно в нём понравилось. Хорошее описание выглядит так: «у этого сайта нравится крупная типографика и много воздуха», «здесь удобно устроена карточка товара: фото слева, цена и кнопка сразу под названием», «здесь не нравится тёмный фон и мелкий текст». Три таких комментария заменяют страницу общих слов о стиле.
Прототипы до дизайна
Эффективный порядок — сначала прототип: схема блоков без оформления. На этом этапе обсуждают содержание и логику страницы, а не цвета. Когда прототип согласован, дизайн идёт быстрее, а правки касаются визуала, а не состава блоков.
Функциональные и технические требования
Эта часть ТЗ влияет на смету сильнее остальных. Одна строка «интеграция с 1С» может означать и выгрузку прайса раз в сутки, и полноценный двусторонний обмен товарами, остатками, ценами и заказами.
Как описывать функции
Хорошее описание функции отвечает на вопросы: кто пользуется, что делает, что видит в результате и кого уведомляет система. Например, для формы заявки: какие поля, какие обязательны, куда уходит заявка, что видит посетитель после отправки, передаётся ли заявка в CRM, какая цель фиксируется в Метрике.
Технические требования к сайту
| Требование | Пример формулировки |
|---|---|
| CMS | WordPress с WooCommerce или 1С-Битрикс, редакция по функциям |
| Скорость | Соответствие Core Web Vitals: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 |
| Адаптивность | Корректное отображение на смартфонах, планшетах и десктопах |
| SEO | Управляемые title, description, H1, ЧПУ, карта сайта, robots.txt |
| Аналитика | Яндекс Метрика с целями на формы, звонки и заказы |
| Безопасность | SSL, регулярные обновления, резервные копии, ограничение доступа к админке |
| Редактирование | Изменение текстов, цен и товаров без участия разработчика |
Выбор CMS
Если CMS не указана, исполнители предложат каждый свою, и сравнивать сметы станет сложно. Для сайтов услуг и небольших магазинов часто подходит WordPress с WooCommerce, для проектов с тесной интеграцией с 1С, сложным каталогом и требованиями к корпоративной инфраструктуре — 1С-Битрикс. Если выбран Битрикс, в ТЗ стоит указать редакцию: интернет-магазин доступен начиная с редакции «Малый бизнес». Подробнее о выборе — в статье о редакциях 1С-Битрикс.
Образец технического задания сайта: пример разделов
Ниже — сокращённый пример технического задания сайта для корпоративного сайта производственной компании. Его можно использовать как шаблон и дополнять под свой проект.
Цели
Получение заявок на продукцию из поиска и рекламы, информирование дилеров, снижение числа однотипных вопросов менеджерам за счёт раздела с документацией.
Структура
- Главная.
- Продукция: разделы по типам изделий, карточка изделия с характеристиками, фото и документацией.
- Услуги: изготовление на заказ, доставка, монтаж.
- О компании: производство, сертификаты, реквизиты.
- Проекты: примеры выполненных заказов.
- Дилерам: условия сотрудничества, форма заявки.
- Контакты: адрес, карта, телефоны отделов, форма обратной связи.
Функции
- Форма заявки на расчёт: имя, телефон, email, комментарий, прикрепление файла. Заявка уходит на почту отдела продаж и в CRM, фиксируется цель в Метрике.
- Фильтр в каталоге по типу, размеру и материалу.
- Скачивание документации в PDF из карточки изделия.
- Управление всеми текстами, изделиями и проектами через админку.
Технические требования
WordPress или 1С-Битрикс «Стандарт», адаптивная вёрстка, соответствие порогам Core Web Vitals, SSL, ежедневное резервное копирование, управление мета-тегами, карта сайта.
Контент и приёмка
Тексты и фото предоставляет заказчик, разработчик наполняет каталог до 50 позиций. Приёмка по чек-листу функций, тестирование форм, проверка на трёх ширинах экрана.
Что добавить в ТЗ для интернет-магазина
Магазин отличается от корпоративного сайта количеством процессов, которые нужно описать. Если оставить их на усмотрение исполнителя, каждый реализует по-своему, и сравнить сметы будет невозможно.
Каталог и товары
- Количество товаров и категорий на старте и через год.
- Источник данных: ручное наполнение, импорт из файла, обмен с 1С или другой учётной системой.
- Список характеристик для фильтра по каждой категории.
- Торговые предложения: размеры, цвета, комплектации с отдельными ценами и остатками.
- Правила вывода товаров, которых нет в наличии.
Заказ, оплата и доставка
- Шаги оформления и обязательные поля.
- Способы оплаты: онлайн картой, по счёту для юрлиц, при получении.
- Способы доставки и расчёт стоимости: фиксированная цена, зоны, расчёт через службу доставки.
- Статусы заказа и уведомления покупателю и менеджеру на каждом статусе.
- Выгрузка заказов в учётную систему или CRM.
Покупатели
Нужна ли регистрация, что видит покупатель в личном кабинете, есть ли персональные цены для оптовых клиентов, программы лояльности, промокоды. Каждый из этих пунктов заметно влияет на объём работ.
Сценарии: как ТЗ меняет проект
Ниже — собирательные ситуации, которые показывают, где отсутствие деталей в документе обходится дороже всего.
Три сметы с разницей в разы
Заказчик разослал исполнителям одну фразу: «интернет-магазин с интеграцией с 1С». Один оценил выгрузку товаров раз в сутки, второй — двусторонний обмен с заказами и остатками, третий добавил личный кабинет. Сметы отличаются в несколько раз, и выбрать невозможно. Когда тот же заказчик описывает в ТЗ, какие данные и в каком направлении передаются, предложения становятся сопоставимыми.
Сайт готов, а наполнять некому
Разработчик сдал сайт с пустым каталогом, заказчик ждал сайт с товарами. В ТЗ не было раздела о контенте. Проект встаёт на несколько недель, пока ищут, кто перенесёт описания и фото. Одна строка о том, кто и в каком объёме наполняет сайт, сняла бы вопрос заранее.
Дизайн по кругу
Макет главной переделывают пятый раз, потому что каждый раз «не то». В документе было написано «современный стиль» без референсов и антиреференсов. После того как заказчик показывает три сайта и объясняет, что в них нравится, следующий вариант принимается почти без правок.
Проект без границ
Во время разработки появляются новые пожелания: блог, калькулятор, ещё один язык. Без ТЗ непонятно, входит ли это в исходную стоимость. С документом каждое изменение оценивается отдельно, заказчик решает, делать ли его сейчас или во второй очереди, и проект сдаётся в срок.
Как составить техническое задание сайта: пошаговый план
Составить техническое задание сайта можно самостоятельно, даже без опыта в разработке. Главное — двигаться от бизнес-задач к деталям, а технические формулировки доверить исполнителю.
Пошаговый план
- Сформулируйте цели. Что должен делать посетитель и что должен получить бизнес.
- Соберите вопросы клиентов. Что спрашивают менеджеры чаще всего — это будущие блоки страниц.
- Изучите конкурентов. Отметьте, что у них удобно и чего не хватает.
- Нарисуйте структуру. Список разделов и страниц, хотя бы на листе бумаги.
- Опишите функции. Формы, каталог, оплата, личный кабинет — что должно работать и как.
- Перечислите интеграции. С какими системами сайт обменивается данными.
- Определите, кто готовит контент. Тексты, фото, товары, перенос со старого сайта.
- Обсудите черновик с разработчиком. Он добавит технические требования и укажет на пробелы.
- Зафиксируйте этапы и приёмку. Что сдаётся на каждом этапе и как проверяется.
Кто пишет ТЗ
Есть три варианта: заказчик пишет сам, разработчик пишет по результатам брифа и интервью, или ТЗ выделяется в отдельный этап проектирования. Для небольших сайтов обычно достаточно брифа и обсуждения, для сложных проектов проектирование как отдельный этап окупается: смета становится точной, а риск переделок снижается.
Бриф, ТЗ и смета: в чём разница
Эти три документа часто путают, хотя у каждого своя роль. Понимание разницы помогает не тратить время на лишнее и не пропустить нужное.
| Документ | Назначение | Объём |
|---|---|---|
| Бриф | Анкета о бизнесе, целях, аудитории и пожеланиях | Несколько страниц, заполняет заказчик |
| Техническое задание | Точное описание результата и требований | От нескольких до десятков страниц |
| Смета | Стоимость и сроки по этапам и работам | Таблица, опирается на ТЗ |
Как они связаны
Бриф — отправная точка: по нему разработчик понимает задачу и задаёт уточняющие вопросы. На основе брифа и обсуждения составляется ТЗ. Смета считается уже по ТЗ, и только тогда она становится точной. Если исполнитель называет окончательную цену сложного проекта после пятиминутного разговора, он либо закладывает большой запас, либо потом будет выставлять доплаты.
Как проверить ТЗ перед отправкой исполнителям
Прочитайте документ глазами человека, который ничего не знает о вашем бизнесе. Если по какому-то пункту можно сделать два разных вывода, его нужно уточнить. Полезно также попросить сотрудника, который общается с клиентами, пройтись по структуре: он быстро заметит, какие вопросы покупателей сайт оставит без ответа. Выбрать, кому отправлять готовый документ, поможет статья о выборе разработчика сайта.
Типичные ошибки в ТЗ и чек-лист
Чего избегать
- Общие слова вместо требований. «Удобный», «современный», «быстрый» без конкретики не проверяются.
- Копирование чужого шаблона целиком. Техническое задание сайта из шаблона в интернете часто содержит лишние разделы и не содержит нужных.
- Молчание о контенте. Кто пишет тексты и наполняет каталог — самый частый источник споров.
- Интеграции одной строкой. «Связь с 1С» без описания данных и направлений обмена даёт разброс смет в разы. Как выглядит нормальное описание обмена, разобрано в статье о настройке обмена Битрикс с 1С.
- Нет критериев приёмки. Без них работу невозможно ни принять, ни оспорить.
- Изменения без фиксации. Новые пожелания по ходу проекта должны вноситься в ТЗ с пересчётом сроков и стоимости.
Чек-лист готового ТЗ
- Описаны цели сайта и целевые действия посетителей.
- Есть полная структура с типами страниц и составом блоков.
- Каждая функция описана с полями, логикой и уведомлениями.
- Указаны CMS, требования к скорости, адаптивности, SEO и аналитике.
- Перечислены интеграции с направлением и частотой обмена.
- Понятно, кто и в каком формате готовит контент.
- Определены этапы, сроки и критерии приёмки.
Частые вопросы
Как написать техническое задание сайта без опыта?
Опишите бизнес-задачи, структуру и нужные функции своими словами, а технические требования попросите сформулировать разработчика. Главное — конкретика, а не терминология.
Где взять образец технического задания сайта?
Используйте структуру из этой статьи как основу и дополните её под свой проект. Готовый шаблон из интернета без адаптации обычно содержит лишнее и упускает важное.
Есть ли шаблон технического задания для сайта?
Шаблоном служит список разделов: цели, аудитория, структура, функции, дизайн, техника, интеграции, контент, этапы и приёмка. Наполнение каждого раздела индивидуально.
Чем техническое задание на дизайн сайта отличается от общего ТЗ?
Это часть общего документа, которая описывает стиль, референсы, список макетов и число итераций. Иногда её оформляют отдельным брифом для дизайнера.
Сколько стоит составить техническое задание сайта?
Для небольших сайтов ТЗ часто входит в стоимость разработки. Для сложных проектов проектирование выделяют в отдельный этап и оплачивают отдельно.
Нужно ли ТЗ для лендинга?
Да, но короткое: цель, структура блоков, форма, интеграции, тексты. Даже одна страница без описания может превратиться в несколько кругов переделок.
Можно ли менять ТЗ после начала работ?
Можно, но каждое изменение фиксируют письменно и оценивают влияние на сроки и стоимость. Иначе проект теряет границы.
Кто отвечает, если сделано не по ТЗ?
Исполнитель обязан привести результат в соответствие с согласованным документом. Поэтому ТЗ прикладывают к договору.
Как ТЗ влияет на сроки разработки?
Подробное ТЗ сокращает сроки: меньше вопросов и переделок. Ориентиры такие: лендинг — от 2 недель, корпоративный сайт — от 3 недель, интернет-магазин — от 3 недель на WooCommerce и от 4 недель на 1С-Битрикс, если контент и согласования не задерживаются. Точный срок для своего состава — в калькуляторе.
Что такое пример технического задания сайта и как его использовать?
Пример показывает, какой глубины должны быть описания. Используйте его как ориентир по уровню детализации, а содержание пишите под свои задачи: чужие цели и функции редко совпадают с вашими.
Итог
Техническое задание на разработку сайта — это общий язык заказчика и исполнителя. Оно фиксирует цели, структуру, функции, требования к дизайну и технике, интеграции, контент и правила приёмки, и за счёт этого делает смету, сроки и результат предсказуемыми.
Писать ТЗ в одиночку не обязательно: заказчик описывает бизнес-задачи, разработчик переводит их в технические требования. Главное — конкретика, проверяемые формулировки и фиксация всех изменений по ходу проекта.
Если нужно составить техническое задание и сразу получить по нему точную смету, я как частный разработчик на WordPress и 1С-Битрикс помогу собрать требования, опишу структуру и функции и реализую проект. Работаю напрямую, без посредников — подробнее на странице разработки сайтов.
