Техническое задание на сайт: шаблон 2026 года

Зачем нужно ТЗ

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

ТЗ ≠ бриф. Бриф — для оценки сметы (1–2 страницы). ТЗ — для разработки (10–50 страниц), пишется уже под выбранного подрядчика.

Шаблон ТЗ на сайт

1. Цели проекта

• Главная цель (1 предложение): «Запустить лендинг для сбора заявок на курс по ИИ».
• Бизнес-цели: получать N заявок в месяц, конверсия Y%.
• Прокси-метрики: время на сайте, scroll depth, заявки.

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

• Кто пользуется (роли, возраст, профессия);
• Сценарии использования (топ-3 сценария);
• Контекст использования (где, когда, с какого устройства).

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

Что система должна делать. Список по приоритету:

• Must-have (критично для запуска);
• Should-have (важно, но не блокирует запуск);
• Could-have (желательно, если хватит времени);
• Won't-have (не делаем в этом релизе).

Для лендинга:

• Show — главный блок с предложением и CTA;
• Form — форма заявки с интеграцией в CRM;
• Faq — частые вопросы;
• Pricing — таблица цен;
• Footer — контакты и юридика.

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

Как должна работать:

• Производительность — LCP < 2.5s, INP < 200ms, CLS < 0.1 на 75-перцентиле.
• Масштабируемость — выдерживать 1000 одновременных пользователей.
• Безопасность — HTTPS, защита от SQL injection, XSS, CSRF.
• Доступность — соответствие WCAG 2.1 AA.
• Браузеры — Chrome, Safari, Firefox, Edge последние две версии.
• Устройства — десктоп от 1280px, планшет, мобильный от 360px.
• SEO — индексируемость, schema.org Organization + Service + FAQPage.
• AEO — llms.txt, llms-full.txt, расширенный schema.org.

5. Ограничения

• Стек — Next.js + TypeScript + Tailwind. Бэкенд на Laravel.
• Хостинг — Selectel.
• Бюджет — до X ₽.
• Срок — до Y дней.
• Команда — N человек.
• Юридика — российское юрлицо, договор-оферта.

6. Интеграции

• CRM — AmoCRM (отдельная воронка для лендинга).
• Аналитика — Yandex.Metrika с целями и UTM.
• Email — Mailgun или SMTP Яндекса для уведомлений.
• Платежи — ЮKassa (если будут платежи на сайте).

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

Что считается «принятым»:

• Все must-have функции работают на staging-сервере;
• Lighthouse Performance ≥ 90, Accessibility ≥ 95, Best Practices ≥ 95, SEO = 100;
• Прохождение чек-листа QA (10–30 пунктов);
• Schema.org валидируется в validator.schema.org без ошибок;
• Документация на staging-сервере доступна в README.md;
• Деплой на боевой сервер с проверкой DNS и SSL;
• Работа в основных браузерах подтверждена.

8. Этапы и оплата

• Этап 1 (X дней) — дизайн + архитектура. Сдача и оплата Y%.
• Этап 2 (X дней) — вёрстка + бэкенд. Сдача и оплата Y%.
• Этап 3 (X дней) — тестирование + деплой. Сдача и оплата Y%.

9. Передаваемые материалы

После сдачи клиент получает:

• Доступ к репозиторию с кодом;
• Доступ к серверу и БД;
• Документацию (README, архитектура, API);
• Инструкции по администрированию;
• Контакты команды для гарантийной поддержки.

10. Гарантии и поддержка

• Гарантия — первый месяц бесплатно (фикс багов из приёмки).
• Дальнейшая поддержка — пакеты или подписка.

Типичные ошибки в ТЗ

• «Сделайте красиво» — субъективно, не приёмочный критерий. Замените на «соответствует прилагаемым референсам».
• «Должно быть быстрым» — не измеримо. Замените на «LCP < 2.5s».
• «Отзывчиво на всех устройствах» — слишком общо. Перечислите конкретные device-sizes.
• «Сделайте на современном стеке» — субъективно. Укажите конкретный стек.
• Огромное ТЗ на 100 страниц — никто не прочитает. 10–30 страниц с приоритезацией — оптимум.

Что дальше

Как выбрать подрядчика.

Лендинг за 7 дней.

Приёмка работ без споров.

Бриф в Вадлайн.