техническое задание (тз) для сайта

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

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

Представьте: вы хотите построить дом, но говорите строителям только «сделайте красиво». Результат может вас не устроить. С сайтом та же история. ТЗ фиксирует ожидания, приоритеты и критерии приёмки. Это не просто документ — это соглашение, по которому команда будет работать.

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

Кому нужно ТЗ

ТЗ полезно всем участникам проекта. Заказчику — чтобы учесть свои бизнес-цели. Проектному менеджеру — чтобы планировать спринты и контроль качества. Разработчикам и дизайнерам — чтобы знать границы и приоритеты. Тестировщикам — чтобы составлять тест-кейсы. И юридическим отделам — чтобы описать обязательства сторон.

Даже если вы работаете с фрилансером, ТЗ всё равно необходимо. Оно сокращает вероятность недоразумений и служит опорой при обсуждении правок и оплаты.

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

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

• Введение и цели проекта
• Термины и участники
• Область и границы работ
• Функциональные требования
• Нефункциональные требования
• Требования к дизайну и UX
• Контент и структура сайта
• Интеграции и API
• Безопасность и GDPR
• Хостинг и инфраструктура
• Тестирование и приёмка
• Сроки, этапы, бюджет
• Сопровождение и документация
• Приложения: макеты, словарь терминов, примеры

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

Введение и цели проекта

Начните с краткой, но ёмкой формулировки задачи: зачем создаётся сайт, какую бизнес-цель он решает, кто целевая аудитория. Это помогает всем участникам выстраивать приоритеты. Например: «Создать интернет-магазин для продажи спортивного питания с удобной корзиной и интеграцией 1С» — уже даёт много контекста.

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

Термины и участники

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

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

Область и границы работ

Чётко пропишите, что входит в объём работ, а что — нет. Это главное место, где фиксируются ожидания. Например, «включить базовую SEO-оптимизацию» мало говорит; лучше: «прописать мета-теги для 50 ключевых страниц, настроить ЧПУ и карту сайта».

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

Примеры границ

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

Функциональные требования

Это сердце ТЗ. Описывайте функции так, чтобы по ним можно было написать тест-кейсы. Лучше использовать список или таблицу с приоритетами. Укажем примерный набор для интернет-магазина, но структуру можно применить к любому типу сайта.

Для других типов сайтов — портала или лендинга — список будет другим, но принцип тот же: функция, описание, приоритет, критерии приёмки.

Пользовательские сценарии и истории

Опишите ключевые сценарии взаимодействия. Лучше в форме user story: «Как покупатель, я хочу… чтобы…». Такие истории удобны и разработчикам, и тестировщикам.

1. Как посетитель я хочу найти товар по фильтру, чтобы быстро сравнить варианты.
2. Как покупатель я хочу сохранить адрес доставки, чтобы ускорить повторные покупки.
3. Как администратор я хочу выгружать заказы в CSV, чтобы загружать их в учётную систему.

Нефункциональные требования

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

Примеры: время ответа страницы менее 2 секунд при 100 одновременных пользователях, аптайм не менее 99.9%, поддержка браузеров последние две версии Chrome, Firefox, Safari, Edge, адаптивность для мобильных и планшетов.

Производительность и нагрузочное тестирование

Укажите цели по производительности и условия для нагрузочного тестирования. Например: «Сайт должен выдерживать 500 одновременных пользователей при времени отклика не более 3 секунд. Провести нагрузочное тестирование и предоставить отчёт.»

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

Требования к безопасности

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

Дизайн и UX

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

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

Прототипы и макеты

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

Доступность

Если это важно, укажите требования по доступности: соответствие WCAG 2.1 уровня AA, контрастность текста, навигация с клавиатуры, корректные alt-атрибуты для изображений. Это не только этическая опция, но и юридическая защита и улучшение SEO.

Контент: структура и наполнение

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

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

Интеграции и API

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

Например: интеграция с 1С через обмен по XML каждые 15 минут; интеграция с платежным шлюзом X — реализовать webhooks и тестовые сценарии для успешной и неуспешной оплаты.

Примеры требований к API

• Описание всех эндпоинтов с примерами запроса/ответа
• Требования к авторизации и безопасности
• Ограничения по частоте запросов и обработка ошибок

Хостинг, инфраструктура и деплой

Опишите, где будет размещён сайт, какие ресурсы нужны, план по масштабированию. Уточните требования к резервному копированию и восстановлению, схемы CI/CD, процессы деплоя и права доступа к серверам.

Если инфраструктуру предоставляет подрядчик, зафиксируйте SLA. Если заказчик — предоставит доступы, перечислите, какие именно: FTP, SSH, панели управления, учётные записи в облаке.

Пример требований

• Развернуть на VPS с минимальными ресурсами: 4 vCPU, 8 GB RAM, SSD 100 GB
• Настроить автоматическое ежедневное резервное копирование с хранением 14 дней
• Настроить CI/CD: автоматический деплой в staging при пуше в ветку develop, ручной деплой в production

Тестирование и приёмка

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

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

Критерии приёмки

Опишите процедуру обработки багов: как они фиксируются, сроки исправления, критерии закрытия. Часто используют систему приоритетов P0-P3 и SLA на исправление.

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

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

Например: дизайн — 2 недели, верстка и интеграция — 4 недели, тестирование — 1 неделя. Общая оценка 7 недель плюс 2 недели на правки. Бюджет укажите в виде фиксированной суммы или поэтапной оплаты с процентами по вехам.

Таблица этапов

Сопровождение и документация

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

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

Примеры шаблонов и чеклисты

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

Чек-лист приёмки

• Все функции из раздела «Функциональные требования» реализованы и протестированы
• Макеты утверждены и соответствуют реальной верстке
• Произведено тестирование на основных устройствах и браузерах
• Проведено базовое нагрузочное тестирование
• Настроены резервные копии и доступы к серверу переданы заказчику
• Документация и инструкции переданы

Частые ошибки при составлении ТЗ

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

Пример готового фрагмента ТЗ: страница каталога

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

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

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

Обычно вводят каналы коммуникации (технический канал в мессенджере, таск-трекер для задач), форму заявки на изменение и SLA по оценке. Например: «Заказчик подаёт запрос, подрядчик оценивает в течение 3 рабочих дней, согласовывает стоимость и сроки, затем работа начинается».

Что ещё полезно добавить

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

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

Заключение

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

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

Полезная ссылка для дальнейшего чтения и заказа услуг: техническое задание (тз) для сайта