Начните с задачи бизнеса и посетителя
Запишите, зачем нужен сайт: принимать вопросы по услугам, показывать ассортимент, записывать на консультацию или давать доступ к документам. Затем сформулируйте действие пользователя. Например: посетитель выбирает услугу, описывает ситуацию и оставляет удобный контакт. Такую задачу можно разложить на страницы, поля и проверки.
Разделите обязательное для запуска и пожелания на будущее. Если в первой версии не будет онлайн-оплаты, не оставляйте её в списке как неуточнённую функцию. Для каждого спорного пункта запишите решение или вопрос с ответственным. Иначе заказчик и разработчик могут по-разному понимать, что входит в согласованный объём.
Опишите страницы через вопросы читателя
Составьте перечень страниц и назначение каждой. У страницы услуги — объяснить, кому она подходит, что входит в работу и как обратиться. У страницы контактов — помочь выбрать способ связи и найти компанию, если у неё есть место приёма. Не добавляйте разделы только для совпадения с чужим сайтом.
Для каждой страницы укажите источник текста, изображений и других данных. Кто предоставляет материалы, кто проверяет факты и кто размещает итоговую версию? Если часть содержимого пока отсутствует, обозначьте, допустим ли временный вариант. Заглушка в рабочем документе не должна незаметно превратиться в опубликованный отзыв или выдуманный проект.
Разберите сложные действия по шагам
Для формы заявки опишите поля, обязательность и путь после отправки. Куда сохраняется вопрос, кто получает уведомление и что видит посетитель? Отдельно перечислите ошибки: пустое поле, неверный формат контакта, повторная отправка и недоступность связанной системы. У каждой ситуации должно быть ожидаемое поведение.
Если есть запись на услугу, уточните, является ли выбор времени подтверждённой бронью или пожеланием для менеджера. Если стоимость зависит от осмотра, не называйте результат формы окончательным расчётом. Такие различия важнее цвета кнопки: они определяют ожидания клиента и работу сотрудников после обращения.
Укажите данные, доступы и интеграции
Перечислите системы, с которыми сайт должен обмениваться данными. Для каждой связи опишите состав передаваемых полей и направление обмена. Формулировку «интеграция с CRM» замените конкретным действием: после подтверждённой отправки создаётся обращение с текстом вопроса, источником и ответственным по согласованному правилу.
Запишите, какие роли нужны для управления содержимым и кто имеет право менять важные настройки. Доступы и секреты передавайте по отдельному согласованному каналу, а не включайте в общедоступную версию ТЗ. Также определите, где будет размещён сайт и кто отвечает за резервные копии и поддержку после запуска.
Превратите пожелания в критерии приёмки
«Удобная мобильная версия» требует уточнения. Например: на согласованных размерах экрана текст не обрезается, поля доступны, меню открывается, контактная кнопка приводит к нужному действию. Добавьте список устройств или браузеров, на которых будет проведена проверка. Не обещайте охват всех существующих сочетаний без обсуждения объёма тестирования.
Условный пример проверяемого требования: «После отправки заполненной формы сотрудник видит в CRM одну заявку с указанным контактом и текстом; повторное нажатие в том же сценарии не создаёт вторую запись». Это пример задания, не универсальное правило для любой формы. Конкретный способ распознавания повтора нужно согласовать с разработчиком.
Согласуйте изменения и передачу результата
Опишите, как принимаются новые пожелания во время работы. Дополнительная страница или новый сценарий должны попадать в список изменений с оценкой влияния на объём и сроки. Иначе текущий документ перестанет отражать договорённости, а спор возникнет уже на приёмке.
В передачу результата включите согласованные доступы, размещённую версию, исходные материалы и инструкцию по типовым изменениям. Попросите отдельно перечислить известные ограничения и незавершённые задачи. Если используется сторонний сервис, уточните владельца учётной записи и дальнейшие платежи. Заказчик должен понимать, как сайт будет работать после окончания разработки.
Проверьте ТЗ коротким разбором сценария
Пройдите документ вместе с будущим пользователем и сотрудником, который принимает обращения. Возьмите одну задачу и последовательно ответьте: откуда пришёл человек, что увидел, что отправил, кто получил запрос и как продолжился разговор. Если на шаге нет ответа, уточните ТЗ до начала соответствующей работы.
В Дело Прёт можно обсудить создание сайта по готовому заданию или подготовку структуры с нуля. Пришлите через форму или мессенджер ниже описание задачи, существующий сайт и список обязательных функций. По этим вводным можно предметно обсудить объём разработки и критерии результата.