ТЗ начинается с изменения
Опишите, что должно стать быстрее, понятнее или управляемее после запуска. Формулировка «нужен современный сайт» не задаёт критерий решения.
Полезный контекст содержит текущий процесс, участника, проблему, желаемое действие и способ понять, что изменение произошло.
Вместо списка экранов опишите один сквозной пример: откуда человек приходит, что знает в этот момент, какие данные вводит, где сомневается и какой результат должен получить. Из сценария естественно выводятся страницы, состояния и интеграции.
Укажите, что уже существует: бренд, домен, аналитика, CRM, база контента, backend и команда поддержки. Эти активы и ограничения влияют на архитектуру не меньше желаемых функций.
Отделите известное от гипотез
Роли, интеграции и контент часто уточняются во время discovery. Помечайте предположения явно, чтобы команда не оценивала их как уже подтверждённый объём.
Для каждого спорного пункта нужен владелец решения и дата, когда неопределённость должна быть снята.
Полезная маркировка проста: подтверждено, требует проверки, решение отложено. Рядом фиксируются источник информации и влияние на срок или бюджет. Так риск не теряется внутри протокола встречи.
Если неизвестность меняет весь технический контур, её снимают до детальной оценки. Например, документация интеграции, качество исходных данных или права редакторов заслуживают отдельной проверки, а не сноски в конце сметы.
Зафиксируйте приёмку
Критерий готовности описывает наблюдаемое поведение: кто выполняет действие, с какими данными и какой результат получает. Слова «удобно» и «быстро» нужно переводить в проверяемый сценарий.
Тогда ТЗ становится общей рамкой для дизайна, разработки и QA, а не большим текстом, который никто не перечитывает.
Добавьте негативные случаи: пустой ответ API, неверный формат файла, потеря сети, отсутствие результатов, недостаточные права и длинный текст. Система считается готовой, когда в этих состояниях человек понимает, что произошло и что делать дальше.
Для контентного сайта отдельно проверяют каждый маршрут, метаданные, индексацию, адаптив и формы. Для сервиса — роли, данные, журнал изменений и восстановление после ошибки. У каждого пункта должен быть способ демонстрации.
Хорошее ТЗ остаётся живым документом: решения обновляются вместе с проектом, а изменения объёма видны всем участникам. Точность появляется не от количества страниц, а от управляемости допущений и приёмки.
Сильное ТЗ не угадывает все экраны заранее — оно делает цель, ограничения, ответственность и приёмку однозначными.