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

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

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

Бриф, ТЗ и договор: в чём разница

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

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

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

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

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

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

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

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

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

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

Страницы и макеты считайте отдельно

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

Обратная ситуация — одна страница с калькулятором. Адрес один, а состояний много: начальное, заполненное, ошибка, расчёт и отсутствие результата. Поэтому запись «сайт из одной страницы» ещё не определяет стоимость.

Контент тоже входит в требования

Для каждого типа страницы укажите поля и правила: заголовок, описание, цена, фотографии, связанные услуги. Затем — кто готовит и загружает материалы и в каком объёме.

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

Фраза «добавить форму» не объясняет, какие поля обязательны, где сохраняется обращение и что увидит посетитель при ошибке. Чтобы грамотно составить ТЗ, используйте короткую карточку требования.

Схема: идентификатор → задача пользователя → условия → действие → результат → исключения → проверка.

Для интеграций важны исключения

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

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

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

Проверяйте результат, а не только нажатие

«Кнопка работает» — слабый критерий. Посетитель может увидеть сообщение об успехе, хотя обращение нигде не сохранилось.

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

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

Зафиксируйте:

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

Как использовать референсы

Ссылка «хотим примерно так» оставляет слишком много трактовок. Лучше подписать, что именно подходит: читаемая таблица тарифов, способ сравнения услуг или последовательность блоков.

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

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

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

Платформа, браузеры и управление

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

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

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

Что включить в SEO-подготовку

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

Правила обхода, запрет индексации и защита закрытых данных — разные задачи. В частности, robots.txt не служит механизмом защиты информации и не гарантирует исключения URL из Google. Различия объясняют Google Search Central и справка Яндекс.Вебмастера о robots.txt.

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

Аналитика: событие должно соответствовать действию

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

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

Разберём вымышленный проект «Точная мера» — сайт компании, которая обслуживает измерительное оборудование. Это учебный образец, а не кейс SMA, готовая смета или полный комплект документации для запуска.

1. Паспорт и задача проекта

Версия: 0.1, для обсуждения. Язык: русский. Формат: многостраничный сайт услуг.

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

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

2. Структура и объём

Техническая страница 404 описывается дополнительно и не включена в эти 14 содержательных страниц. Состояния меню и формы также перечисляются отдельно. Количество контрольных макетов для адаптации нужно утвердить после выбора правил поведения интерфейса.

3. Содержание страницы услуги

REQ-01. Страница содержит название, описание задачи, состав работ, ограничения, порядок расчёта, связанные проекты и форму. Редактор меняет эти поля через CMS без изменения кода.

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

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

4. Форма обращения

REQ-02. Форма доступна на главной и страницах услуг. Поля: телефон — обязательное, имя — необязательное, комментарий — необязательное, до 1 000 символов. Правила допустимого номера и сообщения об ошибках фиксируются перед реализацией. Загрузка файлов отсутствует.

REQ-03. Сервер проверяет данные. Невалидная форма не создаёт обращение и показывает ошибку рядом с соответствующим полем. Введённые данные сохраняются в форме для исправления.

REQ-04. Успешная отправка означает сохранение обращения в защищённом разделе системы. Сохраняются поля формы, время, идентификатор обращения и адрес страницы. После подтверждения сохранения пользователь видит: «Обращение принято». Пока идёт отправка, повторное нажатие блокируется. Правило защиты от повторной записи при сетевых повторах уточняет разработчик.

REQ-05. После сохранения система отправляет уведомление на согласованный адрес менеджера. Ошибка уведомления не удаляет обращение. Администратору доступен его статус; способ уведомления о сбое и повторной отправки нужно определить до утверждения ТЗ.

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

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

5. Проверка формы и аналитики

REQ-07. В согласованную систему аналитики передаётся событие `request_saved` после подтверждённого сохранения обращения. Повторное нажатие во время одного запроса не создаёт второе событие. Успех CRM не проверяется: подключения к ней в первом запуске нет.

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

6. Что ещё нужно решить

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

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

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

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

Разделяйте стоимость подготовки требований, разработки и дальнейшего сопровождения. Условия зависят от проекта; нельзя автоматически считать ТЗ бесплатным или включённым в любой пакет.

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

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

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

Какие данные отправить в SMA

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

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

Подмена требований прилагательными. «Удобный», «современный» и «быстрый» требуют пояснений: сценариев, примеров и условий проверки.

Копирование чужого образца целиком. Чужие роли, объёмы и интеграции превращаются в лишние работы или противоречат вашему процессу.

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

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

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

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

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