Как составить техническое задание на разработку сайта

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

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

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

Чем ТЗ отличается от брифа и структуры

Эти материалы отвечают на разные вопросы, хотя могут находиться в одном документе.

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

Такое обсуждение даёт исходные данные, но не готовое ТЗ. Ответ «хотим сами добавлять проекты» ещё нужно превратить в описание редактирования: какие поля доступны, как сохранить черновик и проверить публикацию.

Карту страниц удобно подготовить до подробных требований: тогда понятно, к какой странице относится каждая функция.

Что включить в техническое задание

Для небольшого сайта предлагаем такую рабочую основу:

1. Цель и границы. Для кого сайт, какое действие нужно, что входит в первую версию и что отложено.
2. Страницы и содержание. Карта, задача каждой страницы, тексты, фотографии и связи.
3. Функции. Действия посетителя и владельца, ожидаемый результат, обработка ошибок.
4. Интерфейс. Согласованные макеты, поведение на телефоне, состояния меню и форм.
5. Материалы и ответственность. Что предоставляет заказчик, что готовит исполнитель, кто подтверждает сведения.
6. Проверка. Тестовый адрес, устройства и браузеры, исходные данные, признаки выполнения.
7. Передача. Что получает владелец, как меняет содержание и продолжает работу с сайтом.
8. Открытые решения и изменения. Что ещё не определено, кто решает, как фиксируется новая версия.

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

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

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

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

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

Ещё один вид требования — зависимость опций. В расчёте «Послушных рольставней» ручное открывание доступно только вместе с электроприводом. Для подобного выбора в ТЗ нужно описать допустимые сочетания и результат отключения основной опции.

Заполненный пример ТЗ для сайта мастерской

Следующие пункты — связанный учебный фрагмент для адаптации. Здесь выбран сайт без онлайн-оплаты, личного кабинета и автоматического расчёта окончательной стоимости. Форма собирает запрос на обсуждение. Ниже описаны требования к предполагаемому результату; работоспособность реализации ещё не проверялась.

Исходные данные и состав

Цель: посетитель выбирает направление, смотрит примеры работ и отправляет запрос, связанный с выбранным проектом. Владелец добавляет новые работы через редактор.

Страницы: главная; направления «Кухни» и «Шкафы»; общий список проектов; страница каждого проекта; «Как заказать»; «Контакты».

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

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

С-01. Переходы между направлением и проектом

На странице «Кухни» показывается демонстрационный проект кухни. Его карточка открывает отдельную страницу с названием, фотографиями, описанием и кнопкой «Обсудить похожий проект». Из проекта доступен переход обратно к направлению «Кухни». В общем списке показаны кухня и шкаф; они открывают те же страницы проектов.

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

Ф-01. Запрос из проекта

Кнопка «Обсудить похожий проект» открывает форму. В ней видны название выбранного проекта, обязательное поле телефона и необязательный комментарий. Название проекта нельзя изменить в форме. Для телефона допускаются цифры, пробелы, круглые скобки, знак «+» и дефис; значение без цифр считается незаполненным. Такая проверка не подтверждает существование номера.

При отправке с пустым телефоном рядом с полем появляется сообщение «Укажите телефон для связи», запрос не создаётся. Комментарий сохраняется. При успешной отправке появляется сообщение «Запрос отправлен».

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

Ф-02. Получение запроса и ошибка отправки

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

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

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

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

Р-01. Добавление проекта владельцем

В редакторе владелец создаёт карточку с названием, направлением «Кухни» или «Шкафы», описанием и фотографиями. Можно сохранить черновик, вернуться к нему и опубликовать. Черновик не показывается посетителям ни в списках, ни при открытии его адреса без входа в редактор. При публикации карточка появляется в общем списке и выбранном направлении.

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

И-01. Проверка на телефоне

Для учебной приёмки выбраны размеры области просмотра 390 × 844 и 1440 × 900 пикселей. На этих размерах проверяются главная, направление, список и страница проекта, контакты и форма с описанными состояниями. Текст и поля не обрезаются, горизонтальная прокрутка всей страницы не требуется, меню открывается, переходы и кнопка отправки доступны.

Проверка: пройти С-01 и Ф-01 на обоих размерах. Отдельно повторить отправку на доступном телефоне; название устройства, операционной системы и версию браузера записать в протокол. Этот набор не доказывает работу на всех устройствах. Список устройств и браузеров для своего проекта согласуйте до приёмки; без него этот раздел ещё не готов для реального ТЗ.

П-01. Передача результата

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

Проверка: заказчик входит под своей учётной записью и выполняет Р-01 по инструкции. Исполнитель показывает, где находятся файлы, настройки и резервная копия, и объясняет порядок восстановления. Если нужны внешние сервисы, их перечень, плательщика и условия использования согласуют отдельно.

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

Что делать с неопределёнными требованиями

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

Например, пока не выбрано место получения обращений, нельзя считать Ф-02 готовым для реального проекта. Сначала определите получателя и систему, затем опишите успешную отправку и отказ. Учебное решение с закрытым списком не нужно автоматически переносить в свой сайт.

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

Как использовать ТЗ при проверке сайта

Свяжите каждый важный пункт с проверкой. В замечании указывайте номер требования, страницу, действия, ожидаемый и фактический результат. Например: «Р-01: после публикации шкафа карточка есть в общем списке, но отсутствует в направлении “Шкафы”».

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

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