Узнаваемая история: «Мы же всё обсудили…»
Обычно это звучит одинаково: «Мы созвонились, всё проговорили, даже в переписке было. А на выходе получили не то».
Сайт вроде работает, страницы открываются, кнопки нажимаются — но ощущение такое, будто вам привезли кухню: шкафы красивые, а розетка под холодильник оказалась за шкафом. И теперь любой шаг — с разбором половины конструкции.
Так чаще всего и происходит, когда техническое задание на сайт либо отсутствует, либо выглядит как два листа «сделать современно и удобно». И это не про «все вокруг плохие». Это про то, что слова — слишком неточный инструмент, если их не превратить в понятный план.
Почему проблема появляется именно на этапе ТЗ
Техническое задание на разработку сайта — это не бумажка «для галочки» и не попытка усложнить жизнь. Это договорённость о реальности: что именно мы делаем, как это будет работать, кто за что отвечает и как понять, что всё готово.
Когда ТЗ нет, проект превращается в набор ожиданий. У заказчика они одни (часто очень логичные). У исполнителя — другие (тоже логичные, но по-своему).
Пока вы на старте, кажется, что разница мелкая. А потом начинается: «а мы думали, что это входит», «а мы не поняли, что вам нужно именно так», «а это отдельная доработка».
Самое неприятное — страдают не только сроки и бюджет. Страдает смысл сайта. Он может быть «сделан», но не приносить результата, потому что никто не договорился, каким именно должен быть этот результат.
Что обязательно должно быть в техническом задании на сайт
Дальше — не список «как у всех», а вещи, которые реально спасают проект. Именно эти пункты чаще всего отсутствуют у владельцев бизнеса, особенно если прошлый опыт был нервным.
1) Цель сайта и измеримый результат
Пока цель звучит как «чтобы был сайт компании», у каждого будет своё понимание успеха. В ТЗ должно быть зафиксировано, что сайт делает для бизнеса: приводит заявки, продаёт услуги, объясняет продукт, отсекает «не ваших» клиентов, снижает нагрузку на менеджеров.
Важно, чтобы цель была проверяемой. Не «стало лучше», а «появились заявки с формы», «люди начали записываться», «конверсия выросла». Иначе сайт получается как витрина без входа: красиво, но непонятно, что с этим делать.
Что стоит прописать буллитами (коротко и по делу):
- главная задача сайта (1–2 предложения);
- какие действия пользователя считаются успехом (заявка, звонок, покупка, запись);
- что будет считаться «готово» (например: форма работает, письма приходят, заявки фиксируются).
После этого разговор сразу становится взрослым: «делаем инструмент», а не «рисуем странички».
2) Аудитория и сценарии: кто приходит и что делает
У владельцев бизнеса часто есть ощущение: «ну всем же понятно, кому нужен наш продукт». Но на сайте «понятно» не работает. Один человек боится обмана, второй сравнивает цены, третий ищет гарантию, четвёртый вообще не понимает терминов. И всем им нужна разная подача.
В ТЗ важно описать 2–4 типичных сценария: как человек попадает на сайт и что он должен сделать. Это не маркетинговая философия. Это практический способ не получить сайт, который «для всех», а значит — ни для кого.
Например: человек пришёл с рекламы и хочет быстро понять цену. Или пришёл из поиска и сравнивает варианты. Или пришёл по рекомендации и проверяет доверие: кейсы, документы, отзывы.
3) Структура сайта: какие страницы нужны и зачем
Одна из главных причин конфликтов — структура. Заказчик часто представляет сайт как «главная + услуги + контакты». Исполнитель может собрать это в любом порядке, потому что не описано, что важно и как пользователь должен идти по сайту.
Структура в ТЗ — это не просто список пунктов меню. Это смысл каждой страницы.
Какая задача у главной? Что должно быть на странице услуги? Нужно ли отдельное портфолио? Нужен ли блог? Будет ли страница «о компании» содержательной или формальной?
Минимум, который стоит зафиксировать буллитами:
- список страниц и разделов (карта сайта);
- какие блоки важны на ключевых страницах (например: выгоды, этапы, кейсы, форма);
- какие страницы приоритетные (на что делаем упор).
Когда структура прописана, сайт перестаёт быть «набором страниц». Он становится маршрутом, который ведёт к действию.
4) Контент: кто пишет тексты, где взять фото и что уже есть
Очень многие проекты «застревают» не на разработке, а на контенте. Потому что сначала делают дизайн, потом верстку, а потом выясняется, что тексты нужно писать с нуля. Или фото нет. Или у заказчика есть PDF, который «просто вставьте на сайт», а он не подходит.
В ТЗ нужно честно ответить: кто делает контент и в каком виде он будет передан. Если тексты пишете вы — супер, но тогда стоит обозначить сроки и формат. Если тексты пишет подрядчик — это отдельная задача. Если тексты берём из старого сайта — нужно понять, что переносим, а что переписываем.
И это не про «придирки». Это про то, что без контента сайт невозможно собрать нормально: блоки будут пустыми, смысл размоется, а сроки поплывут.
5) Функционал простыми словами: что должно работать
Слово «функционал» пугает, но на деле всё просто. Это список того, что посетитель и владелец сайта смогут делать. Форма обратной связи — это функционал. Калькулятор — функционал. Личный кабинет — функционал. Поиск по каталогу — тоже функционал. Важно описывать не «как сделать», а «что должно получиться».
Пример буллитов, которые реально помогают:
- какие формы нужны и куда приходят заявки;
- нужны ли уведомления в мессенджеры/почту;
- есть ли интеграции (CRM, онлайн-оплата, сервис записи);
- что должен уметь делать администратор сайта (менять тексты, добавлять товары, редактировать цены).
Если этого нет, потом начинаются «а мы думали, что будет кнопка», «а мы думали, что заявки будут падать в CRM».
6) Дизайн и референсы: не «красиво», а «понятно как»
Самая опасная формулировка в любом проекте — «сделайте современно». У каждого своё современно: кому-то минимализм, кому-то «как у банка», кому-то — большие фото и анимации.
ТЗ должно зафиксировать хотя бы ориентиры: примеры сайтов, которые вам нравятся, и — что важно — почему. Не «хочу как тут», а «нравится подача услуг», «удобная навигация», «понятная структура», «спокойные цвета». Ещё полезнее обозначить, что точно не нравится. Иногда это экономит недели.
7) Технические вещи: домен, хостинг, доступы, безопасность
Да, это «техническое», но без заумных слов. Если сайт делается на WordPress, важно заранее договориться, кто отвечает за домен и хостинг, кто предоставляет доступы, кто делает резервные копии, что будет с безопасностью и обновлениями.
Это тот случай, когда неприятности не видны сразу. Зато потом внезапно выясняется, что доступов нет, хостинг слабый, письма не отправляются, а сайт «падает» после обновления. Хорошее ТЗ фиксирует это спокойно и заранее, без драм.
8) Границы работ: что входит, а что считается отдельной задачей
Это не про жадность и не про попытку продать «ещё». Это про то, чтобы проект не превратился в бесконечный ремонт квартиры. Когда границы не обозначены, в проект постоянно добавляются мелкие «а давайте ещё», которые съедают сроки и силы.
Например: перенос старого контента, наполнение каталога, настройка аналитики, SEO-оптимизация, подключение платёжки, написание текстов — всё это разные задачи.
Некоторые входят в типовую разработку сайта, некоторые — нет. Главное — проговорить и зафиксировать.
Почему размытое ТЗ бьёт по бизнесу, а не только по разработке
Снаружи кажется, что проблема «только в удобстве работы с подрядчиком». На деле страдает бизнес:
- Вы платите за сайт, но он не становится инструментом. Он может выглядеть нормально, но не объяснять ценность, не вести к заявке и не закрывать вопросы клиента.
- Менеджеры продолжают отвечать на одно и то же. Реклама работает хуже, потому что посадочные страницы слабые. SEO не растёт, потому что структура и контент сделаны случайно.
- А дальше появляется знакомая мысль: «сайты не работают». Хотя на самом деле не сработала подготовка: не было чётких договорённостей, а значит — не было управляемого результата.
Каким должно быть ТЗ, чтобы с ним реально было легко
Хорошее техническое задание на сайт не обязано быть огромным документом на 60 страниц.
Оно обязано быть понятным: чтобы любой человек мог прочитать и представить будущий сайт одинаково — и заказчик, и исполнитель.
Мы в своей работе видим, что лучший признак хорошего ТЗ — это отсутствие сюрпризов по ходу проекта.
Когда всё важное зафиксировано заранее, сайт делается спокойнее, быстрее и предсказуемее. И главное — получается именно тем инструментом, который нужен бизнесу.
Наша студия — https://sergeev.studio/