Техническое задание на сайт: что в нём должно быть

Техническое задание на сайт - это документ, который отвечает на один вопрос: по каким признакам обе стороны поймут, что работа сдана. Всё остальное вторично. Рабочее ТЗ занимает 8-15 страниц и обязательно содержит карту страниц с URL, список функциональных блоков, измеримые критерии приёмки и порядок передачи исходников. Красивого шаблона на сто страниц не нужно, нужны проверяемые формулировки.

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

Разработка сайта под ключот 250 000 до 600 000 ₽сроки: 4-8 недель

Кто пишет ТЗ

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

Рабочая схема: подрядчик готовит документ, заказчик читает его как проверяющий и требует, чтобы каждый пункт был проверяем. Если вы читаете фразу и не понимаете, как проверите её выполнение, - это дыра, и через неё потом будут спорить.

Отдельный случай - когда ТЗ пишется до выбора подрядчика, чтобы разослать нескольким и сравнить цены. Тогда его пишет либо ваш технический человек, либо аналитик за отдельные деньги. Стоит это обычно 30-60 тысяч и окупается на первом же тендере, потому что предложения становятся сравнимыми.

Что обязательно должно быть

Карта страниц с конкретными URL. Не «раздел услуг», а список: /prodvizhenie-saytov, /razrabotka-saytov, /tseny и так далее. Из этого списка растёт цена, срок и структура работы. Если карты страниц нет, вы не знаете, за сколько страниц платите.

Что на каждой странице. Перечень блоков в порядке следования. Достаточно строки на блок: «первый экран: H1, подзаголовок, цена от, кнопка заявки».

Функциональность списком. Форма заявки, фильтры каталога, калькулятор, личный кабинет, интеграция с 1С. Каждый пункт - отдельная строка, потому что каждый пункт стоит денег. «И прочий стандартный функционал» в ТЗ быть не должно.

Кто делает контент. Самая частая причина срыва сроков. Тексты, фотографии, прайс, описания услуг - чьи и к какой дате. Если тексты пишет подрядчик, укажите объём: «до 4 000 знаков на посадочную».

Технические требования с числами. Не «сайт должен быстро загружаться», а «LCP не более 2,5 секунды на мобильном по PageSpeed Insights при подключении 4G». Не «должна быть микроразметка», а перечень типов: Organization, Service, FAQPage, BreadcrumbList.

Порядок приёмки. Сколько дней на проверку, сколько кругов правок входит в цену, что считается правкой, а что новой задачей. Без этого правки становятся бесконечными, и обе стороны злятся.

Передача. Исходники, доступы к хостингу, домену, Вебмастеру, Метрике, репозиторию. Формулировка «после полной оплаты» - плохая, «после каждого этапа» - хорошая.

Чеклист

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

Критичное - то, без чего ТЗ не защищает ни одну из сторон. Остальное добавляется по мере усложнения проекта.

18 проверок 10 критично 5 важно 3 можно потом

01 Структура и объём

• критично Карта страниц с конкретными URL, а не описание разделов чинить до запуска
• критично Перечень блоков на каждой странице в порядке следования чинить до запуска
• критично Список функциональности построчно, без формулировки «и прочее» чинить до запуска
• критично Кто и к какой дате даёт тексты, фото, прайс чинить до запуска
• важно Что делать с существующими URL: редиректы при переносе в первый месяц
• можно потом Многоязычность и её объём, если она нужна когда дойдут руки

02 Технические требования

• критично LCP не более 2,5 с на мобильном, CLS не более 0,1 чинить до запуска
• важно Список типов микроразметки, а не «должна быть разметка» в первый месяц
• важно Поддерживаемые браузеры и минимальная ширина экрана в первый месяц
• критично Куда уходит заявка: почта, Telegram, CRM чинить до запуска
• критично Требования 152-ФЗ: согласие на обработку, политика ПДн чинить до запуска
• можно потом Нагрузочные требования, если ожидается пик трафика когда дойдут руки

03 Отношения сторон

• критично Критерии приёмки: по каким признакам этап считается сданным чинить до запуска
• критично Сколько кругов правок входит в цену чинить до запуска
• критично Передача исходников и доступов после каждого этапа чинить до запуска
• важно Что считается правкой, а что новой задачей и отдельными деньгами в первый месяц
• важно Срок ответа сторон: сколько дней на согласование в первый месяц
• можно потом Гарантийный период на исправление дефектов когда дойдут руки

Формулировки, из-за которых потом спорят

«Современный продающий дизайн». Заменяется на референсы: три-пять сайтов, которые нравятся, с пометкой чем именно. Это не гарантия, но хотя бы предмет разговора.

«Сайт должен быть оптимизирован под SEO». Оптимизирован до какой степени? Заменяется списком: уникальные title и description по шаблону с переменными, один H1, ЧПУ, sitemap, robots, alt-тексты, перечень типов разметки. Позиции в ТЗ на разработку не пишутся вообще - это другая услуга и другой договор.

«Адаптивная вёрстка». Под какие устройства и как проверяется. Минимальная ширина 360 пикселей, проверка на реальном телефоне, а не в режиме эмуляции.

«Наполнение сайта контентом». Чьим контентом, в каком объёме, сколько страниц. Без этого пункт означает всё что угодно.

«Интеграция с 1С». С какой конфигурацией, какой версии, что именно передаётся и в какую сторону, есть ли уже готовый обмен. Интеграция с чужой системой - это всегда работа с чужим API, которое документировано хуже, чем обещано в рекламе.

Чего в ТЗ быть не должно

Обещаний по позициям и трафику. Разработчик не управляет выдачей Яндекса, и пункт «сайт должен войти в топ-10 по ключевым запросам» либо не будет выполнен, либо был выполнен ещё до вас.

Раздела с описанием технологий, если вам это безразлично. Требование «сайт на WordPress» имеет смысл, только если у вас есть контент-менеджер, который умеет работать именно с ним. Иначе вы ограничиваете подрядчика без выгоды для себя.

Ста страниц описания того, что и так очевидно. Толстое ТЗ не читают, а значит оно не работает.

Что происходит без ТЗ

Ничего фатального, если проект маленький и подрядчик адекватный. Лендинг на неделю нормально делается по переписке.

На проекте от месяца отсутствие документа стоит денег обеим сторонам: заказчик думает, что фильтры каталога входят в цену, подрядчик считал их отдельно, и правы оба. Разбирается это либо доплатой, либо ссорой.

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