Как написать ТЗ на разработку сайта: шаблон, примеры и типичные ошибки

Зачем нужно ТЗ и что бывает без него

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

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

Хорошая новость: ТЗ не обязано быть стостраничным документом по ГОСТу. Для сайта или веб-приложения достаточно 5–10 страниц, написанных понятным языком.

Структура хорошего ТЗ

1. О проекте. Кто вы, что за продукт, какую бизнес-задачу решает сайт. Три абзаца, без воды.

2. Цели и метрики. Что должно измениться: заявки с сайта, продажи, снижение нагрузки на колл-центр. С цифрами, если есть.

3. Целевая аудитория. Кто пользователи, что они приходят делать, на каких устройствах.

4. Структура и функционал. Список страниц и функций. Для каждой — что пользователь видит и что может сделать.

5. Интеграции. CRM, платежи, доставка, 1С, телефония — всё, с чем сайт должен обмениваться данными.

6. Нефункциональные требования. Скорость загрузки, адаптивность, браузеры, SEO-требования, безопасность, 152-ФЗ.

7. Ограничения и этапы. Бюджет, сроки, что не входит в проект.

Что обязательно включить

Критерии приёмки. По каким признакам вы понимаете, что работа принята. «Форма отправляется, заявка приходит в Telegram и на почту, письмо не падает в спам» — это критерий. «Форма работает» — нет.

Ответственность за контент. Кто пишет тексты и делает фото. Если заказчик — зафиксируйте дедлайны: половина срывов сроков происходит из-за контента, которого нет.

Права и доступы. Исходный код, дизайн-макеты, доступы к хостингу и аналитике должны принадлежать вам. Пропишите это.

Примеры: плохо и хорошо

Плохо: «Сделать современный дизайн». Хорошо: «Дизайн в тёмной теме по референсам (прилагаются), адаптив от 360px, UI-кит для типовых компонентов».

Плохо: «Интеграция с CRM». Хорошо: «Заявки из формы уходят в amoCRM: создаётся сделка в воронке “Сайт”, в поля — имя, телефон, комментарий, UTM-метки».

Плохо: «Быстрая загрузка». Хорошо: «LCP до 2.5 секунд на 4G по PageSpeed Insights, оценка Performance не ниже 85».

Типичные ошибки

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

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

Всё важно одинаково. Разделяйте must have и nice to have. Это позволит резать скоуп без потери сути, когда понадобится ужаться по бюджету.

ТЗ высечено в камне. Хороший процесс предполагает уточнение ТЗ после аналитики и прототипа. Зафиксируйте в договоре, что детализация на этапе проектирования — норма, а не «изменение требований».

Каркас ТЗ: копируйте и заполняйте

Готовый шаблон, с которого мы сами начинаем проекты:

1. О проекте. Компания, продукт, текущая ситуация, почему сейчас.

2. Цель. Одна-две измеримые цели: «рост заявок с 30 до 60 в месяц», «перевод записи на услуги в онлайн».

3. Аудитория. 2–3 сегмента: кто они, что им нужно, с каких устройств заходят.

4. Структура. Дерево страниц с назначением каждой.

5. Функционал. Таблица: функция — описание — приоритет (must/nice) — критерий приёмки.

6. Интеграции. Система — что передаём — в какую сторону — как часто.

7. Требования. Скорость, адаптивность, браузеры, SEO, безопасность.

8. Контент. Кто и когда готовит тексты, фото, переводы.

9. Ограничения. Бюджет, дедлайн, что точно не входит.

10. Этапы и приёмка. Как сдаём и как принимаем.

Частые вопросы про ТЗ

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

Можно ли стартовать без ТЗ? Можно — через этап аналитики: 1–2 недели, фиксированная небольшая цена, на выходе ТЗ, прототип и точная смета. Это стандартный вход в проекты без документации.

ТЗ устарело в середине проекта — что делать? Уточняйте письменно и пересчитывайте смету. Молчаливое «ну вы поняли» — главный источник конфликтов.

Кто пишет ТЗ: заказчик или студия? Лучший результат — совместно: вы знаете бизнес, студия знает технологии. Одностороннее ТЗ почти всегда требует переработки.

Выводы

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