- зачем ТЗ нужно в первую очередь заказчику, а не подрядчику;
- из каких девяти разделов состоит рабочее техническое задание;
- как описывать функции через сценарии, а не списком пожеланий;
- что обязательно уточнить про интеграции с 1С, CRM и оплатой;
- как сформулировать приёмку и какие красные флаги искать в чужом ТЗ.
Плохое техническое задание почти никогда не выглядит плохим в момент подписания. Оно выглядит коротким и понятным: «разработать сайт компании, адаптивный, с формой заявки, с админкой». Цена этой краткости выясняется на середине проекта, когда подрядчик сделал ровно то, что написано, а заказчик представлял себе другое — и выясняется, что оба правы.
Зачем техническое задание нужно заказчику, а не подрядчику
ТЗ — это не бюрократия для студии, а способ заранее договориться о трёх вещах: что входит в работу, что считается готовым и кто платит за изменения. Без документа каждый из этих споров решается силой или деньгами.
Три конфликта, которые закрывает нормальный документ:
- «Это же само собой разумеется». Заказчик считает, что перенос текстов со старого сайта входит в работу, подрядчик — что это отдельная задача. Оба искренни. В ТЗ это одна строка, в проекте без него — неделя переписки.
- «Сайт же не работает». Без критериев приёмки «работает» — вопрос вкуса. С ними это проверяемый список: формы уходят на такую-то почту, страницы открываются за столько-то, вёрстка держится на таких-то разрешениях.
- «Мы же просили ещё вот это». Любой проект обрастает новыми хотелками. Вопрос только в том, есть ли зафиксированная граница, от которой считается «сверх ТЗ» — и, соответственно, отдельный бюджет.
Побочный, но важный эффект: документ с описанием функций и сценариев позволяет сравнить предложения разных подрядчиков. Без него вы сравниваете цифры, которые посчитаны по разным объёмам работ, и почти всегда выбираете того, кто просто меньше понял.
Девять разделов рабочего ТЗ
Для сайта достаточно девяти разделов. Ниже — что писать в каждом и какая ошибка встречается чаще всего. Государственный стандарт на ТЗ существует (ГОСТ 34.602-2020), но он про большие автоматизированные системы: для коммерческого сайта из него берут структуру, а не букву.
| Раздел | Что писать | Частая ошибка |
|---|---|---|
| Цель и задачи | Зачем сайт бизнесу, какое действие должен совершить посетитель | «Повысить имидж» — непроверяемо |
| Аудитория | Кто приходит, с каких устройств, что ищет | Пропущен, и дизайн делается «для себя» |
| Структура | Перечень страниц и их назначение | Список без вложенности и без шаблонов страниц |
| Функциональность | Формы, фильтры, калькуляторы, личный кабинет — по сценариям | Список слов вместо описания поведения |
| Контент | Кто пишет тексты и готовит фото, что переносится со старого сайта | Не указано — и проект встаёт на месяц |
| Интеграции | 1С, CRM, оплата, доставка, аналитика, телефония | Названы системы, но не сказано, что и куда передаётся |
| Требования к отображению | Разрешения, браузеры, поведение на мобильном | «Адаптивный» без конкретики |
| Приёмка | Проверяемые критерии готовности | Отсутствует, поэтому финал бесконечен |
| Порядок работ | Этапы, что сдаётся на каждом, сроки и правки | Один срок на всё, без промежуточных точек |
Отдельно про SEO: если сайт делается под поисковый трафик, требования к нему пишутся в ТЗ сразу — редактируемые заголовки и мета, человекопонятные адреса, микроразметка, карта сайта, скорость загрузки. Дописать это после сдачи почти всегда дороже, чем заложить заранее.
Как описывать функциональность: сценарии вместо хотелок
Формулировка «нужен калькулятор» ничего не значит. Рабочее описание — это сценарий: кто, что вводит, что видит на выходе, что происходит с данными и что будет при ошибке.
Сравните два описания одной функции.
Так писать не стоит
> Калькулятор стоимости на главной странице.
Подрядчик заложит поле ввода и кнопку. Заказчик ждал подбор по трём параметрам с отправкой расчёта на почту. Оба удивятся.
Так документ работает
> Калькулятор стоимости. Пользователь выбирает тип помещения (список из пяти вариантов), вводит площадь в квадратных метрах (число от 1 до 500) и выбирает срочность (два варианта). Система показывает вилку стоимости и кнопку «Получить точный расчёт». По нажатию открывается форма с полями «Имя» и «Телефон»; после отправки данные калькулятора и контакты уходят в CRM одной сделкой, пользователь видит подтверждение. При вводе площади вне диапазона — подсказка под полем, кнопка расчёта неактивна.
Второе описание занимает абзац, но снимает десяток вопросов и делает оценку сроков честной. Правило простое: на каждую функцию — кто её запускает, что вводит, что получает, куда уходят данные, что при ошибке.
Отдельным списком стоит зафиксировать, чего в проекте нет. Строка «многоязычность в первую версию не входит» экономит больше нервов, чем три страницы описания того, что входит.
Интеграции: что уточнить до подписания
Интеграции — самая частая причина срыва сроков, потому что в ТЗ их пишут одним словом. По каждой нужно знать: что передаётся, в какую сторону, как часто и кто отвечает за доступы.
Учётная система
Если на сайте будет каталог или заказы, нужно решить, что первично: номенклатура и остатки почти всегда живут в 1С, а сайт их отображает. В ТЗ фиксируется список полей обмена, направление и периодичность. Механику мы подробно разбирали применительно к автоматизации закупок — там та же логика: у каждой сущности один хозяин.
CRM
Заявка должна попадать в систему продаж, а не только на почту. В ТЗ указывается, какая CRM, какие поля создаются, что делать с дублями и что происходит, если CRM недоступна — заявка обязана сохраняться на сайте в любом случае. Если CRM ещё нет, полезно сначала разобраться с ней: как выбирать, разобрано в материале про CRM-систему.
Оплата и доставка
Указывается конкретный эквайринг и юрлицо, от которого он подключается, а также кто оформляет договор. Это административная часть, и она регулярно занимает больше времени, чем сама разработка.
Аналитика и доступы
Счётчики, цели, вебмастер. Здесь же — на чьи аккаунты всё регистрируется. Правильный ответ: на аккаунты заказчика, с выдачей доступа подрядчику. Иначе после расставания с подрядчиком вы теряете историю данных.
Приёмка: как сделать «работает» проверяемым
Критерий приёмки — это то, что можно проверить, не советуясь с автором. Не «сайт работает быстро», а «страница каталога открывается за N секунд при таком-то соединении».
Что писать в разделе приёмки:
- Функции. Список сценариев из раздела функциональности с отметкой «выполняется». Проверяется по шагам, а не на глаз.
- Отображение. Конкретные разрешения экранов и браузеры, на которых вёрстка не должна ломаться. Достаточно указать актуальные версии популярных браузеров и две-три контрольные ширины.
- Скорость. Измеримый показатель по конкретному инструменту замера и конкретным страницам — главной, каталогу, карточке.
- Данные. Заявка из каждой формы доходит до почты и CRM; тестовый заказ проходит оплату.
- Передача. Исходники, доступы, инструкция по админке, срок гарантийной поддержки и что в неё входит.
Последний пункт пропускают чаще всего, а он определяет, что будет через месяц после запуска. Гарантия должна отвечать на вопрос: исправление чего входит бесплатно (ошибки против ТЗ), а что считается новой задачей (новые пожелания).
Кто пишет ТЗ и сколько это занимает
Хорошее ТЗ пишет подрядчик на этапе аналитики, а заказчик проверяет и утверждает. Написанное только заказчиком обычно упускает техническую часть, написанное подрядчиком без интервью — бизнес-логику.
Разумное разделение: со стороны бизнеса приходят цели, процессы, ограничения и фактура; со стороны исполнителя — структура документа, техническая детализация, сценарии и оценка. Занимает это от нескольких дней до пары недель в зависимости от сложности — и это время, которое возвращается на разработке, потому что вопросы задаются до, а не во время.
Если подрядчик готов начать разработку без ТЗ и без аналитики, это не гибкость, а перенос рисков на вас: споры возникнут всё равно, но уже с потраченным бюджетом. Как устроен нормальный порядок работ, мы описали на странице процесса, а состав услуг — в разделе разработки сайтов.
Скелет ТЗ, который можно скопировать
Ниже — каркас документа. Если по каждому пункту у вас есть один-два абзаца конкретики, ТЗ готово к тому, чтобы по нему считали смету.
- Общие сведения. Компания, продукт, контакты ответственных с обеих сторон.
- Цель проекта. Что должно измениться в бизнесе, какое действие ждём от посетителя.
- Аудитория и сценарии. Кто приходит, с чем, что должен найти.
- Структура сайта. Перечень страниц с назначением и шаблонами.
- Функциональные требования. По каждой функции — сценарий по схеме «кто, что вводит, что получает, куда уходит, что при ошибке».
- Что не входит. Явный список отсечённого.
- Контент. Кто готовит тексты и изображения, что переносится, в какие сроки.
- Интеграции. По каждой: система, направление обмена, состав данных, частота, ответственный за доступы.
- Требования к отображению и скорости. Устройства, браузеры, измеримые показатели.
- Приёмка и передача. Проверяемые критерии, состав передаваемого, гарантия.
- Этапы и сроки. Что сдаётся на каждом этапе, сколько кругов правок включено.
Для сложных систем — порталов, личных кабинетов, торговых площадок — к этому добавляются роли и права доступа, требования к нагрузке и регламент резервного копирования. Такие проекты мы ведём как разработку на своей платформе, и объём аналитики там заметно больше.
Красные флаги в чужом ТЗ
Если ТЗ прислал подрядчик, документ стоит прочитать как договор — потому что он им и станет. Ниже — формулировки, которые почти гарантированно приведут к спору.
- «И другие необходимые доработки». Резиновая фраза без границ: работает в обе стороны и в итоге не работает ни для кого.
- «Дизайн в современном стиле». Непроверяемо. Должно быть: сколько макетов, сколько кругов правок, что считается принятым макетом.
- Функции одним словом. «Личный кабинет», «фильтры», «интеграция с 1С» без сценариев — это не требования, а темы для будущих переговоров.
- Нет раздела приёмки. Значит, момент окончания проекта определит тот, кто настойчивее.
- Молчание про доступы и исходники. Кому принадлежит код, где хостинг, на чьи аккаунты заведена аналитика — должно быть написано.
- Сроки без этапов. «Три месяца» без промежуточных сдач означает, что первый раз вы увидите результат в конце.
Частые вопросы
Что обычно спрашивают заказчики, когда впервые сталкиваются с необходимостью составить техническое задание на сайт.
Нужно ли ТЗ для лендинга?
В сокращённом виде — да. Хватит структуры блоков, описания форм, требований к отображению и критериев приёмки. Это две-три страницы, но они закрывают те же споры, что и большой документ.
Можно ли взять чужой образец из интернета?
Как каркас — да, как содержание — нет. Ценность документа в конкретике вашего проекта: сценариях, интеграциях и границах. Скачанный шаблон, заполненный общими словами, не защищает ни одну из сторон.
Что делать, если требования поменяются в процессе?
Это нормально и учитывается порядком внесения изменений: как оформляется новое требование, как оценивается, как влияет на срок. Важно, чтобы такой порядок был описан заранее — тогда изменение становится рабочей процедурой, а не конфликтом.
Обязательно ли следовать ГОСТу?
Для коммерческого сайта — нет. ГОСТ 34.602-2020 регламентирует ТЗ на автоматизированные системы и обязателен там, где этого требует заказчик или отраслевые правила. Для обычного сайта из него полезно взять дисциплину структуры: цели, требования, порядок работ, приёмка.
Кто владеет исходниками после сдачи?
Тот, кто указан в договоре. По умолчанию исключительные права остаются у разработчика, поэтому передачу прав и состав передаваемых материалов прописывают явно — и в ТЗ, и в договоре.