Хорошее техническое задание на сайт — это не перечень страниц, цветов и кнопок. Оно связывает бизнес-цель, потребности пользователей, контент, функции, потоки данных и проверяемые критерии качества. До начала дизайна команда должна понимать, для кого создаётся сайт, какие задачи на нём будут решать посетители и какой результат хочет измерять компания. До начала разработки необходимо согласовать CMS, интеграции, безопасность, SEO, производительность, доступность, инфраструктуру и порядок приёмки.
Техническое задание не должно заранее определять каждый пиксель или диктовать разработчику структуру кода. Его задача — уменьшить неопределённость. Чем раньше приняты ключевые решения, тем меньше риск переделывать дизайн из-за функциональных ограничений или получить красивый сайт, который не соответствует реальным рабочим процессам компании.
Что такое техническое задание на сайт
Техническое задание, или спецификация проекта, — согласованное описание того, что создаётся, зачем, для кого и по каким критериям будет принят готовый результат. Оно становится общей точкой отсчёта для руководства, маркетинга, авторов контента, дизайнера, разработчика и внешних подрядчиков.
Документ не обязан занимать сто страниц. Для небольшого корпоративного сайта достаточно компактной спецификации, если в ней не остаётся существенной неопределённости относительно границ проекта. Более сложной платформе потребуются дополнительные материалы: модель данных, матрица ролей, схемы интеграций, прототипы и отдельные сценарии приёмки.
Главный принцип: требование должно быть понятным и проверяемым. Фраза «сайт должен быть современным и быстрым» задаёт направление, но не описывает готовый результат. Полезнее указать, что ключевые публичные страницы должны быть удобны на согласованных мобильных устройствах, а производительность оценивается по заранее выбранным Core Web Vitals и сценариям тестирования.
Сначала определите бизнес-цель
До обсуждения главной страницы, меню и анимации ответьте на вопрос: что сайт должен изменить в работе компании?
Целью может быть получение квалифицированных заявок, более понятная презентация услуг, самообслуживание клиентов, приём бронирований, продажи, снижение нагрузки на поддержку или выход на новый языковой рынок. Целей может быть несколько, но им нужен порядок приоритетов. Иначе каждый отдел попытается вынести на главную страницу своё сообщение, а посетитель не поймёт, какое действие от него ожидается.
Для каждой цели фиксируют показатели успеха. Это могут быть отправленные заявки, завершённые бронирования, звонки с сайта, скачивания документов, завершение процесса самообслуживания или количество квалифицированных контактов. Не нужно обещать конкретный рост без достаточных данных. Важно определить, что измеряется, каким инструментом собираются данные и кто будет анализировать их после запуска.
Аудитории и ключевые пользовательские сценарии
Формулировка «наши клиенты — все компании» не помогает проектированию. Нужны несколько конкретных сегментов с разными потребностями, уровнем знаний и мотивами принятия решения. Руководителю важно быстро понять ценность и надёжность, а технический специалист ищет сведения об интеграциях, безопасности и внедрении.
Для каждого важного сегмента опишите основной путь:
откуда посетитель, вероятнее всего, придёт;
какой вопрос он хочет решить;
какая информация нужна для решения;
какое действие должен поддержать сайт;
что может помешать завершить это действие.
Эти сценарии формируют информационную архитектуру и прототип. Если задача сайта — собирать заявки, недостаточно написать «нужна контактная форма». Следует определить, на каком этапе пути появляется форма, какие поля действительно необходимы, что происходит после отправки и куда заявка попадает внутри компании.
Границы проекта и структура сайта
В техническом задании необходимо отделить обязательный объём первой версии от будущих идей. Это защищает проект от постоянного добавления новых требований в уже утверждённый бюджет и срок.
Составьте карту сайта: основные разделы, типы страниц и их иерархию. Корпоративный сайт может включать главную, обзор услуг, отдельные страницы услуг, информацию о компании, проекты, блог, контакты и юридические документы. Определяйте не только перечень страниц, но и повторяемые шаблоны. Одна страница услуги и двадцать страниц на общей модели контента — разный объём реализации.
Столь же явно укажите, что не входит в проект. Например, написание текстов, переводы, фотосъёмка, платежи, клиентский портал или миграция данных. Список исключений предотвращает ситуацию, когда одна из сторон считает работу «очевидно включённой».
Контент, языки и миграция
Качественный дизайн невозможно подготовить без понимания реального контента. Длина заголовков, объём таблиц, пропорции изображений, количество языков и обязательные юридические уведомления напрямую влияют на макеты.
До начала дизайна согласуйте:
типы контента на сайте;
ответственных за тексты, изображения, видео и документы;
готовые материалы и то, что ещё предстоит создать;
процесс согласования контента;
языки первой версии;
должен ли контент полностью совпадать на всех языках;
необходимость переноса старого контента и URL.
При замене существующего сайта техническое задание должно включать инвентаризацию контента и план перенаправлений. Старые URL нельзя просто забыть. Нужно решить, какие адреса сохраняются, какие объединяются и куда ведут постоянные перенаправления. Это снижает количество неработающих ссылок и помогает сохранить уже накопленную видимость в поиске.
Требования к дизайну — это не только цвета
В раздел о дизайне включают материалы бренда, правила их применения, желаемый характер и практические ограничения. Если у компании есть логотип, фирменные цвета, лицензированные шрифты, стиль фотографий или брендбук, их следует предоставить до создания первых макетов.
Примеры других сайтов полезны, если к каждому добавлено объяснение, что именно нравится: логика навигации, иерархия контента, использование изображений или спокойный визуальный ритм. Пять ссылок с комментарием «хотим так же» создают больше догадок, чем ясности.
Согласуйте и результат этапа дизайна: какие страницы и состояния будут отрисованы, как представят мобильную версию, будет ли кликабельный прототип и сколько раундов правок входит в процесс. Для форм нужны не только пустые поля, но и состояния ошибки, успешной отправки, загрузки и недоступности внешнего сервиса.
Описывайте функции через действия и результат
Список «поиск, фильтр, калькулятор, вход» слишком общий для точной оценки. Для каждой существенной функции укажите пользователя, начальное условие, действия, результат, ошибки и возможности управления через CMS.
Например, для формы заявки стоит определить:
обязательные и необязательные поля;
валидацию и принцип сообщений об ошибках;
защиту от автоматического спама;
получателя и формат уведомления;
передачу данных в почту, CRM или обе системы;
сообщение пользователю после отправки;
срок хранения и круг лиц с доступом;
способ проверки интеграции.
Так дизайнер сможет показать полный сценарий, разработчик — оценить логику, а заказчик — понять фактический результат.
CMS и процесс управления контентом
Требование «нужна удобная CMS» субъективно. Опишите, что команда должна выполнять без помощи разработчика. Нужно ли создавать страницы услуг, менять навигацию, управлять SEO-полями, сохранять черновики, планировать публикацию, восстанавливать предыдущую версию и просматривать историю действий?
Определите роли и права доступа. Администратору, редактору, переводчику и внешнему автору не всегда нужен одинаковый доступ. Если контент проходит согласование, зафиксируйте статусы и ответственных: черновик, проверка, утверждено, опубликовано и архив.
Для многоязычного сайта нужно определить, как связаны переводы, что происходит при отсутствии перевода и может ли структура различаться между языками. Эти решения влияют на модель данных CMS и SEO.
Интеграции и потоки данных
Если сайт связан с CRM, ERP, складской системой, платформой email-маркетинга, платежным сервисом или календарём, одного названия интеграции недостаточно. Определите источник данных, направление передачи, поля, способ аутентификации, частоту синхронизации и обработку ошибок.
Особенно важен вопрос: какая система является основным источником данных? Если телефон клиента исправили в CRM, а в CMS осталось старое значение, необходимо правило выбора актуальной версии. Следует предусмотреть и недоступность внешнего сервиса. Сохраняются ли данные для повторной отправки? Получает ли администратор уведомление? Что видит пользователь?
Нефункциональные требования: качество, которое ощущает пользователь
Нефункциональные требования описывают качество всей системы, а не очередную кнопку. Их часто откладывают до конца, хотя они способны повлиять на архитектуру и дизайн ещё в начале проекта.
Производительность и устройства
Укажите приоритетные устройства, браузеры и сетевые условия. Core Web Vitals от Google можно использовать как общую точку отсчёта, но необходимо согласовать среду измерения и типовые страницы. Лабораторный тест и данные реальных пользователей отличаются, поэтому критерий приёмки должен указывать, как и когда выполняется измерение.
Доступность
Доступность должна быть частью проекта с самого начала. Требования WCAG 2.2 влияют на контраст, управление клавиатурой, видимость фокуса, ошибки форм, структуру заголовков, альтернативный текст и поведение интерактивных элементов. В техническом задании следует указать целевой уровень соответствия, объём проверки и ответственность за доступность контента после передачи сайта.
Техническое SEO
Основы SEO закладывают в архитектуру, а не добавляют перед публикацией. Спецификация должна охватывать индексируемые публичные страницы, правила URL, поля title и meta description, canonical, sitemap.xml, robots.txt, hreflang для языков, структурированные данные, страницу 404 и перенаправления. Google называет три минимальных технических условия для возможности индексации: Googlebot не заблокирован, страница отвечает статусом HTTP 200 и содержит индексируемый контент. Выполнение этих условий не гарантирует индексацию, но без технической основы сайт не сможет получить устойчивую поисковую видимость.
Безопасность
Требования безопасности определяют по рискам, а не одной фразой «сайт должен быть безопасным». Следует описать аутентификацию, права ролей, управление сессиями, проверку входных данных, ограничения загрузки файлов, журналы действий, обновления, резервные копии, уведомление об инцидентах и хранение секретов. Для более сложных проектов OWASP ASVS можно использовать как структурированную основу для требований и проверки безопасности.
Аналитика, конфиденциальность и согласие
План аналитики должен соответствовать бизнес-целям. Определите ключевые события: начало и отправка формы, клик по номеру телефона, завершение бронирования, покупка или другое ценное действие. Согласуйте инструменты, доступы и управление тегами.
Если сайт обрабатывает персональные данные, определите цель, необходимые поля, получателей, срок хранения и процесс удаления. Использование cookies и других технологий отслеживания следует связать с корректным управлением согласием. При необходимости основание обработки и тексты уведомлений проверяет специалист по защите данных или юрист; разработчик не может определить все юридические основания вместо компании.
Инфраструктура, права и обслуживание
До начала разработки нужно знать, где будет работать сайт и кто управляет технической средой. В спецификации фиксируют ответственного за домен и DNS, требования к хостингу, среды разработки и тестирования, сертификаты SSL/TLS, отправку почты, частоту резервного копирования, проверку восстановления и мониторинг.
Согласуйте права на результат: кому принадлежат дизайн-файлы, исходный код, контент, лицензии и аккаунты внешних сервисов. Компания должна получить доступы и документацию, чтобы решение не зависело от пароля одного человека или его личного аккаунта.
Обслуживание — это не только исправление ошибок. Определите, кто устанавливает обновления безопасности, контролирует резервные копии, реагирует на инциденты и выполняет изменения после запуска. Гарантийные дефекты, новые функции и работа с контентом должны регулироваться отдельно.
Критерии приёмки и тестирование
Техническое задание готово только тогда, когда на его основе можно провести приёмочные тесты. Для каждой критической функции нужен ожидаемый результат. Например: после корректной отправки формы заявка сохраняется в CRM, ответственный получает уведомление, а пользователь видит подтверждение; при сбое запись не теряется, и администратор получает предупреждение.
План тестирования должен включать:
сценарии функций и интеграций;
проверку мобильной версии и браузеров;
проверку контента и ссылок;
тесты доступности;
измерение производительности;
технический контроль SEO;
проверки безопасности согласно риску;
практическую проверку CMS редакторами;
восстановление резервной копии, если оно входит в поставку.
Укажите, кто тестирует, где регистрируются дефекты, как назначается приоритет и кто даёт окончательное согласование.
Сроки, ответственность и управление изменениями
График должен включать не только дизайн и разработку, но и даты решений заказчика, передачи контента, переводов, тестирования и согласования. Если контент задерживается на две недели, сохранить исходную дату запуска без других изменений невозможно.
Простая матрица ответственности показывает, кто принимает бизнес-решения, утверждает дизайн, готовит контент, предоставляет доступы для интеграций и принимает готовую работу. Один человек должен иметь полномочия объединять противоречивую внутреннюю обратную связь.
Необходимо описать и порядок изменений. Новая идея не создаёт проблемы, если команда оценивает её влияние на объём, стоимость и срок. Проблемы начинаются, когда новая функция называется уточнением исходного требования.
Неясные и проверяемые требования
| Неясное требование | Проверяемое требование |
| Сайт должен быть современным | Дизайн использует утверждённую систему бренда, охватывает согласованные мобильные и настольные сценарии и проходит установленную проверку прототипа. |
| Нужна удобная CMS | Редактор без разработчика создаёт страницу услуги, меняет навигацию, заполняет SEO-поля, сохраняет черновик и восстанавливает предыдущую версию. |
| Форма отправляет заявки | Корректная заявка сохраняется в указанной системе, ответственный получает уведомление, пользователь видит подтверждение, а ошибки регистрируются. |
| Сайт должен быть быстрым | Производительность выбранных шаблонов проверяется в согласованной среде по конкретным показателям до запуска. |
| Нужно SEO | Определены индексируемые страницы, URL, метаданные, canonical, sitemap, robots, hreflang, структурированные данные, перенаправления и поведение 404. |
Практическая структура технического задания
Для большинства корпоративных сайтов достаточно такого каркаса:
Контекст проекта и бизнес-проблема.
Цели, приоритеты и показатели успеха.
Аудитории и ключевые пользовательские сценарии.
Объём, карта сайта и исключения.
Контент, языки, миграция и ответственные.
Направление дизайна, устройства, прототип и согласование.
Функции, пользовательские сценарии и состояния ошибок.
CMS, роли, процессы и модель данных.
Интеграции и потоки данных.
Производительность, доступность, SEO и безопасность.
Аналитика, конфиденциальность и согласие.
Инфраструктура, резервные копии и обслуживание.
Тестирование и критерии приёмки.
Сроки, ответственность, результаты и порядок изменений.
Документ можно дополнить картой сайта, таблицей контента, прототипом, схемой интеграций и матрицей ролей. Важно не количество приложений, а способность команды принимать согласованные решения без разных предположений.
Кто готовит техническое задание
Заказчик не обязан самостоятельно знать все технические детали. Компания лучше всех понимает свои цели, клиентов, внутренние процессы и ограничения. Партнёр по разработке помогает превратить эти потребности в архитектуру, требования и критерии приёмки.
Поэтому сильная спецификация обычно появляется в ходе структурированной диагностики, а не после заполнения пустого шаблона. Шаблон помогает не забыть вопросы, но не заменяет разговор с людьми, которые будут публиковать контент, обрабатывать заявки и обслуживать систему.
Заключение
Техническое задание на сайт — это документ о принятых решениях. До дизайна оно должно определить цель, аудиторию, пользовательские пути, структуру контента и границы проекта. До разработки — функции, поведение CMS, интеграции, требования к качеству, инфраструктуру и порядок приёмки.
Если два человека понимают требование совершенно по-разному, оно ещё не готово. Если требование связано с бизнес-потребностью, его можно спроектировать, реализовать и проверить — оно помогает избежать лишних переделок.
При планировании сайта для компании в Латвии не обязательно приходить с готовым техническим документом. Достаточно ясно описать исходную ситуацию и цель; профессиональный процесс разработки должен превратить эту информацию в реализуемую спецификацию.