Нормальное ТЗ помогает команде понять задачу, структуру, функционал, контент и критерии приемки без лишних страниц и туманных формулировок.
Техническое задание не обязано быть тяжелым документом на десятки страниц. Его смысл — убрать догадки. Команда должна понимать, что делается, для кого, в каком объеме и как будет проверяться результат.
В этой статье разбираем тему без лишних обещаний и универсальных рецептов. Важно не просто добавить на сайт модный блок, а понять, какую задачу он решает, кому помогает и как будет поддерживаться после запуска.
Цель и аудитория
Опишите, кто будет пользоваться сайтом, как человек приходит на страницу, что он уже знает о компании и какое действие должен выполнить. Это превращает вкусовые споры в обсуждение задачи.
Полезно описать не абстрактного "клиента", а две-три реальные ситуации: например, человек ищет цену в Google и сравнивает три компании, или клиент уже звонил и хочет посмотреть портфолио перед оплатой. Под разные ситуации требуются разные акценты на странице.
Если в команде есть разногласия о том, для кого делается сайт, ТЗ — хорошее место их снять. Лучше один раз письменно договориться об аудитории, чем потом спорить о цвете кнопки, не имея общего понимания, кто на нее смотрит.
Карта страниц
Перечислите главную, услуги, карточки услуг, проекты, полезные материалы, контакты и служебные страницы. Для каждой страницы укажите задачу, блоки и материалы, которые нужно подготовить.
Для каждой страницы стоит сразу писать не только название блока, но и кто отвечает за его содержимое — например, фото объектов даст менеджер, а текст о компании напишет директор. Без такой отметки подготовка материалов растягивается, потому что никто не понимает, чья это задача.
Карту страниц удобно делать в виде таблицы или майнд-карты, а не списком в документе. Так сразу видно перекосы — например, что в разделе "услуги" двенадцать вложенных страниц, а раздел "о компании" вообще не описан.
Если тема связана с коммерческой страницей, ее стоит связывать с разделами сайта через понятные внутренние ссылки. Например, пользователь может перейти к разработке бизнес-сайта, посмотреть примеры работ или сразу открыть контакты, если уже готов обсудить задачу.
Функционал сценариями
Формы, фильтры, поиск, корзина, калькулятор и CRM-интеграции нужно описывать не названием, а поведением: что вводит пользователь, куда уходит заявка и что получает менеджер.
Описывая калькулятор или форму через поведение, легко заметить нестыковки заранее. Например, если калькулятор должен присылать расчет на почту менеджеру, в ТЗ сразу видно, нужна ли интеграция с почтовым сервисом или достаточно встроенного уведомления.
Отдельно стоит прописать, что происходит при ошибке пользователя — пустое поле, неверный формат телефона, обрыв связи при отправке. Без этого разработчик сделает что-то на свой вкус, и поведение формы может разойтись с ожиданиями команды.
Контент и ответственность
В ТЗ стоит указать, кто готовит тексты, фотографии, таблицы, документы, отзывы и доступы. Отсутствие материалов чаще всего задерживает проект сильнее, чем сама разработка.
Имеет смысл прямо в ТЗ указать дедлайны по материалам отдельно от дедлайнов по разработке — например, фотографии нужны за неделю до сдачи дизайна, а не "к запуску". Размытые сроки на контент почти всегда сдвигают весь проект.
Полезно сразу решить, кто пишет тексты: заказчик, копирайтер подрядчика или штатный сотрудник. Если этот вопрос не зафиксирован, обе стороны могут неделями ждать друг от друга текст, который никто не начал готовить.
Критерии приемки
Зафиксируйте проверку адаптива, форм, мета-данных, ссылок, скорости, политики, аналитики и резервной копии. Тогда запуск перестает быть субъективным ощущением готовности.
Критерии приемки стоит формулировать так, чтобы их можно было проверить без споров — не "сайт быстрый", а "главная страница открывается на мобильном за определенное время". Конкретная формулировка не оставляет места для разных трактовок при сдаче проекта.
Полезно заранее договориться, что будет, если какой-то пункт не выполнен к дате запуска — переносится дата или сайт публикуется с открытой задачей на доработку. Это снимает напряжение в последний момент перед стартом.
Что в итоге
Нормальное ТЗ помогает команде понять задачу, структуру, функционал, контент и критерии приемки без лишних страниц и туманных формулировок. Хороший сайт держится на конкретике: ясной структуре, нормальном контенте, рабочей технической части и понятном пути к заявке. Чем раньше эти вещи обсуждаются, тем меньше случайных правок появляется перед запуском.
Если задача уже назрела, удобнее начать не с выбора картинки, а с короткого разбора текущего сайта, целей и материалов. После этого проще решить, нужен ли новый проект, доработка существующего сайта или регулярное сопровождение.
Чтобы собрать материалы для разработки уже после ТЗ, посмотрите отдельный разбор: как подготовить материалы для сайта.