Фраза «нужен современный сайт с удобной админкой» выглядит понятной, пока работа не дошла до согласования. Один человек ждёт пять страниц, другой рассчитывает на каталог. Заказчик представляет редактирование каждого блока, разработчик предусмотрел замену заголовков. Техническое задание нужно, чтобы такие расхождения появились до разработки.
Хорошее ТЗ позволяет ответить на вопрос «как мы проверим, что это сделано». Если проверить пункт невозможно, договорённость пока слишком расплывчатая.
Начните с результата для бизнеса
Опишите, кто пользуется сайтом и зачем. Например, производственная компания получает запросы на изготовление деталей. Покупатель должен увидеть подходящие материалы, приложить чертёж и отправить запрос. Менеджер должен получить контакт, файл и адрес страницы, с которой пришёл человек.
Это уже даёт основу для страниц и функций. Команда может обсудить, нужны ли фильтры, какие файлы принимать и где хранить обращения. Формулировка «сайт для повышения продаж» такой разговор не заменяет: в ней нет конкретного действия, за которое отвечает разработка.
Перечислите страницы и их различия
Составьте карту: главная, направления, отдельная услуга, проекты, статья, контакты. Укажите, какие страницы собираются из одного шаблона, а какие требуют отдельной структуры. Разница между двадцатью страницами одного типа и двадцатью индивидуальными макетами заметно влияет на объём работ.
Для каждого типа запишите обязательные сведения. Услуге могут понадобиться состав работ, ограничения, примеры и форма расчёта. Проекту: задача, роль компании и реальные изображения. Не требуется заранее согласовывать каждое слово, но источник текстов и ответственность за заполнение должны быть понятны.
Описывайте функции через сценарии
Возьмём форму запроса. Вместо «форма с загрузкой файла» укажите последовательность: человек заполняет контакт, прикладывает разрешённый файл и отправляет данные. Сервер проверяет поля, сохраняет обращение и передаёт уведомление менеджеру. Посетитель видит подтверждение только после принятия данных.
| Неясный пункт | Проверяемая договорённость |
|---|---|
| Удобная админка | Менеджер меняет текст услуги, изображение и FAQ без правки кода |
| Быстрая форма | При ошибке поля данные сохраняются, а причина показана рядом |
| Заявки в CRM | Передаются согласованные поля и ссылка на исходную страницу |
| Адаптивность | Меню, форма и таблицы проверяются на согласованных устройствах |
Отдельно опишите неудачные ситуации: файл слишком большой, CRM недоступна, контакт не заполнен. Именно здесь часто остаются пробелы. Ошибка внешней системы не должна превращаться в тихую потерю обращения.
Решите, что редактируется после запуска
Перечислите поля, которыми будет пользоваться сотрудник: цены, услуги, проекты, изображения, метаданные, контакты. Если порядок секций можно менять, скажите об этом прямо. Возможность поменять текст и возможность собрать новую страницу из блоков относятся к разным задачам.
Уточните права пользователей и порядок публикации. Кто может менять настройки отправки заявок? Кто отвечает за проверку статьи? Что происходит при удалении страницы? Даже небольшому сайту полезно отделить подготовку материала от изменения служебных доступов.
Зафиксируйте границы работ
В ТЗ нужны не только включённые функции. Запишите, кто приобретает домен, готовит фотографии, подключает сервисы и переносит старые материалы. Если расчёт зависит от внешнего API, обозначьте необходимые доступы и условия проверки. Неизвестную часть разумнее сначала исследовать, затем оценивать.
Приложите список проверок и договоритесь, где фиксируются изменения задания. Новая интеграция посреди проекта может быть полезной, но её влияние на сроки и стоимость должно обсуждаться отдельно. Для разработки кода и интеграций QuickLanding использует ставку 2 900 ₽/час, а объём согласуется по конкретной задаче.
Что подготовить к обсуждению
- Карту страниц и список обязательных функций.
- Пример обращения от посетителя до менеджера.
- Список полей для редактирования и нужных ролей.
- Доступные материалы, документы API и старые адреса.
- Проверки, после которых работа считается принятой.
Документация и проверка сведений
Технические сведения сверены с документацией на 7 октября 2026 года. При настройке конкретного сервиса проверьте его текущую версию и действующие инструкции.
Материалы по соседним задачам
Коротко о важном
Нужно ли писать большое ТЗ для небольшого сайта?
Размер документа зависит от сложности. Для простого сайта достаточно согласованной карты страниц, списка функций, требований к редактированию и проверок. Важна определённость договорённостей, а не количество листов.
Можно ли составить ТЗ вместе с разработчиком?
Да. Заказчик описывает процесс и ограничения бизнеса, разработчик помогает перевести их в страницы, поля и сценарии. Перед началом работ обе стороны подтверждают итоговую версию.
Что делать, если требования пока меняются?
Выделите известную часть и вопросы для исследования. Не обещайте точную оценку неизвестной интеграции. Сначала проверьте доступы и документацию, затем включайте уточнённый объём в задание.
Разработка и SEO в QuickLanding. Помогаем разобраться в задаче и выбрать подходящий состав работ.
Об эксперте
