Ошибки в ТЗ, которые становятся заметны только на этапе правок

Проблема, которую все узнают

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

Почему эти ошибки не видно сразу?

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

«Нравится / не нравится» вместо критериев приёмки

Самая частая ловушка: ТЗ фиксирует задачу («сделать посадочную страницу под услугу»), но не фиксирует, как понять, что задача решена правильно. В итоге решение о том, хорош макет или плох, принимается постфактум — на уровне личного вкуса конкретного человека на созвоне, а не по заранее согласованным критериям. Если в ТЗ нет ни референсов, ни описания тональности, ни хотя бы списка «что точно нельзя», дизайнер работает вслепую и неизбежно промахивается мимо ожиданий, которые существовали только в голове заказчика. По наблюдениям Nielsen Norman Group, структурированное ревью с заранее заданными критериями оценки сокращает число повторных итераций по сравнению с обсуждением «нравится/не нравится» в свободной форме. Команда, которая берёт на себя разработку сайта под ключ, обычно закрывает это на этапе брифинга — фиксирует референсы и критерии приёмки письменно, а не держит их в уме до первой итерации правок.

Платформа и технические ограничения, которые всплывают в макете

Если в ТЗ не зафиксировано, на какой платформе и в каких технических рамках будет собираться сайт, дизайнер предлагает решения, которые потом либо невозможно реализовать, либо это обходится в разы дороже. Классический пример — сложная анимация перехода между экранами, которая отлично смотрится в Figma, но требует отдельной разработки, не заложенной в бюджет. Или адаптивная сетка, которая не укладывается в возможности выбранной CMS. Эти ограничения не прописывают в ТЗ не потому, что о них забыли, а потому, что на старте проекта ещё не очевидно, где именно макет упрётся в технический потолок — это становится видно только тогда, когда макет уже есть и его начинают сверять с реализацией.

Отсутствующие пользовательские сценарии

ТЗ чаще всего описывает экраны — главная, каталог, карточка товара, форма заявки. Но оно редко описывает путь: что делает пользователь, если нужный товар закончился, как он возвращается назад после ошибки в форме, что видит человек, который пришёл не с главной, а сразу на страницу акции. Расхождение вылезает именно на этапе ревью: рецензент пытается пройти сценарий по готовому макету и понимает, что сценарий в принципе не был прописан. Правки в этом месте — это не доработка дизайна, а восполнение пробела, которого не было видно на уровне текстового документа. Дешевле всего эту категорию ошибок закрывать не на ревью готового макета, а чуть раньше — прогоняя черновой прототип по 2–3 ключевым сценариям до того, как дизайнер перейдёт к детальной отрисовке экранов.

Чек-лист: что внести в ТЗ, чтобы снять половину правок заранее

Эти четыре пункта не гарантируют нулевое число правок, но закрывают самые частые и самые дорогие расхождения ещё до первой итерации.

• Критерии приёмки по каждому ключевому экрану — не «красиво», а конкретные ориентиры: референсы, запрещённые решения, обязательные элементы.
• Зафиксированная платформа и технические ограничения реализации — на чём собирается продукт и что это допускает.
• Минимум 2–3 пользовательских сценария, прописанных текстом, а не только список экранов.
• Явно названный человек, который принимает финальное решение при разногласии между стейкхолдерами.