Как составить техническое задание на сайт: структура, примеры и ошибки

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

Зачем вообще нужно ТЗ

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

Без ТЗ проекты страдают одинаково. Заказчик уверен, что «личный кабинет» подразумевает историю заказов, повтор заказа и бонусный счёт. Разработчик заложил вход по паролю и список заказов. Обе стороны честны, но через два месяца выясняется, что разница — три недели работы и 120 000 ₽. Хорошее ТЗ вытаскивает такие расхождения на свет до подписания договора, когда их ещё дёшево обсуждать.

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

Из каких разделов состоит техническое задание

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

Для сайта-визитки всё это укладывается в три-пять страниц. Для интернет-магазина с интеграцией 1С и личным кабинетом ТЗ легко достигает тридцати-сорока страниц, и это оправдано: каждый сценарий обмена данными нужно описать отдельно.

Как писать: пошаговый порядок

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

1. Бриф и интервью

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

2. Структура и шаблоны

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

3. Сценарии пользователя

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

4. Интеграции и данные

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

5. Нефункциональные требования

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

6. Вычитка и утверждение

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

Как формулировать требования однозначно

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

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

Обратите внимание: конкретные формулировки длиннее, но каждая из них проверяется за минуту. И каждая сразу подсказывает разработчику объём работы. «Интеграция с 1С» может стоить и 40 000 ₽, и 300 000 ₽ — всё решает состав и направление обмена.

Чего не нужно писать в ТЗ

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

Типичные ошибки заказчиков

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

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

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

ТЗ, прототип и дизайн: как они связаны

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

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

Вопросы, которые нам задают о ТЗ

Коротко о главном

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

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