Техническое задание на корпоративный сайт должно отвечать на практический вопрос: что именно получит компания и как стороны поймут, что работа завершена. Перечня «главная, услуги, контакты» для этого недостаточно. В документе нужны пользовательские сценарии, состав контента, правила редактирования, интеграции и проверяемые критерии приёмки. Такой подход помогает сравнивать предложения подрядчиков по одинаковому объёму.
Начните с задач клиента и бизнеса
Опишите, кто приходит на сайт и с каким вопросом. Например, закупщик ищет характеристики оборудования, руководитель сравнивает подрядчиков, а действующий клиент хочет скачать документ. Для каждого сценария определите следующее действие: отправить параметры задачи, выбрать услугу, получить консультацию. Формулировка «сайт должен продавать» не объясняет, какие возможности нужно разработать.
Разделите основную задачу запуска и последующее развитие. Личный кабинет, онлайн-оплата и сложный калькулятор имеют разный объём работ, даже если на макете занимают по одной кнопке. Отдельно обозначьте ограничения: доступность исходных данных, сроки согласования, используемые системы и сотрудников, которые будут поддерживать информацию.
Зафиксируйте страницы и повторяемые сущности
Составьте карту разделов и перечислите типы материалов. Услуга, кейс, статья и товар отличаются полями и связями. Если проектов двадцать, обычно нужен один управляемый шаблон кейса, а не двадцать независимо запрограммированных страниц. В ТЗ укажите, что редактор может добавлять сам и какие изменения требуют разработчика.
| Сущность | Редактируемое содержание | Связи |
|---|---|---|
| Услуга | Задача, состав работ, этапы, условия, вопросы | Подходящие кейсы и статьи |
| Кейс | Клиент, задача, решения, изображения, подтверждённый результат | Услуга и следующий проект |
| Статья | Текст, обложка, тема, автор, дата | Материалы по теме и услуга |
| Контакты | Адрес, телефоны, часы работы, способы связи | Филиал и форма обращения |
Опишите редактор на примере одного экрана: сотрудник раскрывает именованный блок, меняет заголовок, текст и изображение, сохраняет страницу. Уточните возможность скрывать и переставлять блоки. Проверьте, как новая запись попадёт в список, какие поля обязательны и что произойдёт без обложки. Удобство админки тоже является результатом разработки.
Назначьте ответственных за материалы
Для каждого раздела укажите источник текста, фотографий, характеристик и документов. Зафиксируйте, кто пишет, проверяет факты и утверждает финальную версию. Если контент переносится со старого сайта, определите его объём заранее. Дизайн на коротких демонстрационных фразах может вести себя иначе с настоящими названиями услуг и длинными таблицами.
В качестве визуального ориентира можно рассмотреть кейс Carrot, а затем выписать конкретные подходящие элементы: расположение формы, подачу информации, сценарий обращения. Референс полезен, когда понятно, что именно в нём нужно изучить. Фраза «сделать как у них» оставляет слишком много трактовок и не определяет функциональность вашего проекта.
Опишите интеграции через движение данных
Для каждой формы или обмена укажите источник данных, получателя, обязательные поля и поведение при ошибке. «Подключить CRM» недостаточно: нужно знать, в какую сущность попадает обращение, как назначается ответственный и что происходит при повторной отправке. Аналогично описывают импорт каталога, обновление цен и связь с сервисом записи.
- Какие данные пользователь вводит и какие передаются автоматически.
- Где сотрудник увидит обращение и как отличит его от тестового.
- Как показывается ошибка и можно ли повторить действие без потери заполненного.
- Кто предоставляет доступы и проверяет результат со стороны внешней системы.
Сделайте требования к качеству измеримыми
Укажите контрольные размеры экранов, браузеры и важные сценарии. Вместо «хорошая адаптивность» запишите: меню открывается с клавиатуры, длинный заголовок не перекрывает кнопку, таблица читается на телефоне. Для форм нужны связанные с полями подписи: это помогает понять назначение элемента и пользоваться вспомогательными технологиями, как объясняет руководство W3C по подписям элементов форм.
SEO-требования включите до вёрстки: управление метаданными, понятную структуру заголовков, внутренние ссылки, адреса страниц и правила переноса старого сайта. Базовые принципы доступности контента для поиска приведены в руководстве Google по поисковой оптимизации. Обещание определённых позиций не является техническим критерием готовности сайта.
Согласуйте приёмку и передачу
Приложите сценарии проверки: редактор создаёт кейс, посетитель находит его в портфолио, отправляет форму, менеджер получает корректные данные. Зафиксируйте передачу исходников, доступов, инструкций и условий поддержки. Отдельно определите, как согласуются новые пожелания после утверждения задания: так изменение задачи не потеряется среди исправлений ошибок.
Хорошее ТЗ можно проверить на конкретных примерах. Если по пункту нельзя показать результат или воспроизвести действие, формулировку стоит уточнить. На странице разработки сайтов DENKOV IT можно посмотреть состав направления, а для обсуждения проекта достаточно подготовить задачи бизнеса, текущий сайт и перечень нужных интеграций.