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