ТЗ помогает договориться о результате до старта разработки. Оно фиксирует, что именно вы покупаете. Оно снижает риск переделок и лишних часов.
В этой статье разберём основу. Зачем нужно ТЗ, как начать, как поставить границы проекта, как описать структуру и как формулировать функциональные требования так, чтобы они помогали считать смету, а не раздували её.
Техническое задание не обязано быть сотней страниц. Но оно должно закрыть две вещи: что вы делаете в первом релизе и как вы поймёте, что сайт готов.
Зачем сайту нужно ТЗ и что оно фиксирует на старте
Техническое задание переводит ожидания бизнеса в понятные требования. Вы фиксируете цель сайта, состав страниц, функции, интеграции, контент, правила приемки. Подрядчик фиксирует объём работ и ограничения. Так вы получаете документ, по которому удобно считать смету и проверять результат.
ТЗ не обязано быть сотней страниц. Но оно должно закрыть две вещи. Что вы делаете в первом релизе. И как вы поймёте, что сайт готов.
Какие риски возникают без зафиксированных требований
Без ТЗ вы начинаете обсуждать детали уже в процессе. Это почти всегда дороже. Дизайн меняется, потому что нет референсов и критериев. Структура плавает, потому что цель сайта не определили. Функции добавляются, потому что их вспомнили в середине разработки.
Ещё один частый риск — это скрытые зависимости. Например, вы планировали простую форму заявки, а потом выясняется, что нужна передача лидов в CRM, уведомления в мессенджер и защита от спама. Если вы не зафиксировали это на старте, смета растёт, а сроки сдвигаются.
Чем ТЗ отличается от договора и коммерческого предложения
Коммерческое предложение показывает цену и состав работ в общем виде. Оно помогает выбрать подход. Но оно редко раскрывает поведение сайта по шагам.
Договор фиксирует юридические условия. Он отвечает за сроки, оплату, ответственность и порядок сдачи. Но договор не должен описывать каждый экран и каждую ошибку формы.
ТЗ описывает продукт. Оно отвечает на вопрос, что именно будет на сайте и как это работает. Договор обычно ссылается на ТЗ как на приложение. Так вы связываете юридическую часть и конкретный результат.
Кто участвует в подготовке ТЗ со стороны бизнеса и подрядчика
Со стороны бизнеса обычно нужен человек, который отвечает за результат. Часто это собственник, директор или руководитель маркетинга. Ему важно сформулировать цель, приоритеты и ограничения по бюджету и срокам.
Ещё нужен тот, кто знает процессы. Например, менеджер продаж, администратор клиники или руководитель отдела поддержки. Он подскажет, какие вопросы задают клиенты и где теряются заявки.
Со стороны подрядчика в подготовке ТЗ участвуют менеджер проекта, аналитик и UX-специалист. Иногда подключается дизайнер и разработчик, если проект сложный. Их задача — уточнить сценарии, снять противоречия и описать требования так, чтобы их можно было реализовать и проверить.
С чего начать подготовку ТЗ до описания страниц и функций
Не начинайте с меню и блоков. Начните со смысла. Сайт — это инструмент. Если вы не понимаете, для чего он нужен, вы не сможете отсечь лишнее.
На старте вам нужен короткий набор вводных. Цель, аудитория, сценарии выбора, референсы. Это основа, на которой потом строятся структура, функции и дизайн.
Цель сайта и одно главное целевое действие
Сформулируйте одну главную цель сайта. Не десять. Одну. Например, оставить заявку на расчёт, записаться на консультацию, позвонить, оформить заказ.
Дальше зафиксируйте одно главное целевое действие. Это то, что вы хотите получить от пользователя чаще всего. Оно влияет на структуру, тексты и дизайн. Если главный шаг — это заявка, вы строите путь к форме. Если главный шаг — это покупка, вы строите путь к корзине и оплате.
Проверьте цель на простом вопросе. Что должно произойти, чтобы вы сказали, что сайт работает. Если ответа нет, ТЗ начнёт расползаться.
Аудитория и сценарии: как люди принимают решение
Опишите 2 или 3 ключевых сегмента аудитории. Не по возрасту. По задаче и мотиву. Кто эти люди и зачем им ваш сайт.
Дальше опишите сценарии. Коротко и по шагам. Например, такой путь.
- Человек ищет услугу в Алматы
- Заходит на сайт со смартфона
- Сравнивает цены и сроки
- Смотрит примеры работ
- Задаёт вопрос в мессенджере
- Оставляет заявку
Сценарии помогают понять, какие страницы нужны, какие блоки важны и где ставить призывы к действию. Они также помогают описывать поведение сайта в функциональных требованиях.
Референсы и антипримеры, чтобы убрать субъективность
Соберите 3 или 5 референсов. Укажите, что именно вам нравится. Не пишите просто «нравится дизайн». Пишите конкретно. Например, короткий первый экран, понятная форма, структура услуг, подача кейсов, стиль иллюстраций.
Добавьте 2 или 3 антипримера. И тоже объясните почему. Например, много текста без смысла, сложное меню, мелкие кнопки на мобильном, навязчивые попапы.
Референсы убирают споры на этапе дизайна. Они экономят время. И они снижают риск переделок.
Границы проекта, чтобы смета не раздувалась
Границы проекта — это главный инструмент контроля бюджета. Вы выбираете, что делаете сейчас, а что позже. И фиксируете это письменно. Без этого любая идея превращается в задачу, а любая задача — в счёт.
В ТЗ важно разделить первый релиз и развитие. И прописать, как вы будете работать с изменениями.
Что входит в первый релиз и что откладываем
Составьте список функций и разделов. Разбейте его на две группы. Первый релиз и «потом».
В первый релиз включайте то, что напрямую ведёт к главному целевому действию. Остальное переносите в развитие. Например, блог, личный кабинет, сложные фильтры, интеграции второго уровня, мультисклад, расширенная аналитика.
Такой список помогает считать смету честно. И помогает не спорить в середине проекта, почему чего-то нет.
Как описать MVP без потери смысла
MVP — это минимальная версия, которая решает основную задачу. Она не должна быть сырой. Она должна быть простой.
Опишите ядро. Какие страницы и функции нужны, чтобы пользователь дошёл до целевого действия. Например, такой набор.
- Главная
- Услуги
- Цены или пакеты
- Кейсы или портфолио
- Контакты
- Форма заявки
- Базовая админка для правок
Если сайт должен собирать заявки, MVP не требует сложной анимации и десятков уникальных страниц. Он требует ясного оффера, понятной структуры и рабочих форм.
Правила работы с изменениями: версионирование и согласование
Изменения будут всегда. Важно не запрещать изменения, а управлять ими.
Зафиксируйте правило. Любое изменение вы оформляете как отдельную правку. Вы описываете, что меняется и зачем. Подрядчик оценивает влияние на сроки и стоимость. Вы согласуете. И только потом задача уходит в работу.
Так вы не платите за хаос. И вы не спорите на приемке, что входило в объём.
Структура сайта и типовые страницы: что описывать в ТЗ
Структура отвечает за путь пользователя. Она показывает, как человек найдёт нужную информацию и как дойдёт до заявки. В ТЗ структура должна быть понятной и проверяемой. Лучше всего работает карта сайта и набор шаблонов страниц.
Карта сайта и логика навигации
Составьте карту сайта. Это список разделов и страниц в иерархии. Она помогает увидеть лишнее и недостающее.
Дальше опишите навигацию. Как человек попадёт на ключевые страницы. Через меню, через блоки на главной, через внутренние ссылки, через футер.
Если у вас много услуг, зафиксируйте правило. Как вы группируете услуги. Как называете страницы. Как делаете хлебные крошки. Это помогает избежать путаницы и дублей.
Шаблоны страниц и блоки на странице
Не нужно расписывать каждую страницу как уникальную. Опишите типовые шаблоны.
Обычно бизнесу хватает нескольких типов. Главная, страница услуги, страница о компании, кейсы или портфолио, контакты, статья блога, политика конфиденциальности.
Для каждого шаблона перечислите блоки. Например, для страницы услуги.
- Первый экран с оффером и кнопкой
- Описание проблемы и решения
- Этапы работы
- Примеры или результаты
- Частые вопросы
- Форма заявки
- Контакты
Такой подход ускоряет дизайн и разработку. И делает смету предсказуемее.
Формы заявки и контактные сценарии
Формы часто выглядят просто. Но именно они ломают конверсию, если их не продумали.
Опишите, какие формы нужны. Где они стоят. Какие поля в них есть. Что происходит после отправки. Какой текст видит пользователь. Куда уходит заявка.
Опишите контактные сценарии. Например, звонок, WhatsApp, Telegram, email. Укажите, на каких страницах вы хотите показывать быстрые контакты. И как вы будете считать эти обращения в аналитике.
Функциональные требования: как описывать поведение сайта
Функциональные требования отвечают на вопрос, что делает сайт после действий пользователя и администратора. Здесь важно писать не общими словами, а сценариями. Что нажали. Что увидели. Что сохранилось. Что отправилось.
Если функционал типовой, описания всё равно нужны. Они помогают избежать разного понимания даже в простых вещах.
Пользовательские роли и доступы, если они нужны
Если сайт только витрина, ролей может не быть. Но если есть личный кабинет, закрытый контент или разные уровни доступа в админке, роли надо описать.
Перечислите роли. Например, администратор, контент-менеджер, модератор. Укажите, что каждый может делать. Что может редактировать. Что не может видеть.
Роли влияют на стоимость, потому что они требуют логики доступа и тестирования.
Сценарии и состояния ошибок: что происходит после действия
Опишите сценарии действий. Для форм, поиска, фильтров, записи, оплаты, если они есть.
Для каждого сценария опишите состояния.
- Успех
- Ошибка
- Пустой результат
- Повторная отправка
- Таймаут
Пример для формы. Пользователь заполнил поля и нажал отправить. Сайт показывает сообщение об успешной отправке. Сайт отправляет уведомление ответственному. Если поле заполнено неверно, сайт показывает подсказку. Если сервер не отвечает, сайт показывает понятную ошибку и предлагает повторить.
Такие сценарии экономят время на тестировании и правках.
Админка: кто и как управляет контентом
Опишите, кто будет обновлять сайт. И что именно он будет менять.
Перечислите сущности контента. Страницы, услуги, новости, кейсы, сотрудники, отзывы, вакансии, если они есть.
Укажите, какие поля нужны. Заголовок, текст, фото, SEO-поля, порядок сортировки, статус публикации.
Если вы хотите, чтобы сайт можно было вести без разработчика, зафиксируйте это как требование. Удобная админка снижает стоимость владения, потому что вы реже платите за мелкие правки.
Интеграции и внешние сервисы, которые чаще всего забывают
Интеграции почти всегда всплывают поздно. В начале кажется, что достаточно сайта и формы. Потом появляются требования от продаж, бухгалтерии и маркетинга. И это сразу влияет на смету.
В ТЗ лучше перечислить все внешние системы. Даже если часть из них вы подключите после запуска. Тогда подрядчик заложит правильную архитектуру и не будет переделывать формы, админку и уведомления.
CRM, телефония, мессенджеры и почта
Если вы ведёте лиды в CRM, зафиксируйте это сразу. Опишите, куда должна уходить заявка. Какие поля передаются. Как вы отмечаете источник обращения.
Если у вас есть звонки, добавьте телефонию как канал. Опишите сценарий. Пользователь нажал на номер на мобильном. Вы фиксируете звонок как обращение. Менеджер видит, откуда пришёл контакт.
Если вы общаетесь в WhatsApp или Telegram, укажите, что нужно. Кнопка с быстрым переходом. Виджет чата. Уведомление о заявке в нужный чат. Это разные задачи. Они по-разному влияют на сроки.
По почте зафиксируйте минимум. На какие адреса уходят уведомления. Нужна ли копия клиенту. Нужны ли шаблоны писем. Нужны ли разные письма для разных форм.
Платежи, доставка, карты и уведомления
Если сайт принимает оплату, опишите сценарий до деталей. Что продаём. Как формируется сумма. Нужна ли корзина. Нужны ли статусы оплаты в админке. Что видит пользователь после успешной оплаты и после ошибки.
Если вы планируете доставку, не пишите просто «доставка». Уточните, что именно нужно на первом релизе. Расчёт стоимости. Выбор города. Выбор интервала. Трекинг статуса. Связка с внешней службой. Каждая опция увеличивает объём работ.
Карты часто кажутся мелочью. Но и они требуют требований. Одна точка на контактах или несколько филиалов. Нужен ли поиск по адресу. Нужна ли логика построения маршрута.
Уведомления тоже важны. SMS, email, мессенджеры. Опишите, какие события должны их запускать. Заявка отправлена. Запись подтверждена. Заказ оплачен. Менеджер не обработал лид за N минут. Если это не описать, уведомления начнут додумывать уже в ходе разработки.
Аналитика: события и цели, которые должен передавать сайт
Без аналитики вы не поймёте, где сайт теряет клиентов. Поэтому в ТЗ зафиксируйте, что именно вы измеряете.
Перечислите целевые действия. Отправка формы. Клик по телефону. Клик в мессенджер. Переход в корзину. Оплата. Скачивание прайса, если оно есть.
Для каждого действия опишите событие. Что считать успешным. Например, не нажатие кнопки «отправить», а появление сообщения об успешной отправке.
Зафиксируйте, где вы смотрите данные. Какие доступы нужны. Кто отвечает за проверку в день запуска. Это простые пункты, но они часто экономят недели споров после релиза.
Услуга по теме
Поможем собрать ТЗ, спроектировать структуру и посчитать сайт без сюрпризов
Уточняем цель и целевое действие, описываем первый релиз, формы, интеграции и критерии приемки. На выходе — структура, прототипы и понятная смета, по которой видно, за что вы платите.
Дизайн и контент: как описать без слов «красиво» и «современно»
Дизайн невозможно проверить словами «красивый» и «современный». Эти слова ничего не фиксируют. В ТЗ лучше описать конкретные входные данные и правила. Тогда подрядчик делает дизайн быстрее, а вы принимаете его спокойнее.
Контент тоже влияет на сроки и бюджет. Если контента нет, сайт не выглядит готовым. И проект зависает на финальном шаге.
Бренд-материалы, типографика и правила для интерфейса
Соберите всё, что у вас уже есть. Логотипы в нужных форматах. Фирменные цвета. Шрифты. Примеры презентаций. Гайд по тону коммуникации, если он есть.
Если у вас нет брендбука, зафиксируйте минимум. Основной цвет. Дополнительные цвета. Стиль фото. Стиль иконок. Принцип по кнопкам и ссылкам. Принцип по заголовкам и тексту.
Добавьте референсы из первой части ТЗ. Они заменяют субъективность. И они помогают согласовать дизайн не по вкусу, а по заданным ориентирам.
Адаптивность и требования к доступности
Сайт почти всегда смотрят с телефона. Поэтому в ТЗ зафиксируйте, что вы принимаете проект по адаптивным версиям. Укажите ключевые страницы, которые вы точно проверяете на мобильном.
Добавьте требования к доступности на уровне здравого смысла. Читаемый текст. Контрастные кнопки. Понятные состояния ошибок у форм. Видимый фокус у активных элементов. Это влияет и на UX, и на доверие.
Кто готовит тексты, фото, видео и в каком формате
Определите ответственного за контент. Кто пишет тексты. Кто подбирает фото. Кто согласует юридические документы.
Опишите объём. Какие страницы должны быть заполнены на запуске. Какие можно оставить с временным наполнением. Если вы хотите запуск под ключ с контентом, зафиксируйте это как отдельную задачу.
Зафиксируйте форматы. Логотип в векторе. Фото в хорошем качестве. Видео с понятными ссылками и правами. Чем точнее входные данные, тем меньше переделок на этапе вёрстки.
Нефункциональные требования, которые влияют на стоимость и сроки
Нефункциональные требования не про блоки и кнопки. Они про то, как сайт работает технически. Скорость, безопасность, SEO-база. Эти пункты редко видно на макете. Но именно они часто увеличивают смету, если всплывают в конце.
Скорость загрузки и требования к производительности
Опишите ожидание по скорости как требование к результату. Не пишите просто «быстрый сайт». Укажите, что вы будете проверять скорость после запуска и на каких страницах.
Если у вас планируется большой каталог или много медиа, сразу скажите об этом. Это влияет на архитектуру, хранение файлов и оптимизацию.
Если вы планируете рост нагрузки, тоже зафиксируйте это. Даже без точных цифр. Подрядчик должен понимать, что вы не делаете сайт только для визитки, а готовите площадку для развития.
Безопасность, резервные копии и права доступа
Зафиксируйте базовую безопасность. HTTPS на всех страницах. Разграничение доступов в админке. Сильные пароли и правила хранения доступов внутри команды.
Добавьте требование по резервным копиям. Как часто делаются бэкапы. Кто их хранит. Как проходит восстановление. Это часть стоимости владения. И лучше решить её на старте, чем после первой проблемы.
Если сайт собирает персональные данные через формы, зафиксируйте, что должны быть нужные страницы и чекбоксы согласия. И что формы не должны отправляться без согласия, если вы так решите.
SEO-база: адресация, индексация, редиректы, карта сайта
SEO начинается не с текстов. Оно начинается с адресов страниц, индексации и технической чистоты.
В ТЗ опишите правила URL. Понятные адреса. Логичная структура. Единый формат для услуг и статей, если блог есть.
Опишите, что должно быть на старте. Файл robots.txt. Файл sitemap.xml. Корректные редиректы при изменениях. Страница 404. Это простые вещи. Но без них сайт теряет видимость и трафик, а исправления после релиза стоят дороже.
Если у вас уже есть старый сайт, добавьте пункт про перенос страниц. Какие URL нужно сохранить. Какие нужно перенаправить. Это защищает от потери уже набранных позиций и сохранённых ссылок.
Приемка и критерии готовности: как проверить результат
Приемка защищает бюджет так же, как и границы проекта. Если вы не описали, как проверяете сайт, вы будете спорить на ощущениях. ТЗ должно давать понятный чек-лист. Тогда и вам, и подрядчику проще закрыть проект.
Чек-лист тестирования на разных устройствах и браузерах
Составьте список, что вы проверяете на приемке. Главные страницы. Страницы услуг. Формы. Контакты. Политики. Страницы ошибок.
Опишите устройства. Минимум смартфон и ноутбук. Если аудитория часто использует iPhone или Android, просто зафиксируйте, что вы проверяете оба типа.
Опишите базовые проверки. Вёрстка не ломается. Текст читается. Кнопки нажимаются. Меню работает. Ничего не наезжает и не пропадает.
Как принимать формы, интеграции и уведомления
Сделайте тестовые заявки. Проверьте, что форма отправляется. Проверьте, что пользователь видит понятный результат. Проверьте, что заявка пришла в нужное место.
Если есть интеграции, проверьте их фактами. Данные передались. Поля совпали. Источник обращения сохранился. Уведомления пришли туда, куда вы указали.
Попросите у подрядчика список тестовых сценариев. И добавьте его в ТЗ как приложение. Это упрощает сдачу и снижает риск пропустить критичную ошибку.
Как измерять качество по метрикам и фактам, а не по ощущениям
Качество сайта — это не только дизайн. Это стабильная работа и понятный путь пользователя.
Зафиксируйте метрики, которые вы можете проверить. Количество целей в аналитике. Корректность отправки форм. Отсутствие битых ссылок на ключевых страницах. Корректные редиректы, если вы переносите старые URL.
Добавьте бизнес-критерии. Например, менеджер получает заявки и видит нужные контакты. Администратор может менять контент без разработчика. Пользователь может записаться или оставить заявку с телефона без лишних шагов.
Эти критерии помогают принять сайт спокойно. И помогают не переплачивать за бесконечные вкусовые правки после релиза.
Типовые ошибки в ТЗ, из-за которых вы переплачиваете
Цена растёт не из-за жадности. Она растёт из-за неопределённости. Когда в документе мало фактов, подрядчик закладывает время на уточнения и переделки. А бизнес платит за эти часы.
Ниже ошибки, которые чаще всего превращают разумную смету в дорогой проект.
Расплывчатые формулировки и отсутствие сценариев
Фразы вроде «удобный интерфейс», «современный дизайн», «высокая скорость» не работают. Они не дают разработчику опоры. Они не дают вам критериев приемки.
Заменяйте оценки на поведение и проверку. Что пользователь делает. Что видит. Сколько шагов проходит до целевого действия. Что происходит при ошибке. Какие поля обязательны. Какие уведомления уходят.
Если вы не описали сценарии, команда начинает додумывать. Потом вы начинаете переделывать. И каждый круг стоит денег.
Неучтённые интеграции и контент в последний момент
Интеграции часто всплывают на финише. CRM, уведомления в мессенджер, почтовые шаблоны, аналитика, защита от спама. Любая такая задача тянет за собой правки форм, админки и логики.
Контент даёт тот же эффект. Если тексты и фото приходят поздно, вёрстка стоит. Дизайн приходится подгонять под реальный объём. Появляются новые блоки и новые страницы.
В ТЗ важно заранее зафиксировать список интеграций и ответственного за контент. И важно указать, что готово к старту и что предоставят позже, с конкретными сроками.
Смешивание желаний первого релиза и будущих улучшений
Частая ошибка — это вписать в первый релиз все идеи, которые когда-то пригодятся. В итоге вы платите за функции, которые не влияют на главную цель сайта сейчас.
Разделите требования на две части. Первый релиз и развитие. Для развития достаточно списка и принципов. Что вы точно хотите позже. И что важно учесть в архитектуре, чтобы не переделывать основу.
Так вы сохраняете бюджет. И не тормозите запуск из-за второстепенных задач.
Как Qazaqsoft помогает оформить требования и посчитать проект без сюрпризов
Хорошее ТЗ не начинается с кнопок. Оно начинается с задачи бизнеса. Мы помогаем перевести задачу в понятные требования. И фиксируем то, что можно реализовать и проверить.
Как проходит этап анализа и проектирования перед разработкой
Мы начинаем с анализа и планирования. Уточняем цель сайта и ключевое целевое действие. Снимаем вопросы по структуре, контенту и интеграциям. Определяем первый релиз и то, что уходит в развитие.
Дальше проектируем логику. Формируем структуру и сценарии пользователя. После этого команда может точнее оценить объём работ и сроки. И зафиксировать их в договоре.
Что должно быть на выходе: структура, прототип, критерии приемки
На выходе важно получить набор документов, по которым удобно работать и проверять результат.
- Структура сайта — понятная карта страниц и логика навигации
- Прототипы ключевых страниц — они показывают блоки и порядок смысла, а не декор
- Критерии приемки — чек-лист по формам, интеграциям, уведомлениям, адаптивности и базовой SEO-подготовке
Когда эти вещи зафиксированы, обсуждение идёт по фактам. Это снижает риск переделок и спорных трактовок.
Когда имеет смысл начать с аудита текущего сайта и процессов
Иногда проще не писать ТЗ с нуля. Проще начать с аудита.
Аудит нужен, если сайт уже есть, но не даёт заявок. Или если бизнес поменял услуги и процессы, а сайт остался старым. Или если вы планируете редизайн, но не понимаете, что именно ломает конверсию.
В таких ситуациях аудит помогает собрать требования из реальных данных и проблем. И только потом переходить к проектированию и смете.
