Как составить техническое задание на сайт: структура и типичные ошибки

Техническое задание — это не бюрократия, а способ договориться до того, как начались работы.
Все споры про «мы думали, это входит» решаются одним документом, написанным заранее.

Что должно быть внутри

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

Аудитория. Кто заходит, с какого устройства, что ищет. Сайт для оптовых
закупщиков и сайт для розничных покупателей устроены по-разному, хотя товар один.

Структура. Перечень разделов и типов страниц. Именно типов: каталог из тысячи
товаров — это один тип, а не тысяча пунктов.

Функции. Списком, с уточнениями. Не «личный кабинет», а что в нём: история
заказов, повторный заказ, смена данных, скачивание документов.

Интеграции. С какими системами и в какую сторону идут данные.

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

Кто пишет

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

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

Типичные ошибки

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

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

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

Нет критериев приёмки. Как проверять, что сделано: на каких устройствах,
в каких браузерах, с какой скоростью. Без этого приёмка превращается в спор о вкусах.

Что делать, если ТЗ нет и писать некому

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

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

Как проверить чужое ТЗ за двадцать минут

Если документ прислал подрядчик, пройдитесь по нему с одним вопросом: «а что будет, если
сделать это буквально?». Формулировка «сайт должен быть удобным» проверку не проходит.
«Каталог с фильтрами по цене, бренду и наличию, до 5000 товаров, время отклика фильтра
не более секунды» — проходит.

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

Кто отвечает за данные

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

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

Пример: как одна строка меняет смету

В задании написано «личный кабинет клиента». Кажется, понятно. На практике за этой строкой
может стоять просмотр истории заказов — работа на несколько дней. А может: повторный заказ
в один клик, скачивание счетов и актов, несколько сотрудников с разными правами, уведомления
о статусах, смена реквизитов с проверкой. Это уже недели.

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

Живой документ вместо камня

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

Как ТЗ связано со сметой

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

Чтобы не упираться в это постоянно, полезно заранее разделить объём на первую версию
и на развитие. Тогда новые идеи не ломают текущий этап, а спокойно ложатся в следующий.

Сколько времени это занимает

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