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

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

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

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

Без нормального ТЗ обычно возникают одни и те же проблемы:

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

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

Каким должно быть хорошее ТЗ

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

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

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

Структура технического задания на сайт

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

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

Как собрать ТЗ по шагам

1. Сформулируйте цель сайта

Начинать нужно не со страниц, а с цели. Ответьте простыми словами:

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

Примеры:

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

Хорошая формулировка звучит конкретно: «Сайт должен увеличить количество обращений на консультацию через форму и мессенджеры». Плохая — «нужен красивый сайт компании». Я часто советую заказчикам представить, что они рассказывают о проекте коллеге за 30 секунд — именно эта суть и должна лечь в основу цели.

2. Опишите аудиторию

Без понимания аудитории сложно сделать адекватную структуру и подачу. Укажите:

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

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

3. Зафиксируйте структуру сайта

На этом этапе нужен список всех страниц и разделов. Для сложных сайтов полезно добавить карту сайта.

Пример структуры:

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

Для интернет-магазина дополнительно понадобятся:

• каталог;
• карточка товара;
• корзина;
• оформление заказа;
• личный кабинет;
• доставка и оплата;
• избранное.

Важно: не ограничивайтесь названием страницы. Если есть важные вложенные разделы, формы или сценарии, их тоже нужно перечислить. Например, в разделе «Услуги» может быть фильтр по категориям и тегам, а в «Кейсах» — сортировка по отрасли. Эти детали напрямую влияют на дизайн и верстку.

4. Опишите функционал

Функционал — это все, что сайт должен уметь делать. Чем конкретнее он описан, тем меньше шансов на недопонимание.

Указывайте:

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

Не пишите «добавить удобную форму». Лучше так: «Форма заявки должна содержать имя, телефон, email, поле комментария, чекбокс согласия, валидацию и сообщение об успешной отправке». В нашей практике был случай, когда фраза «интеграция с CRM» в ТЗ обернулась неделей дополнительной разработки, потому что не уточнили, какие именно поля передавать и в каком формате. Детали решают.

5. Пропишите требования к каждой важной странице

Для ключевых страниц нужно не просто название, а состав блоков и их логика.

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

• первый экран с УТП и кнопкой действия;
• блок преимуществ;
• услуги или направления;
• кейсы;
• отзывы;
• этапы работы;
• FAQ;
• контакты.

Для страницы услуги:

• заголовок и краткое описание;
• состав услуги;
• цена или принцип расчета;
• сроки;
• кейсы;
• частые вопросы;
• форма заявки.

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

6. Определите требования к дизайну

Здесь важно не пытаться описать дизайн слишком общо. Лучше собрать опорные материалы:

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

Полезно отдельно описать:

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

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

7. Укажите технические требования

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

Нужно описать:

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

Если требования пока не выбраны, так и напишите: «CMS определяется после согласования структуры и бюджета». Лучше честная неопределенность, чем случайное решение, которое потом придется переделывать. В одном проекте мы потратили две недели на перенос сайта с самописной CMS на WordPress, потому что изначально в ТЗ не уточнили, что заказчику нужна возможность самостоятельно редактировать контент без программиста.

8. Продумайте SEO-требования

Если сайт нужен не только «чтобы был», сразу добавляйте базовые SEO-параметры.

Минимум:

• логичная структура URL;
• возможность редактировать title, description, H1;
• ЧПУ;
• микроразметка для ключевых страниц;
• генерация sitemap.xml и robots.txt;
• корректная работа редиректов;
• оптимизация скорости загрузки;
• адаптивность;
• базовая семантическая структура шаблонов.

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

9. Опишите контент и ответственность за него

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

В ТЗ нужно указать:

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

Если контент делает заказчик, это нужно отдельно зафиксировать. Иначе срыв сроков почти гарантирован. По опыту, самый частый «стоп-кран» в проектах — ожидание текстов от клиента. Прописывайте ответственность явно: «Заказчик предоставляет тексты для всех страниц до 15 числа, в противном случае сроки сдвигаются».

10. Зафиксируйте этапы, сроки и приемку

Без этого ТЗ не работает как управленческий документ. Разбейте проект на этапы:

• аналитика и прототипирование;
• дизайн;
• верстка;
• программирование;
• наполнение;
• тестирование;
• запуск.

Для каждого этапа укажите:

• срок;
• результат;
• ответственного;
• что считается завершением этапа.

Также пропишите приемку:

• кто принимает;
• в какие сроки;
• сколько кругов правок предусмотрено;
• какие ошибки считаются критичными;
• что не входит в объем работ.

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

Что обязательно должно быть в ТЗ на сайт

Ниже — короткий чек-лист.

• Цель сайта и ожидаемый результат.
• Описание компании и аудитории.
• Полный список страниц.
• Функциональные требования.
• Описание ключевых блоков и сценариев.
• Требования к дизайну.
• Технические требования.
• SEO-минимум.
• Контент и ответственность за него.
• Сроки, этапы, формат приемки.

Этот список можно распечатать и держать перед глазами при составлении ТЗ — он не даст упустить критически важные разделы.

Типовые ошибки при подготовке ТЗ

Слишком общие формулировки

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

Отсутствие приоритетов

Не все пожелания равны. В ТЗ полезно разделять:

• обязательно;
• желательно;
• можно отложить на следующий этап.

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

Смешивание требований и пожеланий

Если в одном списке перемешаны критичные функции и идеи «на будущее», исполнитель не поймет, что делать в первую очередь. Отделяйте MVP (минимально жизнеспособный продукт) от дополнительных фич.

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

В России большая часть трафика на многих проектах приходит с телефонов. Если в ТЗ нет требований к мобильной версии, сайт может оказаться неудобным для реальных пользователей. Всегда прописывайте контрольные точки: 320, 768, 1024, 1440 px — и поведение элементов на этих разрешениях.

Нет правил приемки

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

Практический пример: как сформулировать раздел ТЗ

Плохо

• Сделать удобный сайт для компании.
• Добавить форму заявки.
• Нужен современный дизайн.

Хорошо

• Сайт должен собирать заявки на расчет стоимости услуг.
• На главной странице разместить УТП, преимущества, блок услуг, кейсы, отзывы, FAQ и форму заявки.
• Форма должна содержать имя, телефон, email и комментарий.
• Сайт должен корректно отображаться на экранах от 320 px.
• В админке должна быть возможность менять тексты, изображения и цены без участия разработчика.

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

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

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

1. Общая информация

• Название проекта
• Заказчик
• Исполнитель
• Дата

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

• Зачем создается сайт
• Какие бизнес-задачи он решает
• Как измеряется результат

3. Аудитория

• Кто пользователи
• Какие у них задачи
• С каких устройств они заходят

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

• Список страниц
• Подстраницы
• Сценарии переходов

5. Функционал

• Формы
• Интеграции
• Фильтры
• Личный кабинет
• Поиск
• Оплата

6. Требования к дизайну

• Стиль
• Цвета
• Шрифты
• Референсы
• Ограничения

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

• CMS
• Адаптивность
• Браузеры
• Хостинг
• Безопасность

8. Контент

• Что уже есть
• Что нужно подготовить
• Кто отвечает

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

• Метатеги
• Микроразметка
• Счетчики
• Карта сайта

10. Сроки и приемка

• Этапы
• Даты
• Условия сдачи
• Формат правок

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

Когда ТЗ нужно особенно тщательно

ТЗ стоит делать максимально подробным, если:

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

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

Как проверить, что ТЗ готово

Перед передачей исполнителю задайте себе несколько вопросов:

• Понятно ли, зачем нужен сайт?
• Можно ли по ТЗ оценить объем работ?
• Понимает ли исполнитель, что делать на каждой странице?
• Есть ли описание ключевых функций?
• Указано ли, кто дает контент?
• Есть ли сроки и этапы?
• Можно ли по документу проверить результат?

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

Вывод

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

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

FAQ

Кто должен писать ТЗ на сайт?

Идеально — заказчик вместе с исполнителем. Заказчик дает бизнес-цели и контекст, исполнитель помогает перевести их в технические требования. В студии мы часто проводим совместную сессию, где заполняем основные разделы в реальном времени — это снимает 90% вопросов.

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

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

Нужно ли включать SEO в ТЗ?

Да, хотя бы базовый набор: структура URL, метатеги, микроразметка, карта сайта, скорость и адаптивность. Это не займет много времени, но избавит от головной боли при запуске рекламных кампаний.

ТЗ и бриф — это одно и то же?

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

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

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