Что должно быть в техническом задании на корпоративный сайт

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

С чего начинается техническое задание

Начните с ситуации бизнеса: чем Вы занимаетесь, кому продаёте, что есть сейчас и какую задачу должен решить сайт. Если уже работает старая версия, перечислите, что в ней полезно, а что мешает посетителям или сотрудникам. Это поможет сохранить нужное и оценить объём переделки.

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

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

Фраза «нужен современный сайт» не помогает оценке. Лучше написать: посетитель должен найти подходящую услугу, понять условия работы и отправить обращение с телефона; сотрудник должен получить это обращение и связаться с клиентом. За таким описанием уже видны страницы, содержание и проверки.

Как описать посетителей и их действия

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

Рабочая запись состоит из трёх частей: кто посетитель, что он хочет сделать и зачем. Такой подход используется в GOV.UK Service Manual при описании пользовательских задач. Там же критерии приёмки определяются как проверяемые результаты, подтверждающие, что потребность пользователя выполнена. Это метод описания работы, а не обязательный стандарт для любого корпоративного сайта.

Разберём условный пример требования. «Представитель компании хочет найти условия обслуживания оборудования, чтобы понять, подходит ли услуга для его объекта». Для этого ему понадобятся виды оборудования, территория работы, ограничения и способ уточнить задачу. Фотография офиса и общий текст о преимуществах этих ответов не дадут.

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

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

Как составить карту страниц

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

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

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

Кроме списка адресов покажите навигацию: что доступно из меню, как страницы услуг связаны с примерами работ и как посетитель возвращается к выбору. Для повторяющихся страниц опишите общий шаблон и отдельно перечислите различия. Это точнее, чем поручить подрядчику «сделать остальные по аналогии».

Что подготовить для текста и оформления

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

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

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

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

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

Как описать формы и интеграции

Для каждой формы запишите, какие сведения нужны, куда они отправляются и как посетитель понимает результат. Укажите обязательные поля, допустимые форматы, получателя обращения и действия при ошибке. Кнопка «Отправить» сама по себе ещё не подтверждает, что сотрудник получил заявку.

Пример проверяемого требования: человек заполняет контакт и описание задачи; после успешной отправки видит подтверждение, а ответственному приходит сообщение с этими полями и названием услуги. Если доставка не состоялась, форма сообщает о проблеме и предлагает доступный способ связи. Это условный пример, который нужно адаптировать к реальному маршруту заявок.

В руководстве W3C WAI по сообщениям форм рекомендуется давать обратную связь при успешной и неуспешной отправке, а ошибки объяснять кратко и понятно, с указанием способа исправления. В ТЗ можно закрепить эти состояния и затем проверить их на готовой странице.

Если нужен обмен с CRM, почтой или другой системой, выясните следующие детали:

• какая система принимает данные и есть ли у неё подходящий способ подключения
• кто предоставляет и проверяет доступ
• какие поля передаются и как они сопоставляются
• как распознаётся повторная отправка
• что происходит, когда принимающая система временно недоступна
• по каким тестовым обращениям подтверждается работа обмена

До подтверждения доступа и возможностей внешней системы интеграцию стоит отметить как зависимость, которую ещё нужно проверить. Фраза «подключить CRM» не раскрывает ни объём работы, ни условия её завершения. Для обсуждения используйте обезличенные примеры заявок; пароли и ключи доступа передают по отдельному защищённому каналу.

Какие требования к качеству записать

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

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

В требования к поисковому оформлению включите уникальные заголовки страниц и описания, понятные адреса, корректные canonical, состав sitemap и правила индексирования. Укажите, кто пишет эти тексты и как проверяет их соответствие содержанию. Эти настройки помогают поисковым системам читать сайт, но не являются обещанием определённых позиций.

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

Для безопасности в документе достаточно закрепить ожидаемые результаты: HTTPS работает, служебные файлы закрыты, административные действия защищены, секреты не попадают в публичную часть. Технический способ исполнения выбирает разработчик с учётом проекта. Спорные или повышенные требования лучше обсудить до выбора платформы.

Что предусмотреть для публикации и работы сайта

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

При замене старого сайта соберите список существующих адресов и определите судьбу каждой страницы. Там, где адрес меняется, нужна связь со страницей, которая её заменяет. В документации Google Search Central о переносе сайта подготовка соответствия старых и новых URL и настройка перенаправлений входят в порядок переезда. Эту работу полезно включить в ТЗ заранее, если меняются адреса.

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

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

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

Как договориться о приёмке и изменениях

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

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

ТЗ готово к оценке, когда нет неизвестных, которые существенно меняют проект, либо эти неизвестные вынесены на отдельное исследование. Список открытых вопросов тоже полезен: кто пишет тексты, какие доступы готовы, кто проверяет сведения, нужна ли миграция. У каждого вопроса должен быть ответственный.

Расскажите, какой сайт нужен Вашему бизнесу

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

Частые вопросы

Кто должен писать техническое задание

Владелец бизнеса даёт сведения о задаче, клиентах и работе сотрудников. Подрядчик уточняет структуру, технические зависимости и проверки. Итоговый документ согласуют обе стороны.

Можно ли получить оценку без готового ТЗ

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

Нужны ли в ТЗ названия технологий

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

Как поступить, если тексты ещё не готовы

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

Как сравнивать предложения разных подрядчиков

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

Нужно ли обновлять ТЗ во время разработки

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