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

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

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

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

1. Начните с задачи бизнеса и потребностей клиента

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

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

2. Определите, что войдёт в первую версию

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

Разделите пожелания на три группы:

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

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

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

3. Опишите, как должны работать функции

Слова «форма заявки» ещё не объясняют, как она должна работать. Укажите поля, обязательную информацию, получателя сообщения и то, что посетитель увидит после отправки.

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

4. Распределите работу с текстами, фотографиями и дизайном

Кто пишет тексты? Кто подбирает фотографии? Кто проверяет цены и переводы? Назначьте ответственных и сроки подготовки материалов.

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

Договоритесь, что вы увидите и согласуете до разработки всех страниц. Например, макеты главной и страницы услуги для телефона и большого экрана. Подробнее об этой работе — на странице UX/UI-дизайна.

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

5. Сделайте технические требования понятными

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

• Скорость. Договоритесь, какие страницы проверяются, каким инструментом и в каких условиях.
• Доступность. Заранее обсудите управление с клавиатуры, читаемость, названия полей и понятные сообщения об ошибках.
• Поиск. Укажите конкретные работы: заголовки страниц, внутренние ссылки и обработка старых адресов.
• Данные и доступы. Уточните, какие сведения собирает сайт, куда они передаются и кто может их видеть.
• Аналитика. Определите, какие действия нужно учитывать, например отправку заявки, и кто проверит правильность учёта.

Если в ТЗ используются показатели Core Web Vitals, актуальный набор — LCP, INP и CLS. Они описывают загрузку, отклик на действия и стабильность расположения элементов. Тест до запуска отличается от измерений при реальных посещениях. Поэтому отдельно обсудите проверку перед публикацией и наблюдение после неё. Подробнее — в объяснении Google о Web Vitals.

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

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

6. Договоритесь о приёмке, изменениях и поддержке

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

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

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

ИИ может помочь с первым вариантом ТЗ, но его нужно сверить с реальными задачами бизнеса. Об этом также рассказываем в статье о роли ИИ и команды при разработке сайта.

7. Скопируйте этот шаблон для своего проекта

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

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