Техническое задание на разработку сайта: образец и шаблон для скачивания

«Нужен современный сайт с удобной формой» — хорошее начало разговора, но для разработки нужны подробности. Вы можете ждать, что форма создаст сделку в CRM и назначит менеджера, а разработчик — просто настроить отправку письма. Пока вы не обсудили это, каждый понимает заказ по-своему.

В техническом задании записывают, что именно нужно сделать: какие страницы создать, чем их наполнить, какие функции подключить и как проверить готовый сайт. Для простого сайта хватит короткого документа; сложные процессы нужно описать подробнее.

Скачать шаблон технического задания на сайт — DOCX. Файл можно редактировать в Word или другом совместимом редакторе. Внутри — поля для заполнения, таблицы страниц и проверок, разделы об интеграциях, запуске и передаче. Регистрация не нужна. Ниже есть заполненный учебный фрагмент, чтобы было понятно, как пользоваться шаблоном.

Когда писать ТЗ и кто должен его подготовить

Сначала решите, для чего нужен сайт. Кто на него придёт, что будет искать и как обратится к вам? Если вы ещё выбираете между каталогом и обычными страницами услуг, рано писать подробное задание на разработку.

Начать можно с брифа — короткого описания бизнеса, клиентов, материалов и пожеланий. После разговора с разработчиком станет понятнее, какие нужны страницы и функции. Эти решения и попадут в ТЗ, по которому вы будете заказывать и принимать работу.

Вам не нужно разбираться в сервере или программном интерфейсе CRM. Расскажите, как работает бизнес, какие данные есть и кто будет общаться с разработчиком. Техническое решение предложит исполнитель. Если нужно связать сайт с другой системой, пригласите к разговору человека, который с ней работает.

Подробное ТЗ — тоже работа. Спросите, входит ли его подготовка в стоимость сайта. Если документ написал другой специалист, покажите его будущему разработчику до начала работ: возможно, некоторые требования придётся уточнить.

Какие разделы нужны в техническом задании

Удалите из шаблона то, что вашему сайту не нужно. Но по каждой обязательной функции должно быть понятно, что сделать и как это проверить.

Раздел	Что записать	Зачем это нужно
Задача и ограничения	Для кого сайт, какое действие нужно, что входит в первую версию	Чем закончится проект и что пока не разрабатывают
Страницы	Перечень, разные шаблоны, количество материалов	Сколько именно нужно спроектировать и наполнить
Содержание	Источники текстов, фото, цен, ответственные и сроки	Кто готовит и размещает материалы
Функции	Действия пользователя, данные, ответы системы, ошибки	Что скрывается за словами «форма», «каталог», «запись»
Подключения	Сервисы, передаваемые поля, тарифы и доступы	Где заканчивается сайт и начинается внешняя система
Дизайн и использование	Макеты, типовые экраны, мобильные сценарии, редактирование	Что утверждают визуально и что владелец сможет менять
Качество и запуск	Проверки, адреса, HTTPS, SEO-настройки, перенос	При каких условиях сайт можно выпускать
Передача и приёмка	Аккаунты, файлы, инструкция, замечания, ответственные	Как проверить результат и продолжить работу после сдачи

Проверьте, что договор, смета и ТЗ описывают один и тот же сайт. Где-то должны быть записаны этапы, сроки, суммы, порядок оплаты и правила добавления новых задач. Повторять всё в каждом документе не нужно. Юридические условия договора обсудите отдельно.

Как описать страницы и наполнение

За словами «пять страниц» может скрываться разная работа. Нужно ли для каждой услуги писать текст и подбирать фотографии? Сколько будет разных шаблонов, а сколько страниц собирается по одному образцу? Укажите это в задании.

Например, у компании могут быть один шаблон услуги и восемь услуг, которые на нём размещаются. Разработка шаблона и подготовка восьми материалов — разная работа. Если к запуску размещаются только три услуги, а остальные добавит заказчик, это тоже нужно записать.

Для текстов, фотографий и данных каталога назначьте ответственных. Исполнитель пишет с нуля, редактирует ваши материалы или только загружает готовое? Кто проверяет цены, подписи и право использовать фотографии? Одна ссылка на общую папку этих вопросов не решает.

Если сайт уже есть, составьте список того, что нужно перенести: страницы, товары, статьи, изображения. Какие адреса сохранятся, а какие изменятся? Кто составит список перенаправлений? За словами «перенести сайт» не должно остаться неучтённой работы.

Проверить список нужных материалов поможет гайд по вашей сфере. Например, для строительной компании нужно выбрать объекты, подготовить фотографии и описания работ. Шаблон помогает ничего не забыть, а наполняете вы его сведениями о своём бизнесе.

Как превратить пожелание в проверяемое требование

Опишите, что делает человек и что должно произойти в ответ. Тогда вы сможете открыть готовый сайт и проверить, работает ли функция так, как договорились.

Пожелание	Что уточнить в ТЗ
«Удобная форма заявки»	Где открывается, какие поля есть, что обязательно, куда передаются данные, как показаны успех и ошибка
«Каталог с фильтрами»	По каким свойствам фильтруют, можно ли сочетать условия, что показывают при отсутствии результатов
«Можно менять сайт самому»	Какие поля и страницы меняет владелец, может ли добавить новый материал, как публикуется изменение
«Сайт хорошо работает на телефоне»	Какие действия проверяют на согласованных устройствах и браузерах, что происходит с меню, формой и таблицами
«Быстро загружается»	На каких страницах, в каких условиях и каким способом измеряют; какие внешние сервисы участвуют

Опишите и ошибки формы. Что увидит посетитель, если оставит обязательное поле пустым? Сохранится ли текст при сбое отправки? Когда появится сообщение об успехе? Эти детали нужны не меньше, чем оформление кнопки.

С требованием «быстрый сайт» нужны подробности. Даже «100 баллов в PageSpeed на любом устройстве» не объясняет, что и в каких условиях проверять. У Google есть Core Web Vitals — показатели загрузки, отклика и стабильности страницы. Договоритесь о страницах и условиях теста. Замеры до запуска и данные реальных посетителей — разные вещи.

Образец фрагмента ТЗ для сайта услуг

Возьмём условную компанию по обслуживанию вентиляции. Она работает с организациями и получает запросы на расчёт. В первый сайт не нужны магазин, личный кабинет и автоматический расчёт цены.

Задача. Посетитель узнаёт, какие системы обслуживает компания, знакомится с условиями и отправляет запрос. Дальше с ним общается менеджер и обсуждает договор.

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

Материалы. Заказчик даёт фотографии, перечень работ, реквизиты и условия. Исполнитель пишет главную и две страницы услуг по интервью и материалам компании. Описания проектов редактирует и перед размещением показывает заказчику.

Теперь запишем, как всё должно работать:

Код	Требование	Как проверить
F01	Кнопка на каждой услуге открывает форму с названием этой услуги	Открыть обе страницы; название в форме соответствует странице
F02	В форме обязательны имя и телефон; комментарий необязателен	Пустая форма показывает подсказки, заполненная допускает отправку
F03	Обращение содержит услугу, имя, телефон, комментарий и страницу отправки	Сверить согласованную тестовую запись у получателя с введёнными значениями
F04	При ошибке доставки форма не показывает успешную отправку	Разработчик воспроизводит согласованный тест ошибки и демонстрирует сообщение
C01	Ответственный может изменить текст услуги и номер телефона	Владелец выполняет изменение в своём аккаунте и проверяет опубликованную страницу
L01	Перед запуском готовые страницы размещены на домене компании с HTTPS	Открыть все пять адресов и проверить защищённое подключение

Куда приходит заявка. Укажите способ доставки, адрес или аккаунт и получателя. Пароли в ТЗ не нужны. Если заявки должны попадать в CRM, дополните F03: в какую систему, что в ней создаётся, как заполняются поля и что происходит при повторном обращении.

Что не входит. Съёмка объектов, проекты сверх трёх, CRM, оплата и дальнейшее продвижение. До запуска формы также нужно решить, кто проверит работу с данными и подготовит документы.

Приёмка. Требования F01–L01 проверяют по таблице. Замечания записывают, после исправления проверяют ещё раз. Ответственный от компании разрешает запуск. Сроки исправлений и поддержку обсуждают отдельно.

По такому описанию разработчик уже может оценить работу. Для магазина или бронирования его нужно переделать: там будут другие действия, данные и проверки.

Интеграции лучше проверить на образце до большой разработки

Если сайт будет получать данные из другой системы, попросите пример выгрузки или документацию. Разработчик сможет сопоставить поля и проверить одну загрузку до того, как вы потратите деньги на весь проект.

В проекте «Риэлт-Лидер» выгрузку CRM в XML пришлось преобразовывать для каталога Tilda. Последний шаг — загрузка готового файла на сайт — остался ручным. Поэтому в ТЗ стоит описать весь процесс: откуда брать данные, как часто обновлять и что делать сотруднику.

Договоритесь, кто даст разработчику доступ для теста и подготовит пример данных. Не используйте в общем шаблоне пароли и реальные обращения клиентов.

Как согласовывать изменения без бесконечного переписывания

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

Если вместо писем понадобились сделки в CRM, запишите, что меняется. Разработчик оценит новые поля, подключения, проверки, цену и срок. А если уже заказанная функция F03 не работает, речь об исправлении ошибки, не о новом заказе.

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

Как пользоваться скачиваемым шаблоном

Сохраните DOCX-шаблон, опишите задачу и нужные страницы, затем обсудите функции с исполнителем. Подсказки в квадратных скобках замените ответами. Строки таблиц можно добавлять, лишние разделы — удалять.

Перед утверждением проверьте три вещи: как проверять функции, кто и когда готовит материалы, что нужно для подключения сервисов. Вопросы без ответа выпишите отдельно и обсудите с разработчиком.

Если пока трудно составить список работ, посмотрите, что входит в сайт под ключ. Или расскажите мне о задаче — обсудим будущий сайт. ТЗ сохраните до сдачи: оно пригодится, когда будете принимать готовую работу.