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

1. Контекст, цели и задачи проекта

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

В разделе фиксируют:

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

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

2. Аудитория и пользовательские сценарии

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

Для основных групп аудитории определяют:

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

У корпоративного сайта могут быть разные группы пользователей: потенциальные клиенты, действующие партнёры, соискатели и представители СМИ. У каждой группы своя задача и свой маршрут по сайту. На этом этапе требования бизнеса связываются со сценариями пользователей.

3. Состав и границы проекта

В этом разделе фиксируют согласованный объём и границы работ.

Он может включать:

• публичную часть сайта;
• личный кабинет;
• административную панель;
• интеграции;
• миграцию контента;
• дизайн-систему;
• настройку аналитики;
• подготовку текстов;
• базовую SEO-подготовку;
• другие необходимые работы.

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

4. Порядок согласований, ответственность и актуальная версия документа

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

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

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

5. Структура сайта и типы страниц

В этом разделе описывают информационную архитектуру сайта.

ТЗ может содержать:

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

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

6. Функциональные требования

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

Например:

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

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

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

7. Интеграции и работа с данными

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

Сайт может быть связан с:

• CRM;
• ERP;
• 1С;
• платёжными сервисами;
• службами доставки;
• картографическими сервисами;
• внешними каталогами;
• системами авторизации;
• аналитическими платформами;
• сторонними API.

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

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

8. Технические и нефункциональные требования

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

К ним могут относиться требования к:

• производительности;
• безопасности;
• адаптивности;
• браузерам и устройствам;
• доступности;
• CMS;
• инфраструктуре;
• хранению данных;
• резервному копированию;
• SEO;
• логированию;
• допустимой нагрузке.

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

9. Контент

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

В ТЗ полезно зафиксировать:

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

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

10. Требования и ограничения для дизайна

На этапе подготовки ТЗ фиксируют исходные условия и ограничения дизайна:

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

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

11. Критерии приёмки

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

Например, формулировки «сайт интегрирован с CRM» недостаточно.

Нужно определить:

• какие данные передаются;
• какое событие запускает передачу;
• в какой объект CRM попадает информация;
• что считается успешным результатом;
• как система реагирует на ошибку.

Критерий можно сформулировать так: «После отправки формы со страницы продукта заявка создаётся в CRM с названием выбранного продукта, контактами и UTM-метками; при успешной отправке пользователь видит подтверждение». Чем точнее критерий, тем меньше неоднозначности остаётся при тестировании и приёмке.

Как ТЗ связано с этапами разработки сайта

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

Аналитика

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

UX-проектирование

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

Дизайн

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

Разработка

Команда разбивает требования на задачи для front-end, back-end и других специалистов. Ей нужно понимать, что реализовать и с какой исходной задачей связано решение. В больших проектах между формулировкой требования и реализацией конкретного модуля может пройти много времени.

Тестирование и приёмка

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

бизнес-задача → требование → проектное решение → реализация → проверка.

Как ТЗ помогает контролировать сроки и бюджет

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

Что делать, если требования меняются после начала проекта

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

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

• в интерфейсе;
• в валидации;
• в базе данных;
• в CRM-интеграции;
• в административной панели;
• в аналитике.

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

Каким должно быть хорошее требование

Хорошее требование можно однозначно понять и проверить. Оно должно быть:

• конкретным;
• понятным участникам проекта;
• реализуемым;
• проверяемым;
• связанным с задачей бизнеса или пользователя.

Слабая формулировка	Проверяемая формулировка
«Сайт должен быстро загружаться»	«Страницы каталога и карточек товаров соответствуют согласованным показателям производительности на мобильных устройствах; показатели и способ проверки указаны в ТЗ».
«Нужен удобный каталог»	«Пользователь может отфильтровать товары по трём согласованным параметрам, сбросить фильтры и открыть карточку товара из списка результатов».
«На сайте есть поиск»	«Поиск работает по названию, артикулу и категории; при отсутствии результатов пользователь видит сообщение и ссылку на каталог».
«Сайт интегрирован с CRM»	«После отправки формы сайт передаёт в CRM контакты, выбранный продукт, источник и UTM-метки; при ошибке обмена заявка сохраняется для повторной отправки».
«Интерфейс должен быть современным»	«Дизайн использует утверждённую дизайн-систему, адаптируется к согласованным разрешениям и учитывает все состояния форм и интерактивных элементов».

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

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

Частые ошибки при подготовке ТЗ

Сразу фиксировать способ реализации

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

Использовать субъективные формулировки

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

Описывать только успешный сценарий

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

Не определять границы проекта

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

Не фиксировать критерии приёмки

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

Кто должен составлять ТЗ на сайт

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

Со стороны клиента нужны:

• бизнес-задачи;
• знание продукта;
• внутренние процессы;
• ограничения;
• требования заинтересованных подразделений;
• информация о существующих системах.

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

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

Нужно ли готовить ТЗ до выбора подрядчика

Полное техническое задание требуется до выбора исполнителя не во всех проектах.

Для первого разговора с агентством обычно достаточно исходных данных, которые позволяют понять масштаб задачи:

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

Этой информации достаточно, чтобы обсудить проект и определить, какие данные нужно собрать дальше.

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

Для простой и хорошо определённой задачи ТЗ можно подготовить заранее.

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

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

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

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

Можно ли разработать сайт без ТЗ

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

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

Главный вывод

• ТЗ связывает бизнес-задачу сайта с конкретными решениями: структурой, функциями, контентом, интеграциями и критериями приёмки.
• Сроки и бюджет можно оценить обоснованно, только когда зафиксированы объём и границы работ, зависимости и требования к качеству.
• Хорошее требование должно быть понятным, реализуемым и проверяемым; общие формулировки нужно уточнять.
• ТЗ развивается вместе с проектом: существенные изменения оценивают, согласуют и вносят в актуальную версию документа.

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

См. также

• Как провести предпроектный анализ сайта
• Сколько времени нужно на создание сайта
• Как правильно составить ТЗ на разработку интернет-магазина
• Разработка сложных веб-сервисов
• Как составить ТЗ для дизайнера без брифа