Как составить ТЗ на сайт, если вы не технический специалист
Хорошее ТЗ пишет не заказчик и не студия по отдельности. Заказчик описывает бизнес-задачу, студия превращает её в технические требования.
С чего начать, если вы не разработчик
Не пытайтесь описать технологии. Ваша часть — бизнес: кто клиент, какое действие он должен совершить на сайте, какие возражения у него есть, чем вы отличаетесь от конкурентов. Это то, что знаете только вы, и без этого никакая студия не построит работающую структуру.
Полезное упражнение: выпишите десять вопросов, которые вам чаще всего задают клиенты по телефону и в Telegram. Ответы на эти вопросы и есть каркас будущего сайта — они точно попадут в структуру, потому что за ними стоит реальный спрос, а не догадки.
Обязательные разделы ТЗ
Цель сайта и целевое действие. Список страниц с кратким описанием содержимого каждой. Языковые версии — для Узбекистана почти всегда русский и узбекский, иногда английский. Функциональные требования: формы, фильтры, калькуляторы, личный кабинет.
Интеграции: CRM, Telegram-бот для уведомлений, Payme и Click, если планируется оплата, системы аналитики. Требования к админке — что именно вы хотите менять сами, без разработчика. Этот пункт забывают чаще всего, а потом выясняется, что тексты на главной правит только программист.
Что забывают почти всегда
Кто предоставляет контент: тексты, фотографии, логотипы, описания товаров. Это не мелочь — половина сорванных сроков в вебе происходит из-за того, что заказчик не прислал материалы, а в ТЗ не написано, что он должен был.
Также забывают: что происходит со старым сайтом и его адресами, нужен ли перенос данных, кто оплачивает домен и хостинг, кто настраивает почту на домене, и какие метрики считаются успехом после запуска.
Как описывать дизайн, не будучи дизайнером
Через референсы. Соберите пять-шесть сайтов, которые вам нравятся, и к каждому напишите одну фразу, что именно нравится: «спокойные цвета», «понятно, куда нажимать», «хорошо смотрится на телефоне». И столько же примеров того, что не нравится — это работает даже лучше.
Не описывайте дизайн словами вроде «современный», «дорогой», «чтобы цепляло». Каждый понимает их по-своему, и вы получите три раунда правок, прежде чем стороны договорятся о значении слов.
Живой документ, а не памятник
ТЗ на старте всегда неполное — это нормально. Важно, чтобы изменения фиксировались: что-то добавили, что-то убрали, сроки и стоимость пересчитали. Тогда к финалу никто не удивляется ни счёту, ни составу работ.
Практический совет: держите ТЗ в общем документе с историей правок, а не пересылайте файлы в чате. Версия «финальный_итог_2_правки.docx» — источник половины конфликтов на проекте.