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

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

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

Почему ТЗ важно и когда его нужно составлять

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

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

Кому адресовано ТЗ

ТЗ адресуют нескольким сторонам: заказчику, менеджеру проекта, команде разработки, дизайнерам и тестировщикам. Каждый из участников черпает из ТЗ ту информацию, которая нужна ему для работы. Менеджер смотрит на сроки и риски, разработчик — на технические требования, дизайнер — на интерфейс и поведение, тестировщик — на критерии приёмки.

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

Общая структура ТЗ

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

• Введение и цели проекта
• Целевая аудитория и сценарии использования
• Функциональные требования
• Нефункциональные требования
• Дизайн и интерфейс
• Интеграции и внешние сервисы
• План работ, сроки, вехи
• Критерии приёмки и тестирование
• Бюджет и оплата
• Риски и управление изменениями
• Приложения и материалы

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

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

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

Пример формулировки цели: «Создать интернет-магазин, который позволит увеличить продажи на 30% в течение года и снизить ручную обработку заказов за счёт интеграции с CRM». Такая цель сразу задаёт ориентир для функциональной части и интеграций.

Целевая аудитория и пользовательские сценарии

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

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

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

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

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

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

Здесь перечислите все функции, которые должен выполнять сайт. Не откладывайте этот раздел на эмоциональные фразы. Пишите строго: «пользователь может зарегистрироваться по email», «восстановление пароля через почту», «поиск по названию и фильтры по цене и категории». Каждую функцию можно сопроводить приоритетом и примерной оценкой трудозатрат.

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

Как описывать функционал

Каждую функцию сопровождайте критериями приёмки. Например: «Форма регистрации должна отправлять письмо с подтверждением в течение 60 секунд и не допускать дубли email». Такой подход делает тестирование понятным и объективным.

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

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

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

Примеры: время загрузки страницы не больше 3 секунд при 1000 одновременных пользователях, поддержка HTTPS, соответствие стандартам доступности WCAG 2.1 уровня AA, журналирование действий администратора.

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

• Производительность: среднее время отклика API не более 200 мс.
• Безопасность: хранение паролей с хешированием bcrypt, защита от CSRF и XSS.
• Масштабируемость: возможность горизонтального масштабирования сервисов.
• Совместимость: корректное отображение в последних версиях Chrome, Firefox, Safari и мобильных браузерах.

Дизайн и пользовательский интерфейс

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

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

Элементы интерфейса и поведение

Опишите карточки товара, списки, формы, всплывающие окна. Для каждой крупной части интерфейса укажите поведение при ошибках и граничные случаи. Это избавит вас от недопонимания: не «форма с валидацией», а «поле телефона принимает только цифры, формат +7 (XXX) XXX-XX-XX, при ошибке показывать подсказку и не отправлять форму».

Контент и система управления контентом (CMS)

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

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

Права доступа и роли

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

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

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

Например: «Интеграция с CRM: передавать заказ в формате JSON с полями id, name, email, phone, items[]. Ответ CRM должен подтверждать приём заказов кодом 200. Триггер на создание сделки при сумме заказа выше 10 000 рублей».

Пример списка внешних сервисов

План работ, сроки и вехи

Разбейте проект на этапы и определите вехи. Не оставляйте только общие сроки «месяц или два». Конкретика помогает всем: вы увидите, где возможны узкие места, команда поймёт, когда ожидать оплату и какие нужно готовить материалы.

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

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

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

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

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

• Регистрация, вход, восстановление пароля — работают корректно.
• Каталог и фильтры возвращают нужные результаты.
• Оформление заказа, оплата и уведомления — рабочие.
• Интеграции с CRM и платёжной системой — передают данные без ошибок.
• Кроссбраузерность: сайт корректно отображается в основных браузерах.

Бюджет и способы оплаты

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

Частая схема — аванс 30%, оплата по этапам и финальный платёж после приёмки. Если у проекта есть ограничения по оплате, это стоит зафиксировать заранее, чтобы избежать конфликтов.

Риски и управление изменениями

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

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

Пример политики изменений

Все изменения оформляются в виде дополнения к ТЗ. Для оценки изменения команда предоставляет список задач и новую смету в течение 5 рабочих дней. После согласования новый объём работ и сроки фиксируются в проектном плане.

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

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

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

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

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

Примеры услуг сопровождения: исправление критических багов в течение 24 часов, ежемесячное обновление платформы, резервное копирование данных, мониторинг работоспособности.

Формат передачи проекта

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

Приложения и дополнительные материалы

В приложениях соберите всё, что поможет команде: брендбук, логотипы, тексты, фотографии, примеры удачных интерфейсов, соглашения с 3rd-party сервисами. Чем меньше нужно догадок, тем быстрее пойдёт работа.

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

Шаблон простого ТЗ: кратко и по делу

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

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

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

• Неопределённые цели. Без конкретных метрик сложно понять успех проекта.
• Отсутствие приоритетов. Команда должна знать, что важно сегодня, а что можно отложить.
• Неполные данные для интеграций. Отсутствие спецификаций API затормозит сроки.
• Неформализованные критерии приёмки. Без них споров не избежать.
• Недостаток материалов. Пустые страницы, отсутствующие тексты и картинки — частая причина задержек.

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

Практические советы по работе с подрядчиком

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

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

Чек-лист перед стартом работ

• Определены цели и метрики успеха.
• Собраны брендовые материалы и тексты.
• Прописаны ключевые функции с приоритетами.
• Указаны внешние интеграции и требуемые форматы данных.
• Договорены сроки, бюджет и схема оплаты.
• Назначены ответственные с обеих сторон.

Заключение и краткий план действий

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

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

Желаю удачи в составлении ТЗ и успешного запуска сайта. Если будете делать всё по плану, результат вас не разочарует.

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