← Все статьи

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

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

Что такое ТЗ на сайт и зачем оно заказчику?

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

В типовых договорах Roboweb техзадание — отдельное приложение № 1, а рядом с ним спецификация (смета) и акт сдачи-приёмки. Акт прямо ссылается на ТЗ: работы принимаются «в соответствии с Техническим заданием». Шаблоны открыты на странице договоров — их можно скачать и посмотреть до разговора с любой студией. Раздел ТЗ в них построен как таблица, которую заполняют обе стороны:

• цели и задачи;
• целевая аудитория;
• состав работ и структура;
• функциональные требования;
• дизайн и фирменный стиль;
• интеграции;
• материалы заказчика;
• что не входит в работы.

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

Что обязательно должен написать сам заказчик?

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

1. Цель сайта. Не «сделать современный сайт», а «получать заявки на монтаж кровли из Московской области» или «принимать заказы без звонка менеджеру». Цель определяет всё остальное.
2. Кто придёт на сайт. Частные клиенты или закупщики компаний, с телефона или с компьютера, из рекламы или из поиска. От этого зависят структура и тон текстов.
3. Целевое действие. Что посетитель должен сделать: оставить заявку, купить, записаться, позвонить, зарегистрироваться в кабинете.
4. Страницы или экраны. Списком: главная, услуги, цены, кейсы, контакты. Для веб-сервиса — роли пользователей и что каждая роль видит и делает.
5. Куда уходят заявки и данные. В почту, в Telegram, в CRM, в таблицу, в 1С. Это одна из главных причин, по которой меняется смета.
6. Материалы, которые уже есть. Логотип, фирменный стиль, тексты, фото, домен. Чего нет — тоже напишите: это станет отдельной строкой работ.
7. Сроки и бюджет. Хотя бы вилкой. Это не торг, а ориентир, чтобы исполнитель предложил решение по средствам, а не «идеальное».

Что можно спокойно оставить студии?

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

• Техническую архитектуру. Базу данных, API, роли и права доступа для веб-сервиса студия проектирует сама; на тарифе веб-приложения этап так и называется: «Бриф и ТЗ: роли, сценарии, модель данных, интеграции».
• Структуру страниц и блоков. Достаточно сказать, что должно быть на сайте, — порядок блоков и карту сайта предложит исполнитель.
• Требования к вёрстке. Адаптив под телефон, планшет и компьютер, базовое SEO, подключение аналитики — у нас это уже есть в составе тарифов сайтов, расписывать это заново не нужно.
• Детали интеграций. Вам достаточно назвать систему: «заявки в amoCRM», «остатки из 1С». Формат обмена и точки стыковки уточняются на этапе проектирования.

Единственное, что не стоит делегировать целиком, — дизайн «на вкус студии». Дайте 2–3 примера сайтов, которые нравятся, и 1–2, которые не нравятся, с пояснением почему. Это экономит раунд правок.

Чем ТЗ на веб-сервис отличается от ТЗ на сайт?

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

• Роли. Например: клиент, менеджер, администратор. Для каждой — одной строкой, зачем она заходит в систему.
• Сценарии. Короткие истории «кто — что делает — что получает»: «клиент оставляет заказ и видит его статус», «менеджер меняет статус, клиенту приходит уведомление».
• Данные. Какие сущности живут в системе — заказы, объекты, документы, товары — и какие поля у них обязательны. Схему базы по этим описаниям проектирует студия.
• Первая версия. Отметьте, без чего запуск не имеет смысла, а что можно добавить второй итерацией. На тарифе веб-приложения так и заложено: «MVP → развитие итерациями».
• Внешние системы и оплата. С какими сервисами нужен обмен и принимаются ли платежи — это сильнее всего влияет на срок.

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

Как помогает бриф, если писать ТЗ с нуля трудно?

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

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

Какие ошибки в ТЗ чаще всего приводят к спорам?

Споры почти всегда возникают не из-за того, что написано в ТЗ, а из-за того, чего в нём нет: размытых формулировок и неназванных исключений.

• Оценочные слова вместо проверяемых. «Красивый», «удобный», «быстрый» нельзя принять по акту. Лучше: «форма заявки на первом экране», «оплата картой и через СБП».
• Нет раздела «что не входит». Тексты, фото, домен, хостинг, лицензии сторонних сервисов — если это не оговорено, каждая сторона понимает по-своему.
• Интеграции «когда-нибудь потом». Подключение CRM или 1С меняет смету и срок; лучше сразу отметить, что нужно в первой версии, а что — во второй.
• Функции «как у конкурента» без списка. Ссылка на чужой сайт — хороший референс по виду, но не описание функций. Перечислите, что именно из увиденного нужно.
• Меняющаяся концепция. Правки в рамках согласованной структуры — нормальная часть работы; смена концепции на середине — уже другой проект.

Что происходит, если ТЗ нужно поменять по ходу работ?

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

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

Чек-лист: готово ли ваше ТЗ к отправке студии

Если на все пункты ниже есть ответ хотя бы в одну строку, этого достаточно, чтобы получить оценку срока и цены:

1. Цель сайта или сервиса — одной фразой.
2. Кто основная аудитория и откуда она придёт.
3. Целевое действие посетителя.
4. Список страниц, разделов или экранов; для сервиса — роли пользователей.
5. Куда отправлять заявки и какие системы подключить.
6. Нужны ли оплата, личный кабинет, каталог, несколько языков.
7. Какие материалы есть: логотип, стиль, тексты, фото, домен.
8. Примеры сайтов, которые нравятся и не нравятся, с пояснением.
9. Что точно не нужно в первой версии.
10. Желаемый срок и вилка бюджета.

Как вилка бюджета превращается в смету и что на неё влияет сильнее всего, мы разобрали в статье из чего складывается цена сайта, а базовые цены по видам работ — от 24 000 ₽ за лендинг до 160 000 ₽ за веб-приложение — собраны на странице цен. Точную сумму для вашего проекта называем после брифа и фиксируем в спецификации к договору.

Короткие ответы на частые вопросы

Обязательно ли заказчику самому писать техническое задание на сайт?

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

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

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

Что самое важное написать в ТЗ, если опыта нет?

Цель сайта и целевое действие посетителя (заявка, покупка, запись), список страниц или экранов, куда должны уходить заявки и какие системы нужно подключить. Этого достаточно, чтобы исполнитель назвал срок и цену и предложил остальное.

Зачем в ТЗ раздел «что не входит в работы»?

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

Можно ли поменять ТЗ после начала работ?

Можно, но это меняет объём, а значит и цену или срок. В типовых договорах Roboweb цена фиксированная, а объём меняется только по соглашению сторон отдельным документом.

Услуги и кейсы по теме: бриф проекта онлайн · заказная разработка · типовые договоры с ТЗ