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

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

Если вы никогда не писали ТЗ, не бойтесь — это навык, который растёт с опытом. Главное — ясность. Когда все требования прописаны конкретно и по делу, команда движется быстрее и увереннее.

Зачем нужно ТЗ и кому оно пригодится

На стартовом совещании часто кажется, что все поняли друг друга. Через неделю выясняется, что у заказчика и у разработчика были разные представления о «главной странице». ТЗ минимизирует такие сюрпризы. Документ фиксирует требования и служит опорой при обсуждениях, изменениях и приёме работ.

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

Общая структура хорошего ТЗ

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

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

Каждый раздел должен содержать конкретику. Не «сайт должен быть быстрым», а «время ответа сервера на первую отрисовку не более 1,5 секунды при 1000 одновременных пользователях». Чем точнее, тем лучше.

Введение: цели проекта и ключевые показатели

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

Примеры формулировок целей:

• Увеличить количество лидов через форму заявки на 30% за полгода.
• Снизить отказ на мобильных устройствах до 25%.
• Обеспечить возможность оформить покупку за 2 шага.

Также здесь полезно указать ключевые показатели эффективности (KPI): посещаемость, CTR, конверсия, среднее время сессии. Они помогут оценивать результат после запуска.

Описание целевой аудитории

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

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

Такие карточки помогают не гадать, а принимать решения, опираясь на реальные сценарии использования.

Содержание и структура сайта

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

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

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

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

Ниже примерный список функционала, который часто встречается:

• Адаптивная верстка для мобильных и планшетов
• Форма обратной связи с валидацией и антиспамом
• Личный кабинет пользователя: регистрация, восстановление пароля, профиль
• Каталог товаров/услуг с фильтрами и сортировкой
• Процесс оформления заказа с калькуляцией стоимости
• Административная панель для управления контентом
• Интеграция с CRM: передача лидов и статусов
• Система уведомлений по email и SMS

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

Пример описания функции: форма заявки

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

Критерии приёмки: отправка работает при заполненных обязательных полях, данные приходят в CRM, письмо администратору содержит все поля формы.

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

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

Примеры формулировок:

• Кроссбраузерность: последние две версии Chrome, Firefox, Safari, Edge; мобильные браузеры Android и iOS.
• Производительность: LCP менее 2.5 с на медленном мобильном 3G.
• Сервер: PHP 8.1 или Node.js 16+, MySQL 8 или PostgreSQL 13.
• Использовать HTTPS с HSTS, сертификат Let’s Encrypt или коммерческий.

Чем конкретнее, тем меньше споров при приёмке. Не оставляйте «по возможности» там, где нужна гарантия.

Требования к дизайну и интерфейсу

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

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

Пример: требования к кнопкам

Основная кнопка: цвет #FF6A00, радиус 6px, паддинги 12px 24px. При наведении — затемнение на 10%. Все кнопки имеют aria-label и видимую фокусную рамку.

Такие мелочи экономят время разработчика и дизайн-системы находятся в одном месте.

Контент: кто готовит и как передаётся

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

Например: тексты предоставляются в формате .docx, изображения — .jpg или .png с минимальной стороной 1200px, видео — .mp4, субтитры — .srt. Укажите крайние сроки передачи и контактное лицо.

SEO и аналитика

Сайт должен учитывать базовые требования поисковой оптимизации. Пропишите, как будут работать метатеги, ЧПУ, карта сайта, robots.txt и микроразметка. Укажите, кто отвечает за первичную оптимизацию текстов и структуру.

Не забудьте об аналитике: требуется подключение Google Analytics, Яндекс.Метрики, настройка целей и событий. Описывайте, какие события важно фиксировать: отправка формы, клик по телефону, завершение заказа.

Безопасность и соответствие требованиям

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

Пример пунктов:

• Пароли хранятся в виде хэшей bcrypt с подходящим фактором сложности.
• Регулярные бэкапы ежедневно и хранение резервных копий не менее 30 дней.
• Защита от SQL-инъекций и CSRF на всех формах.

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

Многие сайты интегрируются с CRM, платёжными шлюзами, ERP и email-сервисами. Для каждой интеграции опишите API, тип данных, частоту синхронизации и сценарии ошибки.

Пример: интеграция с CRM должна передавать лид при отправке формы, включать utm-метки и источник. При ошибке записи в CRM — система должна повторять попытку 3 раза и отправлять уведомление администратору.

Администрирование и CMS

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

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

Хостинг, домен и деплой

Укажите, где будет размещён сайт, кто отвечает за домен и настройки DNS, какие требования к резервному копированию и процессу деплоя. Поделитесь ожиданиями по доступности: SLA, время восстановления.

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

• Деплой через CI/CD: git push → автоматический билд → тесты → продакшн.
• Минимальный аптайм 99.9% в месяц.
• Резервирование в двух дата-центрах при высоконагруженных проектах.

План работ, этапы и сроки

Разбейте проект на этапы с конкретными сроками и результатами. Каждый этап должен иметь критерии приёмки и список артефактов.

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

Бюджет и условия оплаты

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

Примеры условий:

• Аванс 30% при старте, 40% после тестового релиза, 30% после приёмки.
• Часы сверх объёма оплачиваются по ставке, указанной в договоре.
• Изменения объёма работ фиксируются отдельным соглашением.

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

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

Критерии приёмки по каждому этапу помогут избежать споров. Например: баги, приводящие к потере данных или невозможности оплаты, считаются критическими и должны быть исправлены в течение 48 часов.

Поддержка и сопровождение после запуска

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

Например: плановое обслуживание раз в месяц, аварийная поддержка 24/7 с временем реакции 1 час для критических проблем.

Приложения: макеты, примеры, чек-листы

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

• Макеты страниц и компоненты интерфейса
• Примеры писем и шаблоны уведомлений
• Список API и их документация
• Контакты заказчика и ответственных лиц
• Чек-лист приёмки по этапам

Чек-лист должен быть простым и конкретным: «Форма обратной связи отправляет данные в CRM», «Все страницы имеют мета-теги и корректные заголовки H1». Такой список экономит время при проверке.

Типичные ошибки при составлении ТЗ и как их избежать

Одна из самых частых ошибок — неопределённость. Фразы вроде «удобный дизайн» или «быстрая загрузка» оставляют простор для разных интерпретаций. Конкретизируйте.

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

Не пренебрегайте тестированием. Иногда в ТЗ забывают прописать сценарии тестирования и критерии приёмки. Это приводит к спорам и дополнительным оплатам.

Готовый шаблон ТЗ — кратко и по делу

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

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

Несколько советов для быстрой и качественной подготовки ТЗ

• Начинайте с карты сайта и ключевых сценариев пользователя. Они задают тон всему документу.
• Иллюстрируйте требования прототипами или скетчами. Один рисунок лучше сотни слов.
• Пишите критерии приёмки. Лучше короткие и ясные, чем длинные и расплывчатые.
• Оставляйте буфер в сроках и бюджете на непредвиденные работы.
• При необходимости обсуждайте ТЗ с подрядчиком, фиксируйте правки письменно.

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

Заключение

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

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

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