Техническое задание принято считать бюрократией, которая нужна подрядчику для подстраховки. На самом деле оно нужнее заказчику: это единственный документ, по которому можно доказать, что сайт сделан не так, как договаривались.
Главный принцип простой: в ТЗ не должно быть требований, которые нельзя проверить. «Современный дизайн» проверить нельзя. «Макеты в трёх разрешениях: 1440, 768 и 375 пикселей» — можно.
Из чего состоит рабочее ТЗ
Цели и метрики
Начинайте не со страниц, а с того, зачем сайт существует. «120 заявок в месяц через полгода после запуска» — цель. «Сделать сайт» — не цель. Метрика определит всё остальное: где стоят формы, какие блоки на главной, что считаем успехом.
Аудитория и сценарии
Кто приходит на сайт и что хочет сделать. Для каждой группы — короткий сценарий: откуда пришёл, что ищет, что должно произойти. Пять таких сценариев дают больше, чем двадцать страниц описания «портрета клиента».
Структура
Полный список страниц с указанием типа шаблона. Не «каталог», а «страница категории — шаблон А, карточка товара — шаблон Б, сравнение — шаблон В». Именно из этого списка растёт смета.
Требования к дизайну
Фирменные цвета и шрифты, примеры сайтов, которые нравятся, и обязательно — что именно нравится. «Нравится сайт X» бесполезно; «нравится, как на сайте X устроен подбор по параметрам» — уже требование.
Функциональные требования
Списком, по одному на пункт. Формы и что с ними происходит, интеграции, личный кабинет, поиск, фильтры, многоязычность, роли пользователей. Каждый пункт заканчивается словами «проверяется так-то».
Технические требования и приёмка
CMS, требования к скорости, адаптив от какой ширины, поддерживаемые браузеры, требования к доступности, SEO-минимум: уникальные title и description, микроразметка, sitemap.xml, robots.txt, человекопонятные адреса.
Формулировки, из-за которых спорят
| Плохо | Хорошо |
|---|---|
| Сайт должен быстро загружаться | PageSpeed Insights ≥ 85 для мобильных на главной и странице каталога |
| Удобный каталог | Фильтр по 6 параметрам, результат обновляется без перезагрузки, выбранные фильтры видны в адресе страницы |
| Современный адаптивный дизайн | Макеты 1440 / 768 / 375 px, без горизонтальной прокрутки от 320 px |
| Интеграция с CRM | Заявка создаёт сделку в Битрикс24 с полями «имя, телефон, источник, UTM», дубль по телефону не создаётся |
| Наполнение контентом | Подрядчик заполняет 7 страниц по согласованным текстам, остальные заполняет заказчик до 15 числа |
Кто пишет ТЗ
Идеальный вариант — совместно. Заказчик приносит цели, аудиторию и ограничения; подрядчик превращает это в структуру, сценарии и технические требования. Если ТЗ пишет только заказчик, в нём обычно не хватает технической части. Если только подрядчик — в нём не хватает бизнеса.
У нас этот этап оформлен как отдельная работа: мы проводим интервью, собираем спрос и отдаём документ, с которым можно идти к любому подрядчику. Многие так и делают — и это нормально.
Проверка на качество ТЗ: дайте его прочитать человеку, который не участвовал в обсуждениях. Если он задаёт больше трёх вопросов «а как это должно работать» — документ ещё не готов.
Что делать, если ТЗ нет и писать его некогда
Такое бывает чаще, чем хотелось бы. Рабочий компромисс — короткий бриф плюс прототипы. Прототип заменяет десятки страниц описания: на нём видно, какие блоки есть на странице и в каком порядке. Дальше прототип согласуется, и именно он становится приложением к договору.
Начать можно с нашего брифа — он занимает 5–10 минут и закрывает большую часть вопросов из списка выше. Если проект — переделка существующего сайта, посмотрите услугу доработки существующих сайтов: там требования собираются иначе, от того, что уже работает.
