Техническое задание на разработку сайта. Шаблон ТЗ на разработку, который ускорит запуск и защитит бюджет

Техническое задание на сайт – это способ заранее зафиксировать договорённости. Что именно делаем, в каких пределах, какие требования считаем обязательными и как принимаем результат. Когда это прописано, студии проще оценить сроки и стоимость, а вам проще контролировать процесс и не возвращаться к одному и тому же по кругу.

Ниже – понятная схема, как собрать ТЗ со стороны клиента. Без лишней бюрократии, но с достаточной конкретикой, чтобы проект можно было честно посчитать и спокойно запустить.

Без нормального ТЗ почти всегда страдают сроки и бюджет

Когда технического задания нет или оно слишком общее, проект превращается в постоянные уточнения. Студия задаёт вопросы, вы отвечаете “на ходу”, появляются новые вводные, часть решений приходится менять после того, как уже сделана работа.

Размытые формулировки приводят к постоянным пересогласованиям. В итоге задачи растягиваются на недели, даже если сами по себе они несложные.

• Не оговорили границы работ – появляются спорные моменты, что входит в обязанности подрядчиков, а что – нет. Появляются дополнительные работы и растёт стоимость услуги. А если постоянно появляются новые подзадачи, команда вынуждена делать больше, чем планировала, и сроки сдвигаются.

• Нет правил приёмки – в конце начинаются споры, что считать готовым, а что нет. Проект формально “сдан”, но по факту требует доработок.

• Не описали интеграции и роли – сайт запускается, но работает не так, как нужно. Приходится исправлять это после релиза, обычно дороже.

Если сайт нужен для заявок или продаж, цена ошибок – это не только лишние часы разработки, а ещё и потерянные заявки в момент запуска.

В конце статьи оставили пример хорошего технического задания, дочитайте до конца.

Бриф и техническое задание: в чём разница

Бриф отвечает на вопрос: “что это за проект и зачем он нужен”. В нём обычно есть информация о компании, продукте, аудитории и целях.

Техническое задание отвечает на вопрос: “что именно делаем и как проверяем, что сделали правильно”. В нём описывают страницы, сценарии, функциональность, ограничения, интеграции и критерии приёмки.

Если вы не можете на 1–2 страницах описать, что человек должен сделать на сайте и что он получит в ответ, студия всё равно будет вытаскивать это вопросами. Лучше собрать основу заранее – тогда оценка и сроки будут точнее.

Карта технического задания: 9 блоков, которые стоит согласовать до старта

По этим пунктам важно договориться:

1. Цели и метрики
   
2. Границы работ
   
3. Структура сайта и типы страниц
   
4. Контент и материалы
   
5. Референсы
   
6. Функционал и сценарии, роли
   
7. Интеграции
   
8. Нефункциональные требования (SEO, скорость, безопасность)
   
9. Приёмка

Дальше рассказываем что именно стоит продумать в каждом блоке.

1. Цели и метрики: что вы хотите получить от сайта

Тут не нужна стратегия на десятки страниц. Достаточно ответить на три вопроса:

1. Зачем вам сайт: заявки, продажи, запись, запрос расчёта, демо.
2. Какое действие вы считаете главным. Одно основное – плюс один-два вторичных.
3. По каким признакам вы поймёте, что сайт работает. Это могут быть базовые KPI: количество заявок, конверсия формы, заявки с конкретных страниц.

Сайт “для имиджа” и сайт “для заявок” будут устроены по-разному. Лучше сразу зафиксировать цель.

2. Границы проекта: что входит в услугу подрядчика

Это один из самых важных блоков, потому что именно здесь чаще всего “уезжает” бюджет. Заранее проговорите:

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

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

3. Структура сайта (а не просто список страниц)

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

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

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

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

4. Контент: главный стоп-фактор сроков

Большинство проектов тормозится из-за контента. Поэтому в ТЗ лучше сразу зафиксировать:

• кто готовит тексты – вы, студия или совместно.
• кто согласует и сколько времени это занимает.
• в каком виде вы передаёте материалы.

Если контента пока нет, не проблема. Главное не делать дизайн “в вакууме”, чтобы потом переделывать под реальные тексты. В таком случае лучше сразу предусмотреть этап: структура смыслов и контент-план.

5. Референсы: чтобы быстрее согласовать дизайн

Референсы нужны не для того, чтобы “сделать так же”, а чтобы студия правильно считала ваши ожидания. Достаточно 3–5 примеров того, что нравится, и 2–3 примера того, что не нравится. Можно коротко подписать: что именно цепляет или раздражает – структура, шрифты, плотность контента, стиль иллюстраций. Это сэкономит недели согласований.

6. Функционал: описывайте через сценарии

Формулировка “нужна форма заявки” почти ничего не говорит. 

Гораздо полезнее описать сценарий:

• какие поля нужны и какие обязательные.
• куда отправляется заявка: CRM, почта, мессенджер.
• что видит пользователь после отправки.
• нужна ли защита от спама.
• что фиксируем в аналитике.

То же самое касается корзины, поиска, фильтров, личного кабинета. Чем понятнее сценарии, тем меньше “доработок” в конце.

7. Интеграции: “у нас есть CRM” – это не требование

Чтобы студия сделала интеграции правильно, уточните:

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

Если вы не знаете часть ответов, это нормально. Тогда нужно заранее заложить время на уточнение и согласование.

8. Нефункциональные требования: то, что дорого “догонять” после релиза

Это требования, которые редко описывают в начале, а потом за них приходится платить:

1. SEO. Если вы рассчитываете на органику, важно заранее договориться о структуре, формировании страниц, отсутствии дублей, базовой подготовке под индексацию.
2. Скорость. Уточните, какие страницы критичны и что вы считаете нормой: быстро на мобильных, стабильность при трафике, оптимизация изображений.
3. Безопасность. Формы, админка, доступы, резервные копии, обновления. Это важно даже для небольших сайтов.

9. Приёмка: чтобы не спорить в конце

В приёмке важно заранее договориться что значит “готово” именно для вашего проекта. Какие сценарии вы проверяете обязательно (заявки, оплата, поиск, фильтры, личный кабинет). Что вы получите на руки (доступы, инструкции, список настроек, рекомендации по поддержке). Это экономит много времени и нервов в конце сотрудничества.

Когда техническое задание можно сделать самому, а когда лучше вместе со студией

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

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

Часто помогает короткий созвон: вы отвечаете на вопросы по процессам и задачам, а студия превращает это в понятный план работ и критерии приёмки.

Быстрый самотест: насколько ваше техническое задание уже рабочее

Если хотите проверить себя перед стартом, ответьте на пять вопросов:

1. кто ваша аудитория и что ей важно.
2. какие страницы нужны и зачем.
3. какие интеграции будут.
4. контент готов или его ещё нужно собрать.
5. на каких языках будет сайт.

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