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

u

1. Из каких обязательных разделов должно состоять профессиональное техническое задание (ТЗ)?

Любое качественное ТЗ для веб-разработки включает минимум пять блоков. Первый — введение и цели проекта: для кого сайт и какие бизнес-задачи решает. Второй — требования к функционалу: точный перечень модулей (каталог, корзина, личный кабинет) с описанием логики их работы. Третий — требования к вёрстке и интерфейсу: поддержка браузеров (например, Chrome 110+, Firefox 120+), разрешения экранов (от 320px до 2560px), максимальное время загрузки страницы (не более 2 секунд по метрике FCP). Четвертый — технические спецификации: серверное окружение, CMS (если выбрана), используемые языки и библиотеки. Пятый — этапы и критерии приёмки: контрольные точки с указанием ответственного за каждую проверку.

2. Какие материалы нужно подготовить до написания ТЗ и почему это критически важно?

До начала составления текста документа необходимо собрать три группы данных. Первая — контентная матрица: тексты, изображения, видео, которые уже есть. Без неё разработчик заложит в смету время на написание текстов или поиск изображений, что увеличит бюджет на 30-40%. Вторая — референсы и прототипы: примеры сайтов с удачной структурой или элементами навигации. Скриншоты с аннотациями позволяют избежать разночтений на старте. Третья — список исключений и ограничений: требования к интеграции с CRM, 1С или платёжными шлюзами. Пропуск этого пункта ведёт к тому, что на этапе тестирования выясняется несовместимость модулей, а доработка обходится в 50% от исходной стоимости проекта.

3. Как правильно описать структуру сайта (меню и страницы) в ТЗ?

Описание иерархии страниц должно быть представлено в виде вложенного списка или диаграммы. Используйте механизм «плоской карты»: у каждого раздела первого уровня — не более 4-5 подразделов (например: Услуги -> Веб-дизайн, Разработка, SEO-продвижение). Для каждого типа страниц укажите шаблон: «главная», «список товаров», «карточка товара», «текстовая страница», «контакты». Важно прописать путь к каждой странице (ЧПУ): не /page?id=12, а /katalog/nazvanie-tovara. Зафиксируйте, как обрабатываются страницы с ошибкой 404 и 500 — должна быть кастомная страница с поиском и кнопкой на главную.

4. Какие конкретные требования к дизайну и вёрстке нужно включить в спецификацию?

В разделе требований к UI/UX используйте точные параметры. Укажите сетку (например, Bootstrap 5 на 12 колонок), минимальные размеры кликабельных элементов (не менее 48x48px для мобильных версий по рекомендациям WCAG), контрастность текста (4.5:1 для обычного текста, 3:1 для крупного). Пропишите правила для типографики: шрифтовые пары (например, Roboto для заголовков, Open Sans для основного текста), междустрочный интервал (минимум 1.5 для читаемости), размеры заголовков h1-h6. Зафиксируйте, что все изображения должны загружаться с атрибутами width и height для предотвращения смещения контента (Cumulative Layout Shift < 0.1).

5. Как в ТЗ сформулировать требования к скорости загрузки сайта?

Скорость загрузки должна измеряться конкретными метриками Core Web Vitals. В техническом задании пропишите следующие пороговые значения: LCP (Largest Contentful Paint) — не более 2,5 секунд, FID (First Input Delay) / INP (Interaction to Next Paint) — не более 200 мс, CLS (Cumulative Layout Shift) — не более 0,1. Укажите обязательные методы оптимизации: сжатие изображений через WebP/AVIF с автоматическим выбором формата, использование CDN для статических файлов, минификация CSS и JS через сборщик (Webpack или Vite). Зафиксируйте, что страницы должны проходить проверку PageSpeed Insights на 85+ баллов для мобильной версии и 92+ для десктопной.

6. Что должно быть написано в разделе «Требования к совместимости и браузерам»?

В этом разделе перечислите точные версии браузеров и устройств. Минимальный список включает: Google Chrome (последние 2 версии), Mozilla Firefox (последние 2 версии), Safari (начиная с версии 15.0), Edge (Chromium, последние 2 версии). Для мобильных платформ — Chrome Mobile для Android (версия 105+) и Safari Mobile для iOS (версия 15+). Обязательно укажите тестирование на реальных устройствах, а не только в эмуляторах: как минимум iPhone 12, Samsung Galaxy S21 и планшет iPad. Запишите, что проценты поддержки по сервису Can I Use должны составлять не менее 95% для глобальной аудитории.

7. Как правильно описать в ТЗ требования к контент-менеджменту и администрированию?

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

8. Какие критерии качества и приёмки необходимо заложить в техническое задание?

Критерии должны быть измеримыми и проверяемыми. Запишите следующие контрольные точки:

  1. Валидность кода: проверка W3C Validator — не более 3 ошибок на главную страницу.
  2. Кросс-браузерность: визуальное совпадение (pixel-perfect) в указанных браузерах с точностью до 2 пикселей.
  3. Доступность: прохождение автоматического аудита axe DevTools (не более 5 критических нарушений уровня A).
  4. Нагрузочное тестирование: стабильная работа при 500 одновременных сессиях с временем ответа не более 500 мс.
  5. Безопасность: отсутствие XSS-уязвимостей (проверка через OWASP ZAP или Burp Suite).

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

9. Как в ТЗ учесть разницу между готовым решением (CMS) и индивидуальной разработкой?

В документации чётко разделите требования на два уровня. Первый — архитектурный: если выбрана CMS (1С-Битрикс, WordPress, Joomla), укажите требования к ядру и версии системы, а также перечень сторонних плагинов с версиями. Для индивидуальной разработки запишите стек технологий (например, бэкенд: PHP 8.2 + Laravel 10, фронтенд: Vue.js 3 с Composition API). Второй уровень — ограничения по модификации: для CMS пропишите, допустима ли модификация ядра системы (часто запрещено из-за сложности обновлений). Для самописного решения зафиксируйте требования к документированию кода (комментарии на русском или английском, описание всех методов в PHPDoc). Это предотвратит ситуацию, когда подрядчик сдаёт «чёрный ящик» с кодом, который сложно поддерживать.

10. Какие ошибки в ТЗ чаще всего ведут к срыву сроков и увеличению бюджета?

Наиболее критичная ошибка — отсутствие описания пограничных состояний. Например, не указано, что сайт должен корректно отображать 0 товаров в категории или показывать уведомление при отсутствии результатов поиска. Вторая распространённая проблема — неоднозначность формулировок. Фразы “удобный интерфейс” или “современный дизайн” заменяйте на измеримые параметры: “все интерактивные элементы реагируют за 0.1 секунды”, “шрифт не менее 16px для основного текста”. Третья ошибка — игнорирование мобильной адаптации как отдельного этапа. Впишите точные точки перелома (breakpoints): 320px, 768px, 1024px, 1440px. Если эти детали не зафиксированы, на этапе вёрстки подрядчик применяет «резину» без адаптации, и половину критического функционала приходится переделывать за дополнительные деньги.

Добавлено: 07.05.2026