Техническое задание на сайт — документ из 12 разделов о целях и аудитории, структуре страниц, типах контента, функциональных и нефункциональных требованиях, интеграциях, требованиях к дизайну, контенте, хостинге и домене, этапах и сроках, критериях приемки и порядке изменений.
Функции в ТЗ описывают формулой «система должна <действие> при <условии>» — с проверяемым результатом, а не общим пожеланием.
ТЗ на разработку сайта идет приложением к договору и становится основанием для акта: подрядчик сдает работу по нему, а не по общим договоренностям на словах.
Размытый пункт спокойно доживает до этапа приемки — и там же превращается в спор: кто-то трактует формулировку в свою пользу, кто-то платит за доработку, которую считал частью проекта.
Дальше — сама структура, готовые формулировки и список фраз, которые в ТЗ писать нельзя.
Зачем ТЗ, если прототип уже есть
Прототип показывает экраны и переходы между ними. Логику, сроки, контент и порядок приемки он не объясняет.
Типичный конфликт: заказчик ждал сайт на WordPress, получил на MODX. В ТЗ движок не был указан, а прототип этого не показывает — там нет технического слоя вообще.
Если функция нарисована только в прототипе и не описана текстом, в договоре ее нет. Подрядчик вправе не делать ее бесплатно, заказчик не может требовать ее на приемке.
Кто что приносит в проект
ТЗ фиксирует, кто отвечает за контент, доступы, домен и хостинг — и к какому сроку передает. Для web-проекта в спецификации прямо описывают этапы работ и предварительный график.
- •Тексты и иллюстрации — заказчик или исполнитель, с датой передачи
- •Домен и доступы к нему — сторона, у которой они уже есть
- •Хостинг — кто оплачивает и настраивает
- •Политика конфиденциальности и оферта — кто готовит юридические документы
Сорванный срок передачи контента сдвигает весь график разработки, а не только этап наполнения. Заполните эту таблицу до разговора с подрядчиком — так каждая сторона видит свою часть заранее.
Структура технического задания из 12 разделов
Оглавление ТЗ, которое можно взять за основу:
- •Цели и аудитория
- •Структура страниц
- •Типы контента
- •Функциональные требования
- •Нефункциональные требования
- •Интеграции
- •Дизайн
- •Контент
- •Хостинг и домен
- •Этапы и сроки
- •Критерии приемки
- •Порядок изменений
Если страниц много и карта сайта раздувает документ, ее выносят в приложение. Скопируйте это оглавление в свой документ и заполняйте разделы по порядку.
Что писать в каждом разделе
Порядок изменений стоит расписать подробно: правку оформляют письменно, согласуют обе стороны, и вместе с ней пересчитывают срок и цену. Без этого дополнение превращается в спор о бесплатной доработке.
Как описать страницы, каталог и формы
Раздел «Структура и страницы» начинается с дерева разделов. Для каждой страницы перечисляют шапку, подвал и блоки; общие шапку и подвал описывают один раз. Допустим, B2B-сайт с каталогом: главная → каталог → категория → карточка товара, рядом «Услуги», «Оптовым клиентам» и «Контакты».
Каталог описывают параметрами: фильтры, сортировка, число товаров на странице, что видит пользователь при пустом результате. Сортировку указывают по конкретным полям: цене, новизне, названию. Чем больше ассортимент, тем важнее расписать фильтры полями — категория, цена, бренд, — а не словами «удобный поиск».
Карточка товара и форма заявки
Карточка: фото, цена, наличие, характеристики, кнопка. Характеристики перечисляют полями, а не одним блоком текста. Если товара нет в наличии, пишут, что видит пользователь и какая кнопка заменяет «Купить» — например, «Сообщить о поступлении».
Форма заявки: список полей, какие из них обязательны, маска телефона, текст ошибки при неверном вводе и сообщение, которое пользователь видит после отправки.
Чего избегать: строки «форма обратной связи» без перечня полей — подрядчик сделает два поля там, где нужно пять. Распишите одну свою форму по этому образцу.
Функциональные требования по формуле
«Интеграция с CRM» — тема, а не требование: проверить ее нечем. Шаблон: «система должна <действие> при <условии>» плюс проверяемый результат. Например, «система должна передавать заявку в CRM в течение N минут после отправки формы», где N согласуют с подрядчиком.
Если требование нельзя проверить одним коротким сценарием, его переформулируют.
Примеры для 8 функций
- •Форма заявки: отправляет данные при нажатии «Отправить»; ошибка — пустое обязательное поле блокирует отправку.
- •Передача в CRM: заявка появляется в CRM после отправки формы; ошибка — при сбое связи заявка сохраняется и уходит повторно.
- •Уведомление: письмо менеджеру после создания заявки; ошибка — без ответственного письмо уходит на общий адрес.
- •Поиск: результаты по названию и артикулу; ошибка — при нуле выводится сообщение и похожие товары.
- •Фильтр: применяет параметры без перезагрузки; ошибка — пустой результат не скрывает фильтры.
- •Корзина: состав сохраняется между страницами; ошибка — снятый с продажи товар убирается с уведомлением.
- •Оплата: статус заказа меняется после ответа платежной системы; ошибка — при отказе заказ остается «не оплачен».
- •Кабинет с ролями: разделы открываются по роли; ошибка — чужой раздел дает отказ доступа, а не пустую страницу.
Перепишите свои функции по этой формуле.
Нефункциональные требования с цифрами
Этот раздел описывает не что делает сайт, а как быстро и стабильно он работает: время загрузки в секундах, вес изображений до 200 КБ, браузеры с версиями, мобильные разрешения, число одновременных пользователей и время ответа сервера.
Готовая формулировка: «Сайт корректно работает в последних N версиях браузеров из списка и выдерживает N одновременных пользователей при времени ответа сервера не более N секунд».
Если предпочтений по CMS нет, фиксируйте ограничения, например «без платных лицензий». Безопасность держите одной группой: SSL, резервное копирование, права доступа по ролям.
Доступность и SEO-минимум
Доступность задают через ориентир WCAG 2.1: контраст, alt-тексты, работа с клавиатуры. Стандарт EN 301 549 обязателен для публичных веб-ресурсов госорганов ЕС; коммерческому сайту ссылаться на него стоит, только если это важно для аудитории.
SEO пишут на уровне «должна быть возможность»: редактировать мета-теги, формировать ЧПУ, sitemap.xml и robots.txt, добавлять микроразметку, настраивать редиректы.
Обратите внимание: мета-теги, которые нельзя править из админки, — частый пробел, закройте его отдельным пунктом. Затем впишите в раздел свои цифры по скорости, браузерам и нагрузке.
Как связать ТЗ с актом приемки
Каждый пункт ТЗ получает проверку: шаг, ожидаемый результат, отметка «пройдено». Акт подписывают по этой таблице, а не на веру.
Проверку закладывают за 1–2 недели до запуска, а не в день релиза, и проводят на тестовом сервере с реальным контентом. Пункт, не прошедший проверку, уходит в список багов, а не в новое ТЗ.
Баги, гарантия и сроки исправления
- •Критические — сайт или форма не работают: реакция за N часов, исправление за N рабочих дней.
- •Существенные — функция работает с ограничениями: реакция за N рабочих дней, исправление в согласованный срок.
- •Минорные — опечатки и визуальные неточности: исправление в рамках гарантии.
Формулировка для ТЗ: «Заказчик регистрирует ошибки в трекере или почте проекта. Сроки реакции и исправления отсчитываются от регистрации. Гарантийный срок — N месяцев после подписания акта».
Добавьте таблицу и регламент в раздел «Критерии приемки» своего ТЗ.
10 фраз, за которые платят дважды
Размытая фраза не экономит время. Подрядчик трактует ее дешевле, заказчик — дороже, и переделку оплачивают отдельно. Злого умысла тут обычно нет: у фразы просто две версии результата. Например, «адаптивный» для одного — отдельная мобильная версия, для другого — просто сжатая страница.
Критерий: если фразу можно понять двумя способами, ее заменяют числом, списком или ссылкой на образец.
Размытая фраза и замена
Прогоните свой документ поиском по этим словам и замените каждое совпадение. Замену пишите сразу, пока помните, что имели в виду.
Составим ТЗ на ваш сайт вместе с прототипом: в МАЙПЛ это входит в проект от 50 000 ₽, отдельным этапом — от 15 000 ₽. Пришлите вводные в разделе «Сайты».
Источники
