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

Половина споров между заказчиком и разработчиком начинается с фразы «а я думал, это входит». Техническое задание нужно не для суда, а чтобы обе стороны представляли себе один и тот же сайт до начала работы. Хорошее ТЗ на небольшой сайт помещается на две-три страницы и пишется за вечер — если знать, что в нём должно быть и чего в нём быть не должно.

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

1. Зачем сайт. Одна-две фразы: «получать заявки на замер окон из рекламы», «показывать каталог оптовым покупателям и принимать заказы», «дать клиентам доступ к их документам». От цели зависит всё остальное: лендинг под рекламу и каталог для оптовиков — разные сайты, хотя оба «сайт компании».

2. Кто посетитель. С телефона или с компьютера, из рекламы или из поиска, знает ли компанию. Оптовик с компьютера в офисе и мама с телефоном в очереди ведут себя по-разному, и интерфейс для них разный.

3. Список страниц. Не «как у конкурента», а перечень: главная, услуги (сколько), о компании, портфолио, контакты, документы. Для каждой — что на ней должно быть, хотя бы списком блоков. Это самая полезная часть ТЗ и самая часто пропускаемая.

4. Что должно работать. Формы (какие, куда приходят заявки), калькулятор, фильтр в каталоге, личный кабинет, оплата, обмен с 1С, интеграция с CRM. Каждый пункт — отдельная работа, и если его нет в ТЗ, его нет в смете.

5. Кто наполняет. Тексты, фото, цены — заказчик, разработчик или копирайтер? Сайт без текстов не запускается, а ждать тексты от заказчика можно месяцами. Это стоит записать прямо: «тексты предоставляет заказчик до такого-то числа».

6. Чем управляет заказчик после сдачи. Какие страницы и блоки редактируются в админке, а какие меняет только разработчик. Заказчик, который хочет сам менять цены на главной, должен получить для этого поле в админке, а не просьбу «напишите нам».

7. Требования закона. Политика, согласия отдельными чекбоксами, cookie-баннер, реквизиты, хостинг в России, русский язык интерфейса. Мы делаем это по умолчанию, но в ТЗ с другим подрядчиком это лучше записать — иначе «сайт по закону» окажется отдельной услугой.

8. Домен, хостинг, доступы. Кто регистрирует домен и на кого (на заказчика, всегда), где хостинг, кто платит, кто получает доступы после сдачи.

9. Сроки и этапы. Прототип — дизайн — вёрстка — наполнение — запуск, с датами и тем, что заказчик принимает на каждом этапе. Принятый этап не переделывается бесплатно — это защищает обе стороны.

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

• «Современный дизайн», «удобная навигация», «продающие тексты» — не проверяемые требования. Замените примерами сайтов, которые нравятся, и тем, что именно в них нравится.
• Технологии ради технологий. Заказчику не нужно выбирать между PHP и Node — нужно записать, что сайт должен открываться быстро, редактироваться без программиста и жить на российском хостинге.
• Требования к продвижению. «Сайт должен быть в топ-10» — не свойство сайта. Свойство сайта — корректные заголовки, скорость, карта сайта, адреса страниц; продвижение — отдельная работа.

Если ТЗ писать некому

Нормальная ситуация: заказчик знает свой бизнес, а не устройство сайтов. Тогда ТЗ пишет разработчик по итогам разговора — у нас это первый этап работы: час-полтора вопросов, потом документ на согласование. Заказчик правит формулировки, добавляет забытое, и только после этого считается смета. Считать смету до ТЗ — гадать, а гадание всегда заканчивается фразой «а я думал, это входит».