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

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

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

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

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

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

Техническое задание решает сразу несколько задач.

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

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

Чем техническое задание отличается от прототипа и дизайна

Эти документы часто путают, хотя они решают разные задачи.

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

Отвечает на вопрос: что должен представлять собой будущий сайт и как он должен работать?

Прототип

Показывает структуру конкретных страниц и расположение основных элементов интерфейса.

Дизайн-макет

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

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

1. Общая информация о проекте

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

Здесь можно указать:

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

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

2. Цели и задачи разработки сайта

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

Лучше определить конкретные задачи.

Например:

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

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

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

3. Целевая аудитория

Разработчикам и дизайнерам важно понимать, для кого создается сайт.

В ТЗ стоит описать основные сегменты аудитории и их особенности.

Для каждого сегмента можно указать:

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

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

4. Анализ конкурентов и позиционирование

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

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

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

Это помогает избежать ситуации, когда дизайнер создает красивый интерфейс, но он никак не отражает позиционирование компании.

5. Структура и карта сайта

В ТЗ необходимо определить состав основных разделов сайта.

Например:

1. Главная.
2. О компании.
3. Услуги.
4. Страница отдельной услуги.
5. Кейсы.
6. Блог.
7. Новости.
8. Вакансии.
9. Контакты.

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

Например:

• Услуги
  • Разработка сайта
  • Редизайн
  • SEO
  • Поддержка

Карта сайта должна быть согласована до начала активной разработки, особенно если структура влияет на SEO и пользовательские сценарии.

6. Требования к каждой странице

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

В ТЗ можно определить:

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

Пример описания страницы услуги

Для страницы услуги можно предусмотреть:

1. заголовок и краткое описание;
2. основные преимущества;
3. описание услуги;
4. этапы работы;
5. кейсы;
6. ответы на частые вопросы;
7. отзывы;
8. призыв к обращению;
9. контактную форму.

Такой подход значительно полезнее формулировки «сделать продающую страницу услуги».

7. Требования к функциональности

Все функции сайта желательно перечислить отдельно. Чем сложнее функциональность, тем подробнее она должна быть описана.

В ТЗ могут быть указаны:

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

Для каждой сложной функции желательно описать не только ее наличие, но и сценарий работы.

Например, для формы заявки

1. Пользователь заполняет обязательные поля.
2. Система проверяет корректность данных.
3. Показывается сообщение об успешной отправке.
4. Заявка передается в CRM.
5. Ответственный сотрудник получает уведомление.
6. Источник обращения сохраняется в системе аналитики.

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

8. Требования к административной панели

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

Например:

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

Также стоит определить уровни доступа, если с сайтом будут работать несколько сотрудников.

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

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

В этот раздел можно включить:

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

Если компания работает в нескольких странах или сегментах, дополнительно стоит определить требования к локализации дизайна.

10. Требования к адаптивности

Фраза «сайт должен быть адаптивным» слишком общая для технического задания.

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

Можно зафиксировать:

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

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

11. Требования к SEO

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

В зависимости от проекта можно предусмотреть:

• SEO-friendly структуру сайта;
• понятную структуру URL;
• возможность редактирования Title и Description;
• корректную иерархию заголовков;
• файл sitemap.xml;
• настройку robots.txt;
• 301-редиректы;
• канонические URL;
• микроразметку при необходимости;
• возможность создания и оптимизации посадочных страниц;
• внутреннюю перелинковку;
• корректную индексацию.

Если создается новый сайт вместо старого, отдельный раздел ТЗ стоит посвятить миграции: переносу URL, контента, метаданных и настройке редиректов.

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

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

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

В ТЗ можно зафиксировать требования к:

• оптимизации изображений;
• загрузке CSS и JavaScript;
• кэшированию;
• серверной конфигурации;
• корректному отображению страниц;
• обработке ошибок;
• стабильности сайта при ожидаемой нагрузке.

При необходимости конкретные показатели производительности можно согласовать отдельно. Главное — определить критерии, которые реально можно проверить.

13. Интеграции с внешними системами

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

Это могут быть:

• CRM;
• телефония;
• сервисы аналитики;
• платежные системы;
• сервисы рассылок;
• ERP;
• складские системы;
• карты;
• внешние API;
• системы авторизации.

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

14. Контент и требования к материалам

ТЗ должно определить, кто и в каком формате предоставляет контент.

Нужно зафиксировать:

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

Если контент входит в услуги веб-студии, это также должно быть четко описано: объем текстов, количество страниц, количество изображений и другие параметры.

15. Требования к аналитике

Если сайт должен приносить заявки, важно заложить систему измерения результатов еще на этапе разработки.

В ТЗ можно предусмотреть настройку и проверку:

• систем веб-аналитики;
• целей;
• событий;
• отправки форм;
• кликов по телефонам;
• кликов по email;
• переходов в мессенджеры;
• источников обращений.

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

16. Безопасность и резервное копирование

Для корпоративного сайта вопросы безопасности нельзя полностью оставлять за рамками ТЗ.

В зависимости от проекта можно описать:

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

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

17. Требования к домену, хостингу и инфраструктуре

ТЗ может содержать технические требования к среде размещения сайта.

Например:

• версия серверного ПО;
• требования к базе данных;
• объем дискового пространства;
• SSL;
• резервное копирование;
• требования к DNS;
• ограничения хостинга;
• требования к серверным ресурсам.

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

18. Требования к тестированию

До запуска сайт необходимо проверить. Но формулировка «провести тестирование» сама по себе недостаточна.

В ТЗ можно определить проверку:

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

Для сложных проектов желательно составить отдельный чек-лист приемочного тестирования.

19. Порядок сдачи и приемки сайта

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

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

Стоит зафиксировать:

1. какие результаты передает подрядчик;
2. в каком виде передается сайт;
3. сколько времени есть у заказчика на проверку;
4. как передаются замечания;
5. какие исправления входят в стоимость;
6. как подтверждается устранение недостатков;
7. когда этап считается принятым.

Чем конкретнее критерии приемки, тем меньше вероятность спора на финальном этапе.

20. Что должно быть в ТЗ с точки зрения договора

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

Важно проверить, что документы не противоречат друг другу.

Особое внимание стоит уделить:

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

Что не стоит писать в техническом задании

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

Избегайте расплывчатых формулировок:

• «сайт должен быть красивым»;
• «дизайн должен быть современным»;
• «страницы должны быстро загружаться»;
• «SEO должно быть на высоком уровне»;
• «сайт должен быть удобным»;
• «форма должна работать корректно».

Такие требования желательно заменять критериями, которые можно проверить.

Как сделать ТЗ действительно рабочим документом

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

Перед согласованием документа полезно проверить каждый важный пункт по четырем вопросам:

1. Что именно должно быть сделано?
2. Как это должно работать?
3. Как проверить, что требование выполнено?
4. Что происходит, если требование меняется?

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

Оптимальная структура технического задания на разработку сайта

Для большинства корпоративных проектов структуру ТЗ можно выстроить следующим образом:

1. Общая информация о проекте.
2. Цели и задачи.
3. Целевая аудитория.
4. Позиционирование и анализ конкурентов.
5. Карта сайта и структура разделов.
6. Описание ключевых страниц.
7. Функциональные требования.
8. Требования к CMS и административной панели.
9. Требования к дизайну.
10. Адаптивность.
11. SEO.
12. Производительность.
13. Интеграции.
14. Контент.
15. Аналитика.
16. Безопасность.
17. Хостинг и инфраструктура.
18. Тестирование.
19. Приемка.
20. Порядок внесения изменений.

Чек-лист перед утверждением ТЗ

Перед подписанием или согласованием технического задания проверьте, что в документе действительно есть ответы на следующие вопросы:

• Какая бизнес-задача решается с помощью сайта?
• Для кого он создается?
• Какие страницы должны быть разработаны?
• Какие функции обязательны?
• Кто предоставляет контент?
• Какие интеграции необходимы?
• Какие требования предъявляются к мобильной версии?
• Какие SEO-задачи входят в проект?
• Как будет настраиваться аналитика?
• Как сайт будет тестироваться?
• Какие критерии определяют готовность проекта?
• Как проходит приемка?
• Как согласуются изменения?
• Какие материалы и доступы получает заказчик после запуска?

Итог

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

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

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

Хорошее ТЗ отвечает на главный вопрос проекта: «Как мы поймем, что сайт действительно сделан правильно?»

Если этот ответ понятен заказчику и веб-студии одинаково, большая часть рисков разработки уже снижена еще до начала работ.

FAQ: часто задаваемые вопросы о техническом задании на разработку сайта