1. Цели проекта: зачем мы вообще делаем сайт
Ошибка номер один — начинать проект со слов “хочу красивый сайт”. Красота — не цель, а инструмент.
Если цель не измеряется, её нельзя достичь. Поэтому в ТЗ нужно ставить конкретные бизнес-задачи:
-
увеличить онлайн-продажи на 20% в течение полугода;
-
собрать заявки с конкретных форм;
-
разместить каталог без корзины, но с возможностью “Запросить цену”;
-
перенести старый сайт на Bitrix без потери SEO и ссылочного профиля.
Чем точнее “зачем”, тем понятнее “как”: какие модули нужны, какая логика, где можно упростить.
2. Целевая аудитория: кому всё это показываем
Сайт всегда разговаривает с кем-то. И от того, кто этот человек, зависят все решения — от UX до SEO.
В ТЗ стоит зафиксировать:
-
кто основные пользователи (предприниматели, B2B-клиенты, частные покупатели);
-
в каких странах и на каких языках они говорят;
-
технические условия: мобильный трафик, VPN, слабое соединение, блокировки.
Эти данные напрямую влияют на дизайн и архитектуру. Если 80% трафика приходит с телефонов — проект не “адаптируется под мобильный”, он проектируется для мобильного.
3. Функциональные требования: ядро проекта
Это не просто “чек-лист возможностей”. Это — то, что сайт должен делать на старте.
Типичный набор выглядит так:
-
каталог, фильтры, корзина, быстрый заказ;
-
интеграции с CRM, 1С, платёжными системами;
-
личный кабинет пользователя или админпанель;
-
возможность редактировать контент через блочный редактор;
-
мультиязычность, поиск, сортировки, сохранение фильтров.
Главный принцип — писать что должно происходить.
4. Нефункциональные требования: технический фундамент
О них почти всегда вспоминают в конце, а зря. Это именно те пункты, которые влияют на то, насколько хорошо работает сайт.
Ключевые:
-
скорость загрузки;
-
адаптация под мобильные устройства без компромиссов;
-
SEO-база с первого дня: ЧПУ, мета-теги, микроразметка, редиректы;
-
безопасность: SSL, защита от ботов, двухфакторка для админов;
-
права доступа: админ, редактор, контент-менеджер, модератор.
Эти параметры не видны пользователю, но без них любой проект будет хрупким.
5. Контент и наполнение: кто отвечает за смысл
Один из частых провалов — готовый сайт с пустыми разделами. В ТЗ нужно зафиксировать:
-
кто создаёт тексты, фото, видео, категории;
-
когда именно сайт наполняется (100% к запуску, частично, или стартует пустым);
-
нужны ли шаблоны для HR-раздела, блога, кейсов, новостей.
Контент — это не “дополнительная работа”, а часть проекта. Если его нет, проект нельзя считать завершённым.
6. Интеграции и обмен данными: не просто “подключить”
Фраза “нужна интеграция с 1С” ничего не значит. В ТЗ важно расписать логику движения данных:
-
при заказе → CRM создаёт сделку и подтягивает товары;
-
при изменении цены в 1С → обновляется карточка на сайте;
-
при оплате → чек в ОФД, статус “оплачен”, письмо клиенту.
Когда этого нет, разработчик делает “по умолчанию”, а потом приходится переделывать.
7. Границы ответственности: кто за что отвечает
Любой опытный проджект скажет: половина конфликтов в проектах — из-за отсутствия рамок. В хорошем ТЗ должно быть явно:
-
что входит в задачу;
-
что не входит (и оформляется отдельным договором);
-
что происходит после релиза (support-пакет, SLA, приоритеты заявок).
Когда это зафиксировано, и клиент, и подрядчик понимают: что оплачено, что можно доработать, а что требует отдельного бюджета.
Типичные ошибки при составлении ТЗ
-
«Хочу сайт как у X» — без конкретики, что именно работает.
-
Нет списка функций, только “нужен интернет-магазин”.
-
Не описана логика CRM/1С.
-
Пропущены требования к скорости, безопасности и SEO.
-
Нет ответственного за наполнение.
-
Не прописано, когда проект считается завершённым.
Как мы работаем с ТЗ в PHPDev.ORG
Мы не ждем, что заказчик принесёт идеальный документ. При необходимости помогаем его собрать, привлекая бизнес-аналитика.
Результат — прозрачное, рабочее ТЗ, по которому можно точно посчитать сроки, бюджет и ответственность сторон.
