Как составить ТЗ на сайт или приложение: шаблон и примеры

Хорошее ТЗ на сайт (его ещё называют брифом) — это одна-две страницы, которые отвечают на пять вопросов: зачем вам сайт, для кого он, что в нём должно быть, что он должен уметь и какие у вас ограничения по бюджету и срокам. Всё. Не нужны технические термины и документ на 30 страниц — нужны понятные ответы, чтобы разработчик мог честно оценить проект и сделать то, что нужно, с первого раза.

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

#Зачем нужно ТЗ и как оно экономит деньги

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

Бриф это исправляет:

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

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

#Что указать в ТЗ на сайт

#1. О бизнесе

Два-три предложения: чем занимаетесь, где, для кого. Добавьте ссылку на текущий сайт (если он есть) и что в нём не так.

#2. Цель проекта

Самый важный раздел. Что сайт должен делать для бизнеса? Например: «приносить заявки на расчёт ремонта», «продавать товары онлайн по Молдове», «показать инвесторам, что мы серьёзная компания», «дать клиентам записываться самим». Если целей несколько — расставьте приоритеты.

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

#3. Аудитория

Кто пользователи? Возраст, город, язык, устройство. «В основном женщины 25–45 из Кишинёва, с телефона, на русском и румынском» скажет разработчику больше, чем страница общих слов. Если аудитория говорит на нескольких языках, укажите на каких — это влияет на структуру и SEO (подробнее в статье про мультиязычный сайт).

#4. Страницы или экраны

Хватит примерного списка: Главная, Услуги, О нас, Цены, Блог, Контакты. Для приложения: онбординг, вход, каталог, корзина, профиль. Для одностраничника перечислите ожидаемые блоки — поможет статья про структуру лендинга.

#5. Функции

Честно разделите их на две колонки:

Это разделение — главный инструмент, чтобы уложиться в бюджет.

#6. Интеграции

Оплата, службы доставки, CRM, Google Maps, мессенджеры, email-рассылки, бухгалтерия. Если знаете конкретные сервисы — назовите их.

#7. Контент

Кто пишет тексты, кто даёт фото, есть ли логотип и фирменные цвета? Неготовый контент — самая частая причина, по которой проекты стоят.

#8. Референсы по дизайну

Два-три сайта или приложения, которые нравятся, — и что именно нравится: цвета, раскладка, конкретная анимация, простота. И один, который не нравится, если есть. Часто это полезнее длинного описания.

#9. Бюджет и сроки

Даже примерная вилка помогает выбрать правильный подход: решение на шаблоне, индивидуальный сайт или запуск по этапам. Со сроками так же: они жёсткие (мероприятие, сезон) или гибкие?

#10. После запуска

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

#Шаблон ТЗ на сайт (скопируйте)

Скопируйте, заполните то, что знаете, и оставьте пустым то, в чём не уверены, — «пока не знаю» тоже нормальный ответ.

БРИФ НА ПРОЕКТ

1. Бизнес
   Название компании / проекта:
   Чем занимаемся (2–3 предложения):
   Текущий сайт (ссылка, что не так):

2. Цель
   Главная цель сайта/приложения:
   Второстепенные цели:
   Как поймём, что работает:

3. Аудитория
   Кто пользователи:
   Города / страны:
   Языки (RO / RU / EN):
   Основное устройство (телефон / компьютер):

4. Структура
   Страницы или экраны:

5. Функции
   Обязательно к запуску:
   Желательно потом:

6. Интеграции
   Оплата / доставка / CRM / другое:

7. Контент
   Тексты готовы? (да / частично / нет)
   Фото, логотип, фирменные цвета:

8. Референсы
   Сайты/приложения, которые нравятся, и чем:
   Чего точно не хотим:

9. Ограничения
   Вилка бюджета:
   Срок (жёсткий или гибкий):

10. После запуска
   Кто обновляет контент:
   Нужна поддержка / хостинг:

Контактное лицо и удобный канал связи:

#Частые ошибки в ТЗ

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

#Не хочется писать? Соберите в конструкторе

Если заполнять документы — не ваше, есть путь быстрее. В конструкторе проекта на этом сайте выбираете сайт или приложение, стартуете с готового пресета, собираете блоки или экраны, отмечаете нужные функции и сразу видите примерную оценку. На выходе — структурированный скелет, по сути разделы 4 и 5 брифа (и частично 6), только наглядно. При отправке конструктор спросит бюджет, сроки и контакт — добавьте строчку о цели, и этого достаточно, чтобы начать разговор.

А перед отправкой можно посмотреть, что входит в разработку сайтов или разработку приложений.

#Частые вопросы

#Какого объёма должно быть ТЗ на сайт?

Для большинства небольших и средних проектов достаточно одной-двух страниц. Главное — чтобы были понятны цель, аудитория, обязательные функции и вилка бюджета.

#Чем бриф отличается от технического задания?

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

#Можно ли отправить бриф, не зная бюджета?

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

#Нужно ли ТЗ для мобильного приложения?

Да, и даже больше, чем для сайта. Перечислите экраны, пользователей, нужны ли iOS и Android, push-уведомления, оплата или офлайн-режим. Шаблон выше подходит и для приложений.

#Готовы отправить своё?

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