Большинство конфликтов между заказчиком и разработчиком сайта начинаются задолго до сдачи, ещё в момент подписания договора. Заказчик уверен, что форма заявки «конечно же» отправляет лиды в CRM, а подрядчик считает это отдельной задачей. Каталог «как у конкурента» один представляет с фильтрами по десяти параметрам, другой со списком карточек. Через три месяца обе стороны правы, деньги потрачены, а сайт не запущен.
Техническое задание снимает большую часть этих споров. Хорошее ТЗ на разработку сайта не обязано быть толстым. Оно обязано отвечать на вопросы, которые иначе всплывут посреди проекта: что именно делаем, для кого, на чём, как проверяем готовность и кто за что отвечает после запуска. Мы не начинаем работу без разделов, перечисленных в этой статье, и почти в каждом чужом ТЗ находим одни и те же дыры.
Зачем ТЗ, если есть бриф и договор
Бриф фиксирует пожелания: какой бизнес, какие конкуренты, какие цвета нравятся. Договор фиксирует деньги, сроки и ответственность. Между ними остаётся пустое место, и именно туда проваливаются деньги.
ТЗ превращает пожелания в проверяемые требования. «Удобный каталог» становится фразой «каталог с фильтрами по бренду, цене и наличию, сортировкой по цене и новизне, не более 24 товаров на странице». Такое требование можно проверить при приёмке, а «удобство» проверить нельзя.
Для заказчика у ТЗ есть ещё одна практическая ценность: с ним можно получить сопоставимые коммерческие предложения. Если три студии оценивают проект по одному документу, разница в цене показывает разницу в подходе. Если каждая оценивает свою фантазию на тему «сайт компании», сравнивать нечего.
Кто пишет техническое задание
Идеальный вариант, когда ТЗ пишет исполнитель, а заказчик внимательно читает и правит. Разработчик знает, какие вопросы нужно закрыть, чтобы оценить работу. Заказчик знает свой бизнес. Поэтому обычно процесс выглядит так: интервью с владельцем и менеджерами, черновик от исполнителя, одна-две итерации правок, подпись.
Написать ТЗ самостоятельно тоже можно, особенно если сайт небольшой. Но тогда важно не описывать решение вместо задачи. «Сделать на плагине X» ограничивает подрядчика, а «в форме заявки нужны поля имя, телефон и комментарий, заявка должна попадать в CRM» оставляет ему выбор инструмента и ответственность за результат.
Отдельные компании берут ТЗ как самостоятельную платную услугу, до основного договора. Это разумно для средних и крупных проектов: документ остаётся у заказчика, и с ним можно пойти к любому исполнителю.
Обязательные разделы ТЗ на разработку сайта
1. Цели и аудитория
Два-три абзаца о том, зачем компании сайт и кто на него придёт. Примеры целей: получать заявки на услуги из поиска и рекламы, разгрузить менеджеров от типовых вопросов, дать дилерам доступ к прайсу. От цели зависит всё остальное. Сайт под заявки из Google Ads строится вокруг посадочных страниц и форм, сайт для дилеров вокруг личного кабинета и прав доступа.
Аудиторию описывайте конкретно: кто принимает решение о покупке, с какого устройства чаще заходит, на каком языке ищет. Для Казахстана сразу решите вопрос языковых версий. Добавить казахскую версию после запуска заметно дороже, чем заложить её в структуру с самого начала.
2. Структура сайта
Список всех страниц и разделов, лучше в виде дерева. Для каждого типа страницы коротко: что на ней должно быть. Главная, страница услуги, карточка товара, статья блога, контакты, политика конфиденциальности.
Структуру стоит строить от поискового спроса, а не только от внутренней логики компании. Если люди ищут «ремонт кондиционеров в Алматы» и «заправка кондиционеров», это, скорее всего, две разные страницы, даже если в прайсе это одна услуга. Как разложить разделы под продвижение, мы разбирали в статье про SEO-структуру сайта на WordPress.
3. Функциональные требования
Самый важный и самый недооценённый раздел. Здесь описывается, что сайт делает, а не как выглядит. Типичный набор:
- формы: какие поля, какие обязательные, куда уходит заявка (почта, CRM, мессенджер), что видит пользователь после отправки;
- каталог: типы товаров, характеристики, фильтры, сортировка, вывод цен и наличия;
- поиск по сайту: нужен ли, по каким разделам ищет;
- личный кабинет: кто регистрируется, что видит, какие действия может совершать;
- оплата и доставка, если это магазин: способы оплаты, расчёт доставки, статусы заказа;
- калькуляторы, конфигураторы, записи на приём и прочие интерактивные элементы;
- блог или новости: рубрики, теги, автор, похожие материалы.
Каждую функцию описывайте через сценарий: «пользователь выбирает услугу, указывает дату, получает подтверждение на почту, менеджер получает сделку в CRM». Сценарий потом превращается в тест при приёмке.
4. Интеграции
Отдельный список внешних систем, с которыми сайт обменивается данными: CRM, учётная система, платёжный сервис, службы доставки, аналитика, мессенджеры, онлайн-чат. Для каждой укажите направление обмена (сайт отдаёт, получает или и то и другое), какие данные передаются и как часто.
Именно интеграции чаще всего раздувают бюджет после старта. Фраза «выгрузка товаров из учётной системы» может означать и разовый импорт файла, и двусторонний обмен остатками каждые пятнадцать минут. Разница в трудозатратах бывает кратной.
5. Контент
Кто готовит тексты, фотографии и описания товаров, в каком виде и к какому сроку. Если контент готовит заказчик, это надо записать, иначе сайт будет сдан с заглушками, а сроки сорвутся по вине, которую никто не признает. Если тексты пишет исполнитель, укажите объём, количество страниц и требования к SEO-оптимизации.
Отдельно оговорите перенос контента со старого сайта: сколько страниц, вручную или автоматически, сохраняются ли адреса. При смене сайта без настройки редиректов легко потерять накопленные позиции в поиске.
6. Дизайн
ТЗ не заменяет дизайн-макет, но задаёт рамки: наличие фирменного стиля и брендбука, примеры сайтов, которые нравятся и не нравятся (с пояснением, чем именно), количество макетов и итераций правок, адаптивность для телефонов и планшетов. Хорошая практика: указать, какие устройства и ширины экрана проверяются при приёмке.
7. Технические требования
Здесь фиксируется платформа (WordPress, 1С-Битрикс или другая CMS), требования к хостингу, скорости загрузки, поддерживаемым браузерам, резервному копированию. Если у компании уже есть хостинг или сервер, укажите его параметры.
Для сайтов, которые собирают данные клиентов в Казахстане, учтите требования закона «О персональных данных и их защите». Закон требует, чтобы базы с персональными данными граждан РК находились на территории страны, а на сбор данных нужно согласие пользователя. В ТЗ это превращается в конкретные пункты: где физически расположен сервер, где хранятся заявки, есть ли на формах отметка о согласии и ссылка на политику конфиденциальности.
8. Требования к SEO и аналитике
Даже если продвижение будет отдельным проектом, базовая подготовка закладывается на этапе разработки: человекопонятные адреса страниц, редактируемые title и description, карта сайта, файл robots.txt, микроразметка, корректные коды ответа для несуществующих страниц. Сюда же относится установка счётчиков аналитики и настройка целей на отправку форм, звонки и клики по мессенджерам.
9. Админ-панель и роли
Кто будет управлять сайтом после запуска и что должен уметь делать без программиста: менять тексты, добавлять товары, публиковать статьи, редактировать баннеры. В WordPress, например, есть встроенные роли пользователей (администратор, редактор, автор и другие), и в ТЗ полезно прямо указать, какому сотруднику какая роль нужна. Отдельно оговорите обучение: инструкция, видеозапись или живая встреча.
10. Порядок приёмки
По каким критериям работа считается выполненной. Лучше всего работает чек-лист, собранный из сценариев раздела 3: каждая форма отправляет заявку, каждый фильтр работает, каждая страница открывается на телефоне. Здесь же фиксируется срок на проверку со стороны заказчика и порядок фиксации замечаний.
11. Сопровождение после запуска
Гарантийный срок, что входит в гарантию (исправление ошибок разработчика), что не входит (новые функции, последствия правок третьих лиц), кто обновляет CMS и плагины, кто делает резервные копии. Об этом часто забывают, а через полгода выясняется, что сайт не обновлялся с запуска. Что обычно включают в поддержку, мы подробно описывали в материале о техподдержке сайта на WordPress.
12. Безопасность и доступы
Короткий, но важный раздел. Кому принадлежат домен, хостинг и учётные записи в сервисах аналитики. Правильный ответ: компании-заказчику, а исполнитель получает доступ на время работ. Мы не раз видели ситуацию, когда домен зарегистрирован на личное имя фрилансера, и после расставания с ним бизнес месяцами возвращает собственный адрес сайта.
Сюда же стоит записать требования к защите форм от спама, к SSL-сертификату, к паролям администраторов и к тому, кто хранит резервные копии. Если сайт принимает оплату, отдельно оговорите, что данные карт обрабатывает платёжный сервис, а не сам сайт.
Этапы, сроки и смета: как связать их с ТЗ
Техническое задание удобно делать основой для календарного плана и сметы. Каждый крупный раздел превращается в этап с понятным результатом: прототип структуры, дизайн ключевых страниц, вёрстка и программирование, наполнение, интеграции, тестирование, запуск. Для каждого этапа фиксируется срок, стоимость и то, что заказчик должен предоставить к его началу.
Такая разбивка решает две проблемы. Во-первых, оплата идёт за готовые этапы, и заказчик не платит вперёд за всё сразу. Во-вторых, задержки становятся видны: если к этапу наполнения не пришли фотографии, это фиксируется, и сдвиг срока не превращается в спор о том, кто виноват.
Полезно также разделить требования на обязательные для запуска и желательные. Первая версия сайта выходит быстрее, а желательные функции переносятся во второй этап, когда появится статистика и станет понятно, что действительно нужно пользователям. Часто оказывается, что половина «обязательных» идей из первой редакции ТЗ после запуска никому не нужна.
В каком виде оформлять документ
Формат вторичен, но несколько правил экономят время. Нумеруйте разделы и пункты, чтобы в переписке можно было ссылаться на «пункт 3.4», а не на «то место про фильтры». Ведите историю версий с датой и перечнем изменений. Прикладывайте схемы и прототипы страниц как отдельные файлы с понятными названиями. Держите глоссарий, если в компании есть внутренние термины, которые подрядчик может понять иначе.
Документ должен быть один. Если требования лежат частично в письме, частично в презентации и частично в голосовых сообщениях, это не ТЗ, а набор поводов для разногласий.
Типичные ошибки в ТЗ на сайт
Мы регулярно получаем от клиентов готовые задания, написанные ими самими или предыдущими подрядчиками. Проблемы повторяются.
Первая и самая частая: описание внешнего вида вместо функций. Три страницы о цветах и шрифтах и одна строка «форма обратной связи». В итоге дизайн согласован, а куда уходят заявки и кто их получает, не решено.
Вторая: формулировки, которые нельзя проверить. «Современный», «быстрый», «удобный», «как у лидеров рынка». Любое такое слово нужно заменить измеримым требованием или удалить.
Третья: не описаны исключения. Что происходит, если товара нет в наличии, если пользователь ввёл телефон без кода страны, если платёж не прошёл. Разработчик сделает «как обычно», и это «обычно» может не совпасть с процессами компании.
Четвёртая: интеграции в одну строку. «Интеграция с CRM» без уточнения, какие данные передаются, в какую воронку и с каким ответственным.
Пятая: нет раздела про контент. Исполнитель ждёт тексты, заказчик ждёт, что тексты напишет исполнитель, а сроки тем временем идут.
Шестая: ТЗ не обновляется. Требования меняются по ходу проекта, это нормально. Ненормально, когда изменения обсуждаются в мессенджере и нигде не фиксируются. Любое изменение объёма работ стоит оформлять дополнением к ТЗ с пересчётом сроков и стоимости.
Пример: ТЗ для сайта сервисной компании
Возьмём условный проект: сервисная компания в Алматы, ремонт и обслуживание промышленного оборудования, заявки сейчас приходят по телефону и в WhatsApp. Первый вариант ТЗ от заказчика занимал одну страницу: «сайт-визитка, пять страниц, красивый дизайн, форма заявки».
После двух встреч документ вырос до двенадцати страниц, и вот что в нём появилось.
- Цель: получать заявки из поиска по направлениям ремонта и сократить время менеджера на первичную квалификацию.
- Структура: вместо пяти страниц двадцать две, потому что каждое направление ремонта получило свою страницу под поисковый спрос.
- Форма заявки: тип оборудования из списка, модель, описание неисправности, фото, телефон, согласие на обработку данных. Заявка создаёт сделку в CRM с ответственным по направлению.
- Интеграции: CRM, аналитика с целями на отправку формы и клик по номеру телефона.
- Контент: тексты для страниц направлений пишет исполнитель, фотографии объектов предоставляет заказчик до определённой даты.
- Технические требования: WordPress, хостинг в Казахстане, ежедневное резервное копирование.
- Приёмка: чек-лист из тридцати пунктов, проверка на трёх ширинах экрана.
Бюджет по сравнению с «визиткой» вырос, но зато все участники одинаково понимали, что будет на выходе. Спорных пунктов при сдаче не возникло, а изменения, которые заказчик захотел по ходу, оформлялись дополнениями.
Самым полезным в этом примере оказался разговор о форме заявки. Пока её описывали, выяснилось, что менеджеры тратят первые десять минут каждого звонка на вопросы о модели и характере поломки. Поля «тип оборудования», «модель» и «фото» сняли эту работу: менеджер открывает сделку и уже видит, с чем обратился клиент, и может сразу назвать ориентировочный срок. То есть ТЗ повлияло не только на сайт, но и на процесс продаж. Так бывает часто: когда компания впервые записывает, что должно происходить с заявкой, она замечает лишние шаги, которые годами никто не пересматривал.
Как проверить готовое ТЗ перед подписанием
Прочитайте документ и попробуйте ответить на вопросы ниже. Если на какой-то ответа нет, раздел нужно дописать.
- Можно ли по этому документу оценить работу, не задавая уточняющих вопросов?
- Для каждой формы понятно, куда уходят данные и кто их получает?
- Для каждой интеграции понятно направление, состав и частота обмена?
- Понятно, кто и когда готовит контент?
- Есть ли хотя бы одно слово вроде «удобный» или «современный» без расшифровки?
- Описано, как будет проходить приёмка?
- Понятно, что происходит после запуска и сколько длится гарантия?
- Учтены требования к хранению персональных данных?
Полезно дать документ прочитать человеку, который будет работать с сайтом каждый день, например менеджеру по продажам или контент-менеджеру. Такие сотрудники быстро находят сценарии, о которых руководитель не подумал.
Если хотите получить ТЗ и оценку от команды, которая потом сама будет по нему работать, посмотрите наши услуги по разработке сайтов: мы начинаем с интервью и документа, а не с дизайна. Если сайт уже есть и его нужно переделать, пригодится материал о редизайне без потери позиций.
Частые вопросы
Сколько страниц должно быть в техническом задании на сайт?
Фиксированного объёма нет. Для небольшого сайта услуг хватает от 5 до 10 страниц, для магазина с интеграциями документ может занимать несколько десятков. Важнее полнота: по ТЗ должно быть возможно оценить работу без уточняющих вопросов.
Кто должен писать ТЗ на разработку сайта: заказчик или исполнитель?
Чаще всего черновик готовит исполнитель по итогам интервью, а заказчик правит и согласует. Заказчик может написать ТЗ сам, но тогда стоит описывать задачи и сценарии, а не конкретные технические решения.
Можно ли менять ТЗ после начала работ?
Можно, но каждое изменение лучше оформлять дополнением к документу с пересчётом сроков и стоимости. Договорённости в переписке без фиксации в ТЗ чаще всего становятся предметом спора при приёмке.
Нужно ли указывать в ТЗ CMS?
Да, если у компании есть причины выбрать конкретную платформу: уже работающие сотрудники, интеграции, требования к безопасности. Если причин нет, можно описать требования к управлению сайтом и попросить исполнителя обосновать выбор.
Что в ТЗ важно учесть для сайта в Казахстане?
Языковые версии, требования закона о персональных данных (согласие на обработку и хранение баз с данными граждан РК на территории страны), способы оплаты и доставки, которыми пользуются ваши клиенты, и интеграцию с мессенджерами, через которые они привыкли писать.