Как составить ТЗ на сайт, если вы не программист

ТЗ — это не документ на 40 страниц

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

Начните с пяти простых вопросов

Структура брифа, которую можно просто скопировать

Как правильно описывать функции

Плохой вариант: «Нужен личный кабинет». Он ничего не говорит о содержимом.

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

Такое описание не требует знания JavaScript, PostgreSQL или API, но уже позволяет разработчику оценить объём.

Как пользоваться референсами

Ссылки на сайты полезны, если вы объясняете что именно нравится: «здесь нравится крупная типографика», «здесь удобно сделан каталог», «хочу похожую плотность информации». Фраза «сделайте как Apple» почти бесполезна: копирование чужого визуального языка не объясняет задачу вашего бизнеса.

Контент — часть ТЗ

До начала дизайна стоит понять, кто готовит тексты, фотографии, цены, документы, переводы. Если контента нет, макет строится на условных блоках, а после появления реального текста всё может измениться. Особенно это заметно на мобильной версии.

Добавьте критерии приёмки

• сайт корректно работает на актуальных мобильных и desktop-браузерах;
• формы действительно отправляют данные, а не просто показывают анимацию;
• нет горизонтальной прокрутки на телефоне;
• все основные страницы имеют title и description;
• заказчику переданы доступы к домену, хостингу и другим сервисам;
• после публикации пройден полный пользовательский сценарий на production-домене.

Это превращает «кажется, готово» в понятный список, по которому обе стороны могут проверить результат.

Не выбирайте технологии вместо разработчика, если вам это не нужно

Фразы «обязательно React», «нужна микросервисная архитектура» или «хочу PostgreSQL» имеют смысл, когда у компании есть техническая причина: существующая команда, корпоративный стандарт, интеграция с текущей системой. Если такой причины нет, лучше описать требования к результату: скорость, ожидаемое количество пользователей, необходимость личного кабинета, загрузки файлов, редактора контента.

Иначе легко получить ситуацию, когда техническое решение выбрано ещё до того, как сформулирована задача. Хороший исполнитель сможет объяснить, почему предлагает конкретный стек и какие у него есть ограничения.

Пометьте приоритеты

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

Это особенно помогает, если срок или бюджет начинают сжиматься. Вместо хаотичного удаления функций команда заранее понимает, какие части нельзя трогать.

Что попросить на финале проекта

• исходный код и доступ к репозиторию;
• доступ к домену, DNS и хостингу;
• список подключённых внешних сервисов;
• короткую инструкцию по типовым действиям администратора;
• описание того, как делается deploy или кому писать для обновления;
• список известных ограничений, если они есть.

Эти пункты лучше записать в ТЗ заранее. Тогда передача проекта — часть работы, а не неожиданная просьба после того, как разработчик уже переключился на другую задачу.