Типичные ошибки в ТЗ на сайт сводятся к недосказанному функционалу, размытым требованиям к интерфейсу, забытым интеграциям, отсутствию критериев приёмки и нереалистичным ограничениям по срокам/бюджету. Избежать их помогает подход "симптом → причина → приоритетное действие", фиксация измеримых критериев и безопасные read-only проверки до любых изменений, чтобы не ломать прод.
Симптомы проблем в ТЗ и приоритетные меры
- "Сделайте как у конкурента" без расшифровки → заменить на список пользовательских сценариев + критерии приёмки для каждого.
- Дизайн "на вкус" (нравится/не нравится) → зафиксировать UI-ограничения (сетку, состояния, адаптив) и UX-цели (конверсия, путь пользователя) в проверяемом виде.
- Интеграции вспоминают после верстки → составить реестр систем (CRM/оплата/аналитика) и провести read-only аудит доступов, API и ограничений.
- Нет приоритетов: всё "must" → ввести MoSCoW или аналог, отделить MVP от "хотелок" и привязать к релизам.
- Контент "потом наполним" → определить ответственных, форматы, объёмы, дедлайны и правила миграции/импорта.
- Сроки и бюджет заданы без объёма → добавить буфер на риски, прототипирование, интеграции и согласования; зафиксировать процесс change request.
Неполное описание функционала: как распознать и быстро устранить
Симптомы (что обычно видит заказчик/команда)
- Вопросы от разработки начинаются с "а что должно быть при нажатии?" и "а кто это может делать?".
- Формулировки уровня "личный кабинет", "каталог", "поиск" без ролей, полей, состояний и ошибок.
- Постоянные "мелкие" правки, которые на деле меняют логику (например, статусы заказа, возвраты, промокоды).
- Споры на приёмке: "мы так не договаривались", потому что не было критериев.
Вероятные причины
- ТЗ описывает страницы, а не пользовательские сценарии и бизнес-правила.
- Нет карты ролей и прав (клиент/менеджер/админ/контент-редактор).
- Не описаны исключения: пустые состояния, ошибки, отмены, таймауты, недоступность сервиса.
Приоритетные действия (быстро и безопасно)
- Read-only инвентаризация: выписать модули сайта и для каждого - цель, акторы (роли), входы/выходы.
- Описать 5-15 ключевых сценариев в формате "Дано/Когда/Тогда".
- Добавить бизнес-правила: статусы, ограничения, валидации, расчёты (словами, без кода).
- Для каждого сценария указать критерии приёмки (что считается "сделано").
- Приложить пример тз на создание сайта в виде одной заполненной карточки функционала - и масштабировать шаблон на остальные разделы.
Короткие примеры формулировок
- Плохо: "Сделать поиск по сайту". Хорошо: "Поиск по товарам и статьям; минимум 3 символа; подсказки; сортировка по релевантности; пустое состояние с рекомендациями; логирование запросов в админке".
- Плохо: "Личный кабинет". Хорошо: "Роли: клиент/менеджер. Клиент видит заказы и статусы, может отменить до статуса X; менеджер меняет статус, добавляет трек-номер; все действия пишутся в журнал".
Неясные требования к UX/UI: признаки и практические правки
Быстрая диагностика (чек-лист)
- Есть ли у каждой страницы/экрана цель и одно главное действие пользователя?
- Описаны ли состояния: loading/empty/error/success для ключевых блоков?
- Зафиксированы ли брейкпоинты и принципы адаптива (что скрывается/перестраивается)?
- Есть ли требования по доступности: контраст, фокус, клавиатура, alt-тексты?
- Определены ли правила типографики/сеток/отступов или ссылка на дизайн-систему?
- Описаны ли компоненты: поля, селекты, маски, валидации, подсказки, ошибки?
- Указаны ли требования к скорости восприятия (скелетоны, прогресс, оптимистичные обновления)?
- Есть ли примеры "как не делать" (запрещённые паттерны, лишние модалки, автоплей)?
- Согласованы ли микро-копирайтинг и тон сообщений (ошибки, уведомления, системные тексты)?
- Определён ли источник истины: макеты, прототип, описательная часть - что главнее при конфликте?
Практические правки (симптом → причина → действие)
- Симптом: "Сделайте современно". Причина: нет критериев. Действие: закрепить 3-7 референсов и выписать, какие именно свойства переносим (сетку, плотность, стиль иллюстраций, анимации).
- Симптом: "Как на мобилке - сами решите". Причина: не описан адаптив. Действие: зафиксировать правила адаптива для каждого ключевого шаблона (каталог/карточка/форма/ЛК).
- Симптом: много переделок после первой сборки. Причина: не описаны состояния и тексты. Действие: добавить таблицу состояний по экранам и набор системных сообщений.
Пропуски в интеграциях и технических ограничениях: что проверить в первую очередь
Причины, отсортированные по вероятности
- Интеграции воспринимаются как "подключить сервис", но не описываются сущности, события, права и ошибки.
- Нет владельца интеграции со стороны заказчика (кто даст доступы, кто принимает поток данных).
- Не обозначены ограничения инфраструктуры: хостинг, стек, политика безопасности, регламенты.
Read-only проверки до любых изменений (чтобы не ломать прод)
- Список систем и точек обмена: CRM/ERP, платежи, доставка, e-mail/SMS, аналитика, коллтрекинг, CDN, антиспам.
- Доступы: есть ли тестовые ключи/песочницы, лимиты, IP allowlist, 2FA, требования к токенам.
- Данные: какие справочники нужны (товары, остатки, статусы), кто источник истины, частота обновления.
| Симптом | Возможные причины | Как проверить (read-only) | Как исправить (в ТЗ) |
|---|---|---|---|
| "Интеграция с CRM" звучит одной строкой | Не описаны сущности/события; нет схемы данных | Собрать список сущностей (лид/контакт/сделка/заказ) и событий (создание/изменение/отмена) по документации CRM | Добавить матрицу "событие → куда → поля → кто владелец → обработка ошибок" |
| Оплата "подключить позже" | Нет сценариев возвратов/чарджбеков; не выбран провайдер | Проверить, есть ли провайдер, договор, sandbox и требования по фискализации/чекам | Зафиксировать провайдера, сценарии: оплата/неуспех/повтор/возврат/частичный возврат; требования к статусам |
| Аналитика не сходится после релиза | Не определены события и источники; нет плана тегирования | Просмотреть текущие контейнеры/счётчики и список нужных целей/событий | Описать dataLayer/события, параметры, правила дедупликации, ответственность за настройку |
| Сайт "тормозит", виноват непонятно кто | Не задано окружение и ограничения; нет нефункциональных требований | Собрать текущие ограничения хостинга/стека и критичные страницы | Добавить нефункциональные требования: кеширование, изображения, ограничения на сторонние скрипты, профилирование |
Где чаще всего забывают ограничения
- Политики безопасности: хранение персональных данных, журналы, доступы подрядчиков.
- Ограничения CMS/фреймворка: что можно в плагинах, что только в кастомной разработке.
- Миграции: перенос URL, редиректы, сохранение метаданных, импорты/экспорты.
Ошибки в приоритетах задач и критериях приёмки: как поставить корректные цели
Пошаговое устранение (от безопасного к рискованному)
- Зафиксировать цель проекта в 1-2 измеримых формулировках (что улучшить и для кого), без привязки к "красоте".
- Составить список пользовательских сценариев и отметить 20% сценариев, которые дают 80% ценности (внутренне, без "магии", просто по здравому смыслу и опыту команды).
- Ввести приоритизацию (MoSCoW / MVP+Nice-to-have) и закрепить, что в MVP попадает только то, без чего сценарии не работают.
- Определить критерии приёмки на уровне сценариев: входные данные, ожидаемый результат, обработка ошибок, права доступа.
- Согласовать "источник истины": что главнее при конфликте - ТЗ, макеты, прототип, задачи в трекере.
- Добавить политику изменений (change request): как оформлять новые требования, кто оценивает, как меняются сроки/бюджет.
- Разнести релизы: сначала стабильный MVP, затем улучшения (рискованные пункты - во второй волне).
- Провести сухую приёмку на бумаге: пройти сценарии "Дано/Когда/Тогда" по ТЗ до начала разработки.
Мини-шаблон критериев приёмки
- Сценарий: ...
- Роли/права: ...
- Предусловия: ...
- Шаги: ...
- Ожидаемый результат: ...
- Ошибки/исключения: ...
Недостаточная детализация контента и SEO-требований: шаблоны для точных формулировок
Симптом → причина → приоритетное действие
- Симптом: "Контент дадим потом". Причина: нет владельцев и форматов. Действие: прописать матрицу контента (страница → типи контента → объём → источник → ответственный → дедлайн).
- Симптом: SEO упоминается как "сделать базово". Причина: нет требований к URL, метаданным, индексируемости. Действие: зафиксировать правила URL, шаблоны meta/title/H1, robots/sitemap, каноникал, редиректы при миграции.
Шаблоны формулировок для ТЗ
- URL и шаблоны: "URL ЧПУ по шаблону /katalog/{category-slug}/{product-slug}/; запрещены параметры в индексируемых URL; при изменении slug - 301 на новый адрес".
- Метаданные: "Для карточки товара: title = {Название} - купить в {Город}; description = ...; правила обрезки и приоритет ручного ввода над автогенерацией".
- Индексация: "Фильтры: индексируются только страницы из белого списка; остальные закрыты от индексации; каноникал на основную категорию".
- Миграция: "Сохранить текущие URL и метаданные; если невозможно - предоставить карту редиректов и согласовать до запуска".
Когда эскалировать и брать консультацию
- Есть миграция с сохранением SEO-показателей, но нет карты текущих URL, редиректов и правил каноникал - нужна консультация по тз на сайт со стороны SEO-специалиста.
- Структура каталога/фильтров спорная и влияет на индексируемые страницы - подключайте SEO и аналитика до прототипов.
- Контент создают несколько команд (маркетинг, продукт, редакция), нет единого владельца - стоит отдельно техническое задание на сайт заказать у специалиста по контент-моделированию или BA.
Нереалистичные сроки, бюджет и управление рисками: предупреждающие индикаторы и корректировки
Индикаторы, что план нереалистичен
- Срок зафиксирован раньше, чем согласованы интеграции, контент и критерии приёмки.
- В бюджете нет времени на прототипирование, тестирование, исправления, внедрение аналитики.
- Разработка тз на сайт цена обсуждается отдельно от объёма: нет перечня модулей, ролей, сценариев и нефункциональных требований.
- Слишком много задач помечено как обязательные для первого релиза.
- Нет буфера на внешние зависимости: доступы, договоры, ответы провайдеров, согласования безопасности.
Корректировки и профилактика (5-10 практик)
- Сделать декомпозицию по сценариям, а не по страницам: так проще оценивать и резать объём.
- Заморозить контур MVP до начала разработки; всё остальное - через change request.
- Ввести риск-реестр (интеграции, контент, доступы, миграция) и назначить владельцев риска.
- Планировать read-only аудит текущей системы/аналитики/интеграций перед любыми вмешательствами, чтобы не ломать прод.
- Согласовать среду: dev/stage/prod, правила деплоя, окно релизов, откат, резервные копии.
- Заранее определить формат приёмки: чек-листы, сценарии, кто подписывает, что считается блокером.
- Выделить время на стабилизацию после функциональной готовности (исправления, регресс, полировка).
- Закрепить формат артефактов: если хотите составить тз на разработку сайта качественно, договоритесь, что итог включает сценарии, интеграции, критерии, контент-матрицу и ограничения.
Практические ответы на типовые затруднения при составлении ТЗ
Что делать, если заказчик просит "как у конкурента", но без деталей?
Переведите запрос в сценарии и критерии приёмки: что пользователь делает, какие поля видит, какие ошибки возможны. Референс оставьте как иллюстрацию, но не как спецификацию.
Можно ли начать разработку, если интеграции ещё не выбраны?
Только при явной фиксации заглушек и границ MVP, плюс read-only проверках доступности API/песочниц. Иначе риск переделок закладывайте сразу в change request.
Как корректно оформить критерии приёмки без "технической" перегрузки?
Используйте "Дано/Когда/Тогда" для ключевых сценариев и добавьте исключения (ошибки, пустые состояния). Это проверяется тестированием и снимает споры.
Где взять пример тз на создание сайта, чтобы не изобретать структуру?
Берите шаблон карточки функционала (роль → сценарий → правила → критерии) и заполните на 1-2 модуля. Затем масштабируйте на остальные разделы.
Когда имеет смысл техническое задание на сайт заказать, а не писать самим?
Когда есть миграция, много интеграций или несколько стейкхолдеров с разными целями. В таких проектах внешняя фасилитация и фиксация критериев часто дешевле переделок.
Как обсуждать разработка тз на сайт цена, чтобы не получить "кот в мешке"?
Привяжите оценку к объёму артефактов: сценарии, интеграции, критерии приёмки, контент-матрица, нефункциональные требования. Сравнивайте предложения по составу, а не по формулировке "ТЗ под ключ".
Нужна консультация по тз на сайт: какие вопросы подготовить заранее?
Подготовьте цели проекта, список ролей, перечень интеграций и текущих систем, ограничения по CMS/хостингу и черновой список сценариев. Это ускорит диагностику и снизит количество итераций.
