Техническое задание (ТЗ) — это документ, который описывает, каким должен быть сайт. Без него разработка превращается в угадывание: исполнитель делает одно, заказчик ожидает другое. В итоге — переделки, задержки и перерасход бюджета.
Хорошее ТЗ не требует технических знаний. Оно требует ясности. Эта статья покажет, что включить в ТЗ и как описать требования понятным языком.
Что будет без ТЗ
Результат предсказуем:
- Размытые ожидания. Вы представляли одно, разработчик сделал другое. Оба правы, потому что договорённости не было
- Бесконечные правки. «А давайте ещё добавим...» — каждая такая фраза без ТЗ стоит денег и времени
- Срыв сроков. Без чёткого объёма работы невозможно назвать реальный срок
- Конфликты. Заказчик думает, что это входит в проект. Разработчик думает, что нет. ТЗ снимает этот вопрос
ТЗ — это не бюрократия. Это ваша защита. Документ, к которому обе стороны могут обратиться в случае разногласий.
Структура хорошего ТЗ
1. Цели проекта
Самый важный раздел. Ответьте на вопросы:
- Зачем вам сайт? Собирать заявки? Продавать товары? Информировать клиентов?
- Какой результат вы ожидаете? 50 заявок в месяц? Онлайн-продажи? Имидж компании?
- Как вы будете измерять успех? Количество заявок, звонков, продаж
Пример: «Нужен сайт для стоматологической клиники. Цель — получать 30-50 заявок на запись в месяц через форму на сайте и кнопку звонка.»
2. Целевая аудитория
Опишите, кто будет пользоваться сайтом:
- Кто ваши клиенты? Возраст, пол, доход, местоположение
- С каких устройств они заходят? (В Узбекистане 70-80% трафика — мобильные)
- Что для них важно при выборе? Цена, качество, скорость, отзывы
- На каком языке они говорят? Русский, узбекский, оба
3. Структура сайта
Перечислите страницы, которые нужны. Не обязательно рисовать схему — просто список.
Типичная структура бизнес-сайта
- Главная страница
- Услуги (или каталог товаров)
- О компании
- Портфолио / Кейсы
- Контакты
- Блог (опционально)
- Страница «Спасибо» (после отправки формы)
Для каждой страницы опишите: что на ней должно быть и какую задачу она решает.
4. Функциональность
Что сайт должен уметь делать? Опишите действия, а не технологии:
- Форма заявки — какие поля: имя, телефон, email, сообщение
- Куда приходят заявки — на email, в Telegram, в CRM
- Калькулятор — если нужен расчёт стоимости на сайте
- Каталог — фильтры, сортировка, поиск
- Корзина и оплата — для интернет-магазинов
- Мультиязычность — переключение языков
- Личный кабинет — если пользователям нужна авторизация
Не знаете, нужна ли функция? Напишите «обсудить» — разработчик поможет решить.
5. Интеграции
С какими сервисами сайт должен работать:
- CRM-система — Bitrix24, AmoCRM, другая
- Платёжные системы — Click, Payme, Uzum
- Мессенджеры — кнопки WhatsApp, Telegram
- Аналитика — Google Analytics, Яндекс.Метрика
- Карты — Google Maps, Yandex Maps
- Социальные сети — виджеты, кнопки «Поделиться»
6. Дизайн и визуальные ориентиры
Вы не обязаны быть дизайнером. Но помогите разработчику понять ваш вкус:
- Примеры сайтов, которые нравятся. Дайте 3-5 ссылок и объясните, что именно нравится: стиль, цвета, структура, анимации
- Примеры, которые не нравятся. Это тоже полезно
- Брендбук. Если есть логотип, фирменные цвета, шрифты — приложите файлы
- Фотографии. Есть ли свои фото или нужны стоковые?
«Хочу современный, минималистичный сайт как у Apple» — это нормальное описание. Оно лучше, чем ничего. Но ещё лучше — конкретные ссылки с пояснениями.
7. Контент
Кто пишет тексты для сайта?
- Вы предоставляете тексты. Укажите, к какому сроку
- Разработчик пишет тексты. Это отдельная работа и отдельная стоимость
- Тексты будут позже. Сайт можно сделать с макетными текстами, но запуск затянется
8. Сроки и бюджет
Укажите реалистичные ожидания:
- Когда нужен сайт? Через 2 недели, месяц, 3 месяца
- Есть ли жёсткий дедлайн? Запуск продукта, мероприятие, сезон
- Какой бюджет? Даже приблизительный диапазон помогает — разработчик подскажет, что возможно в этих рамках
Чего не нужно писать в ТЗ
- Технические детали реализации. «Использовать React с серверным рендерингом» — это решение разработчика, не заказчика
- Точные размеры в пикселях. «Кнопка 200x50 пикселей» — это задача дизайнера
- Переписку из чатов. ТЗ — это структурированный документ, а не скриншоты сообщений
- Требования без контекста. «Сделать красиво» — у каждого своё «красиво». Дайте примеры
Шаблон: минимальное ТЗ на одной странице
Быстрый шаблон
- Компания: название, сфера деятельности, город
- Цель сайта: зачем он нужен, какой результат ожидаете
- Аудитория: кто будет пользоваться
- Страницы: список нужных страниц
- Функции: формы, каталог, калькулятор, оплата
- Интеграции: CRM, платёжные системы, мессенджеры
- Дизайн: 3-5 ссылок на сайты, которые нравятся
- Контент: кто пишет тексты, есть ли фото
- Сроки: когда нужен сайт
- Бюджет: примерный диапазон
Этого достаточно для первого разговора с разработчиком. Дальше ТЗ будет уточняться совместно.
Как CONURA работает с ТЗ
Мы не требуем от клиента 50-страничный документ. Наш процесс:
- Бриф. Вы заполняете короткую анкету или рассказываете на созвоне, что нужно
- Мы формируем ТЗ. На основе вашего брифа мы создаём структурированное ТЗ с описанием страниц, функций, интеграций
- Вы утверждаете. Читаете, вносите правки, согласовываете
- Начинаем разработку. По утверждённому ТЗ, с понятными сроками и стоимостью
Вы тратите 30 минут на бриф — мы берём на себя остальное. ТЗ — это наша ответственность. Ваша задача — рассказать о бизнесе и целях.