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

Техническое задание на разработку сайта фиксирует, какой результат должна получить компания:

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

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

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

Чем ТЗ отличается от брифа и договора

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

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

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

Что важно зафиксировать до разработки

Задачу проекта и его границы

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

Одной компании нужен сайт для нескольких направлений услуг. Другой важно перенести большой каталог. Третьей требуется связать обращения с CRM, представить новое направление или подготовить структуру для дальнейшего SEO-продвижения.

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

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

Структуру и основные сценарии

Состав страниц зависит от бизнеса и того, как клиент принимает решение.

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

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

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

Функции и интеграции

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

Это особенно касается личных кабинетов, каталогов и фильтров, онлайн-оплаты, CRM, 1С, внешних API, онлайн-записи, бронирования и калькуляторов.

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

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

Контент и ответственность сторон

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

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

Подробнее взаимосвязь этих работ разобрана в статье «Что входит в создание сайта для бизнеса». Заказчику при этом не требуется самостоятельно переводить сведения о компании на язык разработчиков.

Дизайн и мобильные сценарии

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

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

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

SEO и аналитика

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

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

При редизайне отдельно определяют, какие существующие адреса сохраняются. Если URL меняются, заранее предусматривают перенаправления.

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

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

Приёмку, запуск и доступы

На этапе приёмки требования превращаются в понятные пункты проверки.

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

К запуску также должно быть понятно, у кого находятся доступы к домену, хостингу, CMS, аналитике, CRM и другим сервисам.

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

Что должен подготовить заказчик, а что — студия

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

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

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

Как проверить ТЗ без технических знаний

Заказчику не требуется оценивать документ как программисту.

Достаточно проверить пять вещей:

1. Понятно ли, какой результат должен быть готов к моменту запуска?
2. Перечислены ли функции и интеграции, влияющие на работу бизнеса?
3. Распределена ли ответственность за тексты, изображения, каталог и другие материалы?
4. Можно ли проверить существенные требования без субъективных формулировок вроде «удобно», «быстро» или «современно»?
5. Понятно ли, какие работы не входят в первоначальный объём и как будут согласовываться изменения?

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

Мини-кейс: как требования влияют на архитектуру

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

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

Подробнее решение показано в кейсе VENTSYSTEM.

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

Формулировки, которые создают разночтения

«Сделать современный дизайн» не объясняет, какой результат проверять.

«Сайт должен быстро работать» не определяет, какие страницы, устройства и сценарии критичны.

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

«Интегрировать с CRM» не описывает состав и момент передачи данных.

«Подготовить к SEO» не фиксирует, какие технические и структурные работы входят в проект.

«Сделать удобную админку» не отвечает на вопрос, какие данные сотрудник компании сможет изменять самостоятельно.

Если существенное требование нельзя проверить, заказчик и разработчик могут понимать его по-разному.

Частые вопросы

- Нужно ли техническое задание для небольшого лендинга?

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

- Что делать, если требования изменились во время разработки?

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

- Нужно ли заранее выбирать CMS?

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

- Техническое задание заменяет чек-лист приёмки?

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