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

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

Что решает техническое задание на разработку сайта и где его границы

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

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

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

Критерии проверяемости требований

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

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

Кто участвует в подготовке и какие роли нужны

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

Роли на стороне заказчика

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

Роли на стороне исполнителя

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

Ответственный за итоговый текст ТЗ — один человек. Чаще всего это аналитик или менеджер со стороны исполнителя, но утверждает документ заказчик. Важно, чтобы у каждого раздела был владелец и согласующий. Если за раздел никто не отвечает, он останется неполным.

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

Перевод бизнес-задач в пользовательские сценарии

Бизнес-задача описывает, зачем нужен сайт: например, получать заявки на услуги. Пользовательский сценарий описывает, как посетитель этого достигает. Сценарий состоит из шагов, у него есть начало, результат и возможные исключения.

Как формулировать сценарий

Формулировка сценария начинается с роли и цели: «Посетитель — руководитель производственного предприятия — хочет узнать, может ли компания выполнить его задачу, и запросить коммерческое предложение». Далее перечисляются шаги: открывает главную, переходит в раздел услуг, выбирает услугу, изучает описание, нажимает кнопку «Запросить КП», заполняет форму, отправляет. Результат: заявка зафиксирована, посетитель видит подтверждение.

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

Пример сценария для корпоративного сайта

Учебный пример. Сценарий «Запрос коммерческого предложения»: посетитель открывает карточку оборудования, нажимает «Запросить КП», заполняет поля «Имя», «Телефон», «Email», «Комментарий», отмечает согласие на обработку персональных данных, отправляет форму. Система проверяет обязательные поля, сохраняет заявку, отправляет уведомление менеджеру и передаёт данные в CRM. Посетитель видит сообщение об успешной отправке.

Критерий: сценарий можно пройти по шагам и проверить. Если в описании есть слова «интуитивно», «удобно», «быстро», их нужно заменить на конкретные действия и измеримые условия.

Каркас технического задания: обязательные разделы

Каркас ТЗ помогает ничего не забыть. В документ обычно включают:

1. Общие сведения: название проекта, стороны, дата, версия. 2. Цели и задачи сайта: какие бизнес-результаты ожидаются. 3. Аудитории и сегменты: для кого сайт, какие у них потребности. 4. Структура сайта: перечень разделов и страниц, связи между ними. 5. Пользовательские сценарии: пошаговые описания ключевых действий. 6. Функциональные требования: формы, фильтры, поиск, личный кабинет, если нужен. 7. Требования к контенту: какие тексты, изображения, документы нужны, кто их готовит. 8. Требования к дизайну: фирменный стиль, адаптивность, состояния элементов. 9. Интеграции: с какими системами и по каким данным. 10. Нефункциональные требования: браузеры, мобильные устройства, доступность, резервное копирование. 11. Критерии приёмки: как проверяется каждый блок. 12. Порядок внесения изменений: как оформляются новые требования.

Как описывать функциональные требования

Функциональные требования описывают поведение системы. Например: «На странице услуги есть форма заявки. Поля: имя, телефон, email, комментарий. Обязательные поля: имя, телефон. После отправки данные сохраняются и отправляются на согласованный адрес. Посетитель видит сообщение об успехе». Каждое требование проверяется отдельно.

Как описывать нефункциональные требования

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

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

Критерии приёмки вместо пожеланий

Пожелание «сделать современный дизайн» нельзя принять. Критерий приёмки переводит пожелание в проверяемое утверждение. В таблице ниже показано, как это делается.

Как превратить пожелание в критерий

Сначала пожелание записывают в исходном виде. Затем задают вопрос: что должно произойти, чтобы мы поняли, что пожелание выполнено? Ответ формулируют как действие и наблюдаемый результат. После этого указывают, кто и как проверит требование. Если проверка невозможна, требование переформулируют.

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

Как описать контент и типовые страницы корпоративного сайта

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

Типовые страницы корпоративного сайта

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

Требования к контенту

В ТЗ перечисляют, какие тексты, изображения и документы нужны для запуска. Указывают, кто их готовит и в каком виде передаёт. Если контент готовит заказчик, в ТЗ фиксируют сроки и ответственного. Если контент создаёт исполнитель, описывают объём и требования к материалам.

Критерий: контент-менеджер может заполнить страницу по инструкции, не обращаясь к разработчику. Если для добавления текста нужно менять код, это требование к функциональности, а не к контенту.

Интеграции и внешние системы в ТЗ

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

Что фиксировать по каждой интеграции

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

Обработка ошибок

Для каждой интеграции описывают поведение при сбое. Что видит пользователь? Что происходит с данными? Кто получает уведомление? Ответы на эти вопросы должны быть в ТЗ. Иначе при сбое команда будет действовать наугад.

Если планируется обмен с 1С, в ТЗ указывают, какие данные передаются, кто инициирует обмен и как обрабатываются расхождения. Конкретные условия обмена уточняются у интегратора и в документации системы. Не стоит описывать интеграцию словами «настроить обмен» — это не требование.

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

Учебный пример: ТЗ для корпоративного сайта условной компании

Учебный пример. Компания «ООО „Вектор“» (название и данные условны) поставляет промышленное оборудование. Нужен корпоративный сайт с каталогом оборудования, новостями, проектами и формой заявки. Сайт должен редактироваться контент-менеджером, заявки — передаваться в CRM.

Входные условия

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

Фрагмент ТЗ

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

Проверка результата

Критерии приёмки: форма не отправляется с пустыми обязательными полями; при некорректном email появляется сообщение об ошибке; после успешной отправки заявка появляется в CRM и на почте менеджера; посетитель видит подтверждение. Проверка: тестировщик заполняет форму с пустыми полями, с неверным email, с корректными данными. Проверяет получение уведомления и запись в CRM.

Ограничения примера: конкретная CRM и сроки передачи данных не указаны, потому что зависят от настроек интеграции. В реальном ТЗ эти параметры согласуются отдельно.

Как проверить ТЗ до старта разработки

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

Проверка полноты и однозначности

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

Привлечение тестировщика и контент-менеджера

Тестировщик задаёт вопросы о поведении системы в исключительных ситуациях. Контент-менеджер проверяет, сможет ли он работать с контентом по описанию. Если возникают вопросы, на которые нет ответа в ТЗ, документ возвращается на доработку.

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

Типичные ошибки и ограничения

Одна из частых ошибок — смешивать требования и решения. «Сделать на Битрикс» — это решение, а требование — «контент-менеджер редактирует тексты без разработчика». Решение может быть любым, если требование выполнено.

Ошибки в формулировках

Другая ошибка — отсутствие критериев приёмки. Без них приёмка превращается в переговоры о вкусах. Также опасно описывать интеграции общими словами: «настроить обмен с 1С» не даёт понимания, что именно и как передаётся. Противоречия между разделами — ещё одна причина переделок. Например, в одном разделе указано, что форма отправляет заявку на почту, в другом — что только в CRM. Такие расхождения нужно устранять до старта.

Ограничения документа

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

Какие исходные данные подготовить для оценки

Для оценки сроков и стоимости исполнителю нужны исходные данные. Чем полнее они собраны, тем точнее оценка. В список входят:

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

Список данных

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

Доступы и безопасность

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

Чек-лист приёмки и передачи

Перед приёмкой работы проверьте:

• Все разделы ТЗ заполнены и согласованы.
• У каждого требования есть критерий приёмки.
• Пользовательские сценарии описаны с шагами и исключениями.
• Типовые страницы описаны по блокам и полям.
• Для каждой интеграции указаны направление, данные, частота и обработка ошибок.
• Контент-менеджер может редактировать контент без разработчика.
• Формы проверены на пустые поля, некорректные данные и успешную отправку.
• Перед изменениями на работающем сайте сделана резервная копия и есть план возврата.
• Доступы переданы ответственным лицам по акту.
• Обучение контент-менеджера проведено и зафиксировано.

Передача проекта

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