Техническое задание на разработку сайта: как составить, чтобы оценка не поплыла

Техническое задание на разработку сайта редко пишут ради формальности — к нему обычно приходят после того, как договорённость «на словах» привела к спору. Заказчик считал, что в объём входит форма обратной связи с валидацией и уведомлением на почту, подрядчик — что достаточно поля и кнопки «Отправить». Формально оба правы, потому что нигде не зафиксировано, что значит «форма обратной связи». ТЗ существует, чтобы такие расхождения всплывали до старта работ, а не на приёмке.

Зачем нужен документ, если и так примерно понятно, что делать

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

Из чего состоит техническое задание на разработку сайта

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

Цель и задачи сайта

Раздел отвечает на вопрос, зачем сайт нужен бизнесу, а не что на нём должно быть технически. «Сайт для лидогенерации в сфере B2B-услуг» — это цель. «Увеличить конверсию заявок с 1,5% до 2,5%» — уже задача, которую можно сверить с результатом. Без этого раздела дизайнер и разработчик оптимизируют сайт под собственные представления о «хорошо».

Аудитория и сценарии использования

Кто приходит на сайт и зачем — с телефона в поиске конкретной услуги, с десктопа сравнивая подрядчиков, повторно за прайсом. У каждого сценария свой путь: что человек видит первым, куда кликает, что происходит, если он передумал на середине формы. Раздел не обязан быть длинным, но должен покрывать 2–4 реальных сценария, а не абстрактного «пользователя».

Карта страниц

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

Функциональные требования по каждому блоку

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

Требования к контенту

Кто готовит тексты и изображения, в каком формате и до какого этапа их нужно передать. Отдельно стоит зафиксировать объём: количество карточек услуг, длину описаний, наличие фото или заглушек на старте. Без этого раздела разработка часто стоит из-за того, что вёрстка готова, а контента для неё нет.

Интеграции

CRM, платёжный шлюз, рассылка, аналитика, чат — для каждой важно указать не «нужна интеграция с CRM», а конкретно с какой, что передаётся (только контакт или вся переписка) и кто отвечает за настройку на стороне CRM.

Нефункциональные требования

Скорость загрузки, корректное отображение на мобильных экранах, базовая защита от спама и распространённых уязвимостей — то, что не видно на скриншоте макета, но определяет, будет ли сайт работать в реальных условиях. Формулировать стоит в измеримых величинах: не «сайт должен быстро грузиться», а конкретный порог по времени загрузки на мобильной сети.

Доступы и хостинг

Кто владелец домена и хостинга, куда разворачивается сайт, кому передаются административные доступы после сдачи. Раздел кажется формальностью, пока не выясняется, что домен оформлен на подрядчика, а не на заказчика.

Критерии приёмки

Список проверяемых условий, при выполнении которых работа считается принятой. Разбираем подробно ниже — это единственный раздел, из-за нехватки которого чаще всего срывается сдача проекта.

Пример технического задания на разработку сайта: как расплывчатое требование становится проверяемым

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

Проведём её через разделы структуры:

• Функциональные требования. Поля: имя, телефон (обязательно, маска +7), комментарий. Валидация телефона на клиенте и сервере. При успешной отправке — «Заявка отправлена» без перезагрузки страницы.

• Контент. Текст под формой: «Ответим в течение рабочего дня». Текст ошибки для каждого поля отдельно, а не общее «Заполните форму верно».

• Интеграции. Заявка уходит в CRM клиента через API (name, phone, comment, source) и дублируется письмом на email в течение 1 минуты.

• Нефункциональные требования. Ответ сервера — не дольше 2 секунд при нормальной нагрузке.

• Критерии приёмки. Заявка с корректными данными доходит до CRM и почты за отведённое время; форма с некорректным телефоном не отправляется и показывает ошибку; форма проверена в Chrome, Safari и на экране 375 px.

Вместо одной фразы — пять конкретных пунктов, каждый из которых можно либо выполнить, либо не выполнить.

Почему критерии приёмки важнее всего остального раздела

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

Формулировать критерии стоит так, чтобы результат не зависел от того, кто проверяет:

• избегать оценочных слов — «удобно», «быстро», «современно» — без числа или сценария за ними;

• привязывать к действию: «заявка появляется в CRM в течение минуты», а не «форма работает корректно»;

• указывать устройства и браузеры проверки явно, а не полагаться на «стандартный набор»;

• разделять критерии по блокам, а не писать один общий пункт «сайт работает без ошибок» на весь проект.

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

Создание технического задания на разработку сайта: кто и когда этим занимается

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

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

Техническое задание на разработку дизайна сайта

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

Частые вопросы

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

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

Можно ли обойтись без технического задания, если сайт небольшой

Формально можно, но риск тот же, что и на крупном проекте, просто в меньшем масштабе. Даже для лендинга полезно письменно зафиксировать карту блоков и критерии приёмки — споры о том, «что входило в объём», возникают независимо от размера сайта.

Что делать, если требования меняются в процессе разработки

Это нормальная ситуация, а не провал ТЗ. Изменения фиксируются дополнением к исходному документу с указанием, как они влияют на сроки и стоимость — проблема возникает не от самого изменения, а когда его вносят устно и нигде не фиксируют.

Чем ТЗ отличается от коммерческого предложения

КП описывает, что вы получите и по какой цене, в общих чертах, для выбора подрядчика. ТЗ — рабочий документ для команды, которая делает сайт, с детализацией, достаточной для оценки трудозатрат и приёмки. КП обычно предшествует ТЗ, а не заменяет его.

Есть готовое ТЗ и нужен просчёт, или документ ещё предстоит составить? Опишите задачу — посмотрим, чего в ней уже хватает, а чего нет.