Фраза «на сайте должна быть форма заявки» оставляет слишком много вопросов. Какие поля в ней нужны? Куда попадёт заявка? Что увидит посетитель, если CRM недоступна? Должен ли менеджер получать уведомление? На эти вопросы можно ответить уже во время разработки, но тогда меняются объём работы, оценка и ожидания сторон.
Техническое задание на сайт фиксирует согласованный результат: что входит в проект, как сайт ведёт себя в важных сценариях, какие данные использует и по каким признакам можно проверить выполнение требований. Полезность ТЗ определяется тем, помогает ли оно принимать решения и проверять результат. Количество страниц документа само по себе ничего не решает.
Ниже — структура такого задания и связный учебный пример для сайта сервисной компании. Это пример формулировок, а не универсальный документ, который можно подписать, заменив название организации.
Начните с задачи бизнеса и границ проекта
Пожелание «увеличить продажи» объясняет интерес бизнеса к сайту, но не задаёт проверяемый объём разработки. Продажи зависят также от предложения, рекламы и работы менеджеров. Для ТЗ нужно определить, какую часть задачи решает сам сайт: например, позволяет выбрать услугу, оставить контакт и передаёт менеджеру сведения, необходимые для первого разговора.
Дальше свяжите три вещи: почему требуется изменение → что должен делать сайт → как проверить это поведение. В разделе System Design Processes руководства NASA Systems Engineering Handbook требования выводятся из ожиданий заинтересованных сторон, а критерии проверки сверяются с этими ожиданиями. Здесь используется сам инженерный принцип; масштабы и процедуры космических проектов переносить в веб-разработку не требуется.
Границы удобно описать на одном листе: что создаётся, какие существующие системы используются, кто готовит входные материалы и какие функции отложены. Например, «сайт принимает запрос на обслуживание» ещё не означает, что он рассчитывает смету, назначает выезд специалиста или принимает оплату.
Для разработки сайта под ключ особенно важно раскрыть состав результата. Укажите, включены ли подготовка текстов, наполнение страниц, подключение внешних сервисов, перенос существующих данных и обучение сотрудников. Название услуги не заменяет это описание.
Что включить в техническое задание
Разделы можно объединять или делить, если документ остаётся понятным. Для небольшого сайта хватит компактного задания с приложениями; для сложного проекта отдельные описания интеграций и данных помогут избежать противоречий.
Страницы, шаблоны и сценарии
Разделите количество страниц и количество шаблонов. Десять услуг могут использовать один шаблон, но для каждой всё равно нужны текст, изображения, адрес страницы и параметры. Укажите, кто предоставляет эти материалы и кто их размещает.
Для каждого важного сценария опишите вход и результат: откуда приходит посетитель, что выбирает, какие действия выполняет и что получает. Добавьте существенные альтернативы: пустой каталог, неопубликованная услуга, неверные данные формы, временный отказ внешнего сервиса. Карта страниц без сценариев не описывает поведение сайта.
Дизайн можно вынести в приложение со ссылкой на конкретную согласованную версию макета. В ТЗ останутся требования к состояниям и адаптивному поведению: что происходит с меню, формой и таблицами на небольшом экране. Формулировку «как на макете» нужно связать с определёнными экранами и состояниями, иначе стороны могут иметь в виду разные версии.
Данные и управление ими
Для каждой сущности — услуги, товара, новости, заявки — перечислите поля, обязательность и правила заполнения. Отдельно определите источник данных: редактор вводит их вручную, подрядчик переносит из файла или сайт получает их из внешней системы.
Здесь же нужны правила изменения: кто может редактировать и публиковать запись, что считается черновиком, что происходит после удаления или снятия с публикации. Если данные хранятся в нескольких системах, назовите основную. Иначе изменение телефона клиента в CRM может неожиданно расходиться с записью на сайте.
Для сведений о клиентах согласуйте необходимый состав, права доступа и срок хранения. Пароли, ключи доступа и реальные клиентские базы передавайте через предусмотренные для этого защищённые каналы, а не помещайте в общедоступное приложение к ТЗ. Правовые основания обработки данных и необходимые тексты следует согласовать отдельно с ответственным за этот вопрос; техническое описание полей их не устанавливает.
Интеграции и внешние зависимости
«Подключить CRM» — это название работы. Для оценки и проверки нужен её результат: какие данные отправляются, какая запись создаётся, что считается подтверждением, кто предоставляет доступ и что происходит при отказе.
Попросите разработчика зафиксировать контракт обмена: поля и их соответствие, обязательность, возможные ответы, ошибки и ограничения выбранного сервиса. Например, в спецификации OpenAPI описание операции охватывает успешный ответ и известные ошибки. Владелец бизнеса не обязан писать такую спецификацию, но должен понимать, какую операцию выполняет интеграция и как команда узнаёт о её результате.
Особенно важен случай, когда запрос ушёл, а ответ не пришёл. Это ещё не доказывает, что внешняя система ничего не сохранила. В ТЗ требуется правило повторной отправки и поиска уже созданной записи. Способ зависит от API конкретного сервиса: нельзя обещать отсутствие дублей, не проверив доступные механизмы.
Условия качества и проверки
Слова «быстрый», «удобный», «безопасный» требуют уточнения. Для скорости нужны измеряемый показатель и условия: страница, устройство, сеть, объём данных и метод измерения. Для удобства — конкретный сценарий и наблюдаемое поведение. Для доступа — роли и операции, разрешённые каждой из них.
Рядом с требованием запишите способ проверки. Иногда достаточно осмотра, иногда нужен сценарий в браузере, сравнение данных или испытание отказа сервиса. Инженерный ориентир — однозначность, одна основная мысль в требовании и возможность подтвердить выполнение — есть в памятке NASA How to Write a Good Requirement.
Учебный пример: сайт компании по обслуживанию вентиляции
Представим вымышленную компанию, которая обслуживает вентиляцию в офисах. Менеджеру нужно понимать, какую услугу выбрал посетитель, и иметь контакт для обратного звонка. Сайт принимает запрос; стоимость и время выезда менеджер согласует после разговора.
В учебный проект входят главная страница, каталог, один шаблон страницы услуги, контакты, форма заявки на странице услуги и административный раздел. Для первоначального наполнения заказчик предоставляет три услуги. Онлайн-оплата, личный кабинет, календарь выездов и автоматический расчёт стоимости в эту версию не входят.
Заказчик передаёт согласованные тексты и фотографии, подтверждает состав услуг и назначает ответственного менеджера. Разработчик создаёт шаблоны, управление контентом, хранение заявок и интеграцию. Администратор CRM предоставляет описание API и доступ к тестовому контуру. Проверки ниже выполняются на синтетических данных без отправки реальным клиентам.
Для примера принято отдельное условие: выбранная CRM умеет создавать заявку с уникальным внешним идентификатором и находить запись по нему. Это условие вымышленного проекта, а не свойство любой CRM. Если у реального сервиса таких возможностей нет, порядок защиты от дублей придётся согласовать иначе.
Сначала определим состав данных
Минимальный набор данных нужен и для реализации, и для проверки. Ограничения в таблице выбраны только для этого учебного сценария.
| Данные | Правило в учебном ТЗ | Зачем фиксировать |
|---|---|---|
| Имя | Обязательно; после удаления пробелов по краям от 1 до 80 символов | Отличить введённое имя от пустой строки и ограничить размер поля |
| Телефон | Обязателен; принимаются российские номера с префиксом +7 или 8 и десятью цифрами после него; пробелы, скобки и дефисы допускаются | Определить допустимый ввод; при сохранении привести оба варианта к +7 и десяти цифрам |
| Комментарий | Необязателен; до 1000 символов | Разрешить уточнение без обязательного длинного описания |
| Услуга | Идентификатор существующей опубликованной услуги | Передать контекст обращения и отклонить неизвестную услугу |
| Название услуги | Копия названия на момент сохранения заявки | Сохранить смысл обращения, если услугу позднее переименуют |
| Идентификатор заявки | Неизменяемый уникальный идентификатор одной отправки | Связать запись сайта, попытки доставки и запись CRM |
| Время и состояние доставки | Время задаёт сервер; отдельно отмечаются ожидание, подтверждённая доставка и необходимость проверки | Различать принятую сайтом заявку и результат обмена с CRM |
Для проекта с международной аудиторией правило телефона будет другим. Даже такой небольшой пункт нужно выбирать под пользователей, а не копировать из чужого шаблона.
Требование 1. Заявка относится к выбранной услуге
Причина: менеджеру не нужно повторно выяснять, о какой странице идёт речь.
Формулировка: на странице опубликованной услуги форма показывает её название. При сохранении сайт связывает заявку с этой услугой и сохраняет название на момент обращения. Неизвестный идентификатор или идентификатор неопубликованной услуги отклоняется сервером; запись заявки не создаётся.
Проверка: отправить заявки со страниц двух разных услуг и сравнить сохранённые идентификаторы и названия. Затем повторить тестовый запрос с неизвестным идентификатором и с услугой в черновике: в обоих случаях форма сообщает об ошибке, новая заявка отсутствует. Такая проверка охватывает и обычный путь, и прямую отправку запроса в обход интерфейса.
Здесь важна связка страниц и данных. Требование «добавить поле “Услуга”» не сообщает, должен ли посетитель выбирать её сам, откуда берётся значение и можно ли передать произвольный идентификатор.
Требование 2. Ошибку формы можно исправить
Причина: посетитель должен понимать, почему заявка не принята, и продолжать заполнение.
Формулировка: сайт проверяет данные по согласованным правилам и в браузере, и на сервере. При пустом имени, недопустимом телефоне или превышении длины комментария он указывает соответствующее поле и выводит текстовое объяснение. Остальные введённые значения сохраняются в форме. До успешной проверки заявка не создаётся и в CRM не отправляется.
Проверка: поочерёдно отправить форму с именем из пробелов, телефоном с буквами и комментарием длиннее установленного ограничения. В каждом случае проверить сообщение у нужного поля и отсутствие заявки. Затем исправить только ошибочное поле: ранее введённые значения остаются, допустимая форма сохраняется. Дополнительно проверить нормализацию разрешённых вариантов телефона.
Текст ошибки — конкретный критерий. Например, «Введите имя» понятнее одной красной рамки. Требование идентифицировать ошибочное поле и описывать обнаруженную ошибку текстом предусмотрено критерием 3.3.1 стандарта WCAG 2.2. Это отдельное требование к форме; его выполнение само по себе не означает соответствие сайта всему стандарту.
Требование 3. Подтверждение означает сохранение заявки
Причина: посетитель и менеджер должны одинаково понимать, что уже произошло.
Формулировка: сообщение «Заявка сохранена» появляется только после успешного сохранения записи на стороне сайта. Доступность CRM не влияет на этот факт: доставка во внешнюю систему учитывается отдельно. При ошибке сохранения сайт сообщает «Не удалось сохранить заявку. Попробуйте ещё раз», оставляет введённые значения в форме и не показывает подтверждение успеха.
Повтором считаются те же данные с тем же идентификатором заявки. Если сайт уже сохранил запись, он возвращает её подтверждение и не создаёт вторую. Если с идентификатором уже принятой заявки пришли изменённые данные, сайт сообщает о конфликте отправки, не меняет прежнюю запись и не создаёт новую. Пока результат исходной отправки неизвестен, интерфейс позволяет повторить её без изменения полей. После подтверждения посетитель может выбрать «Создать новую заявку»: форма получает новый идентификатор. Совпадение телефона само по себе не делает новое обращение дублем.
Проверка: сначала выполнить обычную отправку и убедиться, что подтверждение связано с существующей записью. Затем имитировать отказ хранилища: записи и сообщения успеха нет, значения формы доступны для повтора. Отдельно воспроизвести потерю ответа после успешного сохранения и повторить ту же отправку: на сайте остаётся одна заявка. В тестовом запросе изменить телефон, сохранив идентификатор принятой заявки: получен ответ о конфликте, прежняя запись не изменена. После подтверждения создать новое обращение через предусмотренное действие: оно получает отдельную запись и идентификатор.
Такое условие точнее фразы «форма успешно отправляется». Оно определяет момент успеха и не выдаёт сохранение на сайте за подтверждённую доставку в CRM.
Требование 4. Доставка в CRM имеет понятные состояния
Причина: сохранённая заявка должна дойти до рабочего места менеджера, а сбой — стать заметным ответственному сотруднику.
Формулировка: сайт передаёт в согласованную CRM идентификатор заявки, имя, нормализованный телефон, комментарий, идентификатор и сохранённое название услуги. При штатной доступности обеих систем CRM подтверждает создание записи не позднее чем через 60 секунд после сохранения на сайте. Только после подтверждения сайт отмечает доставку.
При временном отказе предусмотрены первоначальная попытка и два автоматических повтора: через одну и через пять минут после первой попытки. Если через десять минут от сохранения доставка всё ещё не подтверждена, заявка получает состояние «Требует проверки». Ответственному менеджеру отправляется уведомление по электронной почте с идентификатором заявки и ссылкой в закрытый раздел; контакт посетителя в уведомление не включается. Эти интервалы — параметры учебного примера, не рекомендуемые нормативы для всех сайтов.
Если ответ CRM потерян, перед повторным созданием сайт проверяет запись по внешнему идентификатору. Обнаруженная запись считается результатом первоначальной операции. Диагностика хранит идентификатор заявки, время попытки и категорию ошибки без паролей и ключей доступа.
Проверка: в исправном тестовом контуре отправить заявку и сверить время, поля и идентификатор в обеих системах. Затем воспроизвести временный отказ и восстановление CRM до второго повтора: доставка подтверждается, создаётся одна запись. В отдельном сценарии CRM сохраняет запись, но её ответ теряется: повтор не создаёт дубль. При постоянном отказе проверить переход в «Требует проверки» и уведомление назначенного сотрудника.
Проверка последнего сценария не завершается словами «сервер вернул ошибку». Нужно увидеть, как бизнес узнает о проблеме и где найдёт сохранённую заявку. Для испытаний уведомления направляются в тестовый почтовый ящик.
Требование 5. Редактор контента не получает доступ к заявкам
Причина: сотруднику, который обновляет описание услуг, не нужен список контактов посетителей.
Формулировка: редактор создаёт, редактирует и публикует услуги, но не читает заявки и не меняет настройки интеграции. Менеджер читает заявки и состояние доставки, но не назначает роли и не изменяет ключи CRM. Администратор управляет учётными записями и настройками интеграции. Отсутствие доступа проверяется на сервере, а не только скрытием пунктов меню.
Проверка: войти под каждой ролью и выполнить разрешённые операции. Под редактором открыть прямой адрес списка и отдельной заявки: данные недоступны. Под менеджером попытаться изменить роль сотрудника и настройки интеграции: изменение отклоняется. Под администратором подтвердить управление учётными записями.
Эти пять требований описывают один сценарий с разных сторон: контекст услуги, корректность ввода, сохранение, внешнюю доставку и доступ сотрудников. Это фрагмент ТЗ. Для полного документа к нему добавляются остальные согласованные страницы, состояния интерфейса, условия эксплуатации и результаты передачи проекта.
Как превратить пример в согласованное задание
Для своего сайта замените учебные условия реальными решениями. Проверьте поля с менеджером, роли — с теми, кто будет работать в административном разделе, а ограничения интеграции — по документации и тестовому доступу выбранного сервиса. Срок передачи заявки в CRM нужно выбирать с учётом рабочего процесса и возможностей систем.
Каждому требованию присвойте устойчивый номер. Рядом укажите причину, зависимость, способ проверки и приложение, если оно нужно. Тогда замечание «CRM получает неверную услугу» можно связать с конкретным пунктом и воспроизвести на согласованных данных.
Перед утверждением разберите требования на встрече. Заказчик подтверждает, что сценарии решают нужную задачу. Разработчик проверяет выполнимость и оценку. Владелец внешнего сервиса подтверждает ограничения и готовность доступа. Неизвестные условия отмечаются прямо, с ответственным за решение; существенную зависимость не следует считать согласованной до её проверки.
Храните одну согласованную версию документа и его приложений. Если после неё добавляется функция, опишите изменение, влияние на другие требования, стоимость, сроки и способ проверки. Например, календарь выездов изменит не только страницу формы: понадобятся правила доступности специалистов, бронирования и отмены. Такое расширение нужно оценить целиком, прежде чем включать его в работу.
Что проверить в самом ТЗ до начала разработки
Пройдите главный сценарий по документу от первого действия посетителя до результата у сотрудника. В каждой точке должно быть понятно, кто действует, какие данные используются, что происходит при успехе и что — при значимом отказе.
Попросите двух участников независимо объяснить одно требование. Если один понимает «отправлено» как запись на сайте, а другой — как появление в CRM, формулировку нужно уточнить. Если для проверки приходится заново придумывать правильное поведение, критерий ещё не определён. Если требование не связано с задачей, ограничением или согласованным сценарием, выясните, зачем оно включено.
Подробности планирования работ раскрыты в статье об этапах разработки сайта. При выборе веб-студии можно предложить подрядчику разобрать один важный сценарий таким способом: это поможет увидеть, какие вопросы он считает необходимыми до оценки.
Чтобы обсудить проект, не обязательно заранее составлять идеальное ТЗ. Подготовьте описание задачи, список важных действий посетителя и сведения о существующих системах. Из них можно совместно получить конкретные требования и согласовать границы работы до начала реализации.
