| ID | Что проверяем | PASS |
|---|---|---|
| TZ-01 | Первый экран | Пользователь без пояснений понимает, что результатом этапа являются требования и архитектура до разработки. |
| TZ-02 | Мобильная версия | При 320, 360, 390 и 768 px нет потери текста или действий; навигация остаётся доступной с клавиатуры. |
| TZ-03 | Поисковая роль | Основной коммерческий интент принадлежит странице проектирования; информационный материал о ТЗ не копирует её оффер. |
| TZ-04 | Доказательство | Пример прямо обозначен как собственный проект и не выдаётся за клиентский кейс. |
| TZ-05 | Следующий шаг | Из материала можно открыть услугу проектирования или скачать шаблон без обязательной отправки контактов. |
Экспертный журнал / Практика
ТЗ на разработку сайта: не список пожеланий, а договорённость о результате
Ниже — рабочая структура ТЗ, заполненный фрагмент на материале собственного сайта WEB BOGDANOV и критерии, которые можно проверить при приёмке.
01 / граница
Шаблон не проектирует сайт за вас
Хорошее ТЗ фиксирует решения так, чтобы разработчик и заказчик одинаково понимали поведение системы и способ проверки. Но оно не создаёт эти решения из пустых полей.
Если ещё не определены структура, поисковые роли страниц, пользовательские сценарии, данные и интеграции — сначала нужен этап проектирования. Заполнение шаблона догадками только переносит неопределённость в разработку.
02 / структура
Что должно быть в рабочем ТЗ
Разделы ниже нужны не ради объёма документа. Каждый из них закрывает класс решений, которые иначе придётся принимать уже во время разработки.
Пользователи и приоритетные сценарии
Структура, типы страниц и URL
Контент, данные и источники истины
Функции, состояния ошибок и права доступа
SEO, индексация и миграционные правила
Нефункциональные требования и эксплуатация
Проверяемая приёмка и границы проекта
03 / заполненный фрагмент
Пример: собственный сайт WEB BOGDANOV
Это не вымышленный заказчик и не клиентский кейс. Пример показывает, как стратегическое решение превращается в требование с границами.
Задача
Собственный сайт WEB BOGDANOV должен объяснять три понятных входа — аудит, проектирование и ограниченную доработку — и при этом не сводить бюро только к этим трём работам.
Входные данные
Согласованная стратегия, карта поисковых владельцев, результаты двух аудитов, фактические страницы и ограничения: никаких выдуманных кейсов, отзывов, KPI и неподтверждённых интеграций.
Требование
На странице проектирования пользователь должен увидеть результат этапа: карта структуры и URL, сценарии, требования к данным и функциям, фрагмент ТЗ и правила передачи в разработку.
Граница
Проектирование не обещает готовую разработку. Если требования уже подтверждены, реализация может быть следующим отдельным этапом; неизвестные интеграции сначала обследуются.
04 / приёмка
Требование должно заканчиваться способом проверки
Фразы «современно», «быстро», «удобно» или «SEO-friendly» нельзя принять однозначно. Для значимых требований заранее задаётся наблюдаемый PASS/FAIL.
Что не стоит фиксировать без обследования
Не обещайте конкретную CRM, обмен с 1С, сложную миграцию, роли личного кабинета, нагрузочные показатели или внешние API только потому, что они звучат как стандартный пункт ТЗ. Сначала нужен доступ к системе, документация и проверка ограничений.
Что передать разработчику вместе с ТЗ
- утверждённую карту страниц и URL;
- прототипы ключевых типов страниц;
- контент-модель и источники данных;
- redirect map, если меняются адреса;
- доступы к тестовым контурам интеграций;
- матрицу приёмки и ответственных.
Следующий шаг
Сначала определить решения — потом фиксировать их в ТЗ
Если исходные требования уже готовы, шаблон можно использовать самостоятельно. Если спорными остаются структура, поиск, сценарии или интеграции, их лучше закрыть до начала разработки.