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

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

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

Читайте также: Особенности создания сайта на WordPress

Скидка 5000 рублей на SEO продвижение

Дарим скидку 5000 рублей на SEO продвижение сайта. Акция действует до конца сентября.

Заказать SEO

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

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

Зачем оно нужно:

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

Хорошее ТЗ — это фундамент проекта: с ним проще планировать, быстрее согласовывать и легче принимать работу.

Что должно быть в техническом задании

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

1) Вводная и контекст проекта

В начале дайте короткое описание, чтобы исполнитель сразу понял картину:

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

2) Цели и задачи (чтобы сайт был «про результат», а не «про страницы»)

Важно различать:

• Цель — ради чего создаётся сайт (бизнес-результат).
• Задачи — что нужно реализовать, чтобы к цели прийти (конкретные действия/функции).

Пример связки:

Чем точнее цели, тем проще принимать решения по дизайну и функционалу: «это помогает цели или просто хочется?».

3) Тип сайта и структура

Укажите тип проекта:

• лендинг / корпоративный сайт / интернет-магазин / медиа / сервис / портал.

Дальше — структура: какие разделы и страницы нужны. Лучше не «примерно», а списком.

Пример для интернет-магазина:

Если есть сложная навигация — добавьте схему (mindmap/diagram), это экономит часы созвонов.

4) Контент и материалы от заказчика

Чтобы сроки не «упёрлись в тексты», зафиксируйте:

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

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

5) Функциональные требования (самый важный блок)

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

Удобный формат: «что делает пользователь → что делает система → где это хранится → какие уведомления/интеграции».

Примеры функций:

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

Если есть требования к правам доступа в админке (контент-менеджер/админ/маркетолог) — укажите.

6) Дизайн и UX (как сайт выглядит и насколько им удобно пользоваться)

Этот раздел отвечает за то, чтобы «красиво» не противоречило «понятно».

Укажите:

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

Если планируются прототипы — зафиксируйте этап: прототип → дизайн-концепт → дизайн всех страниц.

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

Здесь важно описать рамки реализации:

• CMS/платформа (WordPress, 1C-Битрикс, Tilda, custom и т.д.) — если принципиально;
• требования к хостингу и окружению (PHP/Node, базы данных, объём, бэкапы);
• SSL/HTTPS, безопасность, защита форм от спама;
• скорость загрузки (ориентиры по PageSpeed/Core Web Vitals — если применимо);
• адаптивность (какие разрешения/брейкпоинты);
• требования к SEO: ЧПУ, редактирование meta, sitemap/robots, микроразметка (если нужна).

Пример требований к хостингу для магазина:

8) Сроки, этапы, бюджет

Чтобы ожидания совпали:

• этапы (аналитика → прототип → дизайн → разработка → тест → запуск);
• сроки по этапам;
• стоимость по этапам (если есть);
• условия оплаты (предоплата/по этапам/по факту).

9) Приёмка: как проверяем и что считается «готово»

Это то, что чаще всего забывают — и потом спорят.

Зафиксируйте:

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

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

Ниже — компактный шаблон, который можно адаптировать под свой проект.

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

Чтобы ТЗ было полезным, а не «на 50 страниц ради объёма», держите правила:

• Пишите однозначно. Вместо «красиво» — «минималистичный стиль, светлый фон, 2 основных цвета».
• Описывайте функции через сценарии. «Пользователь заполняет форму → система отправляет в CRM → менеджеру приходит уведомление».
• Разделяйте обязательное и желательное. Must have / Nice to have — иначе оценка бюджета будет неточной.
• Подкрепляйте примерами. Скриншоты, ссылки на референсы, прототипы — всё ускоряет понимание.
• Сразу думайте о приёмке. Если нельзя проверить результат — значит, требование сформулировано размыто.

Как изменить ТЗ в процессе разработки сайта

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

Как делать правильно:

• Вносите правки только в актуальную версию ТЗ (или через отдельный документ Change Request).
• Согласовывайте влияние на сроки и стоимость до начала работ по изменению.
• Фиксируйте, кто и когда утвердил правку (это дисциплинирует обе стороны).
• Доведите изменения до всех участников (разработка, дизайн, контент, маркетинг), чтобы не было расхождений.

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