ТЗ на сайт — что написать, чтобы получить точную оценку

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

Ниже — структура, по которой я прошу описывать задачу, и примеры формулировок. Хватит пары страниц обычного текста. Короткая версия, которую можно скопировать в документ:

1. Компания и цель сайта. Что считается заявкой и куда она приходит.
2. Кто приходит на сайт и с каким вопросом.
3. Страницы и функции — сценариями. Что вы хотите менять сами.
4. Интеграции: какая система, какие данные, в какую сторону и как часто.
5. Тексты, фото и языки — кто их готовит.
6. Дата запуска, бюджетная рамка, что делать со старым сайтом.
7. Сайты, которые нравятся, и чем именно.

Теперь по каждому пункту подробнее.

Цель сайта и что считается заявкой

Начните с пары фраз о бизнесе и одной — о том, зачем сайт. Цель должна быть проверяемой: что человек должен сделать на сайте и что вы считаете заявкой.

Расплывчато: «Сайт должен продавать и повышать узнаваемость бренда».

Можно оценить: «Стоматология в Алматы. Сайт нужен для записи на приём по направлениям — имплантация, брекеты, лечение, гигиена. Заявка — это запрос на запись с названием услуги, он приходит администратору в WhatsApp. Сейчас пациенты записываются по телефону и через Instagram».

Второй вариант можно оценить: понятно, сколько нужно страниц услуг, где стоит кнопка записи и куда уходит сообщение. Последняя фраза тоже важна — она показывает, с чем новый сайт будет конкурировать за внимание пациента.

Кто приходит на сайт и с каким вопросом

Опишите несколько типов посетителей и что каждый хочет узнать. Это важнее списка страниц: структуру я построю сам, если понимаю, кто по ней будет ходить.

Для сайта генераторов вроде WEICAN это звучало бы так: «Инженер подбирает генератор по мощности, мотору и исполнению. Закупщику важны наличие и сроки поставки. Владелец объекта хочет понять, кто будет обслуживать генератор после покупки». Из трёх фраз сразу видно, что нужно: каталог с фильтрами, понятные сроки и наличие, страница сервиса и кнопка заявки на каждой карточке.

Страницы, функции и админка — описывайте сценариями

Список страниц полезен, но сценарий полезнее. «Каталог» может быть списком из нескольких карточек, а может быть фильтрами, сравнением, наличием по складам и выгрузкой из учёта. Слово одно, а задачи совсем разные.

Пишите, кто что делает и что происходит дальше:

«Посетитель выбирает категорию, фильтрует по цене и наличию, открывает карточку и нажимает „Заказать“. Заказ приходит менеджеру в Telegram. Менеджер раз в день обновляет цены в админке — сам, без программиста».

Отдельно опишите, что вы хотите менять сами: тексты, цены, фото, баннеры, контакты, кнопки WhatsApp. На сайте WEICAN компания сама ведёт каталог, тексты, контакты и кнопки WhatsApp. Такую админку нужно проектировать вместе с сайтом, а не прикручивать после запуска.

Если на сайте будут личные кабинеты или роли сотрудников, перечислите их: кто что видит и что может менять.

Интеграции — какая система и какие данные

Фраза «интеграция с 1С» сама по себе ничего не говорит. Для оценки нужны три ответа:

• какая система — 1С, UMAG, МойСклад, amoCRM, Bitrix24, платёжный сервис;
• какие данные и в какую сторону — товары и остатки на сайт, заказы с сайта в учёт, статусы обратно;
• как часто — раз в сутки, раз в несколько минут или сразу.

Например: «Товары, цены и остатки — из UMAG на сайт, раз в несколько минут. Заказы с сайта — менеджеру в WhatsApp и в общую таблицу». Такую фразу можно оценить, а «нужна интеграция со складом» — нет.

Сразу спросите у поставщика системы, есть ли у неё API. Если нет — это не тупик, но это отдельная работа, и о ней лучше узнать до оценки. У Wigwam складская система UMAG не отдавала данные интернет-магазину — API для этого просто не было. Я добился, чтобы его открыли, и теперь сайт получает цены и остатки каждые пять минут. Подробнее о такой связке — в решении «Интеграция с UMAG».

Контент, языки и сроки

Здесь проекты срываются чаще всего, поэтому пишите честно.

• Тексты. Кто пишет — вы, копирайтер или я? Какие факты можно публиковать: гарантии, сроки, цифры, документы, сертификаты.
• Фото и видео. Есть свои или нужна съёмка. Сток для сайта компании — крайний случай: его узнают с первого взгляда, и доверия он не добавляет.
• Языки. Какие версии нужны и кто готовит тексты. Казахская версия, написанная носителем языка, и автоперевод — разные объёмы работы. Подробнее — в статье про сайт на казахском, русском и английском.
• Дата. Если она жёсткая — выставка, сезон, событие, — напишите её и почему она жёсткая. Под дату я соберу объём, который успевает.
• Старый сайт. Что с ним делать: переносить материалы, сохранять адреса страниц, закрывать.
• Бюджет. Если есть рамка, назовите её. Под рамку я предложу объём, а не буду гадать.

Чего не писать в ТЗ на сайт

Есть формулировки, которые занимают место, но не помогают оценке.

• Прилагательные — «современный», «стильный», «удобный», «продающий». Их нельзя проверить, и каждый понимает их по-своему. Лучше покажите сайты, которые нравятся, и объясните, что именно в них нравится.
• Технологии без причины — «на React», «с микросервисами». Опишите задачу, а инструмент я подберу под неё. Если требование есть — например, сайт должен жить на вашем сервере, — напишите его вместе с причиной.
• Длинный список функций «на будущее». Сначала то, без чего сайт не имеет смысла. Остальное — во вторую очередь, когда появятся данные о том, что нужно посетителям.
• Копию сайта конкурента. Конкурент тоже мог ошибиться. Полезнее написать, чего в его сайте не хватает вашим клиентам.

Ваш документ — вход, а не финал. На разборе я превращаю его в список требований с критериями «готово», а логику проверяю на прототипе: кликабельные экраны часто оказываются точнее любого текста. Что происходит дальше — в статьях об этапах разработки сайта и о том, почему прототип окупается.

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